Insights · 11 min read
What intelligent document processing actually is, where it earns its cost back, the pipeline behind a working system, and realistic build costs.
By GGP Editorial
Most companies that say they want to "do something with AI" actually want to do something with documents. Invoices sit in an inbox, contracts pile up in a shared drive, claim forms arrive by email and get retyped into another system. Intelligent document processing, or IDP, is the software that reads those files, pulls out the fields that matter, and drops them into the right place without a person retyping them.
I write this from the vendor side. GlobeSoft is a software company founded in 2018 with 40-plus engineers and more than 300 delivered projects, and document-heavy workflows show up across our FinTech, accounting, and operations work. This guide covers what an IDP system actually is, where it earns its cost back, what the pipeline looks like, and what it costs to build one that holds up in production.
If you are still deciding whether to build AI at all, start with our piece on enterprise AI development, which covers the pilot-to-production path.
OCR turns an image of text into text. That is a solved problem and a small part of the job. IDP goes further: it works out what kind of document it is looking at, finds the fields that matter, extracts them, checks them against rules, and writes them to a downstream system. A plain OCR tool gives you the words on an invoice. An IDP system gives you the supplier name, invoice number, amount, due date, and line items, already validated and ready to post.
Three levels of difficulty matter more than any feature list:
Most vendors demo on structured documents and quote for semi-structured ones. The real work is usually unstructured, and that is where accuracy claims fall apart.
The strongest cases are processes where a person currently retypes or copy-pastes data from a document into a system, at volume. A few examples:
| Process | Document types | Where the value is |
|---|---|---|
| Accounts payable | Invoices | Fewer manual entries, faster approvals, early-payment discounts |
| Contract intake | Contracts and amendments | Find renewal dates, clauses, and obligations before they lapse |
| Loan and mortgage origination | Bank statements, payslips, IDs | Faster decisions and fewer data-entry errors |
| Insurance claims | Claim forms, receipts, medical reports | Lower processing cost per claim |
| Onboarding and KYC | Passports, licenses, utility bills | Faster signup, fewer compliance slips |
| Logistics | Bills of lading, proof of delivery | Less back-office data entry |
The common thread is volume plus a downstream system. If a process handles a few hundred documents a year, IDP is rarely worth building. If it handles thousands a month, the payback is usually fast and easy to measure.
An IDP system is not one model. It is a sequence of steps, and any one of them can fail.
The review step is the one buyers forget to budget for. No model gets everything right, so you need a screen where a human can confirm or correct a field in a few seconds, and you need that correction to feed back into the model. Without a good review screen, the automation becomes a slower way to do data entry.
Vendors quote field-level accuracy numbers, and buyers optimize for them. That is usually the wrong target. Two things matter more.
Straight-through processing rate, or STP, is the share of documents that flow end to end with no human touch. A system that extracts 99 percent of fields correctly but sends every document to review because one field falls below threshold has an STP rate near zero. A system that extracts 95 percent correctly but passes half the documents straight through is more valuable.
Cost per exception is the second number. The review step is where the remaining cost lives. If a reviewer can fix a document in five seconds, exceptions are cheap. If they have to open the original file, find the field, and retype it, the automation saved nothing.
The useful question to ask a vendor is not "what is your accuracy" but "at what confidence do you pass a document through, and what does your review screen look like".
Document processing has moved through three stages. Template OCR matched a fixed layout and broke the moment the layout changed. Machine learning models trained on labeled samples handled more variety but needed a lot of labeled data per document type. Large language models and vision models, released over the last few years, read a document more like a person does. They handle new layouts without retraining and pull fields by instruction instead of by template.
That does not mean you can drop a model on a folder of invoices and call it done. The model still needs a place to run, access controls, a validation layer, and a review workflow around it. We wrote about the model decisions in RAG vs fine-tuning and the integration path in how to add AI to existing business software.
One honest caveat: LLMs are good at reading but they make quiet mistakes. A hallucinated invoice number or a wrong amount is worse than a missing field, because it looks right. That is why validation rules and confidence thresholds are not optional in a production system.
You have three paths.
Buy an IDP platform. Hyperscience, ABBYY, Google Document AI, AWS Textract, and Microsoft Azure Document Intelligence are the names that come up most. You get a working product fast, but you pay per page or per document, and that pricing can climb as volume grows. The extraction is generic until you configure and validate it for your documents, so the out-of-the-box demo and the reality usually differ.
Build a custom system. You own the pipeline, the validation rules, and the data, and the per-document cost is much lower at scale. The upfront cost is higher and you are responsible for accuracy. This is the right call when document processing is core to your product or when your volume makes per-page pricing painful.
Layer on top of an existing platform. Many teams use an IDP vendor for extraction and build their own validation, review, and export layer on top. This gets you to market faster than a full build while keeping control of the parts that matter.
The decision usually comes down to volume and to whether document processing is a product you sell or a back-office cost. If you are leaning toward building, how to estimate a custom software project is the place to start.
Cost is driven by document variety, not document count. A system that reads ten thousand invoices from the same three suppliers is cheaper than one that reads five hundred documents of twenty different types.
The main cost drivers, roughly in order of impact:
As a rough guide, a focused IDP pipeline for one document type, with classification, extraction, validation, review, and export, typically lands between $40,000 and $90,000. A multi-document-type platform with a review workspace, integrations, and compliance controls runs $100,000 to $250,000 or more. These are ranges, not quotes, and the only number that matters is the one from a scoped proposal. We wrote about where the money goes in custom software development cost breakdown.
A single document type can go from kickoff to production in eight to twelve weeks. A multi-document platform with review, integrations, and compliance runs four to seven months. The schedule is usually set by data, not code. You need real samples to tune the model, and the quality of those samples determines the accuracy you get.
Plan to spend the first two weeks on samples and ground truth. If you do not have a labeled set of real documents, building the system before you build the dataset is doing it backwards.
Chasing accuracy instead of STP. A 99 percent field-accuracy number with a bad review flow delivers less value than 95 percent with a good one.
Starting with the model instead of the data. The documents are the product. Collect and label samples first, or the model has nothing to learn from.
Ignoring the review screen. Low-confidence documents have to go somewhere. If that somewhere is a spreadsheet, the automation is a mirage.
Underestimating integration. Extraction is only useful when the result lands in a system someone already uses. Budget for the ERP or accounting integration up front.
No feedback loop. The system only improves if reviewer corrections flow back into the model. A static model degrades as your documents change.
OCR turns images into text. IDP classifies the document, extracts the fields you need, validates them, and writes them to another system. OCR is one step inside IDP.
A focused pipeline for one document type typically lands between $40,000 and $90,000. A multi-document platform with review and integrations runs $100,000 to $250,000 or more. These are ranges, not quotes.
Buy if you need something fast and can live with per-page pricing and a generic extraction layer. Build if document processing is core to your product, or your volume makes per-page pricing painful.
It is the share of documents that move end to end without human review. A high STP rate matters more than a high field-level accuracy number.
Yes. Modern vision and language models handle handwriting and free-form text far better than template OCR, but accuracy drops and review becomes more important. Expect more human touch on unstructured documents.
Eight to twelve weeks for a single document type, four to seven months for a multi-document platform. Sample preparation usually sets the pace, not the code.
Usually not from scratch. Most builds start with an existing vision or language model and tune it with your documents, or configure a template-free extractor. See RAG vs fine-tuning for how we think about that decision.
GlobeSoft is a software development company founded in 2018, with 40-plus engineers and more than 300 delivered projects for over 100 clients across the US, Brazil, South Africa, and Singapore. We build custom software, AI products, FinTech systems, ERP and CRM, and SaaS platforms on a stack that includes Java, Spring Boot, Go, Python, React, Vue, and Node. Document processing shows up across our FinTech and operations work, from KYC onboarding to payment and accounting systems, so we know the accuracy and validation problems a production system has to solve.
If you are planning a document processing system, an AI automation project, or a FinTech product that has to read and validate documents, talk to us about your project. Send us a few sample documents and we will help you work through the build-versus-buy call, the pipeline, and what to ship first.
Tell us what you are building and where you are today. We typically reply within 24 hours.
