OCR turns pixels into characters. IDP fills in a template it was trained on. DocPro reads your schema instead, pulls every field with the page and coordinates it came from, then runs the arithmetic and the registry checks itself. When a check fails it goes back and re-reads that part of the page. Anything it still cannot stand behind arrives labelled, with the crop attached.
The interesting part is not the model. Every vendor has access to a good multimodal model now, and on a clean digital invoice they all land in roughly the same place. The difference shows up on the document nobody planned for.
Agentic means there is a loop around the model. It reads your schema and decides what to look for. It pulls candidate values and keeps track of where each one came from. Then it checks its own work: do the fourteen line items add up to the printed subtotal, does the recomputed CGST match what is on the page, is that GSTIN even a valid GSTIN, is that date real. If a check fails, it crops the region, zooms in, and reads it again. Three passes, then it stops and tells you which check failed.
A traditional pipeline has no equivalent of that second look. It produces a value and a confidence number, and the confidence number is a statement about how the pattern matched, not about whether the number is right.
That is why IDP fails quietly. It is confident and wrong at the same time, and the first person to notice is whoever reconciles the ledger three weeks later.
Each generation solved something the last one could not, and each one still has a job it does better than the others.
Optical character recognition. Converts marks on a page into characters and coordinates. It has no concept of a field, a total, or a supplier.
Intelligent document processing. OCR, a classifier, a layout model and a rules engine wired together. Trained per document family, tuned by hand.
Agentic document extraction. A multimodal agent reads the page against your schema, verifies its own answer, and re-reads the page when a check fails.
The difference is not accuracy on a clean invoice. It is what happens on the messy one nobody trained for.
| Dimension | OCR | IDP | ADE (DocPro) |
|---|---|---|---|
| What it reads | Characters and their coordinates | Characters, plus a learned layout for trained document families | The page as a page. Text, table structure, checkbox state, stamps, signatures, handwriting, and how they relate |
| How you specify fields | You draw zones on a sample and hope the next document lines up | You label a training set per family, then write rules for what it misses | A JSON schema. Field name, type, one line of description |
| A layout it has never seen | Zones miss. The output is wrong and nothing flags it | Accuracy drops until someone labels more samples or adds a rule | Processed on the first document. No training run, no waiting |
| Table across a page break | Two unrelated blobs of text | Usually two separate tables. Carried forward headers confuse it | Stitched into one table. Continuation rows detected, header carried forward |
| Handwriting, stamps, checkboxes | Handwriting mostly fails. A stamp becomes noise on top of the text underneath | Handled if a model was trained for it, which usually it was not | Read as their own signals. A stamp covering a field is flagged rather than guessed through |
| Does it check its own answer | No | Only what you coded into the rules engine afterwards | Yes, before returning. Line items summed, tax recomputed, GSTIN checksum, dates parsed, IFSC looked up |
| What you get per field | A string and a bounding box | A string and a confidence number with nothing behind it | Value, type, page, bounding box, confidence, and every check that ran with its result |
| When it is wrong | You find out in the ledger, weeks later | Confidence is often high on the wrong value, because the pattern matched | The failing check names itself. The field goes to review with its crop attached |
| Setup before first useful output | Hours per template, repeated per vendor | Weeks. Sample collection, labelling, tuning, then rules | Under a day for a first schema. Refinement means editing field descriptions |
| Ongoing maintenance | Every vendor layout change breaks something | Retraining cycles and a rules file nobody wants to touch | Corrections in the review queue become examples for that vendor. No retraining cycle |
| Cost shape | Cheap per page, expensive in human correction | Licence, plus a labelling effort, plus an integrator | Higher per page than raw OCR. Lower once you count the review hours it removes |
| Where it is still the right tool | Search and archival indexing across a document store | A single fixed form at very high volume, where a trained model is cheaper per page | Long tail vendor mixes, mixed quality scans, and anything that needs an audit trail |
Scroll the table sideways on a narrow screen.
A three page vendor invoice from a supplier onboarded last week, so no template exists for it. Scanned at 200 dpi on an office MFP, slightly skewed. Fourteen line items, the table starts on page 1 and continues onto page 3. Tax split into CGST and SGST at 9 percent each. An APPROVED stamp across the middle of page 2, partly over the quantity column. The PO number written by hand in the top right corner.
TAX INVOICE Suvidha Metals Pvt Ltd
INV-2026-0847 14/06/2026 GSTIN
06AABCP1429R1ZQ Item Qty Rate
Amount 1 M8 hex bolt 500 12.00
6000.00 2 MS flat 40x6 120 ...
A P R O V E D 12 ...
1,42,500.00 12,825.00 12,825.00
1,68,150.00Every character on the page, and no way to tell which one is the invoice total. Column boundaries are gone, so quantity and rate interleave. The stamp lands in the text stream as extra letters sitting inside the quantity column.
invoice_no INV-2026-0847 0.96
invoice_date 14/06/2026 0.94
supplier Suvidha Metals 0.91
total 1,42,500.00 0.93
line_items 9 of 14
po_number nullHeader fields are right, because the layout is close enough to a trained family. Then total picks up the taxable value instead of the invoice total, at 0.93 confidence, and nothing in the pipeline disagrees with it. Page 3 was classified as a separate document, so five line items never arrive. The handwritten PO number is skipped.
invoice_no INV-2026-0847 0.99
invoice_date 2026-06-14 0.99
supplier_gstin 06AABCP...1ZQ 0.98
checksum ok, state 06 = HR
taxable_value 142500.00 0.99
cgst 9 / sgst 9 12825.00 ea 0.97
recomputed, matches page
grand_total 168150.00 0.99
14 line items summed
po_number PO/26/1183 0.88
handwritten, p1 top right
line_7.qty 12 0.61
under stamp -> REVIEWFourteen line items across the page break, summed and compared against the printed subtotal. Tax recomputed and checked against the state code inside the GSTIN. One quantity sits under the stamp, so it is held at 0.61 with the crop attached instead of being posted.
Seven layers. The fourth one is the reason the output is different, and it is the layer most vendor diagrams draw as a single box labelled AI.
Every way a document can arrive, and the hash that stops you paying the same invoice twice.
Cheap fixes that raise every score downstream. Skipping this layer costs more accuracy than any model choice.
The page turned into something a model can reason over, with coordinates preserved so every value stays traceable.
The part that makes it agentic. Not one pass, and not one guess. A failed check sends the agent back to the page: crop the region, rezoom, read again, try the second candidate. Bounded at three passes, so a bad scan cannot loop forever.
After the third pass the field goes to review carrying its failure reason, rather than a value nobody can defend.
Your rules, held separately from the model. This is where a technically correct read gets rejected for business reasons.
One decision per document: post it, queue it, or refuse it. Thresholds are numbers you own, not defaults we chose.
Where the answer goes, and what you can prove about it six months later during an audit.
Most ADE architecture diagrams show the day everything worked. These are the boxes that decide whether the thing survives month end.
Most teams are through the first three in an afternoon.
POST /v1/extract with the file, or drop it in a watched folder, or forward it to a DocPro inbox. PDF, JPG, PNG, TIFF, DOCX and XLSX. A PDF holding several documents gets split before anything else runs.
A JSON schema: field names, types, and a line of description for each. No coordinates, no sample labelling, no template per vendor. Start from the invoice, bank statement, KYC, receipt or purchase order preset and edit it.
It classifies the document, works out a search order from your schema, and pulls candidate values with the page and coordinates attached to each one. Nothing is committed yet.
Arithmetic, tax recomputation, GSTIN and PAN format, IFSC lookup, date parsing, duplicate hash against the last 24 months. A failed check sends the agent back to that region of the page rather than out to your ERP.
You set the numbers, per field. Strict on amounts and tax, looser on a description string. Clean documents post. Anything below threshold or failing a rule goes to review with its crop.
JSON on the response, a webhook to your endpoint, or a posted document in SAP, Oracle, Tally, Zoho or Dynamics. Corrections made in review are stored against that vendor and used on their next document.
Three lanes, and a document lands in exactly one of them. The split below is what a mostly digital AP mix looks like once thresholds are tuned. A mix full of phone photos looks nothing like it.
You describe the fields. DocPro returns values, where each one came from, and every check that ran on it. There is no template to maintain and no per-vendor configuration to keep in sync.
Full field reference, error codes and webhook payloads live in the DocPro API docs.
Four situations where an agent still struggles. You will meet all of them in a pilot, so it is better to say them now.
A creased thermal receipt shot at an angle under a fluorescent tube is a bad input for any system, including ours. Deskew and rezoom recover some of it, and accuracy still drops.
A 1 that could be a 7, written quickly on a delivery note, does not become readable by reading harder. The agent reports low confidence instead of picking one. Some teams find that irritating in week one.
The agent verifies arithmetic and registry formats on its own. It cannot know that one vendor bills in USD but must post in INR at the invoice date rate unless that sits in the policy layer.
If you process a million copies of the same layout every month and nothing about it ever changes, a purpose trained model costs less per page than an agent that reasons about each document.
Your invoices carry bank details, GSTINs and payment terms. They are treated accordingly.
Processing runs in the region you choose. Indian customers can keep originals, crops and extracted values inside India. Retention windows are yours to set, and a purge removes the evidence crops along with everything else.
Role based access down to the field. A reviewer working the AP queue has no reason to open the bank statement queue, so they cannot. Every view and every correction is written to an append only log with a user and a timestamp.
TLS in transit, AES-256 at rest, keys rotated on a schedule. API keys are scoped per environment and per document type, so a test key cannot reach production documents by accident.
Customer documents are not used to train foundation models. Corrections made in your review queue stay inside your tenant and improve your vendors, not somebody else's.
We co-sign a Data Processing Agreement before any document leaves your environment. Use your paper or ours, either works.
DocPro can deploy inside your own cloud account or on-premise, with customer-managed encryption keys. This changes the commercial shape of the deal, so it is quoted case by case.
If your question is not here, a 30-minute call with an engineer is usually faster than email.
A method where a multimodal model reads a document against a schema you define, then runs a plan, extract, verify and repair loop. It checks its own output against arithmetic and registry rules, and re-reads specific regions of the page when a check fails, rather than emitting a value it cannot support.
IDP pipelines chain OCR, a classifier, a layout model and a rules engine. They work well on layouts they were trained on, and they need retraining or new rules when a vendor changes format. ADE is schema driven rather than template driven, so a new layout is handled on the first document, and the agent verifies its own answer before returning it.
Character recognition still runs underneath as one signal among several, alongside page layout, table structure, checkbox state and stamp detection. On clean digital PDFs the embedded text layer is read directly and no recognition step runs at all.
On clean, machine generated PDFs with a tuned schema, field accuracy usually lands between 95 and 99 percent. Phone photos, faxed copies, carbon paper and heavy handwriting drop that materially. We run a paid pilot on your own document mix before quoting a number, because a number measured on someone else's documents tells you nothing useful about yours.
No. You describe the fields you want in a JSON schema with types and short descriptions. A new vendor layout is processed on the first document that arrives. Corrections made in the review queue are stored as examples for that vendor and improve later runs without a training cycle.
GSTIN format and checksum are validated, the state code is compared against the supplier address, and the CGST, SGST and IGST split is checked against the place of supply. HSN and SAC codes, PAN format, TDS sections and IFSC codes are each validated against their own rules. A mismatch routes the document to review with the failing rule attached.
Yes. A table that breaks across a page boundary is stitched back into one table, carried forward headers are recognised as headers, and running balances in bank statements are checked from the opening balance to the closing balance across the whole file.
It says so. Every field carries a confidence score, the page and coordinates it came from, and the result of each check that ran on it. Fields below your threshold, or fields that failed a check, go to the review queue with the cropped evidence attached rather than into your ERP.
The bent ones, the photocopied ones, the vendor who redesigns their invoice every quarter. We run them through DocPro, send back every field with its evidence and confidence, and tell you honestly which ones we would not automate yet.
