Convert Invoice PDFs to Excel Without Retyping

An invoice has two parts and a useful extraction keeps them apart. The header carries the identity of the document — vendor details, a customer where the invoice names one, the invoice number and the date. The body carries the line items, each with its description and, where printed, its quantity, unit price and line total. Underneath sit the subtotal, the tax and the total.

StackExtract reads the fields the invoice actually prints. Plenty of invoices omit things: no quantities on a services invoice, no tax line where none applies, no customer block on a receipt-style document. A missing field is reported as missing rather than filled in with a guess.

A long itemised invoice is handled as one document with many line-item rows, not as many documents. That is worth saying because it is where the retyping cost actually sits — a forty-line invoice is forty rows of manual entry, and it is priced the same as a one-line one.

Invoices carry their own arithmetic, which makes them checkable in a way many documents are not. Quantity times unit price should reach the line total. The line totals plus tax should reach the invoice total. Where the invoice prints the figures for those relationships, StackExtract checks them and flags what does not hold.

That is the extent of it, and the boundary is worth stating. A vendor name, a tax identifier, an address or an invoice number has nothing on the document to check it against — no arithmetic relates it to anything else. Those fields are extracted and shown; they are not independently confirmed, and an important one deserves your eyes. Assisted Review exists for documents where you want a person to do that.

Where an invoice supplies nothing to cross-check, no math check runs and the screen says so. A check that could not run is reported as exactly that, never as a pass.

And nothing is adjusted to make the arithmetic work. Where a line total does not match quantity times unit price, both figures are shown as printed and the row is flagged — because an invoice whose own numbers disagree is a fact about the invoice, and quietly fixing it would hide a vendor error as readily as an extraction one.

Everything is editable before export, so a misread unit price or a description that wrapped badly is a correction rather than a re-run.

The Excel file is a working document: structured rows for further processing, checking against a purchase order, or building a summary. StackExtract extracts and checks the arithmetic on the page — it does not tell you how anything should be treated in your books.

Accented characters, currency symbols and date formats survive extraction and the export. A vendor name with a tilde or a cedilla in it arrives in Excel as it appears on the invoice, which sounds minor until a supplier ledger is being matched on name.

The usual case is volume. A month of vendor invoices to enter, a backlog that built up while somebody was away, a pile of documents that needs to become a spreadsheet before it can become anything else.

Each invoice is one document regardless of its page count, so a long itemised invoice is priced the same as a single-line one — which is the opposite of how retyping costs behave.