Every few months a new model arrives that reads invoices better than the last one. The demo is convincing: drop in a PDF, get back a supplier, a date, a total, and a table of line items. It looks like the hard part is solved.
For a finance team, the hard part has not started. An extraction is a draft. A bookable record is a decision. Someone still has to know whether the total is right, whether the tax was applied to the right base, whether the invoice duplicates one already paid, and whether the purchase order it references has room left.
Reading the document is the beginning of the workflow, not the end of it.
Extraction is a draft, not a record
A typical invoice has a supplier, an invoice number, issue and due dates, a currency, a subtotal, tax, a total, payment terms, and a list of line items. A model can return all of those fields and still produce a record that should not be posted.
The total might not match the line items. The tax line might use a different rate than the rest of the document. The supplier might already exist under another name. The invoice number might already be in the ledger. None of these are reading failures. They are verification failures, and they are what finance actually pays for.
A confidence score is not verification
Confidence scores are useful for routing. They are not proof. A model can be confidently wrong about a total, especially when the total sits far from the line items or the document has a page break in the middle of a table.
Verification needs at least three things:
- Source evidence. Every field should point to the page, the verbatim text, and the run that produced it, so a reviewer can check it without hunting through the PDF.
- A second pass over the numbers. Totals should be recalculated from line items. Tax, dates, currencies, and duplicates should be checked against explicit rules, not a model's opinion of itself.
- A route for uncertainty. A low-confidence field or a mismatched total should go to a person with the source beside it and a reason attached. It should not be silently resolved.
A system that returns 98% confidence and no evidence is less useful than one that returns 80% confidence and shows exactly where the number came from.
What the reviewer needs to see
Exception handling is not a queue of failures. It is a workspace. The reviewer should see the drafted record and the original document side by side, with the flagged fields highlighted and the reason for each flag written in plain language.
When the second pass finds a problem, the right behavior is usually to re-extract or ask for review, not to pick the more plausible number. A plausible answer is not good enough for financial data.
The record has to hold after approval
Approval is a moment. The workflow around it is what makes the record useful. The approved invoice may need to match a purchase order, post to QuickBooks or Xero with the source PDF attached, mirror to a spreadsheet, and keep an audit trail of who approved what and when.
Partial billing makes this concrete. A purchase order for $5,000 may have $3,750 billed across three invoices. The next invoice has to be checked against the remaining balance before it is paid. An extraction tool that only returns fields cannot answer that question.
Questions worth asking a vendor
- Can every extracted field be traced to its page and source text?
- Does a second pass check totals, tax, duplicates, and dates before review?
- What happens when the model is unsure?
- Can the review happen next to the source document?
- Does approval carry through to accounting with the PDF attached?
- Does the audit trail show the upload, the extraction, the review, and the posting?
If the answer is a confidence percentage and a promise, keep looking. The useful standard is simpler: every record should be inspectable, every exception should have an owner, and every decision should leave a trace.
That is the difference between an extraction demo and a document operation your finance team can rely on.