Extraction confidence
Extraction reads an invoice and writes structured fields onto the document: vendor, invoice number, dates, total, tax, currency, purchase order number, property hint, terms and remit-to, plus line items where it can find them. Each field is stored with a confidence value and a record of where it came from.
This page explains what those numbers mean, what they are used for, and where they stop being trustworthy. Anyone who reviews invoices should read the escalations section; the rest is for people deciding how much to automate.
Per field, not per document
Confidence is attached to individual fields.
"This invoice is 82% correct" is not a statement anyone can act on. "The total is certain and the invoice number is a guess" tells a reviewer exactly where to look, which is the only useful form the information can take. The review screen shows the score beside each field for that reason.
Each field also records its source, which is a different question from how confident the reading is:
| Source | Meaning |
|---|---|
ocr | Read off the document itself. |
body | Taken from the text of the email rather than an attachment. |
rule | Written by one of your rules, or by a vendor or property default. |
user | Typed or corrected by a person. |
A GL account stamped from a vendor default carries a deliberately middling score. It was configured by you, so it is a standing instruction rather than a guess, but it was not seen on the page — and a reviewer should be able to tell those apart at a glance.
The review threshold
The document's overall score decides where it goes after extraction. At or above 0.7 it becomes ready_for_approval. Below that it becomes needs_review.
In the interface, field scores are banded so they can be read without arithmetic: 90% and above is shown as good, 70% to 90% as worth a look, and below 70% as doubtful.
A threshold is a blunt instrument, which is why it is not the only thing that routes an invoice to a human.
The escalations that override a high score
Some conditions send an invoice to a person regardless of how confident the extraction claims to be. A model that is confidently wrong is more dangerous than one that admits it is stuck.
| Escalation | Why |
|---|---|
| The vendor is not mapped | Nobody in your workspace has seen this biller before. Confidence about the text says nothing about whether you should be paying them. |
| The file is quarantined | A rule you wrote said hold it. That decision outranks the extractor entirely. |
| Line items do not sum to the stated total | Arithmetic either reconciles or it does not. A high score on a document whose numbers disagree is a strong signal that the extraction misread something. |
The arithmetic check is applied again, harder, at export. Before a bill is posted to QuickBooks, InletAP checks that the lines plus tax settle at exactly the stated total, within a penny for rounding. If they do not, the document is parked with both figures named rather than posted. A wrong number in a ledger is quiet, permanent and somebody else's problem to find.
An invoice that states tax but has no tax code to carry it is parked for the same reason: posting the pre-tax figure would underpay the vendor by the tax, silently and in real money.
What extraction gets wrong
Accuracy is good on the layouts you see most and imperfect on the long tail. A regional supplier's one-off template, a scan photographed at an angle, a handwritten total, an invoice pasted into an email with the columns collapsed — these are the cases where the score drops and a person is asked.
That is the design rather than an apology for it. The realistic aim is calibration: being right most of the time and honest about the rest. An extractor that was quietly confident on the awkward 5% would be far more expensive to use than one that hands them over.
Two consequences worth planning for:
- Your first month will have more review than your third. Vendor mappings, property aliases and rules accumulate as you work, and each one removes a class of decision.
- A document the extractor could not read at all still costs you one processed invoice once a person finishes keying it in. The alternative — the invoices that take the most human effort being the only free ones — would be a strange thing to charge for.
Correcting a field
Change the value on the review screen. The field's source becomes user, and the audit trail records the old value, the new value, your name and the time.
Four fields must be present before an invoice can go for approval: vendor, invoice number, amount and due date. An invoice missing any of them is not sent on, because a bill with no due date is a bill nobody can schedule.
Where to go next
- Invoice statuses — where a low score or an escalation sends the document.
- Coding invoices — what to do once the reading is correct.
- Extraction problems — when a field is repeatedly read wrong.
- Rules reference — how to stop making the same correction twice.