Invoice data extraction is the job of reading a supplier invoice and turning it into structured data: supplier, invoice number, dates, line items, tax, totals and bank details. Reading the page is the easy part. The part that saves you from a bad payment is knowing which values you can post straight away and which ones a person should look at first.
What is invoice data extraction?
You receive invoices as PDFs, scanned pages and photos taken on someone's phone in a loading bay. Somebody in AP opens each one and keys the numbers into the accounting system. Extraction replaces that keying: software reads the document and hands back each field as data you can import, match against a PO, or approve.
Good extraction does a second job too. It tells you when it is not sure. An invoice tool that fills every box with total confidence is just moving the typing errors somewhere harder to see.
Which invoice fields actually matter?
Not every word on an invoice is worth capturing. These are the fields that feed approval, matching and payment, and the check that goes with each.
| Field | Why it matters | Quick check |
|---|---|---|
| Supplier name | Links the invoice to your vendor record | Matches the name in your vendor master |
| Invoice number | Stops duplicate payments | Unique for that supplier |
| Invoice date and due date | Sets the period and the payment run | Due date falls after invoice date and fits the terms |
| PO number | Needed for two-way or three-way match | Exists and is open |
| Currency | Avoids paying 4,812.50 EUR as USD | Matches the PO or contract |
| Line items (description, qty, unit price, line total) | The actual charge | Qty x unit price = line total |
| Subtotal, tax, total | What you will pay | Lines sum to subtotal; subtotal + tax = total |
| Remit-to and bank details | Where the money goes | Routing number is valid and matches your file |
If you only capture the header (supplier, number, date, total), you lose the ability to check the arithmetic. Line items are where most real mistakes hide.
Why do invoice templates keep breaking?
The older way to automate invoices is a template: draw a box where the invoice number sits, another where the total sits, and read whatever text lands inside. It works fine for one supplier who never changes anything.
Then the real world shows up:
- A supplier redesigns their invoice and the total moves down the page.
- The line items run onto a second page, so the "Total" box is now empty on page one.
- Someone photographs the invoice at an angle on a desk.
- The word "Total" appears three times: total before tax, total due, and total paid to date.
- A new supplier arrives and needs a new template before anyone can process their invoices.
Each of these sends a template to the wrong box. It still returns a value, which is the dangerous part. A template has no idea that it just read the freight charge as the invoice total.
Modern extraction reads the document the way you do, by meaning rather than position. "Amount due" is the amount due wherever it sits. That handles layout changes, but it brings its own question: how do you know the reading is right?
How do you extract invoice data without trusting it blindly?
You make the tool show its work. In SensiDocs, every field ends in one of two states: accepted, or flagged for a person to check. A flagged field always comes with a plain reason:
- Not found. The field is not on the document.
- Failed a check. The value breaks a rule, such as line items not adding up.
- Contradicted. Two parts of the document disagree.
- Bad format. A date that is not a date, a routing number with eight digits.
- Not grounded in the document. The value cannot be traced back to text on the page.
- Low confidence. The read itself was shaky.
Two things sit behind that.
Deterministic checks. Line items must add up to the subtotal, and subtotal plus tax must equal the total, allowing only for rounding of a cent or two. US bank routing numbers are checked against the ABA checksum. These are plain arithmetic, so a failed check outranks how confident the model feels about its reading.
A second, independent read. When a field looks doubtful, SensiDocs reads it again without showing the second read the first answer. The value is only accepted if both reads agree. If they don't, the field goes to a person.
The result is a tool that would rather say "please check" than guess. For AP, that is the right trade. A flagged field costs you a few seconds. A confident wrong total costs you a vendor call, a credit note, and sometimes money you don't get back.
What should a good review step look like?
The review step is where you get your time back or lose it. A weak review screen shows you the extracted data and the document side by side and leaves you to compare every field yourself. That is retyping with extra steps.
A good review step does this:
- Shows only what needs you. Accepted fields stay out of the way. Uncertain fields are highlighted.
- Tells you why. "Line items sum to 4,182.50; invoice total reads 4,812.50" is something you can act on. A red box with no explanation is not.
- Points at the source. You should see where on the page the value came from, so you can confirm it in one glance.
- Lets you fix it in place. Click the field, correct it, move on. No exporting to a spreadsheet to edit.
In the example above, the reviewer looks at the invoice, sees the supplier transposed two digits in the total, and either corrects it or sends it back to the supplier. Either way, the decision is made by a person with the evidence in front of them.
What kinds of invoices can you extract from?
SensiDocs reads PDFs (digital or scanned) and phone photos. The Accounts payable pack covers supplier invoices and receipts. If the same team also handles shipping paperwork, the Logistics pack reads commercial invoices, packing lists and bills of lading with the same accept-or-flag approach.
For the cleanest results, upload one document per file.
How do you get started with invoice extraction?
Don't test on your neatest invoices. Pick a handful that cause trouble today:
- A long invoice with many line items
- A scanned page that is slightly crooked
- A phone photo
- A supplier that shows tax per line instead of at the bottom
- One where you already know the total is wrong
Run them through and look at two things. First, did the accepted fields match the document? Second, when something was flagged, was the reason clear enough that you could fix it in a few seconds? Those two answers tell you more than any demo.