Numeric dates on supplier documents were ambiguous between two conventions. Assuming one silently moved documents across period boundaries in both directions.
A date written in numbers alone can name two different real days, and there is no way to tell from the date itself which was meant.
The situation
Supplier documents from a wide range of sources, each printing dates in whatever format its own system produced. Extraction captured a date for every document. Period totals were built from them.
Where the day of the month was above twelve, the reading was unambiguous. Where it was not, the extraction had silently assumed a single convention and applied it to everything.
The pattern
Two failures follow, and the second is worse than the first.
Documents move across period boundaries in both directions. A date read under the wrong convention can land months away from the true one, pulling costs into a period they do not belong to and removing others from a period that should carry them. Nothing about the resulting figure looks wrong.
A date can be captured from the wrong field entirely. Documents carry many dates — due dates, payment dates, dispatch dates, print timestamps, and the column headings of any ledger table printed on a later page. Taking the first date-shaped string on the page is wrong far more often than it appears, because the wrong answer is still a plausible date.
The controls come in two layers.
Prefer a labelled date, and rank the labels. A field explicitly marked as the document’s own date outranks a bare one. Labels indicating due, paid, dispatched or printed disqualify a candidate outright. A bare date immediately followed by transaction table headings is a column heading, not the document’s date — and the first date beneath such a heading is the oldest row of the table, which can be years away.
Refuse to guess an ambiguous date. Where two readings are genuinely possible, record both and flag the document. This is the part that takes discipline, because a flagged document is visibly unfinished while a silently guessed one looks complete.
Ambiguity is then settled from evidence rather than assumption, taking the strongest test that applies and recording which one was used:
- The document’s own stated terms against its printed due date. A payment term plus the document date must reach the due date; usually only one reading does.
- Another document from the same source with a day above twelve. A single unambiguous example fixes that supplier’s convention for everything they have ever sent.
- An annotation on the filed copy — a payment note or reference recorded when it was handled.
- A timestamp elsewhere on the same page, such as a card slip recording the same transaction.
- Reference-number order across that supplier’s documents. Only one reading keeps their numbering ascending in time. This is inference rather than a reading, and should be labelled as such when used.
What must not be used is plausibility — the season, the weather, or what feels like a sensible order of events. It is persuasive and it is not evidence. Where every test is exhausted and the date remains genuinely undetermined, leaving it unresolved is the correct outcome, not a failure.
Engineering takeaway — Refuse an ambiguous date rather than guessing it, then settle it from evidence on the documents themselves. A pipeline that always produces a date is less trustworthy than one that sometimes says it does not know.