Line-Item Level Invoice JSON

Why line-item accuracy determines whether PO matching works

Three-way PO matching — comparing what was ordered, what was received and what was billed — depends entirely on the invoice's quantities and unit prices being correct, line by line. A total that happens to match the PO total tells you nothing about whether the individual quantities are right; two compensating errors on two different lines can produce a correct-looking total while the underlying match is genuinely wrong.

An AP platform whose extraction only reliably captures header fields and a total is, in practice, still asking a human to open every invoice and re-key the line items before real matching can happen — which defeats much of the point of automating AP in the first place. Line-item accuracy is where extraction quality is actually tested.

This matters even more once straight-through processing enters the picture. A platform that wants to post a high-confidence invoice directly, with no human touching it at all, needs to trust every individual quantity and unit price on that invoice, not just its total — a single wrong quantity on one of forty lines is exactly the kind of error a header-only or total-only check will never catch, since the total can still come out correct by coincidence.

What this doesn't decide

Each of these three boundaries follows the same principle: extraction stops at the point where a decision requires context only your platform has — your own PO records, your own tolerance policy, your own customers' chart of accounts. Everything up to that point is reading the document accurately; everything past it is your product's logic.

The line-item JSON shape

{
  "line_items": [
    {
      "description": "Widget, 10mm, zinc-plated",
      "quantity": 40,
      "unit_price": 46.00,
      "tax_rate": 8,
      "amount": 1840.00,
      "confidence": 0.99
    },
    {
      "description": "Freight surcharge",
      "quantity": 1,
      "unit_price": 65.00,
      "tax_rate": 8,
      "amount": 65.00,
      "confidence": 0.94
    }
  ]
}

Every line carries the same five fields plus its own confidence score, whether it's a normal product row or a miscellaneous charge like freight or a discount line — nothing about the shape changes based on what kind of line it is.

Keeping the shape uniform across every kind of line matters for your own downstream code — a matching function that has to branch on whether a row is a "normal" item or a "special" charge is more code to write and more code to get wrong. A consistent shape means one code path handles every row in the array, regardless of what it represents on the printed invoice.

What gets read per line

Numbers come back as actual JSON numbers, not localized strings like "1.840,00" — your platform's matching and calculation logic can use them directly, regardless of which country or number format the original invoice used.

Multi-page tables, specifically

A line-item table that continues onto a second or third page is one of the most common places a hand-built extraction pipeline breaks — the header row doesn't repeat, the page break falls mid-row, or the parser treats each page as a separate table and returns two disconnected arrays instead of one continuous one.

Extraction here treats the full document as one logical table regardless of page breaks — a row that's visually split across a page boundary is still read and returned as a single line item, and the resulting array preserves the original row order across the whole document.

A repeating header row on pages two and three is recognized as a header, not miscounted as an additional line item — a mistake that would otherwise inflate the line count and throw off any downstream check that compares the number of rows against a purchase order's expected line count.

flowparse.io

How to actually benchmark this before you commit

An overall accuracy percentage on a vendor's marketing page rarely tells you what you need to know. The number worth asking for — and the number worth testing yourself before committing to an integration — is line-item accuracy specifically, measured against a real sample of your own suppliers' invoices, not a curated demo set chosen to look good.

A practical benchmark takes twenty to thirty representative invoices from your actual supplier mix, including a few multi-page ones and a few scanned or lower-quality ones, and checks two things: whether the line count matches the invoice exactly, and whether the sum of the returned line amounts reconciles to the printed subtotal. Both checks are mechanical enough to script, and together they catch the two failure modes — dropped or duplicated rows, and misread individual amounts — that matter most for downstream matching.

Because /validate is free and a trial plan lets real invoices run through /extract, this benchmark can be run before any commercial commitment — a concrete answer on your own documents, rather than a general accuracy claim taken on faith.

How it works

A forty-line invoice, extracted

A distributor's invoice with 43 line items spans three pages, with the table header repeating on pages two and three and one line item split visually across the page-one/page-two boundary.

The one flagged line didn't require reviewing the other 42 — the platform's review queue surfaced only that specific row, with its low-confidence field highlighted, while the remaining 42 lines flowed straight into the PO match.

For comparison, the same invoice run through a header-only extraction approach would have returned a single total and left all 43 lines to be re-keyed by hand before any real matching could happen — the difference between a two-minute review and an hour of manual data entry, on one invoice alone.

Table layouts this is built to handle

Header-only extraction vs. line-item extraction

The gap between the two columns widens with invoice complexity, not narrows — a simple one-line invoice is nearly as easy to match on a total alone as on its full line-item detail. A forty-line invoice with mixed quantities and tax rates is exactly where header-only matching quietly loses its reliability, which is also exactly the kind of invoice a growing AP platform sees more of as its customer base matures.

Who uses this

Each of these roles ultimately depends on the same underlying capability, just applied to a different downstream decision — a procurement platform comparing ordered versus billed quantities and a spend-management tool categorizing budget line by line are both, at their core, consuming the same typed line_items array, just for different purposes.

Why line items are where extraction quality actually gets tested

Any extraction tool can be made to look accurate on a header field — there are only a handful of candidate values on the page, and pattern matching against labels like "Invoice #" gets you most of the way. A line-item table has no such shortcut: forty rows means forty independent opportunities to merge two rows, drop one, or misalign a column, and a table spanning multiple pages multiplies that risk further.

This is why line-item accuracy, more than header accuracy, is the number worth asking about when evaluating an invoice extraction API for an AP platform — a vendor quoting overall field accuracy without breaking out line-item performance specifically is quoting the easier half of the problem.

A useful gut check when comparing vendors: ask specifically what happens to a multi-page invoice with a repeating table header, and whether the answer is confident and specific or vague and general. A vendor that has genuinely solved multi-page line-item reconstruction can describe exactly how it handles the case; one that hasn't tends to answer in generalities about "advanced OCR" without addressing the specific failure mode being asked about.

flowparse.io

Get your API key

Run a real multi-page invoice through /extract and see the line_items array yourself. See the full invoice OCR API overview for how this fits into the rest of the extraction workflow, or the build vs. buy frameworkif you're still deciding whether to integrate at all.

A single test call is usually enough to answer the specific question this page is about — send one of your own real multi-line invoices and check whether the returned array matches every row, in order, with the right quantities and prices.

Security and privacy

Full details are on the security page. The same controls apply regardless of how many lines a given invoice carries.

Frequently asked questions

Keep reading