# Software-generated bibliographic entries: common errors and other mistakes to check before use

Background Story: While answering bibliography questions on this site, I often come across incorrect bibliography entries - most of the time they were automatically generated by

• Mendeley
• Journal websites
• ...

Question:

What are notorious problems of automatically generated bib entries? Which things to check before using?

To get a useful sorting please vote for the problems you often encounter / find most important (at the moment all answers are Community Wiki so it does not affect the reputation of the users).

Alphabetic list of topics:

# Author list

Some common problems:

• Are the authors' names spelled correctly? Are all accents correct? Are all language specific characters correct, i.e. ñ in Spanish, å in Nordic languages, č in Czech, and so on? Is the capitalisation correct (see also https://tex.stackexchange.com/a/386066/36296 and https://tex.stackexchange.com/a/386068/36296) ?
• Confusion between first and second names
• Confusion between what's the surname component and the given-names component. E.g., for the author named "Marco Del Negro", the author field should be written either as author = "Del Negro, Marco" or author = "Marco {Del Negro}".
• name parts like van, von, de, junior, senior are placed incorrectly
• For entries with two or more authors, failure to use the keyword and as the separator between names. For instance, the following field uses commas inappropriately:

author = {{Sudipto Bhattacharya, CAE Goodhart, Dimitrios Tsomocos},
Alexandros Vardoulakis},


It should be

author = {Sudipto Bhattacharya and C. A. E. Goodhart and
Dimitrios Tsomocos and Alexandros Vardoulakis},

• be consistent with spacing between multiple initials, e.g. sometimes they are exported as Smith, M.~L. while others do Smith, M.L., or Smith, M. L..

• Most well-written BibTeX styles and biblatex treat Smith, M. L. and Smith, M.~L. alike, so there is rarely something to be won using ~ between name initials. Smith, M.L. on the other hand will not be recognised as a name with two first name initials, but rather as only one very unusual first name "M.L.", which may be abbreviated to "M.".
• @Miguel Thanks for your input! I think it is better to merged your information with the first point. Can you please have a look at my edit if this reflects your point well enough? Please feel free to roll back if you don't like it. – samcarter_is_at_topanswers.xyz Aug 14 '17 at 19:55
• Note though that sometimes the name as written on the work itself might be missing diacritics, so in that case it is debatable whether or not to include them. Always check back with the work you cited as well as your previous knowledge. – moewe Aug 15 '17 at 6:33
• There are also plenty of cases where initials are in the form M. L. and break across lines, or use a non-breaking space character. – Chris H Aug 16 '17 at 6:47
• Braces around names can generate inconveniencies: tex.stackexchange.com/q/414685/105447. (Not sure it should be included, for I don't really know the culprit there, but I leave it here in the comments for reference). – gusbrs Feb 10 '18 at 19:14
• @gusbrs Thanks for the link! I'll wait a bit before I'll add this to the list as for me this looks more like a bug in biber/biblatex. – samcarter_is_at_topanswers.xyz Feb 10 '18 at 23:02

# Failure to treat corporate-author cases properly in author and editor fields

Consider the following three author fields:

author = {National Aeronautics and Space Administration},
author = {Bureau of Labor Statistics},
author = {International Monetary Fund},


All three are instances of "corporate" authors. The correct way to write them is

author = {{National Aeronautics and Space Administration}},
author = {{Bureau of Labor Statistics}},
author = {{International Monetary Fund}},


Without this special treatment, the first author field will be parsed as having two separate authors -- recall that and is a keyword in author and editor fields! -- called "National Aeronautics" and "Space Administration", respectively. The second author will be parsed as having "of" as the "von component" and hence a two-component surname ("Labor Statistics") and a single given name ("Bureau"). The third author would be parsed as having surname "Fund" and given names "International" and "Monetary"! Moreover, if the bibliographic entries are sorted alphabetically, the first entry would be sorted under "A" for "Aeronautics", the second under "L" for "Labor Statistics", and the third under "F" for "Fund". The correct letters would, of course, be "N", "B", and "I", respectively.

By encasing the entire name in an additional pair of curly braces, BibTeX and biber are led to believe that the authors' names have just one component (the surname component).

In many automatic data bases, corporate authors are already wrongly divided in first and last name parts, so pay attention to any stray letters. An example:

    author = {{Cherenkov Telescope Array Consortium}, T. and [...] and et al.},


where the "The" from the original author list was mistakenly interpreted as first name and abbreviated.

# Failure to treat URL strings properly

URL strings frequently are quite long, and they often contain characters -- such as &, #, \$, % and _ -- that have special meanings when parsed by TeX. URL strings should either be encased in a \url{...} wrapper (be sure to load the url and/or hyperref packages!) or placed in a field called url.

Almost all styles that support a dedicated url field accept the URL without additional markup and can interface with the url/hyperref package. URLs in the url field should not be wrapped in a \url{...} call.

url = {\url{https://openreview.net/pdf?id=tV6oBfuyLTQ}},


is wrong and should be just

url = {https://openreview.net/pdf?id=tV6oBfuyLTQ},


Sometimes one sees machine-generated URL strings in which the TeX-special characters have been prefixed with \ (backslash characters). A real-life example:

url = {http://digitalcommons.bard.edu/hm{\_}archive/180},


This is awful. Change it to

url = {http://digitalcommons.bard.edu/hm_archive/180},


especially if you intend to make the URL string usable for your readers (which, obviously, you really should intend to do).

Some export tools put the URL into the note field, if you use a style that supports a dedicated url and urldate field (biblatex styles in general do that, url is also supported by some BibTeX styles), you should use those if possible.

# Month

The syntax for month is often incorrectly exported as month = {mar}. This should be changed to

• month = mar (no braces!) or month = {3} in case you are using BibTeX

• biblatex's Biber backend is less demanding and "only" issues a warning with this syntax, nevertheless you should change it to month = {3} or better date = {1990-03} instead of year and month.

(Example taken from How can I find a bibtex entry for an article? )

• Interestingly even month = {mar} comes out OK with Biber, but there is a warning about sorting. (I'm not sure if maybe the warning is incorrect.) Biber would also accept month = mar without further complaints. But BibTeX really can't take month = {mar}. – moewe Aug 12 '17 at 16:10
• @moewe Thanks a lot for your feedback. I tried to incorporate your information into the answer, could you please check if it is given correctly and edit as you find necessary? – samcarter_is_at_topanswers.xyz Aug 12 '17 at 16:45
• @samcarter, wouldn't it be a good idea to generalize for "Date" issues? For example, most auto-generated entries come with the year, in the year field, while if you are using biblatex the date field is recommended. True, this wouldn't result in an error, but AFAIK the date will get a more general treatment, for unspecified dates and so on, while year won't. Perhaps there are other differences there, this is one I could think of. – gusbrs Aug 13 '17 at 19:44
• @gusbrs Please feel free to amend this "community wiki" answer. – samcarter_is_at_topanswers.xyz Aug 13 '17 at 19:48
• @gusbrs How about writing a new answer about the date issue? I am sure some of the bibliography experts read our answers to this questions and will comment in case they disagree with your point? – samcarter_is_at_topanswers.xyz Aug 13 '17 at 20:00

# Non-ASCII characters

This is something to be checked in basically every field. For example this title:

title={Towards a new research programme—Implications of [...]},


the insuspicious looking — will (for most setups?) cause an error, so replace it by --.

Another examples are ligatures like "fl" and "fi", spaces which just look like spaces and totally invisible characters (searching these can be really annoying!).

• A nasty case I've spotted is ligatures like "fl" and "fi", which in a monospaced font with a "helpful" editor can fall back to looking exactly the same as two characters – Chris H Sep 12 '17 at 8:56
• @ChrisH Very good point! I added it to the answer - thank you! – samcarter_is_at_topanswers.xyz Sep 12 '17 at 9:26

# Failure to treat surnames that consist of more than one word.

(This point is related to this answer.)

Consider the names "Antonio P. Garcia Pascual", "Marco Del Negro", "John Le Carré", "Helena Bonham Carter", and "Kristin Scott Thomas". What do they have in common? In all cases, the surnames have two components; hence, "Garcia", "Del", "Le", Bonham", and "Scott" are not middle names subject to truncation (or outright omission), and the authors should be sorted under "G", "D", "L", "B", and "S", respectively.

A real-life example: There is a well-known article (at least among international economists...) authored by Yin-Wong Cheung, Menzie Chinn, and Antonio Garcia Pascual. A citation call-out that shows all three names should be written as Cheung, Chinn, and Garcia Pascual, not as Cheung, Chinn, and Pascual.

Enter the authors' names as Garcia Pascual, Antonio P., Del Negro, Marco, etc. to ensure that they'll get parsed correctly.

# Incorrect entry type

Is the entry type correct? Quite often, the entry type @article is used for entries that are not pieces published in journals. Rule of thumb: If a given entry is lacking the field names journal and volume, it almost certainly shouldn't be an @article. Especially if you use biblatex you might want to watch out for differences between @book and @collection as well as @inbook and @incollection.

## Examples

### Papers only published on arXiv

inspirehep exports the following entry as @article:

@article{Wegman:2017zui,
author         = "Wegman, D.",
title          = "{Deviations of exact neutrino textures using radiative
neutrino masses}",
year           = "2017",
eprint         = "1711.08004",
archivePrefix  = "arXiv",
primaryClass   = "hep-ph",
SLACcitation   = "%%CITATION = ARXIV:1711.08004;%%"
}


while it seems that at the time I retrieved this entry (13 February 2018) the article was not (yet) published in a journal, thus @online would be more appropriate. See https://tex.stackexchange.com/a/415117/36296 for a more detailed explanation.

### PhD theses

The PhD thesis available at http://elib.suub.uni-bremen.de/diss/docs/00010668.pdf is exported by Google Scholar as

@article{lorenz2007repeated,
title={Repeated averaging and bounded confidence-modeling,
analysis and simulation of continuous opinion dynamics},
author={Lorenz, Von Jan},
year={2007},
publisher={Citeseer}
}

@TECHREPORT{Lorenz07repeatedaveraging,
author = {Von Jan Lorenz},
title = {Repeated Averaging and Bounded Confidence -
Modeling, Analysis and Simulation of Continuous Opinion Dynamics},
institution = {},
year = {2007}
}


Note the incorrect name fields author = {Von Jan Lorenz}, and author={Lorenz, Von Jan},. The author is called Jan Lorenz, presumably the "von" was added because the title page has "Repeated Averaging and Bounded Confidence: Modeling, Analysis and Simulation of Continuous Opinion Dynamics von Jan Lorenz", here "von" is the German for "by".

Furthermore, Google Scholar collapses CiteSeerX's separator between title and subtitle (␣-␣, where ␣ is a space), into - making it appear that the thesis is about bounded confidence-modeling.

Lastly, it is a bit of a stretch to list CiteSeer as the publisher here. Traditionally @article entries don't show a publisher anyway, so there is little point in including it, but CiteSeer did most certainly not publish the original thesis.

For most BibTeX styles the correct entry would probably be

@phdthesis{lorenz,
author = {Jan Lorenz},
title  = {Repeated Averaging and Bounded Confidence:
Modeling, Analysis and Simulation of Continuous Opinion Dynamics},
school = {Universität Bremen},
year   = {2007},
}


and for biblatex it would be

@phdthesis{lorenz,
author      = {Jan Lorenz},
title       = {Repeated Averaging and Bounded Confidence},
subtitle    = {Modeling, Analysis and Simulation of Continuous Opinion Dynamics},
institution = {Universität Bremen},
date        = {2007-02},
url         = {http://elib.suub.uni-bremen.de/diss/docs/00010668.pdf},
}


This example can be found in Incomplete references in Revtex.

# Ranges

for example for pages numbers, are often handled inconsistently. Sometimes they are exported as pages={1--42}, others give pages={1-42}.

There are arguments for both ways and it also depends on the used style (see moewe's comment below), but at the very least be consistent.

• As it turns out for BibTeX a single dash 1-42 is preferable. French typography for example apparently prefers a hyphen instead of an en-dash. Most styles do normalisation of ranges by adding a - to make it -- if necessary. But no style deletes -s. So the normalisation from 1-42 to 1--42 can happen automatically, while 1--42 to 1-42 does not. Of course using 1-42 means you have to modify your style if it does not apply the normalisation. – moewe May 7 '18 at 16:16
• For biblatex (with Biber) any consecutive number of dashes is replaced by \bibrangedash so the input format does not really matter. The LaTeX-side normalisation that is applied in postnote arguments also replaces - and -- by \bibrangedash. So for biblatex it does not really matter whether you write 1-42 or 1--42. – moewe May 8 '18 at 5:39

# Acronyms in titles

Acronyms in titles are error prone. Some common problems are:

• additional spaces between the letters

NASA becomes N A S A

• missing periods

H.E.S.S. becomes HESS

• wrong capitalisation

To fix the most common problem about capitalisation, enclose the respective letters in {}, e.g.

title = "Pascal, {C}, {Java}: were they all conceived in {ETH}?"


• @moewe Would you mind if I would rename this answer to "Acronyms in titles"? – samcarter_is_at_topanswers.xyz May 7 '18 at 16:22
• Not at all, I thought we might broaden the scope a bit since names and other things also need to be case-protected. – moewe May 7 '18 at 16:23
• The dot/period issue is style dependent in some cases: thoughtco.com/abbreviation-for-united-states-1691023 The question is whether the .bib file should follow the style as applied in the work cited or in the current work. – moewe May 8 '18 at 5:52

# year vs. date

Most auto-generated entries come with the year in the year field, which is probably the safest for it will work as expected in most, or probably all, scenarios.

However, if you are using biblatex the date field is recommended. Fortunately, most export tools only export a bare year and that will be treated in exactly the same way in year and date by biblatex/Biber. So, this wouldn't result in an error or in undesired results, but the date will get a more general treatment, while year won't.

For example, for unspecified dates, ranges, full dates and EDTF support, we will need date. In particular, there is no such field as day (in fact it is actively searched for and deleted by Biber), so if you need day precision, date is a must.

Hence, depending on the degree of control you expect to have on date handling, if you are using biblatex, this might be a place to check and adjust.

Also, even if year is recognized by biblatex for compatibility reasons, the same might not be the case for equivalent constructions of other dates in the data model. For example, the use of origyear instead of origdate does fool biblatex-chicago in biblatex-chicago does not print origyear with cmsdate=both.

• Fortunately though, most export tools only export a bare year and that will be treated in exactly the same way in year and date. For ranges, full dates and EDTF support, however, we will need date. A last point is that there is no such field as day (in fact it is actively searched for and deleted by Biber), so if you need day precision, date is a must. – moewe Aug 15 '17 at 6:25
• @moewe, thanks! I tried to incorporate your input to the answer. Please take a look if the changes are in accordance to what you meant. Also, if you notice something still amiss or any other improvements to be made, let me know, or please be welcome to edit directly. – gusbrs Aug 15 '17 at 10:55

# Failure to use uppercase letters

Consider the field

title={John maynard keynes and other british economists},


The failure to write this as either title={John Maynard Keynes and Other British Economists}, or, better still, title={{John Maynard Keynes} and Other {British} Economists}, (to prevent lowercasing of proper nouns) is dreadful.

Similarly, the field

journal = {The economic journal}


really should be journal = {The Economic Journal}.

• Even when they try they still often get chemistry in article titles wrong – Chris H Aug 14 '17 at 15:26

# The content of the information itself.

In my experience the reference information itself should be checked for accuracy. Missing relevant information (missing fields) or erroneous supplied information do happen, I'd say somewhat frequently.

Perhaps I'm biased in this last statement, because I rely heavily on "pre-digital era" material, but I always check... Anyway, even if less frequent in normal cases, it may be tricky, for (La)TeX/Bib(la)tex/Biber (whatever you are using) won't issue any warning or error messages for you, and the result will be much worse than a poorly formatted reference.

Case in point: As of today the authors exported by Google Books for Introduction to Apache Flink (O'Reilly, 2016) on https://books.google.de/books?id=g0RMDQAAQBAJ are

author={Friedman, E. and Ellen Friedman, M.D. and Tzoumas, K.},


A short look on the cover reveals that the correct list of authors would be

author={Friedman, Ellen and Tzoumas, Kostas},


Now this obvious error in the author list where the first author is duplicated might be easy to spot, but other errors might not be as obvious.

# Missing archivePrefix

This is something I observed on ADS, not sure if it also affects other sources, but Eprints are sometimes exported without the field archivePrefix = "arXiv". As a result of the missing prefix, the hyperlink to the preprint is build incorrectly and does not work.

One example is this paper: http://adsabs.harvard.edu/abs/2003A%26A...410..389R

(my rough estimate: about 20% of ADS preprints are effected - this is however based on the sample of papers I use for my own work and may not be representative)

(see Workaround for missing archivePrefix in bib entry for a biblatex workaround)

## HTML (including character codes)

It's common to find things like <sub>2</sub> or &#x2082; in chemical formulae and similar cases.

# Excessive bracing in title fields

The opposite of failure to use uppercase letters, related also to acronyms in titles and bracing the family name.

Some databases may apply double bracing or the functionally equivalent quote-brace combination to title fields

title = "{Sensitivity of the high altitude water Cherenkov detector
to sources of multi-TeV gamma rays}",


or

title = {{Language Change: Progress or Decay?}},


This is the WYSIWYG approach to title casing and destroys the sentence casing function of both BibTeX and biblatex.

It is preferable to only protect words that must always be written with capital letters like acronyms, names, proper nouns, ... See also BibTeX loses capitals when creating .bbl file

If you don't like the fact that your current bibliography style converts titles to sentence case that should be fixed by modifying the style so it does not apply sentence case any more or by switching to a different style altogether. Changing the .bib file is not the best option here (even if it might be the quickest).

# Excessive bracing in other fields

While it could be argued that excessive bracing in title fields is somewhat useful for a quick and dirty WYSIWYG approach, apparently certain providers (ISI Web of Science) go even further and brace all fields.

@Article{lloyd3,
author      = {Lloyd, Alison C.},
title       = {{The Regulation of Cell Size}},
journal     = {{CELL}},
year        = {{2013}},
volume      = {{154}},
number      = {{6}},
pages       = {{1194-1205}},
month       = {{SEP 12}},
issn        = {{0092-8674}},
abstract    = {{An adult animal consists of cells of vastly different size and activity,
but the regulation of cell size remains poorly understood. Recent
studies uncovering some of the signaling pathways important for
size/growth control, together with the identification of diseases
resulting from aberrations in these pathways, have renewed interest in
this field. This Review will discuss our current understanding of how a
cell sets its size, how it can adapt its size to a changing environment,
and how these processes are relevant to human disease.}},
doi         = {{10.1016/j.cell.2013.08.053}},
groups      = {cell_cycle_paper},
owner       = {nbecker},
times-cited = {{78}},
timestamp   = {2018.04.24},
unique-id   = {{ISI:000324239300010}},
}


This can cause quite astonishing error messages as demonstrated in harvard bibliography, improper alphabetic constant.

The JabRef developers have also met this particular problem and tried to contact Clarivate about it: https://twitter.com/JabRef_org/status/1012695298240442368, https://github.com/JabRef/jabref/issues/3974 ... not sure if they heard back

## The abstract or other extraneous data

While this may be useful, it's also a lot of bulk in your bib file which makes searching tedious. It's also a significant source of errors if it contains anything other than plain text, as many of the other problems discussed here can occur. (I remove this field, either manually on import or with a regex in my editor)

Keywords fields can also be problematic. They sometimes seem to be auto-generated from the title without much care for maths or escaped special characters. (I also throw these away, sometimes replacing them with my own)

I've even seen a default option to export the bibliography entry and all references, which means many times the data to check. Again, one to be avoided unless you really want them.

• Very good point about the abstract. One thing to note here is that biblatex with Biber is a lot more fussy about these things than traditional BibTeX. Unescaped special characters in abstract fields regularly cause problems for biblatex users - and because the abstract normally does not appear in the bibliography that can leave people confused. – moewe Aug 17 '17 at 18:15

# Bracing the family names

With ADS the family names are incorrectly braced.

@ARTICLE{2013APh....50...26A,
author = {{Abeysekara}, A.~U. and {Alfaro}, R. and {Alvarez}, C. and {{\'A}lvarez}, J.~D. and
{Tollefson}, K. and {Torres}, I. and {Ukwatta}, T.~N. and {Villase{\~n}or}, L. and
{Weisgarber}, T. and {Westerhoff}, S. and {Wisher}, I.~G. and
{Wood}, J. and {Yodh}, G.~B. and {Younk}, P.~W. and {Zaborov}, D. and
{Zepeda}, A. and {Zhou}, H.},
title = "{Sensitivity of the high altitude water Cherenkov detector to sources of multi-TeV gamma rays}",
journal = {Astroparticle Physics},
archivePrefix = "arXiv",
eprint = {1306.5800},
primaryClass = "astro-ph.HE",
keywords = {TeV gamma-ray astronomy, Water cherenkov, Cosmic ray},
year = 2013,
month = dec,
volume = 50,
pages = {26-32},
doi = {10.1016/j.astropartphys.2013.08.002},
adsnote = {Provided by the SAO/NASA Astrophysics Data System}
}


(also the ~ tokens are wrong). In this case, the name

{{\'A}lvarez}


will cause a bbl file prepared with Biber to fail because of unmatched braces. The braces around the family names are bad under several other respects (sorting, mainly).

See ! Paragraph ended before \name was complete for reference.

The issue is known to the developers of Biber, see issue report here, and the erroneous input should no more raise errors. The braces remain wrong nonetheless.

• +1 of course. But I think it is worth mentioning that the issue was reported and the next version of biber (2.11) should no longer result in unmatched braces and thus will not break compilation. (github.com/plk/biber/issues/210) – gusbrs Feb 13 '18 at 17:13

# Custom macros/strings

The ADS database uses custom macros for certain field values.

For common journals, a .bib entry downloaded from ADS will not contain

journal = {Monthly Notices of the Royal Astronomical Society},


or

journal = {MNRAS},


instead it will deliver a .bib file with

 journal = {\mnras},


For example 2018MNRAS.478.5556A is exported as

@ARTICLE{2018MNRAS.478.5556A,
author = {{Alger}, M.~J. and {Banfield}, J.~K. and {Ong}, C.~S. and {Rudnick}, L. and
{Wong}, O.~I. and {Wolf}, C. and {Andernach}, H. and {Norris}, R.~P. and
{Shabala}, S.~S.},
title = "{Radio Galaxy Zoo: machine learning for radio source host galaxy cross-identification}",
journal = {\mnras},
archivePrefix = "arXiv",
eprint = {1805.05540},
primaryClass = "astro-ph.IM",
keywords = {methods: statistical, techniques: miscellaneous, galaxies: active, infrared: galaxies, radio continuum: galaxies},
year = 2018,
month = aug,
volume = 478,
pages = {5556-5572},
doi = {10.1093/mnras/sty1308},
adsnote = {Provided by the SAO/NASA Astrophysics Data System}
}


In order to use this entry properly the macro \mnras must be defined in your document and it must give the correct replacement text.

The ADS FAQ and the ADS BibTeX guide list several options to get the journal macros to work. See also Undefined control sequence BibTex.

A related phenomenon is the IEEE journal abbreviation database (short journal names in IEEEabrv.bib and full names in IEEEfull.bib). I could not find a database that provides its .bib entries using these journal strings, but who knows...

And entry making use of these journal strings would look like

@ARTICLE{5937283,
author  = {P. Zhan and K. Yu and A. L. Swindlehurst},
journal = IEEE_J_AES,
title   = {Wireless Relay Communications with Unmanned Aerial Vehicles: Performance and Optimization},
year    = {2011},
month   = jul,
volume  = {47},
number  = {3},
pages   = {2068-2085},
doi     = {10.1109/TAES.2011.5937283},
}


In order to use this entry successfully in your document you would have to load either or IEEEabrv.bib or IEEEfull.bib.

# Failure to escape special characters properly

Related to Non-ASCII characters, HTML (including character codes) and in a way the opposite of Failure to treat URL strings properly.

Characters that have special meaning for TeX like %, _, #, ... must usually be escaped (see Escape character in LaTeX). There is an exception to this rule: Characters with special meaning need not be and indeed should not be escaped when they are used in verbatim fields like url, doi and eprint (cf. Failure to treat URL strings properly).

With BibTeX an error will only be raised when a field with problematic contents is actually printed (if you don't escape your %s it might even happen that no error is produced, but parts of the expected output might be missing). With biblatex an error will be raised even if the field is not printed. That error will occur directly when the .bbl file is read at \begin{document}.

A common example is the abstract field. Usually people don't notice malformed abstract contents when they use BibTeX, because hardly any styles print that field. But with biblatex the field is read even if it is not needed.

See for example Changing from natbib to BibLaTex bibliography result in major errors. An unescaped % in the abstract of https://doi.org/10.1016/j.ddmec.2008.05.004 as exported by Elsevier

@article{BURT2007293,
title = "Inheritance of colorectal cancer",
journal = "Drug Discovery Today: Disease Mechanisms",
volume = "4",
number = "4",
pages = "293 - 300",
year = "2007",
issn = "1740-6765",
doi = "https://doi.org/10.1016/j.ddmec.2008.05.004",
url = "http://www.sciencedirect.com/science/article/pii/S1740676508000369",
author = "Randall Burt",
abstract = "Inheritance is involved in up to one-third of colon cancer cases. Highly penetrant inherited syndromes account for approximately 3%, while more common, but less penetrant inherited factors play a role in the remainder. Approaches to recognizing each of these categories and syndromes, using genetic testing for diagnosis where indicated, and accomplishing proper cancer screening and surveillance will be outlined in this review."
}


would cause an

Runaway argument?
{Inheritance is involved in up to one third of colon cancer cases. Hi\ETC.
! File ended while scanning use of \field.
<inserted text>
\par
l.36 \begin{document}


error with biblatex.

It would be necessary to escape the % as in

@article{burt,
author   = {Randall Burt},
title    = {Inheritance of colorectal cancer},
journal  = {Drug Discovery Today: Disease Mechanisms},
volume   = {4},
number   = {4},
pages    = {293-300},
doi      = {10.1016/j.ddmec.2008.05.004},
date     = {2007-12},
abstract = {Inheritance is involved in up to one third of colon cancer
cases. Highly penetrant inherited syndromes account for
approximately 3\%, while more common, but less penetrant
inherited factors play a role in the remainder.
Approaches to recognizing each of these categories and
syndromes, using genetic testing for diagnosis where
indicated, and accomplishing proper cancer screening and
surveillance will be outlined in this review.},
}


Note also the corrected doi field.

I concur with The abstract or other extraneous data that the abstract field usually does more harm than good and would recommend to just delete it.

• Good point! Deleting the abstract field makes the bib file also much cleaner – samcarter_is_at_topanswers.xyz Jan 9 '19 at 15:14
• @samcarter Absolutely, for most people the abstract field is just a waste of space and a possible gateway for errors to sneak in. – moewe Jan 9 '19 at 15:15
• When I cleaned up my bib file, it was suddenly only half as long and much easier to navigate :) – samcarter_is_at_topanswers.xyz Jan 9 '19 at 15:17

# Volume vs Number

For entries like @book or @inbook, BibTeX supports both a VOLUME and a NUMBER field (but not both). The former is intended for multi-volume books (Collected works, vol. I), whereas the latter is meant for numbers in a series (Lecture notes in mathematics 269).

When pulling BibTeX references from MathSciNet (or its freely accessible lookup tool), I noticed that many (most?) books in series (Lecture notes in mathematics, Ergebnisse der Mathematik und ihrer Grenzgebiete, Mathematical Surveys and Monographs, ...) use the VOLUME field instead of NUMBER.

Especially with BibLaTeX this can lead to things like

Author, A., Book title, volume 269. Lecture notes in mathematics.

This is clearly not the desired outcome, and the reason is that the wrong field was used.

(It seems that BibTeX does not have problems with this, and I get the impression that VOLUME and NUMBER are used interchangeably for @book and @inbook entries, at leat when a SERIES is present.)