Extraction confidence
Extraction reads an invoice and writes structured fields onto the document: vendor, vendor address, 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, and one derived document score
Confidence is attached to individual fields, and a single document score is derived from them: the lowest of the four fields the pipeline requires — vendor, invoice number, invoice date and amount — capped by the model's own overall figure. The per-field numbers are what you read; the derived one is what routes.
"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 invoice 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 — the attachment, rather than the email body. The name is historic: there is no separate OCR engine; a vision model reads the page. |
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
Two 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 file is quarantined | A rule you wrote said hold it. That decision outranks the extractor entirely. |
| The property could not be settled with confidence | The invoice named a building too weakly, or it fits more than one. A rule about who sent the bill has said nothing about which building pays it, so this outranks an auto-approval too. |
An unmapped vendor does not by itself route an invoice to review. It surfaces later, at export: a bill whose vendor has no counterpart in your ledger is parked rather than posted. If you want a new biller to stop at a person, write a quarantine rule that matches the sender's address or the vendor.
The arithmetic check is applied at export rather than at review. The document screen shows the line-item total against the header total and the variance between them while you are reading it, and before a bill is posted to your ledger, 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 invoice, opened from the Review Queue. The field's source becomes user, its confidence becomes 1.0, and the audit trail records the field, 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. Note the difference from the four that set the document's confidence score above — that set uses the invoice date, this one uses the due date. An invoice missing a due date can score highly and still refuse to go on, because a bill with no due date is a bill nobody can schedule. Fill it in on the Review Queue and send it again.
What counts as an edit, and what the log can tell you afterwards
Each of those changes is one fields_updated entry written by a person, and the Reports page divides the invoices carrying at least one of them by the invoices extraction actually read. That figure is the extraction edit rate in the metrics reference: the share of invoices where somebody changed what inletAP proposed.
One limit is worth knowing before you read too much into it. The log stores the value as it stood immediately before that edit, not the value extraction first proposed. On the first change to a field those are the same thing. On the second change to the same field, the "before" value is the first editor's, not the machine's — so the log answers "what did this field say before this change" exactly, and "what did extraction originally read" only for the first change. That is why we report a rate per invoice and not a score per field.
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.