Guide · accounts payable

Invoice to Excel: processing a batch, not a document

AP extraction demos are always one invoice. The real workload is a folder of invoices from different vendors, each with its own layout, where the question is not “can you read this” but “which of these two hundred does not add up”.

Updated October 2026 · 6 min read

The AP problem is not OCR. It is that invoice layouts vary by vendor, descriptions wrap, and the numbers have to add up before anything is posted. A tool that produces a plausible table without checking it has moved the work, not removed it.

The fields that actually matter

  • Vendor and invoice number — for matching and duplicate detection.
  • Invoice date and due date — for aging.
  • Description, quantity, unit price, line amount — the line items.
  • Subtotal, tax, total — the document’s own arithmetic, kept for verification.

If the extraction only captures a total, you cannot post to the ledger. If it only captures line items, you cannot verify them. You need both, and they need to be compared.

Three checks before the batch enters the books

1. Line sum vs document total

Add the extracted line amounts and compare with the printed subtotal. Differences point to a missed row, a duplicated wrapped description, or a discount line that was not captured. This one check catches most invoice extraction errors.

2. Quantity × unit price

Where an invoice prints both, recompute the line amount. A mismatch usually means a decimal or a thousands separator was misread — the classic 1,050 vs 10,500.

3. Duplicate invoice numbers

In a batch, the same invoice number appearing twice is either a genuine duplicate submission or two different vendors with colliding numbering. Either way it should be visible before payment, not after.

Designing the batch so it stays reviewable

  • Keep one row per line item and keep the source file in a column, so a merged batch can still be traced back.
  • Keep provenance: which page and region each amount came from. When a vendor disputes a charge, you should not be searching a PDF.
  • Prefer flags over corrections. A tool that silently fixes a total has destroyed the only evidence that something was wrong.

What this looks like in SheetParser

Upload a batch of invoices; each file produces its own table of line items with the document’s totals captured alongside, and every amount mapped to its source page. Anything the second read disagrees on is listed rather than averaged. Export to Excel or CSV for the AP system.

The first file each day is free up to 10 pages — try it on the invoice layout that breaks your current tool. Paid plans run files up to 600 pages, which covers a month of invoices per upload.

Common questions

Why do invoice line items break so easily?+

Invoices mix free-form descriptions with structured columns. A long description wraps to a second line, which a parser may treat as a new row — so one item becomes two, and the line total is counted twice or the row count is wrong.

Should I extract the total or the line items?+

Both. The line items are what you need for the ledger; the document total is what proves the extraction. If you only capture one, you have no way to detect an error.

How do I handle vendors with different templates?+

Layout-aware extraction reads the structure from each page rather than applying a fixed template. It will still produce more flags on unusual layouts — which is fine, as long as the flags are visible.

Check it on your own document

One file is free each day, up to 10 pages. You get the same extraction, the same flags and the same exports as a paid plan — not a preview.

Files shredded after conversion · never used for training

Keep reading