How accurate is AI at reading dates off receipts?

Every AI renaming tool promises to pull the date off your receipts. None of them publish how often it works. We measured ours on 15 real receipt scans, with the correct answer established by hand first. It got 8 of them right.

That number deserves context, and the context is more useful than the number: the failures are not random. They cluster in one specific place, and knowing where means knowing which of your documents to check.

How we measured it

The obvious way to run this test is also the way to get a fake result. Our test corpus had already been renamed by our own app, so every filename already contained the model's previous answer — and one of our fallbacks reads the date out of the filename when the model can't find one in the page. Measured that way, the software would have been grading its own homework.

So: 15 scans drawn at random from a corpus of 211, copied to neutral names (scan-01, scan-02…), and every one read by a human first to record what date is actually printed on the paper. Only then did the model see them. No caching, temperature zero, the same on-device 4B vision model the app ships.

The result

Nearly every failure was a two-digit year

This is the finding that matters. Every scan printing a full four-digit year — 11/26/2023, 04/13/2019 — was read correctly. The failures were almost entirely receipts printing MM/DD/YY:

• A supermarket receipt reading 07/23/18 came back as unknown.
• A restaurant check reading 12-01-18 came back as 2024-12-01 — correct day, correct month, invented year.
• A taxi receipt reading 12/02/18 came back as 12-02-18: never converted to a real date at all.

If your documents carry four-digit years, your results will look a lot better than our headline number. If you file a lot of till receipts — which is exactly where two-digit years live — expect to check them.

The failure that no software can catch

One scan was a receipt from Nepal, printed with a date in the Bikram Sambat calendar: 23/03/2083. The model returned 2003-03-23.

We have a guard that discards impossible dates — a year in the far future, a 31st of February, the 1st of January 1970 that software emits when it means "no date". It did not fire here, and it was right not to: 2003 is a perfectly ordinary year. The guard rejects the impossible. It cannot reject the merely wrong.

That is the honest limit of every tool in this category, ours included. A confidently wrong date looks exactly like a correct one.

What we changed: abstain rather than guess

The taxi receipt above was a real bug, and a revealing one. The model returned 12-02-18, which our checks ignored because they only inspected values already shaped like a proper date. So it flowed straight through into the filename as 12_02_18.

That is worse than useless. Is it 2 December or 12 February? It also quietly destroys the one thing a date in a filename is for: sorting.

We now drop any all-numeric date we cannot read with confidence, and deliberately do not guess which number is the day. MM-DD versus DD-MM is genuinely unresolvable from the string alone, and guessing manufactures exactly the kind of error we are trying to prevent. The file falls back to a date from its original filename, or the file's own timestamp.

This does not make the model more accurate. It converts a bad answer into no answer — which, for anything you will later rely on, is the better failure.

One thing we tried that did not work

Our instructions to the model included an example: a year shown as 24 means 2024. Two receipts printing the year 18 came back as 2024. That looked exactly like the model copying the example instead of reading the page — a known failure mode we had been bitten by before.

So we rebuilt the instructions with the example removed and measured again. It made no difference to those two, and one other scan got worse: 7 correct instead of 8. The model was misreading, not copying. We put the original wording back.

We mention it because "we changed the prompt and it felt better" is how most tuning in this field is done, and it is how you convince yourself of improvements that are not there.

What this means for you

• Review before you apply. Any tool that renames files the moment it reads them is asking you to trust a number like the one above, unseen. Ours proposes; you approve.
• Watch two-digit years. Till receipts are the risk. Invoices and statements, which nearly always print full years, are much safer.
• Prefer no date to a wrong one. A file with no date is obviously incomplete. A file with a confidently wrong date is filed incorrectly, and you may never notice.

We will re-run this measurement as the model and the prompts change, and update this page with the new numbers — including if they get worse.