Your Reference List Has Conflicting Titles, Years, and DOIs: A Repair Workflow for Manuscripts

A reference list that disagrees with itself is a small problem with a large blast radius. One entry says the paper appeared in 2019; the DOI resolves to a 2020 version. A co-author's BibTeX file gives a slightly different title than the publisher page. A reviewer flags a citation that seems to point at two different articles. Before you resubmit, you need to know which record is authoritative, which fields are simply wrong, and which conflicts are real and must be disclosed.

This guide walks through that repair as an auditable process: start from the conflict, resolve identifiers, compare publisher-deposited metadata, correct what is demonstrably wrong, and flag what remains genuinely unresolved. The running example is a research team preparing a revised manuscript whose reference list was assembled from several co-authors' libraries.

Not every mismatch is the same problem, and treating them alike wastes time. Sort each disputed entry into one of three buckets before you touch it.

Version conflicts. The same work exists in more than one form — a preprint and a published article, an early-access version and the final issue version. Titles, years, and even author lists can legitimately differ across versions. The question is not "which is wrong" but "which version does this claim actually rest on, and which should the reference point to?"

Record errors. A field was transcribed or exported incorrectly: a typo in a title, a wrong volume, a year taken from the preprint rather than the version of record. These are correctable against an authoritative source.

Unresolved identity conflicts. Two records appear to describe the same work but cannot be reconciled from available metadata, or a DOI points somewhere that does not match the cited fields. These need to be flagged rather than silently "fixed."

Write the bucket next to each disputed entry in your working file. That single column determines what you do next.

A DOI is the most reliable starting point because it is a persistent identifier that resolves to the current destination registered for that identifier. Resolution tells you where the identifier currently points. It does not, by itself, confirm that the bibliographic fields in your reference match the work, or that the work supports the claim you cite it for.

So the sequence is:

1. Resolve the DOI and note the destination.
2. Compare the destination's title, authors, venue, and date against your entry.
3. Only then decide whether the entry is a version issue, a record error, or an identity conflict.

A DOI that resolves cleanly but to a different title than your entry is a strong signal of a record error or a version mismatch — not proof that the citation is valid. Keep the resolution result in your audit trail either way.

Crossref exposes publisher-deposited scholarly metadata through its REST API, including titles, authors, venues, dates, identifiers, licenses, funding, ORCID and ROR identifiers, abstracts when deposited, and post-publication updates from trusted sources. That makes it a useful comparison layer: you can pull the deposited record for a DOI and check your fields against it.

Two practical cautions follow from how that metadata is produced. First, it is deposited — its completeness and accuracy depend on what the publisher supplied. Second, post-publication updates from trusted sources mean a record can change over time, so a discrepancy you noted months ago may since have been corrected. Re-check before you finalize.

For each disputed entry, record: the DOI, the deposited title, the deposited date, and the deposited venue. Where your entry differs, note the difference explicitly rather than overwriting silently. That note is what makes the repair auditable.

Many conflicts originate in how the reference was found, not in the metadata itself. If a co-author found the paper through a title search and exported a citation, they may have captured a preprint, a conference version, or an alternate record.

Google Scholar documents searching by author and title, date sorting and date limits, Cited by and Related articles, citation export, library access links, email alerts, and ways to locate alternative versions of a work. The "alternative versions" capability is directly relevant here: when you suspect a version conflict, deliberately look for the other versions and compare them, rather than assuming the first record you found is the one you meant.

If you need to re-run the search itself, use a scholarly search interface and keep the query, filters, and date of the search in your notes. You can find academic papers through WisPaper's scholarly search interface and record what you searched and when, so the reconstruction is reproducible by a co-author or reviewer.

This is the decision most teams skip. A version conflict is only resolved when you know what the citation is for.

• If the claim depends on the final published analysis, cite the version of record.
• If the claim depends on something only present in a preprint — a method detail, an earlier result — cite the preprint explicitly and say so.
• If both versions support the claim, prefer the version of record and note the preprint only if the distinction matters to the reader.

Record the decision and its reason next to the entry. "Cited version of record because the claim concerns the final reported effect size" is an auditable note; a silently swapped DOI is not.

For entries in the record-error bucket, correction is mechanical once you have the deposited metadata in front of you. Fix the title, year, venue, and author list to match the deposited record, and log each change.

A few habits keep this clean:

• Change one field at a time and re-check the entry after each change.
• Keep the original value in a comment or a side column so the correction can be reviewed.
• Re-resolve the DOI after editing to confirm the entry and the identifier still agree.

If your reference list is maintained as BibTeX, a citation-screening pass can help catch entries that do not correspond to real records before you hand the file to co-authors. TrueCite checks BibTeX against real academic databases to flag hallucinated references, which is a useful first filter on a large, multi-author bibliography — after which you still compare surviving entries against deposited metadata as described above.

Some conflicts will not close. A DOI may resolve to a landing page whose metadata does not match your entry; two records may share a title but differ in authorship; a publisher record may be incomplete.

For these, the deliverable is a flag, not a guess. In your working file, record:

• the entry as it currently stands,
• what you checked (DOI resolution, deposited metadata, alternate versions),
• the specific mismatch that remains,
• and the action taken (for example, "retained original DOI; flagged for author query").

If the unresolved item affects a claim in the manuscript, raise it with the corresponding author rather than resolving it unilaterally. A flagged conflict that a reviewer can see is far better than a confident-looking citation that turns out to be wrong.

A repair that lives only in one person's notes is not reproducible. Keep the working file — entry, bucket, sources checked, changes made, residual flags — in a shared location, and organize the papers you are verifying so co-authors can inspect the same records. You can save or upload papers and organize them in the WisPaper library as the shared holding area for the versions you are comparing.

When a co-author asks a question about a specific entry, having the papers and the notes in one place shortens the loop considerably. If you need to ask questions grounded in the papers you have collected, ask questions based on papers uploaded to My Library or added from search results rather than re-reading each PDF from scratch.

For a larger revision where the reference repair is one workstream among several, the WisPaper Research Projects area gives the team a place to organize the work; create a project for the revision and keep the reference audit as one tracked component.

When the repair is done, your reference list should come with a short companion record. For the running example, that record has four parts:

1. A conflict log. Every disputed entry, its bucket, and its resolution.
2. A change log. Field-level corrections with original and corrected values.
3. A residual-flags list. Unresolved conflicts, what was checked, and who needs to act.
4. A search record. Queries, filters, and dates for any entry that was re-found.

The reference list itself is then clean: version-of-record citations where the claim requires them, explicit preprint citations where the claim depends on preprint content, corrected fields, and no silent substitutions.

• Bucket before you fix. Version conflict, record error, and identity conflict need different actions.
• Resolve, then compare. A DOI tells you where it points; it does not validate your fields or your claim.
• Treat deposited metadata as a comparison layer, not an oracle. It reflects what publishers supplied and can be updated after publication.
• Reconstruct the search. Many conflicts are search artifacts, and alternate versions are often the explanation.
• Decide by claim, not by convenience. The version you cite should be the one your sentence actually rests on.
• Flag, don't guess. An unresolved conflict recorded honestly is a finished piece of work; a fabricated resolution is not.