Line items as rows, money as numbers you can sum, and the tax summary kept out of the grid instead of wrecking it. The invoice is read on your device and never uploaded.
Open the PDF table extractor, drop the invoice in and press Extract tables. Most invoices hold two tables — the line items and a subtotal/VAT/total block — so press ✂ Choose table and take the line items; read as one grid they interfere with each other. Set Extraction to Financial and the money columns become real numbers, brackets become negatives and a VAT rate becomes a fraction. Nothing is uploaded, which matters for a document carrying a supplier's pricing.
=B2*C2 down the lines and a SUM against the printed subtotal — that takes ten seconds and is exact.(1,250.00) becomes -1250 in Financial extraction, so a mixed ledger of invoices and credits sums correctly instead of adding a refund to the total.Runs in your browser. No account, no upload, no watermark.
A statement carries a running balance, so it proves itself: every row moves the balance and the arithmetic has to close. An invoice does not. It has quantities, unit prices, line totals, a subtotal, tax and a total — a structure that is checkable, but not by the same sum, and not without assuming which column is which.
So on an invoice the balance check declines and says so rather than inventing a verdict. In our test set every invoice, quotation, delivery note, purchase order and receipt declined: 11 of 13 documents refused to check at all, and there were 0 false alarms across the lot. Being told your invoice does not balance, by a converter that has misunderstood your columns, would be worse than being told nothing.
What you can do in about ten seconds, once the table is in a sheet, is check it yourself — and this is the genuinely useful habit:
=B2*C2 beside the first line and fill it down. Any row where it disagrees with the extracted line total is a row to look at.=SUM(D2:D40) against the subtotal the invoice printed. If it is short, a line was missed or arrived as text.SUM silently ignores text, so compare =COUNT(D2:D40) with =COUNTA(D2:D40); the difference is how many cells in that column are not numbers.Almost every invoice does: the line items, and then a smaller block at the bottom right holding subtotal, VAT and total. Read as a single grid they interfere with each other — the narrow block's columns force extra columns onto the wide one, and both sets of headings end up in the wrong place.
Measured on a page with a three-column table above a five-column one, reading the whole page gives eleven rows of six columns with both headings misplaced; taking the two separately gives a clean 5 × 3 and a clean 5 × 5. Stacked tables and side-by-side ones are both detected automatically and offered as choices, and you can always drag a box round any area instead.
Invoice number, invoice date, due date, your reference, the supplier's address — these are labelled values, not rows of the line-item table, and they belong beside it rather than in it. The extractor keeps them in the sheet rather than discarding them, but they are not part of the grid you will be summing, and the cleanest result comes from picking the line-item table and copying the header fields across by hand into their own columns.
This matters more than it sounds when you are building one spreadsheet out of many invoices: the invoice number and supplier have to become columns repeated on every line, or the rows lose their provenance the moment you sort them.
Each PDF is extracted on its own — there is no batch upload here, because there is no upload at all. The practical routine, which is what people actually want when they search for this:
Where suppliers use different column orders — some put quantity first, some the description — paste each one into a scratch sheet first and reorder the columns before it joins the master block. It is duller than a promised one-click import, and it is the thing that makes the result trustworthy.
Drop an invoice in and the page labels it. Six kinds are recognised — invoice, bank statement, purchase order, receipt, payslip and financial report — and anything else is left alone rather than forced into a category. The label never changes what was extracted; it changes what the page suggests next.
The hard part is refusing, not recognising. A quotation carries every commercial word an invoice has — unit price, subtotal, VAT, total — and never prints the word invoice. A delivery note has the entire structural vocabulary of a purchase order. A remittance advice lists invoice numbers. So a type has to name itself before it is considered at all, then clear a score floor, then beat the runner-up by a margin.
Tested against 15 documents including five written specifically to fool it: 15 correct, none given the wrong label, and none left unlabelled that should have been labelled. Remove the self-naming gate and the delivery note becomes a purchase order at any threshold, because its vocabulary simply is one's.
It reads printed English phrases, so an unlabelled French or German invoice is a missing label rather than a failed conversion — the table still comes out.
(1,250.00) becomes -1250, the accounting convention every spreadsheet expects, so a mixed ledger of invoices and credits sums correctly instead of adding a refund to the total.£1,250.00 becomes the number 1250 with a #,##0.00 format. If a single invoice mixes currencies, the symbols are gone from the cells, so keep the currency in a column of your own — the spreadsheet cannot tell you afterwards.20% becomes 0.2, which is what a spreadsheet means by twenty percent. Multiply by it directly; do not divide by 100 again.Two things people are usually doing with a folder of extracted invoices, both of which need columns rather than pictures:
Purchasing teams reconcile three documents: the purchase order (what was agreed), the goods received note (what turned up) and the invoice (what is being charged). Once the line items of all three are in a sheet, the comparison is a lookup rather than a squint — match on the item code, then flag any row where the invoiced quantity or unit price differs from the order. A discrepancy of one unit or a few pence per item is invisible on paper and obvious in a column of differences.
Our extractor labels purchase orders and delivery notes separately from invoices, and refusing to confuse them is the part that took the work: a delivery note has the entire structural vocabulary of an order without ever calling itself one.
With the invoice date and due date extracted as real dates, an aged creditors view is one formula: =TODAY()-E2 for days outstanding, then bucket it into 30, 60 and 90 days. Doing that across a folder of PDFs is the entire reason to extract them at all — no individual invoice tells you anything about your exposure, and the pile of them tells you everything.
Worth knowing: a due date is frequently printed as terms rather than a date — "net 30", "payable 30 days from invoice". That is text, and correctly extracted as text; the due date it implies is yours to compute from the invoice date.
This can skip the whole job, and hardly anyone looks. A growing share of business invoices are hybrid e-invoices: an ordinary-looking PDF with a machine-readable XML file embedded inside it as an attachment. The XML carries every field — supplier, line items, quantities, unit prices, tax rates, totals — as data rather than as printed text, so there is nothing to infer and nothing to get wrong.
The formats you will meet are Factur-X in France, ZUGFeRD in Germany (the same specification under two names), and documents exchanged over the PEPPOL network across much of Europe. Mandates are pushing this forward year by year, so the proportion of your supplier invoices carrying an attachment is rising whether or not anyone mentioned it.
How to tell: open the PDF in a reader and look for an attachments or paperclip panel. A file named something like factur-x.xml or zugferd-invoice.xml means the data is right there. Save it and hand it to whatever you use for accounts — most bookkeeping software imports these directly, and the result is exact rather than inferred.
We do not read the attachment, and this page says so rather than implying it. Extracting the printed table is the right answer when there is no attachment, which is still the overwhelming majority of invoices in circulation — and the only answer for a scan, a supplier portal print-out or anything older than the mandates.
Supplier invoices arrive as scans constantly — printed, signed, scanned back, forwarded. Tick Read scanned pages (OCR) and the characters are recognised in your browser; the invoice is not sent anywhere, which matters when it contains negotiated pricing.
Cells that cannot be what their column is are marked ⚠ before you download. On deliberately corrupted figures that check flagged 6 of 6 with no false alarms, and it raised nothing on 6 correctly extracted typed pages. Its limit is honest: it catches about one OCR mistake in five, because the rest are in description text where there is nothing to check against. The quantity × price arithmetic above is what catches the rest.
A digitally issued invoice — the kind generated by accounting software and emailed as a PDF — has a real text layer and needs no OCR at all. Try extracting first; the page will tell you if there is no text to read.