Invoice data extraction: fields, line items and what to look for in an API

What fields should invoice data extraction return?

Invoice data extraction returns two kinds of data: header fields, which appear once, and line items, which repeat. Amazon Textract’s list of standard fields is a fair picture of the market: invoice number and date, vendor and receiver details, tax IDs, PO number, payment terms, subtotal, tax, total and amount due, then item, quantity, unit price and line total. For a vendor-neutral baseline, the European standard EN 16931, in the business rules published by Peppol, requires every invoice to have an invoice number, an issue date, a currency code and at least one line. Suppliers label these differently, so a tool must map “Bill No.” and “Invoice #” to one name. Extract only what a later step uses. Each extra field is one more thing to check, and the invoice field reference shows what a full set looks like.

Why are invoice line items hard to extract?

Line items are hard because a table on a page is a visual arrangement, not a data structure. Extraction has to find columns that may have no ruling lines, keep a wrapped description attached to the right row, and carry a table across a page break with or without a repeated header. Amazon warns of inconsistent results from merged cells and irregular tables. Microsoft’s documentation expects merged cells to score lower, and expects a row split across pages to score lower than its neighbours. One shifted row can do more harm than a missing header field, because quantity and price feed the purchase order match. Test with long tables, discount lines, zero-priced lines and mixed tax rates. Be realistic about need, too: if you code invoices at header level and never match lines, line-item accuracy may not be worth paying for.

How do you check that extracted invoice totals are right?

An invoice checks itself, and that makes it easier to validate than most documents. The EN 16931 rules state the arithmetic plainly. BR-CO-10 says the sum of line net amounts equals the stated line total. BR-CO-13 says the total without VAT equals the line net amounts, less document-level allowances, plus document-level charges. BR-CO-15 says the total with VAT equals the total without VAT plus the VAT amount. Run the same checks on extracted data, with a small tolerance for rounding, and many misreads surface without a person reading anything. A failed check has two possible causes: the tool misread the page, or the supplier made a mistake. Both deserve a look, so route the invoice to review either way. A pass is good evidence and not proof, because two consistent misreads can still balance.

Where does extraction sit in the accounts payable workflow?

1. Capture: invoices arrive by email, portal, post or EDI.
2. Extraction: fields and line items are read, with a confidence for each value.
3. Validation: duplicates, arithmetic and vendor master checks run.
4. Matching: two-way matching compares the invoice with the purchase order; three-way matching adds the goods receipt, usually within a price tolerance.
5. Coding and approval: the invoice gets its accounts and a sign-off.
6. Posting and payment: the ERP records the liability and schedules payment.

Published benchmarks show why this chain gets attention. Ardent Partners’ AP Metrics that Matter in 2025, drawn from 212 AP professionals, put the average at $9.40 and 9.2 days per invoice, with a 14% exception rate. Best-in-class teams reported $2.78 and 9.0%, against $12.88 and 22.0% for all others. Ardent’s State of ePayables 2025 gives $9.84, 8.2 days and 18.4%. Its AP Metrics that Matter in 2026, a separate report sponsored by Medius, an AP automation vendor, gives $9.90 against $2.67 for best-in-class, and exception rates of 19.9% against 11.8%. These are survey results, so read them as direction, not as targets. Look closely at what Ardent counts as an exception: coding errors, missing information, approval bottlenecks and missing purchase order data. Better extraction addresses only part of that list. A perfect read of an invoice with no matching PO is still an exception, so be wary of any promise that extraction alone will clear your queue.

What should you evaluate in an invoice extraction API?

Run the checklist on a test set you labelled yourself, with suppliers held out from any setup work, as the pillar guide explains. If receipts or utility bills also reach AP, test them separately: they fail in different ways.

Does e-invoicing make invoice extraction unnecessary?

For invoices that arrive as valid structured data, yes: you parse them, you do not extract them. EN 16931 defines the data model, and Peppol BIS Billing 3.0 publishes a UBL format and validation rules built on it. If a supplier can send that, take it, because no extraction beats perfect data. Regulation is pushing in this direction. Under the EU’s VAT in the Digital Age package, member states can introduce mandatory e-invoicing under specific conditions, and digital reporting for cross-border B2B transactions applies from 1 July 2030. Few AP teams will get there all at once, though. Adoption depends on the country and on each supplier’s systems, so most teams should plan for a mix of structured invoices and PDFs for some time. Design the workflow so both routes end in the same validation and matching steps.

Where does docRefinery fit?

docRefinery is one option if your invoices come from the same suppliers month after month. It returns invoice fields and line items through an API, under the Return as names you choose and in the same format as every other document type. It learns each supplier’s layout once and remembers it, returns null for absent fields, and shows reviewers the source page next to the value. Rules can check that lines add up to the total, and a reviewer’s correction can become a suggested fix for that supplier. It will not replace your ERP’s matching or your approval rules. Try it on your own files on the free Starter plan, up to 100 pages a month, or read the quickstart. The comparison page says where other tools are the better choice.