AI document processing uses vision and language models to read a document in any layout, pull out the fields that matter, check them against your business rules, and hand structured data to your ERP. Lleverage's view is that it should be judged on how it handles the documents it gets wrong, not on a headline accuracy figure.
Every back office has the same scene. A supplier invoice lands as a PDF. Someone reads it, keys the header and the lines into Business Central or AFAS, matches it to a purchase order and posts it. An hour later a customer order arrives as an email attachment in a layout nobody has seen before, and the whole thing starts again. The work is invisible right up until the person who does it leaves.
That view comes from building agents for manufacturers, wholesalers and logistics operators whose order desks look much like yours. Our commercial interest is plain: we build this. What follows is what we have seen decide whether a document project works. It covers how the reading happens, what the system does with the documents it misreads, how far accuracy can honestly be pushed, and where the first payback sits. If document intake is your bottleneck, our order intake and confirmation agents are built for that job. Book a demo to see them run on your own files.
What is AI document processing, and how is it different from OCR?
AI document processing reads a document for meaning rather than matching it against a fixed template. It works out what kind of document it is, finds the relevant fields wherever they sit on the page, validates them against your rules, and returns structured records. Older approaches never got past the reading step.
The difference is easiest to see when a supplier changes its invoice layout. Template capture breaks, because the fields it was told to look at have moved. Optical character recognition keeps producing characters. It never knew that one number was a VAT amount and another a line total, so the output is text without meaning. A model that reads the document knows a total is a total wherever it sits. That is why the same approach copes with a Dutch supplier and an English one in one inbox.
| Approach | What it reads | Template per format | What it outputs | Where it breaks |
|---|---|---|---|---|
| Optical character recognition | Pixels turned into characters | Usually yes | Raw text with no meaning attached | Variable layouts, poor scans, handwriting |
| Template capture | Fixed zones on a known layout | Yes, one per supplier | Mapped fields | The day a supplier moves its fields |
| Robotic process automation | Input that is already structured | Not applicable | Keystrokes into a screen | Unstructured input, or a screen that changes |
| AI document processing | The whole document, read for meaning | No | Validated structured records | Genuinely ambiguous or unreadable documents |
None of this makes the older approaches worthless. Character recognition is still how a scanned page becomes machine readable at all. Rule-based automation is still the cheapest way to move data between two systems that already agree on a format. The reading layer is what sits between them, and we have written separately about why template-free reading beats traditional OCR on invoices.
Which documents does AI document processing actually handle?
In practice it handles any recurring business document with a stable meaning and an unstable format: supplier invoices, customer purchase orders, order confirmations, delivery notes, packing lists, certificates, technical specifications and freight documents. The harder the format varies between senders, the more there is to gain.
Volume and repetition matter more than document type. A document that arrives twice a year is not worth automating, however painful it is. One that arrives 400 times a month is worth automating even at four minutes each. Take Xpol, a fresh flower wholesaler. Roughly 20 minutes of manual work went into each large order: reading it, converting units, entering it into Business Central. That ran across about 150 orders a week. Nothing about that is exotic. It is simply the same small task repeated until it adds up to a job.
Technical documents behave the same way once you stop thinking of them as reference material. Oude Reimer, a precision machinery service business, unified 170 manuals from a long list of manufacturers into one searchable base. Triage that meant scrolling through hundreds of pages now returns a referenced answer in 70 seconds.
"Nobody can memorize every manual from every manufacturer. When a customer calls with a machine problem, the quality of the answer depends on who picks up the phone and what they happen to remember." Hugo Oude Reimer, Director, Oude Reimer
The pattern across both is that the document was never the deliverable. What people needed was the answer inside it, in the system where the next decision gets made. We make that argument at more length in our piece on turning unstructured documents into structured ERP data.
How does AI document processing get data into your ERP?
Extraction alone changes very little, and that is the most common way an AI document processing project disappoints. The value appears when the extracted fields are reconciled against what the ERP already knows and written back as posted records, so that no one has to retype anything into a screen afterwards. Five steps do the work.
- Capture. The document arrives by email, upload or portal and is classified by type before anything else happens.
- Extraction. Header and line-level fields are read from the document in its native layout.
- Validation. Extracted data is checked against live ERP records. Does the purchase order exist, do the lines match, is the supplier known, is the total inside tolerance?
- Exception routing. Anything that fails a check goes to a person with the document and the mismatch side by side, rather than posting blind.
- Write-back. Validated records are written into the ERP as posted documents, not into a queue that someone still has to clear.
Steps three and five are where most of the saved time actually lives, and they are also the steps that generic content about document AI tends to skip. Reading a PDF is close to a commodity now. Reconciling it against your live master data and landing it correctly in Business Central, SAP, AFAS or Exact is the part that removes back-office hours. That depends far more on how the agents connect to your systems than on the model doing the reading.
The proof of the whole chain is what happens at the end of it. Topa Bathroom Products now has over 90% of incoming orders processed straight into Business Central with no manual input. Customers get their confirmation within 30 seconds. The 4 FTEs who used to key orders all day moved to after-sales support and service planning.
What happens when the model reads a document wrong?
It will read some documents wrong, and how the system behaves in that moment decides whether anyone trusts it. A good implementation knows when it is unsure, routes that document to a person with the reason attached, and never posts a record it cannot stand behind. A bad one posts confidently and leaves you to find the damage in the ledger.
This is the question we would ask an AI document processing vendor first, and almost nobody leads with the answer. Extraction accuracy on a clean test set is the easiest number to publish and the least useful one to buy on, because your inbox is not a clean test set. What you want to know is narrower. Can the system tell a confident read from a shaky one? Does an unrecognised article code stop the posting or slip through it? When a required field is simply missing from the document, does someone find out before or after the invoice is paid?
Topa's agent is a concrete example of what the answer looks like in production. When a commission number is missing it drafts the response email rather than guessing. When it meets an article code it does not recognise, it flags the order for human review instead of posting it. Every processed email is labelled so the team can audit what the agent touched. None of that is glamorous, and all of it is why the team stopped checking every order.
The principle underneath is the same one that separates a supervised agent from a background process. Work the system can finish alone should run unattended. Work that needs judgement should arrive in front of a person already prepared. We have set out that split in detail in our piece on supervised agents and background automation.
How accurate is AI document processing in practice?
Accuracy is a per-document-type number, not a product number, and any figure quoted without naming the document type and the sender mix is close to meaningless. On a high-volume, repetitive flow from known senders, a well-configured agent is more consistent than a person, because it never gets bored on the four hundredth invoice. On a long tail of one-off documents from unknown senders, it will need more supervision, and pretending otherwise is how pilots lose credibility in week three.
Two things move an AI document processing accuracy figure more than the model does. The first is how much context the system has about your business: which suppliers exist, which article codes are valid, which customers have special unit conversions. Xpol's agent codifies 25 separate customer rulesets covering unit conversions, weekday-specific label text and multi-depot splits, all of which used to live in the heads of senior staff. The second is how tolerances are set. A tight tolerance sends more documents to a human and posts fewer errors. The right setting is a commercial decision about the cost of a wrong post, not a technical one.
The honest framing is that the machine takes the clean cases and people take the exceptions, with the boundary between them moving as evidence accumulates on your own documents. Accuracy is something you measure per flow during rollout, never something you accept from a benchmark.
Where does AI document processing pay off first?
It pays off first on the highest-volume document flow that currently ends in someone retyping. That is usually inbound customer orders in a wholesale or distribution business, supplier invoices in a manufacturer's finance team, or shipping and freight documents in a logistics operation. The industry matters less than the shape of the bottleneck.
Three tests sort a good first candidate from a bad one. The flow should be high volume and repetitive, so that saved minutes compound. It should have a clear definition of correct, so that validation is possible at all rather than a matter of opinion. And it should end in a system of record, because a document that gets read and then sits in a folder has not saved anyone anything.
Finance is usually the easiest place to prove the case. Invoice flows are high volume, well defined and measurable, which is why our supplier invoice and payment agents tend to be where mid-sized manufacturers start. Customer service is a close second. At J. Kisch & Zonen around 80% of incoming customer questions turned out to be repeats of each other, and that profile automates well.
How do you roll it out without a big-bang switch?
Not by cutting over. The approach that works is to run the agent alongside the existing process on one document flow, let it propose the extracted and validated record, and have a person confirm it. As accuracy proves out on that document type, confirmation narrows to exceptions only, and the next flow starts from scratch on the same terms.
That sequencing matters more than the model choice, because it changes what the team is being asked to do. Nobody is asked to trust a system they have never seen be right. They are asked to check its work for a few weeks, which is a far smaller request. The evidence they gather is what earns the switch, not a vendor promise.
"It's a matter of building trust in the organisation with these kinds of initiatives. You can't just throw something like this over the fence." Cees Maaskant, General Manager, Xpol
This is where we land after enough of these rollouts: the projects that fail rarely fail on extraction quality. They fail because someone tried to buy trust in one purchase order instead of earning it one document type at a time.
Frequently asked questions
Is AI document processing the same as OCR?
No. Optical character recognition converts an image into characters without understanding what they mean, and it usually needs a template per layout. AI document processing reads documents in any layout, identifies what each field is, validates it against business rules and outputs structured data. Character recognition is a component of the older pipeline, not a replacement for the reading layer.
What is the difference between AI document processing and RPA?
Robotic process automation moves already-structured data between screens and only works when the input never varies. AI document processing handles the unstructured input, such as a supplier invoice in an unfamiliar format, and turns it into structured records. They are complementary. The reading layer produces clean data, and rule-based automation or a direct ERP integration then acts on it.
Can AI document processing work with our existing ERP?
Yes, and that is where most of the benefit sits. The point is reconciling extracted data against live ERP records, including purchase orders, sales orders and master data, then writing validated documents back into Business Central, SAP, AFAS or Exact. Reading the document is half the job. Landing it correctly, with exceptions flagged before posting, is the other half.
How accurate is AI document processing compared with a person?
On high-volume repetitive document types it is more consistent than a person, because it does not tire or skip a check. On rare documents from unfamiliar senders it needs more supervision. Accuracy is measured per document type on your own data during rollout, and the sensible target is that clean cases run unattended while exceptions reach someone quickly.
Does AI document processing handle documents in multiple languages?
Yes, which matters for Dutch operations handling Dutch and English supplier and customer documents in one inbox. Mixed-language inbound is exactly the variability that defeats template-based capture, since a template is tied to specific labels in a specific position. Reading for meaning handles the same field regardless of the language it is labelled in.
See it run on your own documents
The only test that settles this is your own documents landing correctly in your own ERP. Not a demo dataset, but the exceptions you actually get. We will read your real invoices, orders or shipping documents, reconcile them against your ERP and show you what the agent does with the ones it is unsure about. Book a demo and bring the document flow that costs you the most time.