Every month, someone in your finance team opens supplier invoices, reads the invoice number, tax amount and total, and types them into the accounting system. Someone in operations does the same with signed delivery notes, and someone in sales checks KTP photos sent over WhatsApp before opening new customer accounts. Document AI, built on OCR, is the technology that takes over most of that typing.
Plain OCR (optical character recognition) only turns an image into text. Document AI goes further: it identifies the fields you care about, such as supplier name, NIK or grand total, checks them against business rules, and sends only the uncertain ones to a person. For most businesses the realistic goal is not zero humans. It is people reviewing exceptions instead of keying in every page.
This guide explains the difference, the specific problems of invoices, IDs and forms, the main technical approaches and their trade-offs, and how to measure accuracy and protect the personal data involved.
OCR versus document AI: what actually changes
The difference matters because buyers often pay for OCR and expect document AI.
| Capability | Plain OCR | Document AI |
|---|---|---|
| Output | Raw text with positions on the page | Named fields, tables and the document type |
| Layout | Reads line by line | Understands key-value pairs, tables and sections |
| New layouts | Needs a new template for each layout | Generalizes across layouts of the same document type |
| Validation | None | Business rules, confidence scores and cross-checks |
| Human work | Someone still interprets everything | People review only low-confidence or rule-breaking fields |
An invoice from a national distributor and one from a small local supplier with a handwritten note can look nothing alike, yet both have a supplier, a date, line items and a total. Document AI is built to find those fields in either one. Plain OCR gives you a page of text and leaves the rest to you.
Three document families, three different problems
Supplier invoices and tax invoices
Invoices come in hundreds of layouts, often with line items spread over several pages. The hard part is not reading the characters but trusting the result, so validation rules carry much of the weight:
- Line items should add up to the subtotal, and tax plus subtotal to the total
- The supplier's tax ID should match your supplier master data
- The invoice number should not already exist in your system, which catches duplicates
- Quantities and prices should match the purchase order and the goods receipt, the classic three-way match
Tax invoices produced through e-Faktur carry a QR code that links to the tax office's validation record. Reading that code alongside the visible text gives you a second source for key values, which is more dependable than OCR alone.
Identity documents for onboarding
A KTP photo from a phone brings glare from the laminated card, odd angles, blur and cropped edges. Good capture flows check quality in the app and ask the user to retake the photo before it is ever submitted.
Some checks come straight from the document's structure. The NIK has 16 digits, and digits 7 to 12 encode the date of birth, with 40 added to the day for women. If the birth date embedded in the NIK does not match the printed date of birth, either the extraction or the document is wrong.
Reading a KTP is not the same as verifying a person. Confirming that the identity is real is a separate step: regulated institutions use authorized identity verification channels, while other businesses typically rely on licensed e-KYC providers that have such access.
Forms, delivery notes and handwriting
Signed and stamped surat jalan, handwritten quantities, carbon copies and crumpled paper are the toughest category. Handwriting recognition is far less reliable than printed text, and checkboxes or signatures need their own detection logic. Sometimes the best automation is not OCR at all but replacing the paper form with a simple mobile form, keeping OCR for documents you cannot control, such as those from suppliers.
Choosing an approach
There are four main ways to build document AI. Many production systems combine two of them.
| Approach | Strengths | Weaknesses | Good fit |
|---|---|---|---|
| Template rules on top of OCR | Cheap and predictable for fixed layouts | Breaks whenever a layout changes | Your own forms, a handful of large suppliers |
| Pre-trained cloud document services | Fast start for invoices, receipts and IDs | Per-page fees, may need tuning for Indonesian formats, data leaves your network | Medium volumes of common document types |
| Open-source OCR plus a custom extraction model | Full control, can run on your own servers | Needs labeled data and machine learning engineering | High volumes or strict data rules |
| Multimodal large language models | Handle varied layouts from instructions and a few examples | Can produce plausible but wrong values, cost per page, needs strict validation | Varied documents at low to medium volume |
Pre-trained services from the major cloud providers, such as Google Document AI, Amazon Textract and Azure AI Document Intelligence, include models for invoices, receipts and general forms. Open-source engines such as Tesseract and PaddleOCR handle the text reading if you prefer to build the extraction yourself.
Multimodal language models deserve a specific warning. They read messy layouts surprisingly well, but when a value is unreadable they may return a reasonable-looking number instead of admitting uncertainty. Use them inside a pipeline with validation rules and human review, never as the final word on an amount or an ID number. Our overview of generative AI use cases covers where these models fit more broadly.
Designing the pipeline, step by step
A dependable document pipeline looks much the same regardless of the model inside it:
- Capture. Collect documents from an email inbox, an upload portal, a scanner or messages forwarded from WhatsApp, and convert them into a consistent image or PDF format
- Pre-process. Straighten skewed pages, crop backgrounds, reduce noise and split PDFs that contain several documents
- Classify. Decide what each document is: invoice, tax invoice, delivery note, KTP or something else
- Extract. Pull out fields and tables, each with a confidence score
- Validate. Apply business rules such as totals, NIK structure, supplier matching and duplicate checks
- Review. Send low-confidence fields and rule failures to a review screen that shows the image next to the extracted value, so a person can confirm or correct it in seconds
- Export. Post clean data to your accounting system, ERP or CRM through an API integration, keeping a link to the original image for audit
- Learn. Save every correction. Corrections become test data and, where useful, training data
The same pattern sits behind AI claims processing for insurers, where claim forms, receipts and medical documents are read, validated and routed to adjusters.
Measuring accuracy and protecting the data
Measure on your own documents
Vendor accuracy figures are measured on someone else's documents. Build a test set of a few hundred real documents across suppliers, quality levels and capture methods, with the correct values recorded by hand. Then track:
- Field-level accuracy, separating critical fields such as amounts and tax numbers from minor ones such as addresses
- Straight-through rate, the share of documents that pass every check without a human touching them
- Review time per document that does need a person
- Errors that slipped through, found later in reconciliation, which matter more than any average
Privacy and controls
KTP data, names, addresses and phone numbers are personal data under Indonesia's Personal Data Protection Law (Law No. 27 of 2022, UU PDP), whose two-year transition period ended in October 2024. In practice that means:
- Collect only the fields you need, for a stated purpose, and set a retention period
- Restrict who can view document images, and log every access
- Mask NIK and phone numbers in logs and test environments
- Check where a cloud document service actually processes data, because not every service is offered in an Indonesian region, and put a data processing agreement in place with each provider
How Weaveward can build this for you
We would start with the one document type that costs your team the most time, such as supplier invoices or KTP onboarding, and collect a sample of a few hundred real documents to benchmark two or three extraction approaches on your own data. The first delivery would be an intake pipeline with validation rules and a review screen, connected to your accounting system or CRM, and measured on field-level accuracy and review time before we automate the next document type.
From there we would add document types one at a time and set up access controls and retention rules that fit UU PDP. See our AI solutions for document automation, or talk to our team and bring a few sample documents.