Document processing AI: 12 use cases with real numbers

What can document processing AI do today, and what can it not do?

It reads an incoming document and turns it into structured fields: invoice number, VAT number, total, date, line items. What it cannot do is guarantee that the value it read is correct. Vision models fail in a specific way, returning a number that is correctly formatted and factually wrong. That is why a validation layer and human exception handling belong next to the model.

This distinction matters more than it sounds. Classic OCR fails when it cannot recognise a character, and you get garbage in the field. You can see it. A vision model reads 42.50 off a receipt where the total is 45.20: valid number, valid format, nothing flags it. That failure mode is described in the 2026 OCR guide, and it is the single strongest argument that the model on its own is not a product.

Two things get conflated in the market and are worth separating. A RAG system exists to search and answer: you ask a question, you get an answer from your company documents. Document processing, or intelligent document processing, is structured extraction instead: every incoming file has to yield the same twenty fields, in the same schema, so the ERP can take them. Different metric, different architecture, different tolerance for error.

OCR or vision model: which one do your documents need?

For clean, templated, printed documents classic OCR is faster and cheaper. For noisy scans, handwriting and sender formats that change every month, the vision language model is more accurate. In practice you do not have to choose: the cheap engine runs first, and only the low-confidence pages go on to the expensive model. That routing is where most of the cost is decided.

Treat those numbers with some caution. The AIMultiple DeltOCR benchmark runs on 300 documents, all of them English. The olmOCR-Bench uses 8,413 unit tests across 1,403 PDF pages, also English. The per-document-type accuracy table originates with Parsli, which competes with the tools it is ranking, so it is not a neutral source.

What we do at this point is build a 100 to 200 document test set out of the client’s own files and run the candidates against it. That is a week of work, and after it you can talk about measured numbers instead of promises. Diacritics are the usual trap in Central European languages, the Hungarian ő/ű and ó/ú pairs being the classic example. Rule them out, do not assume them away.

How does a working document processing pipeline fit together?

In four tiers, each more expensive than the last. A document first tries the cheapest route, and only moves up when confidence falls below threshold. This is what keeps the cost under control: most of the incoming volume never reaches the expensive tier at all.

Calibrating the routing matters more than picking the model. A single page-level average confidence is not enough: critical fields such as VAT number, total and IBAN need their own stricter thresholds, with different rules per document class. Skip that and you either send everything to the expensive model or let bad values through.

The validation layer you should not go live without

Since the vision model produces plausible but false values, the error has to be caught after the model rather than inside it. Four checks run on every invoice in our builds, and each of them is cheap compared to a wrong posting.

• Arithmetic reconciliation: net plus VAT has to equal gross, and the line items have to add up to the total.
• Format checks with regular expressions on the date, the VAT number, the IBAN and the phone number.
• Cross-checking with a second model, but only on the critical fields, otherwise the cost doubles.
• Reconciliation against the structured e-invoice record where one exists, which for domestic B2B in most of the EU it increasingly does.

Measurement differs by task type too. Plain text is scored with character and word error rate, forms and receipts with exact match rate and per-field F1, tables with TEDS, question-answering style extraction with ANLS. If a proposal quotes one global accuracy percentage, ask which metric it refers to.

The 12 use cases: manual time, automation share, error rate, human review

Twelve document processing tasks follow, each with the same four data points. Half the list is publicly measured, half is not. We are not papering over that: the six measured cases carry a named source, the six without measurement are labelled as estimates.

The six measured use cases

The six with no public measurement

1. Incoming invoice

The best documented case on the list, and the most over-promised. The 2025 Ardent Partners AP benchmark puts the average cost per invoice at 9.40 USD, with the top quartile at 2.78 USD and average processing time at 9.2 days. The APQC median is 21.40 USD, its top quartile 10.18. Hypatos claims 85 to 92 percent straight-through processing in SAP and Oracle environments, while the independent all-buyer average sits around 25 percent.

The important ROI message is not the percentage, it is the cost structure. IOFM puts data entry at 30 to 35 percent of total invoice processing cost and exception handling at 20 to 25 percent. So the AI is aimed at roughly half the cost, not all of it. Anyone promising 80 percent savings on invoice processing has not looked at their own numbers.

2. Contract extraction

JPMorgan’s COIN system saved 360,000 lawyer and loan officer hours a year reviewing commercial credit agreements, across more than 12,000 contracts annually. The detail most agency write-ups leave out: that is 2017 data, nine years old. The LawGeex NDA study behind the 94 percent AI accuracy versus 85 percent for experienced lawyers is from 2018.

Extraction is close to fully automatable. Notice periods, penalties, warranties and governing law all come out cleanly. The legal qualification does not, and not because the model is incapable, but because professional liability cannot be delegated to an API. Write that boundary into the proposal.

3. Email triage

A Gartner-referenced measurement puts 31 percent of total agent handling time into reading, tagging and rerouting incoming messages, with another measurement at 20 to 30 percent of the working day. From Zendesk 2025 CX Trends data, above 500 emails a day roughly 22 percent of messages get lost to misrouting, duplication or SLA slippage.

Between 55 and 70 percent of first-tier cases can be deflected: order status, opening hours, returns, stock. On escalation, an automatic summary cuts handling time by 35 to 45 percent. The 98 percent classification accuracy figure is a vendor number with no independent measurement behind it.

4. CV screening

A recruiter scans a CV in 6 to 7 seconds and needs 2 to 3 minutes for a real read. Five hundred CVs come to 83 hours that way, against 15 minutes for automated screening. AI consistency runs at 85 to 95 percent where human inter-rater agreement is 60 to 70. Recruiters miss 20 to 30 percent of qualified candidates.

This is also the riskiest item on the list. EU AI Act Annex III 4(a) names the analysis and filtering of job applications explicitly as high-risk, and GDPR Article 22 prohibits fully automated rejection. Academic research shows persistent bias against women, older applicants and candidates with disabilities. Without human review this is not deployable.

5. Insurance claims

The 2026 CAIC claims operations playbook measures a 20 to 40 percent cycle time reduction in document-heavy lines, and 30 to 60 minutes saved per adjuster per file. Adjuster capacity rises 15 to 30 percent when change management is handled properly. The first production use case takes 60 to 120 days to stand up.

The playbook deliberately publishes no named insurer case study. The Aviva figure circulating on several blogs could not be confirmed from a primary source, so we do not use it.

6. Bank KYC

Manual due diligence on a complex institutional client costs between 1,500 and 3,000 USD, and a single verification takes over 18 minutes. Automated, verification drops under 30 seconds, per-case cost falls 48 to 70 percent, and total onboarding time by close to 90 percent. One unnamed regional bank case study reports turnaround falling from 5 working days to 4 hours.

AML hits, PEP matches and high-risk jurisdictions stay human decisions without exception. That is a legal obligation, not a design choice.

7. Medical reports

There is no public benchmark for this, in any language, which is why every number in the second table is an estimate. One thing is documented: Anthropic’s own vision documentation states that the model is not suitable for interpreting complex diagnostic imaging such as CT or MRI, and that its output does not replace a specialist opinion.

What works in practice is structuring the report text, extracting summaries for referrals, and preparing coding. The decision stays with the clinician, because GDPR Article 9 special category data and Article 22 both apply here.

8. Public tender documents

Reading through calls for tender and technical specifications takes time, and mistakes are expensive, because one missed eligibility criterion makes the bid invalid. We found no source measuring return on this. What the model does well is collect deadlines, formal requirements, reference expectations and evaluation criteria into one comparison table.

The bid decision stays with people, and the quirks of each national e-procurement system, the Hungarian EKR or the German e-Vergabe platforms, have to be designed into the extraction schema rather than assumed.

9. Warranty letters

Templated, short, repetitive, so on paper an ideal candidate. There is no public measurement. The practical question here is not accuracy but volume: at thirty warranty letters a month the build never pays back. Above a thousand it becomes one of the cheapest items on the list to automate.

10. Delivery notes

We found no standalone measured data, because procurement benchmarks treat the delivery note as part of the three-way match with the purchase order and the invoice. That is the good news: the delivery note is not a separate project, it is part of the incoming invoice pipeline, where measured returns already exist.

Discrepancies need human review, since a quantity mismatch has financial and inventory consequences. Writing the result back into the ERP or WMS is a systems integration task, not an AI one.

11. Meeting minutes

No measured ROI here either. The modern use case is simple enough: extract decisions, owners and deadlines from the minutes, then load them into the project system as tasks. Interestingly, the only public models trained on minutes are historical, such as the Transkribus model for Hungarian higher education council records.

Where the minutes carry legal effect, a shareholder resolution for instance, the output has to be approved every time.

12. VAT return preparation

This is drifting away from being an extraction problem across the EU. Under the VAT in the Digital Age package, adopted on 11 March 2025 and in force since 14 April 2025, digital reporting requirements for cross-border B2B apply from 1 July 2030, and Member States with domestic real-time reporting have to align by 1 January 2035. Hungary is already there: the NAV eVAT machine-to-machine interface produces a draft return from submitted data that can be approved programmatically.

Where AI earns its keep is line-level classification: posting suggestions, VAT rate assignment, exemption grounds, spotting reverse charge. Not in reading text off a page. We found no public measurement of return on this either.

What changes in the EU: e-invoicing mandates and non-English documents

The most useful technical fact for an EU buyer is that the invoice data you are trying to read off a PDF increasingly already exists in structured form. Germany has required every domestic B2B company to be able to receive structured e-invoices in EN 16931 format since 1 January 2025. Issuing becomes mandatory above 800,000 EUR turnover on 1 January 2027, and for everyone on 1 January 2028.

Hungary is a few years ahead on the same road, which is worth knowing if you are evaluating a nearshore supplier from this region. Domestic B2B invoices are reported to the tax authority within four days, and two endpoints of the NAV Online Invoice interface specification 3.0 give them back: queryInvoiceDigest returns aggregated data on search parameters, queryInvoiceDatareturns the full invoice by invoice number. Practically, that removes OCR from the majority of a Hungarian company’s incoming invoice flow.

So the architecture we build has three layers, and it transfers directly to Germany as the 2027 and 2028 deadlines land. Layer one is the structured e-invoice or tax authority record as ground truth. Layer two is image recognition, but only for what is not in there: foreign suppliers, receipts, expense claims. Layer three is automatic reconciliation between the two. This is more accurate than tools built purely on image recognition, and almost nobody sells it this way.

Diacritics are a real, measurable risk with the classic engines. Tesseract’s segmentation and training data were historically optimised for English and structured Latin script, and by Klippa’s account heavy diacritics combined with a curved typeface and a coloured background degrade accuracy noticeably. That covers German umlauts, Hungarian double acutes and Czech carons alike, and it means the language-specific Tesseract model is not dependable on a poor scan.

For handwriting the large vision models show 93 to 95 percent in English, and there is no comparable evidence for most European languages. The best available Hungarian data point is the Transkribus model for 19th and 20th century handwriting at a 10.7 percent character error rate on 1,265 pages of training material. That is historical material, not a goods receipt. Among multilingual handwriting benchmarks the 2026 METATR covers 29 languages, and Hungarian is not one of them.

What do GDPR and the AI Act require for document processing?

Under GDPR Article 22, a person has the right not to be subject to a decision based solely on automated processing which produces legal effects concerning them. The AI Act transparency obligations in Article 50 have applied since 2 August 2026. The high-risk obligations moved to 2 December 2027 under Regulation (EU) 2026/1744.

Where the data goes is a separate risk, and most proposals skip it. On the free Gemini API tier, by Google’s own statement, content is used for product development, which rules it out for client data. Anthropic’s vision documentation states that uploaded images are not used for model training, that image upload is ephemeral, and that PDF processing is eligible for the zero data retention option. If the document carries medical or attorney-client confidentiality, local execution is what remains: Docling, PaddleOCR or Tesseract on your own hardware.

For German buyers this is the deciding question rather than a footnote. In Bitkom’s March 2026 survey of 604 companies, data protection requirements were the top external barrier to AI adoption at 77 percent, ahead of the skills shortage at 70 percent. Bitkom’s Cloud Report published in June 2026 found 98 percent of companies say the provider’s origin matters and 68 percent would prefer an EU provider. An EU-based supplier processing documents inside the EU is answering a purchasing filter, not making a marketing point, which is part of why nearshore delivery from inside the EU keeps coming up in these projects.

Which documents are not worth automating?

Low volume, irregular documents that arrive in a different layout every time. At 50 a month, a 6,500 EUR build takes decades to pay back. Image extraction of domestic B2B invoices is not worth it either, where the e-invoice or tax authority record is more accurate. And neither is any task where legal or medical liability means someone has to read the output in full regardless.

There is a seventh case that rarely gets said out loud. If the process is slow because the approver does not open the email for three days, then speeding up extraction buys you nothing. Find the bottleneck first. Our process automation guide goes into that in more detail.

What does it cost to process one document?

Model fees run from 1.50 to 50 USD per thousand pages depending on the provider and the operation. That is a fraction of the total cost: manual processing runs 10 to 22 USD per invoice, automated processing 0.50 to 1 USD. Most of that difference is not the API, it is the build, the validation and the exception handling.

Frontier models need a separate calculation, because you pay per token rather than per page. Anthropic’s documentation puts a PDF page at 1,500 to 3,000 text tokens, with every page also entering as an image, and the image token ceiling at 1,568 on the standard tier. That works out to roughly 3,568 input tokens for an A4 page, plus around 300 output tokens for the JSON response.

Two cheap levers get skipped often. Batch processing halves both input and output pricing, and a document pipeline rarely needs a real-time answer. Reading from the prompt cache costs a tenth of the normal price, and since the long system prompt and the extraction schema are identical on every call, that is the fastest-paying optimisation available.

What does the build itself cost?

Our process automation price list puts a simple 1 to 3 step workflow at 100,000 to 500,000 Ft, a multi-system integration with error handling at 500,000 to 2,500,000 Ft, and AI-driven complex automation, meaning invoice OCR, AI classification and an approval flow together, at 2,500,000 to 10,000,000 Ft. Maintenance runs 30,000 to 150,000 Ft a month. At roughly 385 HUF per EUR, the rate on 14 August 2026, that is about 260 to 1,300 EUR, 1,300 to 6,500 EUR, and 6,500 to 26,000 EUR respectively, with maintenance around 80 to 390 EUR a month. We invoice international clients in EUR at the Hungarian central bank mid-rate on the invoice date, so the actual figure moves with it. The pilot takes 1 to 2 weeks, and payback typically lands at 3 to 9 months.

One worked example that fits the European mid-market profile: an unnamed SME case study reports a 65 percent reduction in data entry across 12,000 supplier invoices a year, 600 hours saved and 40,000 EUR of labour cost avoided. The source is a vendor and the client is not named, so use it as a model, not as evidence.

Summary and frequently asked questions

Where we stand on this

One thing is worth saying plainly, because the market avoids it. As of August 2026 there is no published, named, audited case study measuring the return on document processing AI at a Hungarian company. Not ours, not our competitors’. Anyone quoting local numbers is translating an international benchmark. That matters, because the setup in this part of Europe is technically different: with tax authority data already structured, the starting position is better than what the Western tools were built for.

If you are planning a document processing project, our process automation page describes how a build like this runs, the AI integration case studies cover what we do in seven different situations, and the live projects are on the AI portfolio page.

Sources

• Invoice processing benchmarks: WEX (citing Ardent Partners 2025), Lido (APQC, Ardent, IOFM), Hypatos
• Contracts and legal: ABA Journal on JPMorgan COIN (2017)
• Email, recruitment, claims, KYC: Fini Labs, Equip, CAIC playbook, Lorikeet
• OCR accuracy: AIMultiple DeltOCR, olmOCR-Bench, OmniDocBench, Parsli, Klippa on Tesseract
• Non-English measurement: Transkribus Hungarian models, F1000Research 15:181, METATR v1.0 (arXiv:2605.26712)
• EU e-invoicing and VAT: European Commission eInvoicing country sheet, Germany, VAT in the Digital Age (ViDA), NAV Online Invoice interface specification 3.0, NAV receipt data reporting, NAV eVAT M2M 2.0
• Law: GDPR Article 22, AI Act Article 50, AI Act Annex III
• German market data: Bitkom, Digitalisierung der Wirtschaft (2026-03-11), Bitkom Cloud Report 2026 (2026-06-17)
• Pricing: AWS Textract, Azure AI Document Intelligence, Mistral OCR 4.0, Unstructured.io, Docling, Anthropic price list, Gemini API pricing