How to Detect Errors in PDF Invoices

Why PDF invoices create problems

PDF invoices look simple — they are clean, printable documents that a human reads without effort. But behind the scenes they create real challenges for automated processing. The first is variety: every supplier designs their invoices differently, with different layouts, table structures, currencies, tax formats and field labels. A process that works perfectly on one supplier's invoice can stumble on another's.

The second challenge is the format itself. A PDF often stores text at absolute coordinates on the page, with no underlying metadata saying which numbers belong to the same row of a table. To a human the columns are obvious; to software they are just scattered text. Simple PDF-to-Excel tools copy text in file order — which is frequently not left-to-right, top-to-bottom — and quietly mangle the structure. On top of that come the harder cases:

Each of these factors increases the likelihood of extraction errors, and they compound: a poor scan of an unusual multi-page layout in a foreign currency is exactly where mistakes cluster. This is precisely why extraction needs a validation layer on top — the extractor does its best to read the document, and the validator catches the cases where its best was not quite right.

There is also a meaningful difference between digital and scanned PDFs. A digital PDF — one generated directly by accounting or billing software — contains a real text layer, so extraction starts from accurate characters and the main risk is structural (which value belongs to which field). A scanned or photographed PDF contains only an image, so the text has to be reconstructed by OCR before anything else can happen, introducing a whole additional layer where errors can creep in. As a rule of thumb, digital PDFs are lower-risk and scans are higher-risk, which is why a good detection process leans harder on confidence scoring for the latter. Knowing which kind of document you are dealing with tells you how much scrutiny it deserves.

The most common invoice errors

Across thousands of invoices, the same mistakes appear over and over. They are not random — they cluster into a predictable set of categories, and that predictability is good news: it means a validation system can be designed to target each one specifically rather than vaguely “looking for problems”. Knowing the categories also tells a human reviewer where to look first, which is most of the battle when time is short:

It helps to group these by where they come from. Source errors exist on the original invoice — the supplier genuinely made a mistake or omitted a field. Capture errors are introduced during extraction — OCR misreads a digit, or a column is misaligned so a value lands in the wrong field. Process errors happen in handling — the same invoice is uploaded twice, or a page is skipped. A complete detection approach addresses all three: deterministic maths checks catch the source and capture errors that break the totals, duplicate detection catches the process errors, and confidence scoring flags the low-quality documents where capture errors cluster.

The rest of this guide examines each category in turn: what it looks like, why it happens, and how to catch it. The common thread is that almost none of these errors looks wrong on its own — they only reveal themselves when the numbers are checked against each other.

Missing invoice information

One of the most common problems is simply an incomplete invoice. A field that should be there is not — either because the supplier omitted it, or because extraction failed to capture it. The fields most often missing are:

Missing information causes accounting delays and compliance concerns: you cannot post an invoice with no number, you cannot reclaim VAT without a valid VAT number, and you cannot pay a supplier whose payment details are absent. Detecting missing fields is the simplest category of validation — it is a presence check — but it is also one of the most valuable, because the cost of a missing required field is a blocked or incorrect posting downstream. A good validator lets you define which fields are mandatory for your context, so “complete” means complete by your rules.

It is worth distinguishing two reasons a field can be “missing”. Sometimes it is genuinely absent from the source invoice — a supplier forgot to include their VAT number, for instance — which is a supplier problem you may need to chase. Other times the field is present on the page but extraction failed to capture it, perhaps because it sat in an unusual position or on a poor scan. The distinction matters because the fix is different: the first needs a corrected invoice, the second just needs the value re-read or typed in. Crucially, a missing field is one of the few errors that is obvious once you look — the hard part is making sure someone (or something) always looks, on every invoice, which is exactly what an automated presence check guarantees.

VAT errors

VAT mistakes are among the most expensive invoice problems, because they feed directly into your tax return where an error becomes a compliance issue rather than just an internal nuisance. The common examples:

The most useful detection method is to re-derive the VAT and compare it to what the invoice states:

Cross-border transactions add nuance: under the EU reverse-charge mechanism a B2B invoice may legitimately show 0% VAT with a note that the customer accounts for the tax, so a smart validator checks for the reverse-charge context rather than blindly flagging the missing VAT. For a deeper, scored compliance review, pair detection with the AI VAT Auditor or run a quick check with the Invoice VAT Checker.

VAT deserves disproportionate attention in any error-detection process for a simple reason: it is both frequently wrong and unusually consequential. It is frequently wrong because it is a calculated field, so any misread rate, wrong base or rounding choice produces a plausible-but-incorrect figure. It is consequential because the number flows directly onto your VAT return — an overstated input VAT is a reclaim you are not entitled to, and an understated one is money left on the table, both of which the tax authority cares about. Catching a VAT error at upload is therefore one of the highest-return checks you can run, turning what would have been a quarter-end reconciliation headache into a five-second fix.

Invoice calculation errors

Calculation mistakes remain surprisingly common, on both supplier-created and extracted invoices. Typical examples include:

The foundational check is that the totals reconcile:

Validation software performs this check instantly, and applies a small rounding tolerance so harmless per-line rounding does not produce false alarms while genuine discrepancies still surface. A second related check confirms the line items themselves sum to the subtotal — if the total reconciles but the lines do not, a row has usually been missed or misread.

Calculation errors are interesting because they are often invisible to a quick human glance — a total of €1,260 looks just as reasonable as the correct €1,200, and nothing about the figure itself signals a problem. That is what makes them dangerous and what makes them perfectly suited to automated detection. A machine does not judge whether a number “looks right”; it recomputes the arithmetic and compares. Where they originate varies — a supplier's own spreadsheet error, a manual keying mistake during entry, or an extraction that picked up the wrong figure — but the detection is the same in every case: re-derive the value and check it against what the document claims. Done by hand this is tedious and skippable; done automatically it happens on every line of every invoice without anyone having to remember.

Line item errors

Line items are often overlooked, yet they are where many invoice errors originate — and they are the hardest part of an invoice to extract cleanly. Watch for:

Line-item issues can significantly distort financial reports, because they roll up into the totals and into your expense categorisation. A single missing row means the lines no longer sum to the subtotal and the whole invoice fails to reconcile; a duplicated row inflates a cost. Tables that wrap across page breaks, descriptions that span multiple lines, and invoices mixing several VAT rates all make this category error-prone. Validating at the line level — checking that quantity times unit price equals the line total, and that the lines add up — turns these silent structural errors into explicit, locatable flags. Accurate line-item extraction is what makes that level of checking possible in the first place.

Two situations make line items especially error-prone and worth extra attention. The first is multi-page tables: when a line-item list spills across a page break, extractors frequently drop the rows straddling the boundary or duplicate the header, so the page transition is the single most likely place to lose a row. The second is mixed VAT rates: an invoice with some lines at the standard rate, some reduced and some zero-rated is far harder to get right than one with a single rate throughout, and a misattributed rate quietly distorts the tax total. In both cases the reconciliation check — do the lines actually sum to the subtotal? — is what turns an invisible structural problem into a visible flag you can act on.

Duplicate invoices

Duplicate invoices are a major source of direct financial loss, because the failure mode is paying the same invoice twice. They creep in through several routes:

To catch them automatically, validation systems compare a combination of fields across documents:

Matching on a single field is unreliable — invoice numbers get reused, amounts coincide — so robust detection looks at several together and flags near-matches for human confirmation rather than silently deleting them. The same logic catches duplicate transaction rows inside a single document, which is a common artefact of overlapping page extraction.

For accounts payable teams in particular, duplicate detection is one of the highest-value checks in the entire process, because the failure mode is not a misstated report — it is real money leaving the business. A duplicate that clears the approval workflow becomes a payment, and recovering an overpayment from a supplier is slow and sometimes impossible. The risk grows with volume and with the number of channels invoices arrive through: the same invoice emailed, then chased, then re-sent as a PDF can easily enter the system twice. Automated, cross-document duplicate detection is the only reliable defence once you are past a handful of invoices a week, because a human simply cannot remember every invoice they have already seen.

A subtlety worth understanding is the difference between an exact duplicate and a near-duplicate. An exact duplicate — same number, supplier, date and amount — is easy to catch and almost always a genuine repeat. A near-duplicate is trickier: the same invoice re-issued with a corrected line, or a legitimate recurring charge that looks identical month to month. A good system does not silently delete matches; it surfaces them with the fields that matched highlighted, so a human can confirm in a second whether it is a true duplicate or a valid repeat. That human-in-the-loop confirmation is important precisely because the cost of a false positive — rejecting a legitimate invoice — is also real.

OCR extraction errors

OCR — the technology that turns a scanned image into text — is powerful but not perfect. When it misreads, the result is a value that looks plausible but is wrong. Common OCR issues include:

These errors are especially common in scanned invoices, low-resolution PDFs and photographed documents, where a smudged “8” becomes a “3” or a thousands separator is misread. The danger is that an OCR error is invisible — there is no spell-check for numbers. This is exactly where validation earns its keep: it acts as a second layer of protection, catching OCR mistakes indirectly by checking that the read values are internally consistent. A misread digit that breaks the totals gets flagged even though the character itself looked fine, and confidence scoring highlights the fields the OCR engine itself was unsure about, so you know where to look before you even read the document.

There are a few practical ways to reduce OCR errors at the source. Capturing documents at a higher resolution and as flat scans rather than angled phone photos makes a large difference, as does preferring a digital PDF over a scan whenever the supplier can provide one. Where scans are unavoidable, the right strategy is not to trust the OCR blindly but to set a confidence threshold: any field the engine reads with low certainty is routed for a quick human glance, while high-confidence fields flow through. This keeps the review effort proportional to the actual risk — you are not re-checking clean digital invoices, only the genuinely uncertain values on the genuinely difficult documents. Combined with the consistency checks that catch errors the OCR itself was confident about, this gives you two independent safety nets under the most error-prone part of the pipeline.

Invoice validation checklist

Professional finance teams often use a standard review checklist, because working through the same steps every time is what makes detection reliable rather than dependent on attention. Before approving an invoice:

This checklist catches the majority of invoice problems. The catch is that running it by hand on every invoice is slow — which is exactly why teams automate it. For the full, in-depth version of this process, see the companion guide on how to validate invoice data, or jump straight to the invoice validation tool to run the checklist automatically.

The order of the checklist is deliberate. Presence checks come first — there is no point validating a VAT calculation if the VAT amount is missing entirely — followed by the consistency checks that depend on those fields being present, and finally the cross-document checks like duplicate detection that compare this invoice against others. Running them in this sequence means each step builds on the last and failures are reported at the right level of detail. When the checklist is automated, this sequencing happens invisibly and instantly; what you see is a single consolidated result telling you whether the invoice passed, and if not, exactly which step it failed and why.

How AI detects invoice errors automatically

Modern validation systems combine several layers, each catching a different class of error. Together they turn error detection from a manual chore into an automatic gate:

The crucial point is the division of effort. The maths and consistency checks are deterministic, so a flagged error is a real, explainable error — not a guess. Confidence and quality scoring then triage what is left: instead of reviewing every invoice manually, teams focus only on the exceptions the system surfaces. You can see the scoring in action on the Invoice Quality Score page, and the same approach extends across documents through financial data validation.

The practical effect is that detection becomes a gate rather than a chore. Every invoice is checked automatically; the high-quality ones — which are the large majority — pass straight through and can even be exported automatically, while the small minority that fail a check are held back and surfaced for review with the specific problem already identified. This inverts the traditional model, where a human had to look at everything in the hope of catching the few bad ones. It also means detection quality no longer depends on how tired or busy the reviewer is: the thousandth invoice of the month gets exactly the same checks as the first. AI does not replace the accountant's judgement — it removes the mechanical work so that judgement is spent only where it actually adds value.

It is worth being clear about what each layer is good at. The deterministic rules are best for anything with a right answer — arithmetic, reconciliation, format and presence — and you should trust them completely, because a flagged total mismatch is a fact, not an opinion. The AI and confidence layers are best for the fuzzier judgement of “how likely is this value to be wrong?”, which is exactly the kind of prioritisation a human would otherwise do by intuition. Using each for what it does best — hard rules for certainty, scoring for triage, and a person for the genuinely ambiguous cases — is what makes the whole system both fast and trustworthy.

Best practices for reducing invoice errors

Detecting errors is one half of the job; reducing how many occur in the first place is the other. Teams with the cleanest data tend to follow the same habits:

Organisations following these practices typically achieve significantly higher accounting accuracy. The through-line is to push quality control upstream — prefer digital PDFs over scans where you can, validate before export rather than after import, and let the system measure quality continuously so a dip is an early warning rather than a month-end surprise. Over time, reviewing your most common flags also tells you which suppliers or document types need attention, turning detection into a feedback loop that steadily improves your incoming data.

A final word on culture: error detection works best when it is treated as a standard, non-negotiable step rather than something done only when there is time. The teams that get the most from it bake validation into the workflow so that no invoice reaches the accounting system without passing through it — the same way no code ships without passing tests. Once that habit is in place, the conversation shifts from “did anyone check this batch?” to “what did the checks find?”, which is a far healthier place to operate from. The technology is only half the solution; the other half is making validation the default path, not the exception.

Frequently asked questions