Extraction problems
Extraction reads an invoice and produces fields with a confidence score on each one. It is accurate enough to be useful and it is not perfect, particularly on long-tail vendor layouts. This page is about the cases where it gets something wrong, and about deciding between fixing one document and changing how every future document from that vendor is handled.
Start with the confidence scores, not the totals
Every field carries its own score rather than the document carrying one. Open the document and look at the field-level scores before you check anything by hand.
This is the difference between "this invoice is 82% correct", which tells you nothing you can act on, and "the total is certain and the invoice number is a guess", which tells you where to look. A document with one weak field needs one glance, not a full re-key.
Fields also carry their provenance. The evidence panel on a field shows where the value came from and, where it exists, the snippet of source text it was read from. If a value does not appear verbatim in the source, the panel says so, and that is a field worth checking against the original before you approve.
Anything below the review threshold routes to review automatically. So do an unmapped vendor, a quarantined document, and line items that do not sum to the stated total, whatever the model's confidence claims. A model that is confidently wrong about arithmetic is worse than one that admits it is stuck.
A field is wrong or missing
Correct it on the document. Every edit records your name, the old value and the new one, so a corrected field is not a quiet overwrite. See the audit trail.
Then ask one question: is this vendor going to do the same thing next month?
| Situation | Do this |
|---|---|
| A one-off — smudged fax, unusual page order, a vendor's first ever invoice | Correct it by hand and move on |
| The same field is wrong every month for one vendor | Correct it, then set a default on the vendor record |
| The same coding decision every time, driven by sender or keyword | Write a rule |
| The vendor name is read differently each time | Add the variant as a vendor alias |
Correcting one document is not wasted work, but doing it twelve times is a decision you have chosen not to make.
Corrections and vendor mapping
Vendor matching runs against your vendor records and their aliases, using the extracted vendor name first and then the sender's domain.
So the durable fix for "InletAP keeps failing to recognize this vendor" is usually an alias rather than an edit. Add the spelling the invoice actually uses — "Bluepoint HVAC Ltd", "BLUEPOINT H.V.A.C." — and the sending domain as aliases on the vendor record, and later invoices match without a human. Aliases are added by you, deliberately; nothing is inferred from a single correction, because a vendor mapping guessed from one typo would be worse than no mapping at all.
Once a vendor is mapped, its default GL account can be applied automatically. A coding value that comes from a vendor or property default is stamped at middling confidence on purpose, so it reads in review as "assumed, please confirm" rather than "seen on the page". Coding invoices covers the defaults in full.
Poor scans and photographs
Some documents cannot be read by any amount of cleverness. A phone photograph of a handwritten docket, a fax of a fax, a scan at an angle in poor light — these are routed straight to review rather than guessed at, and they never consume an AI call to produce nonsense.
What helps, in order of effect:
- Ask the vendor for the PDF they printed from. Most have one.
- If it must be a photograph, ask for the whole page, flat, in daylight.
- Prefer a scan at normal document resolution over a compressed image.
What does not help is re-sending the same image and hoping. If the source text is not there, it is not there. This is the honest limit of the product, and it is the same limit every OCR pipeline has, whatever their marketing pages say about it.
Unusual layouts
Long-tail layouts — a supplier statement formatted as a table of five invoices, a work order with the total in a footer, a utility bill designed by somebody with strong views about design — are where accuracy falls off.
Two things to check first:
- Is the total the invoice total, or a balance carried forward? Statements are the classic case. A statement is not an invoice, and coding one as though it were will double-count the month.
- Is the amount the model read the amount payable? Some layouts print the subtotal larger than the total.
If a vendor's layout is consistently misread, tell us which vendor and send an example. Layout coverage improves by seeing real documents, and a single representative sample is worth more than a description.
Multi-invoice emails
An email with three invoices attached becomes three documents, each with its own fields, coding, approval and export, and each labeled with its position in the group so you can see they arrived together.
That is the intended behavior, and it is also the honest answer to "why does my usage say three". Each extracted document counts as one processed invoice; see plans and limits.
Where this goes wrong is a vendor who attaches one PDF containing five invoices printed one after another. That is a single document as far as the pipeline is concerned, and it will be read as one invoice. Split it before forwarding, or ask the vendor to send them separately, which they will usually agree to and occasionally even do.
Line items that do not sum
When the line items do not add up to the stated total, the document goes to review regardless of confidence. The document screen shows the line-item total against the header total and the variance between them.
Usual causes, in the order they occur:
- Tax, freight or a fuel surcharge is stated outside the line items.
- A discount or credit line was not read.
- One line was read with a transposed figure — 4,120 for 4,210.
- The invoice genuinely does not add up, which happens more often than vendors like to admit.
Correct the lines, or correct the header if the header is what is wrong. If the invoice itself is wrong, that is a conversation with the vendor rather than a data-entry exercise, and rejecting it with a comment keeps the reason attached to the document.
When to write a rule instead
A rule is worth writing when the decision is mechanical and repeated. Rules match on the source email, the vendor, the amount, a keyword in the document, and property alias, and they run in priority order.
Rules are good at coding, routing and holding. They are not a correction mechanism: a rule cannot make the model read a smudged total correctly. If the problem is that a number was misread, the fix is a human; if the problem is that a correctly-read invoice keeps being coded by hand, the fix is a rule. See the rules reference.
Still stuck
Write to support@inlet-ap.com with the document and, if you can, the original attachment. Extraction problems are difficult to diagnose from a description and usually obvious from the file.