IDP vs OCR on supplier invoices: why classic OCR fails

ininvoice: Classic OCR extracts plain text from a PDF: it reads pixels and returns strings, with typical accuracy of 80-85% on line data when there are tables and variable layouts. Intelligent Document Processing (IDP) understands the document: extracts structured fields with semantic context (supplier, taxable base, VAT per rate, withholding, lines, discounts), 95-98% on standard invoices. For a Spanish invoice with multiple VAT rates in the same header, withholding tax and line-by-line three-way matching, that gap decides whether the flow is touchless or not.

Almost every accounting software vendor talks about “invoice OCR” as if it were a single technology. It is not. There are two generations and, on real supplier invoices, the difference shows every day.

If you handle serious supplier-invoice volume (200, 500, 1,500 per month) with real suppliers, you have hit the limit of classic OCR: an invoice with 21% and 10% VAT in the same header, a self-employed contractor with personal income tax withholding, a credit/correction invoice in negative, a PDF scanned from a mobile phone.

This article separates what OCR is, what IDP is and why Spanish tax peculiarities mean the former is not enough for a real touchless flow.

What OCR (Optical Character Recognition) is

OCR is optical character recognition. It takes an image and returns text. Period. Mature technology, 30 years old: ABBYY, Tesseract, Kofax, modules built into ERPs. It does what it does well and only what it does.

The classic pipeline binarises the image, detects text regions, segments characters, classifies each against a dictionary and returns text strings with coordinates. It works for digitising books, reading IDs, capturing plates: tasks where all that matters is transcribing characters.

Going from “plain text” to “invoice fields” needs a second layer: positional templates or regex rules on the extracted text. That is what many call “invoice OCR”. Technically it is OCR + templates.

What IDP (Intelligent Document Processing) is

IDP is the next generation. It does not only read pixels: it understands the document. The semantic comprehension layer uses models pre-trained on millions of real invoices (LayoutLM, Donut, multimodal LLM-based models, commercial engines such as Google Document AI or Amazon Textract Invoices).

An IDP pipeline combines base OCR (for image PDFs) or native parsing (PDF with text layer), field extraction by semantic context (not by position), table comprehension (rows, columns, lines), cross-validations (sum of lines = base; base + VAT - withholding = total) and reading of XML / FacturaE and Verifactu QR when present.

The output is not plain text. It is a structured object: supplier with tax ID, date, number, base, lines (description, quantity, unit price, amount), VAT per rate, withholding, total. Ready to load into an ERP or cross-check against a PO.

Why classic OCR fails on Spanish supplier invoices

Spain has five peculiarities that break classic OCR more than in other markets.

1. Multiple VAT rates on the same invoice. A hospitality distributor invoice can carry 21% VAT (alcohol, soft drinks), 10% (food), 4% (bread, milk, fruit) and exempt, in different lines with subtotals. Positional OCR pulls the first VAT amount it sees or the aggregate total, but rarely all three rates. The Spanish tax authority requires per-rate differentiation in the input VAT ledger.

2. Personal income tax withholding on freelance and professional invoices. A freelancer, consultant or architect invoices with withholding tax (15% general, 7% new professionals). Withholding is a negative line: Base + VAT - Withholding = Net. Classic OCR, configured for “total = base + VAT”, breaks. Result: empty or wrong field, and the withholding tax return does not match.

3. Early-payment discounts as a separate line. Distributors and wholesalers put early-payment discounts as a negative line before VAT, as a discount on total, or as a footnote with a condition (“2% if you pay in 10 days”). OCR does not tell them apart. IDP, trained on this pattern, does.

4. Correction invoices. Correction invoices (Spanish Royal Decree 1619/2012, art. 15) carry data from the original invoice with negative sign or difference. Classic OCR looking only for “positive total” fails. Trained IDP detects them as credit notes and handles the sign.

5. Fragmented ERP formats. Dozens of templates coexist: Spanish accounting ERPs, vertical ERPs, ones made in Word by a micro-business. Positional OCR needs a template per supplier. IDP generalises by semantic context.

Classic OCR vs IDP: feature matrix

Feature	Classic OCR	IDP
Extracts plain text from PDF	Yes	Yes
Structured fields without template	No (needs per-supplier template)	Yes
Line and table detection	Limited	Yes (trained model)
Multiple VAT rates on one invoice	Confuses rates or aggregates	Splits by rate
Personal income tax withholding	Usually empty or wrong	Detects negative withholding line
Correction invoices	Sign error	Detects credit-note type
Complex tables with subtotals	Loses structure	Keeps hierarchy
Handwritten / handwritten notes	Low	Improves with multimodal
FacturaE / structured XML	No (ignores XML)	Yes (native parsing)
Verifactu QR	Does not decode	Decodes signed data
Internal cross-validations	No	Yes (base + VAT - withholding = total)
Average accuracy on real invoices	80-85%	95-98%

Expected accuracy by format

Format	Classic OCR (field accuracy)	IDP (field accuracy)	Note
Digital-born PDF (text layer)	85-92%	96-99%	IDP parses native text, no OCR needed
Clean scanned PDF (300 dpi)	78-87%	92-97%	Base OCR works for both
JPG mobile photo	55-72%	85-93%	Multimodal IDP handles skew and light
FacturaE XML	0% (does not read it)	99%+ (direct parsing)	XML is signed: more reliable than any OCR
Handwritten invoice	20-45%	60-78%	Still the worst case, but IDP gains margin

The figures above are market ranges, not concrete vendor numbers. Validate with a benchmark on your own invoices. Useful frame of reference: IOFM benchmarking.

When classic OCR is enough

Low volume: fewer than 50 invoices/month with stable templates.
Few suppliers: 5-10 fixed ones that do not change format.
No multi-VAT: one rate per invoice.
No withholding: a company that only receives invoices from corporations, not from freelancers.
No three-way matching: pure bookkeeping without PO or delivery note cross-checks.
No regulatory pressure: Verifactu does not apply yet, no Spanish SII reporting.

If your case fits, do not invest in IDP. It is overkill.

When you need IDP

Volume 100-2,000 invoices/month.
50+ active suppliers with heterogeneous formats.
Mix of corporations and freelancers (withholding in play).
Sectors with multiple VAT rates on one invoice: food distribution, hospitality, retail.
Line-by-line three-way matching with PO and delivery note.
Frequent correction invoices or volume / early-payment discounts.
Active Verifactu at suppliers and/or SII at your company.
Mix of digital PDFs, scans and attached FacturaE XML.

This is exactly ininvoice’s ICP: SMEs with 100-2,000 invoices/month in distribution, construction, multi-location hospitality, retail and light manufacturing.

Want to compare OCR vs IDP on your own invoices?

ininvoice ingests from Gmail or Outlook, reads FacturaE/XML, detects multi-VAT and withholding tax, and exports to your accounting. Book a spot and measure accuracy with your own real invoices.

IDP and three-way matching

Three-way matching cross-checks invoice, PO and delivery note at the line level. Line accuracy is critical: if the invoice line is not extracted well (description, quantity, unit price), the cross-check with the PO line is impossible.

Classic OCR frequently collapses lines: confuses adjacent lines, loses the quantity, puts the discount inside the price. The matcher then fires fake variances and the team ends up checking by hand. Back to re-keying.

IDP delivers clean lines: description, quantity, pre-tax unit price, amount. On top of that, the matcher computes price variance ((inv_unit_price - po_unit_price) * inv_qty) and quantity variance ((inv_qty - po_qty) * po_unit_price). In ininvoice, tolerance is 2% relative or EUR 1.50 absolute per line, OR mode. Detail in three-way matching and invoice and delivery note reconciliation.

IDP, Verifactu and Peppol BIS

There is a shortcut classic OCR does not use: when data comes signed at source, you do not need to extract it; you just need to read it.

Verifactu adds a QR to every invoice issued in verifiable mode. The QR contains issuer tax ID, number, total amount, date. Official data signed at the Spanish tax authority.
FacturaE XML delivers every field structured and signed.
Peppol BIS (more in EU/B2G international) delivers the same structured XML via the Peppol network.

Modern IDP prioritises these channels: if there is XML, parse it; if there is a QR, decode it; the PDF stays as fallback.

Checklist to evaluate your current stack

How many active suppliers do you have? How many different invoice formats arrive per month?
Does your current system extract VAT per rate when there are 21%, 10% and 4% on the same invoice?
Does it capture withholding tax on freelance invoices without manual keying?
Does it detect correction invoices and put the right sign in accounting?
Does it read FacturaE XML when the supplier attaches it, or only the PDF?
Does it decode the Verifactu QR on invoices that already carry it?
Does it deliver lines with description, quantity and unit price, ready for three-way matching?
What is your real “invoice approved without human touch” rate? 30%? 70%?
How many hours/month does the admin team spend correcting extractions?
When did you last measure extractor accuracy on a real sample?

If the answer to questions 2-7 includes several “no” or “I don’t know”, you are paying for classic OCR even if the supplier’s invoice calls it “AI” or “Smart Capture”.

Want to see the difference on your own numbers?

Try it with your real invoices: measure us on multi-VAT, withholding, correction invoices and lines. Plug and play, no consultant.

FAQ

Is my ERP’s OCR enough for Spanish invoices?: Depends on volume and mix. For 30 invoices/month from 5 stable suppliers, yes. For 300 invoices/month with freelancers, multi-VAT and correction invoices, usually no. If more than 20% needs manual touch-up, classic OCR is no longer enough.
Is Tesseract usable for invoices?: Tesseract is an excellent open-source OCR for plain text. For invoices you have to add field detection, table comprehension, validations and XML parsing on top. That is engineering equivalent to an in-house IDP.
Does IDP require training models with my invoices?: Not necessarily. Modern IDPs ship pre-trained and generalise well without specific fine-tuning. For very vertical sectors, fine-tuning can add 1-3 percentage points of accuracy.
Does it work on poor-quality scans?: Yes, with caveats. Accuracy drops vs digital PDF but stays above classic OCR on the same scan. If your intake gets many mobile photos, IDP makes the difference.
And on handwritten invoices?: The hardest case. Recent multimodal IDPs improve on classic OCR but expecting 100% is unrealistic.
What does ininvoice use exactly?: Invoice-processing IDP plus native FacturaE/XML parsing, Verifactu QR decoding and cross-validations. On the clean output, line-by-line three-way matching with 2% / EUR 1.50 OR-mode tolerance. Exports to common accounting ERPs.
What about Google Document AI or Amazon Textract?: They are IDP (not classic OCR) and among the best engines on the market. They are APIs: you have to integrate them into a full AP flow (intake, three-way matching, exceptions, export, archival). An SME that does not want to build software uses a turnkey solution.

Three things to remember

Classic OCR and IDP are not the same. One extracts plain text. The other understands the document. Spanish invoices (multi-VAT, withholding, correction invoices, FacturaE) are where the gap shows.
Classic OCR sits around 80-85% on line data on real invoices. IDP reaches 95-98% on standard formats and exceeds 99% when XML/FacturaE is attached.
For line-by-line three-way matching, per-line accuracy is the key metric. Without clean lines, fake variances and back to keying.

If you want to see the change on your invoices, try ininvoice. Also pricing and features.