Getting invoice data out of PDFs: what actually works
Supplier invoices arrive as PDFs. Somebody opens each one, reads the number, the date, the total and the tax, and types them into the accounting system. It is the most automatable task in a small business and one of the least automated, because everybody who looks into it meets the same wall of vendor marketing and gives up.
This is an attempt to answer the questions that marketing skips.
What does "99% accuracy" actually mean?
You will see figures like 99.8% on almost every product page in this category. The number is not invented, but it does not mean what a reader naturally assumes.
Accuracy in document extraction is usually quoted per field, on a clean document set, often on the vendor's own test corpus. Per field is the important part. An invoice has perhaps ten fields you care about, so 99% per field means roughly one invoice in ten contains at least one wrong value - not one in a hundred.
That changes the design of the whole thing. At a hundred invoices a month you are not building a system that runs unattended; you are building one that handles ninety of them and flags ten for a human. Which is still an enormous saving, and a completely different proposition from what the headline number suggests.
Three things move real-world accuracy away from the brochure figure:
- Digital versus scanned. A PDF generated by accounting software carries a text layer and extracts near-perfectly. A phone photo of a crumpled delivery note goes through OCR and does not.
- How many suppliers you have. Ten suppliers with stable layouts is an easy problem. Two hundred, each with their own format, is a substantially harder one.
- Line items. Header fields - total, date, invoice number - are the easy part. Extracting a table of line items, with quantities and per-line tax, is where extraction quality actually gets tested.
Which fields are worth extracting?
Fewer than you would think, and that is the main lever on cost.
| Field | Difficulty | Worth it |
|---|---|---|
| Invoice number, date, total | easy | always |
| Supplier identification | easy if you match against your own list | always |
| Tax amount | easy where there is one rate, harder with several | usually |
| Purchase order reference | easy when present, often absent | if you run POs |
| Line items | hard | only if you need them |
The instinct is to extract everything because the tool can. Resist it. Every field you add is a field that can be wrong, and a wrong field costs more to find and fix than typing it would have cost in the first place. Extract what you actually post to the ledger.
What does this cost to run?
Per-document pricing is the norm in this category, and for a small business the platform bill is rarely the deciding number. A few hundred documents a month sits in the tens of dollars for most tools - the same order as the running costs described in what automation costs a small business.
The costs that actually decide it are the other two:
The build. Connecting extraction to your accounting system, deciding what happens to a document that fails, and building the review queue. This is where the money goes, and it is roughly the same amount of work whether you process fifty documents a month or five thousand.
The review. Somebody still checks the flagged ones. Budget for it honestly. An automation that turns twenty hours of typing into three hours of checking is an excellent outcome; one sold as turning it into zero is being sold dishonestly.
Work out your own number before talking to anyone: invoices per month, minutes each to enter by hand, your hourly cost. If the answer is four hours a month, you have a mild annoyance and buying an off-the-shelf tool is the right move. If it is four hours a week, you have a business case for something built around your process.
The step that is really the whole project
Extraction is the part everyone thinks about. Matching is the part that determines whether the system is useful.
An extracted invoice has to be attached to something in your business: the right supplier record, the right purchase order, the right cost centre. This is where implementations quietly fail, and the reason is almost always the same - the underlying data is not clean enough to match against.
The same supplier exists three times in your records under slightly different names. Purchase orders live in a spreadsheet with no consistent numbering. Product codes differ between what you order and what you get invoiced for.
None of that is an extraction problem, and no extraction tool fixes it. It is the reason a project like this often starts with a week of tidying supplier records, and it is why the tidying is worth doing regardless of whether you automate anything - the same conclusion reached, from a different direction, in when not to automate a process.
What a working setup looks like
Six steps, and only one of them is extraction:
- Invoices arrive in one place - a dedicated inbox, not scattered across personal mailboxes.
- Extraction pulls the agreed fields.
- Confidence is checked per field. Anything below the threshold is flagged rather than posted.
- The invoice is matched to a supplier and, if you use them, a purchase order.
- Clean invoices post to the accounting system. Flagged ones go to a review queue with the document and the extracted values side by side.
- A human clears the queue - a few minutes a day, not a re-entry job.
Step three is the one that separates a system you can trust from one you cannot. An extractor that posts a value it is unsure about, with no signal, produces errors that surface weeks later during reconciliation. One that says "I am not confident about this total" turns a hidden error into a ten-second decision.
Step one is the one most often skipped, and it silently caps everything else. If invoices arrive in four different inboxes, no amount of extraction quality helps, because the system never sees them all.
Should you build or buy?
Buy first. Genuinely.
There are mature products doing invoice extraction, several of them integrate with QuickBooks and Xero directly, and if your process is ordinary one of them will fit at a price no custom build can compete with. Try one on last month's invoices before commissioning anything - the trial costs you an afternoon and tells you more about your own documents than any consultation will.
A custom build earns its cost in three situations: your documents are not invoices in a standard sense, your accounting system has no usable integration, or the matching logic is specific to how your business works and no product knows about it. Outside those, custom is the expensive way to arrive at the same result.
If you would rather have the numbers worked out before you commit to either, that is the process audit: $299, three business days, and a written answer on what your document handling actually costs you today and what each option would change.