Settling an ambiguous invoice date without guessing

A numeric date can name two real days. Six evidence tests that resolve it from the documents themselves, ranked by strength — and when to leave it unresolved.

A date written in numbers alone can name two different real days, and nothing in the date itself says which. Where the day is above twelve the reading is forced. Where it is not, there are two valid answers and most extraction processes silently pick one.

That silence is the problem, and it is worth being clear about what it costs a firm. A document dated under the wrong convention can land months from its true date, pulling a cost into a period it does not belong to while removing another from a period that should carry it. The totals still foot. Every reconciliation still ties. Nothing looks wrong at any point where anyone is looking.

The damage surfaces later, and indirectly: a period comparison that makes no sense, a client querying a month that seems light, a review where two people spend an afternoon establishing that the ledger is internally consistent and externally wrong. By then the document has been posted, approved and possibly filed, and the correction costs more than the original decision by an order of magnitude. This is the characteristic shape of an automation error that a firm should design against: cheap to prevent, expensive to detect, and silent in between.

The alternative is to resolve the ambiguity from evidence on the documents themselves. Six tests do most of the work. Take the first that applies, and record which one you used — the strength of the answer depends on it.

01 · The document’s own terms against its printed due date

The strongest test, because it is arithmetic on the document’s own figures. Where a document prints both a date and a due date, along with its payment terms, the terms plus the document date must reach the due date. Usually only one of the two candidate readings does.

The check — add the stated payment term to each candidate reading and compare against the printed due date. This settles a large share of cases outright, and requires nothing beyond the single page in front of you.

02 · Another document from the same supplier with a day above twelve

A single unambiguous example fixes that supplier’s convention for every document they have ever sent. Systems do not change their date format between invoices.

The check — group documents by supplier and look for any date in the group with a day above twelve. Where one exists, apply its convention to the whole group.

This is efficient in a way worth noticing: a supplier with many documents is very likely to have at least one unambiguous date among them, so the suppliers you have most documents for are the ones resolved most cheaply.

03 · An annotation on the filed copy

Documents that have been handled often carry a note recording when — a payment reference, a cheque annotation, a stamp. Where the annotation is close to one candidate reading and months from the other, it settles the question.

The check — read the whole page, including handwriting and stamps, not just the printed fields.

04 · A timestamp elsewhere on the same page

A card slip, a terminal receipt or a system-generated footer recording the same transaction gives a second, independently formatted rendering of the same moment. These often print the month as a word, which removes the ambiguity entirely.

The check — look for any date on the page written with an alphabetic month, at any size, anywhere. It does not have to be the invoice’s own date field to be decisive.

05 · Reference-number order across the supplier’s documents

Invoice numbers issued by a supplier rise over time. Where one candidate reading keeps a supplier’s numbering ascending in date order and the other does not, the ascending one is right.

The check — sort the supplier’s documents by number and test whether each candidate reading produces a monotonic sequence of dates.

This is inference rather than a reading, and should be labelled as such. It is reliable in practice and it is not the same kind of evidence as the tests above it.

06 · A printed sequence number that rises with time

The same logic applied to any externally issued sequential number — a ticket, a docket, a receipt number. Where the implied rate of issue under one reading is plausible and under the other is absurd, the plausible one is right.

The check — compute the implied issue rate for each reading and compare against what the issuing operation could plausibly produce.

What is not evidence

The season. The weather. What feels like a sensible order of events for the work described. Whether the date “looks about right” for the project.

All of these are persuasive and none of them are evidence. They produce confident answers with nothing behind them, which is worse than no answer at all, because a flagged document gets checked and a confidently wrong one does not.

Testing whether a supplier’s convention could be inferred from the rest of their documents is worth doing and often fails: in a mixed set, suppliers split both ways and the sample per supplier is too small to decide. Where that is the result, the honest output is that it did not resolve.

Unresolved is a valid answer

Some documents survive every test. The correct outcome for those is a flag carrying both readings and a note of what was tried — not a date.

This is the part that takes discipline, because a flagged document looks unfinished on a deliverable while a silently guessed one looks complete. The flagged one is the honest state, and it is the only one that gets a human’s attention at the point where a human could actually settle it.

A useful property of doing this properly: the flagged set is almost always small. Most ambiguity resolves on the first two tests. What remains is a short list worth a few minutes of someone’s attention, rather than a systematic error distributed invisibly across the whole period.

Running it as a procedure

The tests above are worth applying in order, and the order is not arbitrary — it runs from arithmetic on the document, through direct evidence elsewhere on the page, to inference across a supplier’s set. Each step down is weaker than the one above it, so recording which test settled a date is part of the output rather than a nicety:

1. Terms against printed due date — arithmetic on the document’s own figures. Strongest.
2. An unambiguous date from the same supplier — a day above twelve anywhere in that supplier’s documents fixes the convention for all of them.
3. An annotation on the filed copy — stamps, payment references, handwriting.
4. A second timestamp on the same page — card slips and system footers often print an alphabetic month, which removes the ambiguity outright.
5. Reference-number ordering — inference, not reading. Label it as such.
6. Sequence-number plausibility — the weakest, and only decisive when one reading is absurd.
7. Otherwise: flag it, with both readings and the tests attempted.

Two properties of this procedure make it cheap. Steps one and two settle the large majority, and both are mechanical. And step two gets stronger the more documents a supplier has sent — so the suppliers generating the most volume, which is where a systematic error would do the most damage, are the ones resolved most reliably.

Why this generalises

Ambiguous dates are a small problem that happens to be an unusually clear illustration of a general one: the difference between a system that produces answers and a system that produces answers plus the ones it could not reach.

The second kind is harder to build and much easier to trust, because its output can be reviewed proportionately. Thirty flagged items with reasons attached is a morning. Four thousand confident values, any of which might be a silent guess, is either a full re-check or an act of faith — and firms that have been through one bad automation are usually reacting to exactly this.

The same argument, applied to extraction generally, is in template OCR vs layout-aware invoice extraction.

For processes handling enough documents that this cannot be done by hand, we build these rules into invoice data entry automation: the dates it can prove, and a short exception list for the rest.