Turning a batch of receipts into a CSV your software will import.

Character recognition on a printed invoice has been a solved problem for years. What still eats an afternoon is everything around it: deciding what a row means, getting the tax lines separated, resolving a date that could be two different months, and ending up with a file the software will take without a fight.

What to capture, per document

One row per document, with these columns, is the shape that imports almost everywhere:

• Supplier — as printed, not normalised. You can group later; you cannot un-normalise.
• Date — in ISO form, 2026-09-09. See below.
• Document number — the invoice or receipt number. This is what makes a duplicate detectable.
• Subtotal — before tax.
• GST and QST — each on its own column.
• Total.
• Currency, if you ever see anything but one.
• Source file and page — so that any row can be traced back to the paper it came from. This one column saves more time than all the others combined when something is queried.

Why the tax lines are not optional

A single "tax" column loses the thing the whole exercise exists for. In Quebec, the input tax credit on GST and the input tax refund on QST are claimed separately, at different rates, and a supplier who charges one and not the other is common — a small supplier under the registration threshold, an out-of-province invoice, a zero-rated item on an otherwise taxable receipt.

Keeping them apart also gives you the best error check you will get for free:

• Subtotal + GST + QST = Total. One addition, and it catches a misread digit immediately.
• GST ÷ Subtotal ≈ 5% and QST ÷ Subtotal ≈ 9.975%. This catches the case where the arithmetic adds up because two figures were misread in compensating directions.

Note that QST is computed on the subtotal, not on the subtotal plus GST — the taxes have not been compounded since 2013. A row where QST works out to 9.975% of the GST-inclusive amount is either an old document or a misread one.

The rounding that produces false alarms

Run those checks on a table printed in whole dollars and you will get a screenful of failures on a document that is perfectly correct. Each printed figure is within fifty cents of the true one, so a sum of four of them can be two dollars out through rounding alone.

This matters more than it sounds. A check that fires on sound documents teaches people to click past it, and they will still be clicking past it on the day it is right. Set the tolerance to the precision of the document: cents-level tolerance on a cents-level receipt, dollar-level slack on a table printed in dollars.

Dates, and the one that will get you

01/02/2026 is 1 February in Montreal and 2 January in a system set to American convention. Nothing in the file resolves it. Two habits fix it for good:

• Store dates as YYYY-MM-DD the moment they leave the paper. It sorts correctly as text, and it cannot be misread.
• When a document is genuinely ambiguous, look for a day above 12 elsewhere in the same batch from the same supplier. Suppliers are consistent; that one document tells you the convention for all of them.

Why "export directly to my software" is usually a trap

It is tempting to look for a tool that writes a file badged for the accounting package you use — an FEC file, a Sage template, a QuickBooks or Xero or Acomba import. Two problems.

First, those formats are versioned and configuration-dependent: they encode your chart of accounts, your journal codes, your tax codes. A generic exporter cannot know them, so it guesses, and a guessed account code is a mis-posting that surfaces at year end.

Second, every one of those programs imports a plain CSV with named columns through a mapping screen. You do the mapping once, save it, and it applies to every batch afterwards. It takes ten minutes on the first run and nothing thereafter — and it is your mapping, so the account codes are right.

What to do with what does not add up

Flag it. Do not fix it.

When a total does not follow from its parts, the arithmetic tells you what the total should be — and it is very tempting to write that value in. Resist it. A figure computed by subtraction and then presented as if it were read off the document is undetectable downstream: it looks exactly like a correctly read figure, and nothing later in the chain will ever question it.

State the discrepancy, name the value the arithmetic calls for, and leave the decision to a person. What was not found should stay empty rather than be inferred. An empty cell is a question; an invented one is an answer that happens to be wrong.

Getting better paper in

Most recognition failures are scanning failures. A few minutes at the copier saves an hour of correction:

• 300 dpi, greyscale. Higher resolution rarely helps on thermal receipts and makes everything slower. Pure black-and-white loses faint thermal print.
• Flatten thermal receipts. A curled receipt photographs with a shadow down one side, and the shadow eats a column of digits.
• Two receipts to a page is fine — that is how everybody does it — as long as the tool cuts the page apart before reading it rather than blending both into one document.
• Do not correct the orientation by hand. Feed the stack as it is and let the orientation be settled page by page. Turning a hundred sheets round is exactly the work you are trying to avoid.
• Keep the originals until the batch is reconciled. Thermal print fades; a receipt from three summers ago in a glovebox may already be unreadable, and that is a fact to discover before the filing, not during it.