Almost every business runs on paper it did not ask for. Supplier invoices, delivery notes, receipts, faktur pajak, bank statements, KTP copies for onboarding. Someone opens each file, reads the numbers, and types them into a system that already exists. It is dull, it is slow, and it is where quiet mistakes creep in. For years the promised fix was OCR — optical character recognition — and for years it half-worked.
The reason it only half-worked is worth understanding, because in 2026 the problem is finally being solved differently. Old OCR turns pixels into text. That is all it does. It does not know that the number in the bottom-right is a total, or that a table has line items, or that “Rp 1.250.000” and “1,250,000” mean the same thing. You still had to write brittle rules to find each field, and those rules broke the moment a supplier changed their template. The new approach — vision-language models — reads a document the way a person does, and that difference is bigger than it sounds.
From reading text to understanding documents
A vision-language model (VLM) looks at the image and the text together. Instead of “here are the characters on the page,” it can answer “what is the invoice number, who is the vendor, what are the line items, and does the total match the sum of the rows?” It infers where a field is from context rather than from a fixed position, so it handles a layout it has never seen before. When the printed total does not match the line items, a good system flags it instead of silently passing bad data downstream.
That is the shift the industry is calling agentic document processing: not just extracting characters, but understanding the document and producing clean, structured output — JSON your software can actually consume.
Legacy OCR Vision-Language Model
------------------ ----------------------------
scan --> characters scan + text read together
| |
v v
raw text blob "invoice_no: INV-2026-0412
| vendor: PT Sumber Jaya
v total: 1250000
YOU write rules to items: [ ... ]
find each field total_matches_lines: true"
| |
v v
breaks when the adapts to new layouts;
template changes flags mismatches itselfWhy the accuracy jump actually matters
Numbers make this concrete. On semi-structured documents — the messy real-world kind, where every supplier’s invoice looks a little different — legacy OCR topped out around 78–82% field-level accuracy. Modern multimodal models routinely clear 95%, and on clean, standard invoices the better systems reach 97–99%. Independent 2026 benchmarks put printed-text OCR at 98–99% as well.
The gap between 80% and 98% is not a small quality bump. Think about what 80% means in practice: one field in five is wrong, so a human has to check every document anyway, which means you never really removed the manual work. At 98%, the model handles the ordinary cases on its own and a person only reviews the handful it is unsure about. That is the line between “a demo that impressed the boss” and “a process that saves your team hours every week.” It is also why intelligent document processing is one of the faster-growing corners of enterprise AI right now, with financial services leading adoption.
Where this pays off for Indonesian businesses
The documents that clog Indonesian back offices are exactly the ones VLMs handle well. Faktur pajak with their standard fields. Supplier invoices in a dozen different layouts. Delivery orders and receipts photographed on a phone, slightly crooked, under bad lighting. KTP and NPWP for customer or employee onboarding. Bank statements that need to be reconciled against your books. All of these are high-volume, low-joy, and error-prone when done by hand.
| Legacy OCR + templates | Vision-language model |
|---|---|
| needs a template per document type | works across varied, unseen layouts |
| reads text, no understanding of fields | knows what a total, date, or line item is |
| ~78–82% on messy documents | routinely 95%+, up to 97–99% on clean invoices |
| silently passes bad data downstream | can flag totals that do not add up |
| breaks when a supplier changes format | adapts without new rules |
The payoff is not “fire the finance team.” It is redirecting people from retyping numbers to checking exceptions and doing work that needs judgment. A supplier sends 300 invoices a month; the model reads all 300, gets 290 right on its own, and routes the 10 it is unsure about to a human. Your team reviews ten documents instead of keying in three hundred.
How to adopt it without getting burned
Two failure modes are worth naming up front. The first is trusting the output blindly. Even at 98% accuracy, some fields will be wrong, and the ones that matter most — amounts, tax numbers, account details — are exactly the ones you cannot afford to get wrong. The second is data privacy: these documents contain personal and financial information covered by Indonesia’s PDP law, so where they are processed and who can see them is not an afterthought.
The pattern that works is a confidence gate. Let the model do the reading, but put a validation step between its output and your real systems.
document in
|
v
+-------------------------------+
| VLM extracts structured data |
| + a confidence score/field |
+-------------------------------+
|
v
+-------------------------------+
| validation gate |
| - do the totals add up? |
| - required fields present? |
| - confidence above threshold?|
+-------------------------------+
| |
high confidence low confidence
| |
v v
auto-post human review
to your system then postStart narrow. Pick one document type you handle in volume — supplier invoices are the usual first pick — and one clear success metric, like “hours spent keying invoices per week.” Run the model alongside your current process for a couple of weeks so you can measure its real accuracy on your documents, not a vendor’s benchmark. Keep every extraction logged so you can see what it got wrong and why. Only when the numbers hold up do you let it post automatically, and even then only for the high-confidence cases.
Get those two things right — a validation gate and a careful rollout — and document processing stops being a data-entry tax on your team and becomes something that mostly runs itself. The technology is genuinely good enough now; the engineering is in wiring it up so you can trust it.
If you want help figuring out which documents are worth automating — and building the extraction, validation, and privacy controls to do it properly — see our software engineering services or talk to Bee Mata.