Turning Documents Into Records

Retyping is not a job, it is a tax

Somewhere in your business, a person is reading a number off a document and typing it into a spreadsheet. Supplier invoices, expense receipts, signed order forms, timesheets, delivery notes. The information is already written down. It is simply written down in a place your spreadsheet cannot see.

This is the single most satisfying automation a small business can build, because the saving is obvious and the input arrives whether you like it or not. It is also the one with the sharpest teeth, because the output is numbers, numbers get totalled, and a wrong total is not a wrong tone of voice. It is a wrong payment.

So the whole lesson rests on one principle: an extracted figure is a claim, not a fact, until somebody has seen it next to the document it came from.

Which documents are worth it

Not all paperwork repays this. The good candidates share three traits: they arrive in quantity, they carry the same handful of facts every time, and the facts are printed rather than handwritten. Supplier invoices, expense receipts, order confirmations and standard forms all qualify comfortably.

The poor candidates are the ones where every document is differently shaped, or where the useful information is buried in prose rather than sitting in a labelled box. A contract is not an extraction job. Neither is a handwritten delivery note that has been photographed at an angle in a van. You can force those through, and you will spend more time correcting the output than you would have spent typing it.

Start with your single highest volume supplier. One layout, many documents, and a stack of past examples you already know the answers to.

Decide the fields before you touch a document

Write your column headings first. Six to ten fields, each with a definition and a format. If you cannot say precisely what goes in a column, the extraction cannot either, and it will fill it with something plausible.

Extract the following fields from the document below. Reply
with one line per field, in this exact order, nothing else.
SUPPLIER      the trading name on the document, verbatim
INVOICE_NO    the document reference, verbatim, no spaces added
ISSUE_DATE    as YYYY-MM-DD
DUE_DATE      as YYYY-MM-DD
NET           number only, no currency symbol, two decimals
TAX           number only, no currency symbol, two decimals
TOTAL         number only, no currency symbol, two decimals
CURRENCY      the three letter code shown on the document
Rules:

Copy values exactly as printed. Do not round, reformat,
correct spelling, or convert between currencies.
If a field is not present on the document, write NOT FOUND.
Never calculate a missing value from the others.
If a value is present but you cannot read it with certainty,
write UNCERTAIN followed by your best reading in brackets.
Do not add any commentary before or after the lines.
DOCUMENT:

Read the rules again. Three of the four exist to stop the same behaviour, which is filling a gap. A model asked for a total it cannot see will happily add the net and the tax together and present the result as if it read it. That answer is right most of the time, which is precisely what makes it dangerous.

Make it check its own arithmetic

You are not going to eyeball every row. What you can do is make the automation prove the numbers agree with each other before a human ever looks, so that the rows needing attention identify themselves.

You are checking an extracted record against the document it
came from. Reply with one line only.
Run these tests in order:

Does NET plus TAX equal TOTAL, to the penny?
Does the TOTAL you extracted appear, character for
character, somewhere in the document text?
Is DUE_DATE the same as or later than ISSUE_DATE?
Does INVOICE_NO appear in the document exactly as
extracted?
If all four pass, reply PASS.
If any fail, reply CHECK followed by the numbers of the
failed tests and one short clause naming what disagrees.
Never adjust a value to make a test pass. Report only.
EXTRACTED RECORD:
DOCUMENT:

Test two is the important one. It is the difference between the number being consistent and the number being present. A record can pass its own arithmetic beautifully and still describe a document that does not exist.

The human step, kept small

Checking every extraction defeats the purpose. Checking none of them is how a supplier gets paid twice. The workable middle is to check by exception plus a small sample.

ALWAYS REVIEW, side by side with the document

any row containing UNCERTAIN or NOT FOUND
any row where the reconciliation returned CHECK
any total above [your own threshold]
any supplier appearing for the first time
any invoice number already present in the sheet
SAMPLE REVIEW, five random rows every week

open the document, read the figures off it yourself
compare against the row, field by field
write down every disagreement, even trivial ones
WHAT THE DISAGREEMENTS TELL YOU

always the same field: your definition of that field is loose
always the same supplier: their layout has changed
scattered and rare: normal, keep sampling
rising week on week: stop and rebuild the extraction