OCR Misread Dates on Bank Statements and How to Catch Them

OCR misread dates on bank statements in three main ways: day and month swap places, look-alike digits change the day, and years go missing or wrong when the statement prints only month and day. Bank statements list transactions in date order, so the quickest catch is a sort-order check that flags any date earlier than the row above it.

Day and month swaps in OCR'd statement dates

A day and month swap happens when 04/03/2026 is read in the wrong order: the bank meant 4 March and the sheet stored 3 April. Strictly, the OCR usually read every digit correctly. The swap happens when the text is turned into a date using a different regional order from the one the bank used.

Swaps are dangerous because the result is a valid date. Excel accepts 3 April without complaint, formats it neatly and sorts it with the rest. Only dates with a day above 12 resist the swap, because there is no 25th month, and those usually stay as text. That gives you a mixed column: some swapped dates, some text, and some correct dates where day and month happen to be equal.

The pattern tells you the cause. If every date with a day of 13 or more is left-aligned text and the rest are right-aligned dates, the statement and your settings disagree about date order. Fix the import, not the cells: re-import the file with the column's date order set to match the statement, through the text import wizard or Power Query's locale option.

Swaps also hit statements printed in other countries, where day-first dates are normal. A US-set Excel reading a UK statement swaps every date up to the 12th of the month.

Why does OCR read a 1 as a 7 in statement dates?

OCR reads a 1 as a 7 when the small flag at the top of the 1 looks like the bar of a 7, which gets worse on faint or low-resolution scans. In a date, that turns 03/11 into 03/17, a real date six days later. Nothing about the cell looks wrong.

Dates suffer more from digit confusion than amounts do, for two reasons. First, dates are short, so a single wrong digit changes the meaning entirely. Second, an amount error breaks the running balance and gets caught, while a date error leaves the balance untouched. A transaction dated six days late still adds up.

The confusions that hit dates hardest:

• 1 and 7, turning the 11th into the 17th or January into July.
• 3 and 8, turning the 13th into the 18th.
• 0 and 6, or 0 and 8, turning the 10th into the 16th or 18th.
• A lost slash or dot, which merges 03/11 into 0311 and leaves a number, not a date.

Faint print, small type and ink bleed all raise the odds. If a statement shows many date errors, the scan itself may be the problem. Signs a low quality scan should be redone instead of converted explains when to rescan rather than repair.

Lost years on month-and-day statement dates

Many statements print transaction dates as month and day only, such as 03/11, and give the year once in the header. The converter must add the year itself. If it takes the wrong year, or none, every row inherits the error, and a statement period that crosses January 1 is where this most often goes wrong.

Three things can go wrong:

1. No year at all. Excel fills in the current year when you type a month and day, so a statement from two years ago lands in this year.
2. The wrong single year. A December to January statement is stamped with the start year throughout, so January lines move back a full year.
3. A misread header year. OCR reads 2026 as 2025 in the statement period, and every line follows.

The period check in the next section catches all three, because each one pushes dates outside the statement's start and end dates. The fix is to add the year correctly: for each line, use the year that puts its month and day inside the statement period.

In Excel, a helper formula can do this. Take the start year from the header, build the date with DATE, and if the result falls before the period start, add one year. A December 15 to January 14 statement then dates 01/03 in January of the later year, while 12/28 keeps the earlier one.

A sort-order check for misread statement dates

A sort-order check compares each date with the one above it and flags any that go backwards. Bank statements list transactions in posting order, so a date earlier than its predecessor almost always marks a misread. A second check flags dates outside the statement period. Together, the two catch most bad dates without reading every row.

Set the statement's start and end dates in two cells, say H1 and H2. With converted dates in column B starting at B2, add:

C3: =IF(B3<B2, "order", "")
D2: =IF(OR(B2<$H$1, B2>$H$2), "outside", "")

Fill both down. The order check starts on row 3, since row 2 has no row above it.

A worked example

The rows below are an example. The statement period is 1 to 31 March 2026, printed in US month/day order.

Read the flags in context. Row 4 is a day and month swap: 9 March stored as 3 September, caught by the period check. Row 5 is flagged only because row 4 is so late, but it carries its own error, a 1 read as 7. Row 6 is correct, and its flag comes from row 5 being too late. Row 10 has the wrong year, caught by both checks.

The lesson is that an order flag points at a pair of rows, not one. A date that is too late flags the row after it. A date that is too early flags itself. Look at both rows on the page before changing either.

Card statements need care with this check. Some list transactions by transaction date while posting later, so small reversals of a day or two can be genuine. Treat a one-day reversal as a prompt to look, not proof of an error.

Are misread statement dates always the OCR's fault?

Misread statement dates are not always the OCR's fault. The digits can be right while the date is wrong because of a regional import setting, a page order mix-up, a posting date confused with a transaction date, or Excel's own conversion of text to dates. Knowing the cause saves you from rescanning a page that was fine.

Common causes that have nothing to do with recognition:

• Import settings. As above, a day-first statement read with month-first settings swaps dates with perfect OCR.
• Page order. A statement scanned double-sided can come out with even pages before odd ones, so dates jump backwards at every page break. Scanning double sided bank statement pages in order shows how to prevent that.
• Two date columns. Statements that print both a transaction date and a posting date can have the wrong one mapped to your date column.
• Excel's own picture import. Tools that read a photo straight into cells, such as Excel's Data From Picture, let you review flagged cells, but they still convert dates with your regional settings.

If dates are wrong in a regular pattern, such as every page break or every day under 13, suspect settings or page order first. If they are wrong at random, suspect recognition and the scan quality.

Correcting a misread statement date from its neighbours

Correct a misread date by reading the page first, then using the rows around it as a cross-check. The rows above and below bound the true date, because the statement lists them in order. A date that must fall between the 9th and the 12th, and reads as the 17th, was almost certainly the 11th.

Use the neighbours to narrow the choice, not to make it. The paper or the PDF image settles it. Zoom into the date on the scanned page and read it yourself. If the scan is too poor to read, the bank can supply a copy, or a digital statement for the same period.

A few habits keep corrections honest:

• Fix the cause before fixing cells. If every date is swapped, re-import rather than editing a hundred rows.
• Mark corrected cells with a fill colour or a note, so a reviewer knows which dates were changed by hand.
• Rerun both checks after correcting, since one fix can reveal another error that was hidden by it.

Digital statements avoid most of this, because the dates are text the bank wrote, with no recognition step. If you are deciding how to convert, how to turn a PDF into Excel by four methods compares the options. FastBankConvert is being built to read statement layouts directly, with scans taking longer than digital files, and it is getting ready to open; the homepage explains how to join.