Solutions · Documents
Document Data Extraction
Structured data out of any business document, with a confidence score on each field and validation before hand-off.
Why extraction is hard
Document extraction, as people describe it
Nobody complains about character recognition. They complain about the tool that reads the wrong date, the templates that break when a supplier changes a logo, and the team that still checks every document anyway.
What you hear
The OCR gets the numbers wrong
A tool that reads characters well and still returns the invoice date as the due date, because it had no idea which of the three dates on the page was which.
What you hear
It worked until the supplier changed their layout
Templates built for the forty biggest suppliers, each of which breaks quietly when the supplier redesigns their invoice. Nobody notices until the totals stop adding up.
What you hear
We still check every one
The extraction is good enough that nobody trusts it and bad enough that nobody can skip the check. The team reviews everything, which means the tool saved the typing and nothing else.
What is underneath
Characters are not fields
Reading text in the right order is a solved problem. Knowing that this number is the taxable value and that one is the total is a different problem, and it is the one that matters.
What is underneath
No measure of doubt
A value comes back as a value, whether the agent was sure or guessing. Without a confidence score there is nothing to route on, so everything gets routed to a person.
What is underneath
Validation happens downstream
The extracted data is handed over as-is. The arithmetic check, the vendor lookup and the GSTIN format test happen in the next system, if they happen, by which point the error has a document number.
How PTAS AI automates it
Read by meaning, score every field, validate before hand-off
The extraction is an agent that knows what kind of document it is reading, says how sure it is about each value, and checks the record against arithmetic and your masters before anything downstream sees it.
-
01
Understand
DocPro first classifies the document, so an invoice, a purchase order, a bank statement, a PAN card and a delivery challan each go to the agent built for that type. The agent then finds fields and tables by context rather than position: the total is the total because of what surrounds it, not because it is in the bottom right corner.
A PDF becomes a typed record, whoever designed it
-
02
Decide
Every field carries a confidence score and a pointer to the region of the page it came from. The record is then validated: line items are summed and compared with the stated total, dates and tax numbers are checked for format, and values are looked up against your masters, so a vendor name becomes a vendor ID and an unknown one is flagged.
Each value comes with how sure the agent was
-
03
Act
Fields above your confidence threshold and passing validation are released. Fields below it go to a reviewer, who sees the value, the score and the page region, and confirms or corrects that field alone. The rest of the document does not wait. Corrections feed back, so the same supplier's next document reads better.
Review is per field, not per document
-
04
Verify
The validated record is delivered as JSON through the API, as a file to a folder, through a webhook or straight into the ERP, with the document attached and the extraction log kept. Anyone can later see what was read, with what confidence, who corrected what and what was delivered.
The output is traceable to the pixel it came from
The workflow
What one document looks like when it comes back
A two-page invoice with fourteen lines and one handwritten amendment. Thirteen rows and every header field cleared the threshold. One row did not, so one row went to a person.
One invoice, as the agent returns it · Illustrative example
Thirteen fields cleared the threshold and posted. One handwritten amendment did not, so that row alone went to review.
Context, not coordinates
Fields are found by what they mean, so a redesigned layout does not break the read.
A score on every field
Confidence is what makes it possible to route one field and release the rest.
Validated before hand-off
Arithmetic, formats and master lookups run inside the extraction, not in the next system.
Key capabilities
Eight things the extraction has to do well
Reading a clean, native PDF is table stakes. The awkward inputs, the long tables, the validation and the delivery are where extraction projects succeed or quietly fail.
Input
Any channel, any quality
Scans, phone photos, native PDFs, emails with attachments and portal downloads. Deskew, de-noise and page splitting happen before reading, and a document that arrives as six images becomes one record.
Input
Classification first
The document type is identified before extraction, so multi-document bundles are split and each page goes to the right agent. Unknown types are routed rather than guessed.
Reading
Header fields and tables
Named fields plus line tables of any length, across page breaks, with merged cells and wrapped descriptions handled. The table comes back as rows, not as text.
Reading
Handwriting, stamps and amendments
Handwritten amendments, stamps and tick boxes read where possible and flagged with lower confidence where not, so a hand-corrected quantity goes to a person instead of being read as printed.
Validation
Arithmetic and format checks
Lines summed and compared with totals, tax recomputed, dates and identifiers tested against their formats. A document whose arithmetic does not hold is flagged, not released.
Validation
Master data lookup
Vendors, customers, items, accounts and GSTINs resolved against your masters inside the extraction, so the output carries your IDs and unknowns are surfaced early.
Output
Your schema
Standard schemas for the common document types, and your own schema for the rest, with field names, types and validation rules you define. The same document can be delivered in more than one shape.
Output
Delivery and feedback
JSON by API, webhook on completion, file drop, or direct posting into the ERP. Reviewer corrections are captured and used to improve reading for that document source.
Review and exceptions
What each approach hands you
The question to ask of any extraction tool is what it does with the document it was not built for. The answer separates characters from fields, and fields from checked data.
What each layer hands you
A block of text in reading order. Correct characters, no idea which of them is the invoice total.
Named fields, as long as the layout matches a template someone built. A redesign breaks it silently.
Typed fields found by context, validated against your masters and arithmetic, each carrying a confidence score and a route to review when it falls short.
The difference is not accuracy on a clean sample. It is what happens on the document nobody anticipated.
A reviewer in this workflow sees a short queue of fields, not a pile of documents. Each item shows the value the agent read, its confidence and the region of the page, and the reviewer confirms or corrects that one value. The document itself has usually already been delivered with that field marked pending. Corrections are kept, and the next document from the same source is read with them in mind.
Business outcomes
What changes, and how you would measure it
We do not quote accuracy on your documents before reading them. We do agree the measures up front, on your paperwork, so the decision to extend is based on something.
What changes
Straight-through rate, by document type
The share of documents whose every field cleared the threshold and validation without a person. Track it per type and per source; it tells you where to tune.
What changes
Fields reviewed, not documents reviewed
The number of fields a person touched, divided by the number of fields extracted. The old measure, documents checked, hides the difference between a glance and a retype.
What changes
Accuracy on your documents
Measured by running a month of already-processed documents through and comparing with what your team recorded. This is the only accuracy figure worth quoting, and it is yours.
What changes
Time from arrival to data
Measured per document type, from the file landing to the validated record being available. For a clean document it should be minutes, with no queue in front of it.
What changes
Errors found before the next system
Arithmetic failures, unknown vendors and malformed identifiers caught in extraction rather than in the ERP or the return. Each one would have had a document number by the time it was found downstream.
What changes
Review time per held field
How long a reviewer spends on a flagged field. With the value, the score and the page region on one screen, it should be seconds, and the queue should clear every day.
Integrations
The data goes where the next step is
Extraction on its own is only useful if the record lands in the system that needs it. The API and webhooks are the usual route; direct posting into the ERP through FinSuite is the shortest one.
REST API
JSON in and out · any system
Webhooks
Completion and review events
SAP
ERP · API, IDoc or file
Oracle
ERP · API or file
Microsoft Dynamics
ERP · API
NetSuite
ERP · API
Tally
Accounting · XML import
Zoho
Accounting · API
QuickBooks
Accounting · API
Four integration methods are possible: native integration, API integration, file or flat-file exchange, and custom integration. The systems named here are planning examples; which method applies to your instance, and the schema the data is delivered in, is confirmed during assessment rather than assumed. See the DocPro API for request and response shapes.
Security and governance
Controls an auditor would recognise
Extracted data is only as trustworthy as the record of how it was extracted. These are the controls built into the workflow, and the DocPro security page has the detail.
Confidence thresholds you set
The threshold below which a field goes to review is yours, per document type and per field if you want, and every release and every review is recorded against the threshold in force at the time.
Nothing invented
A field the agent cannot read is returned as unreadable with a low score, not filled with a plausible value. This is a design rule, and it is why the confidence scores can be trusted to route on.
A complete extraction log
Each document carries the image, the classification, every field with its score and page region, the validation results, any correction and who made it, and what was delivered where. Retained for the period you set.
Data handling
Documents are processed and retained under your retention policy, with role-based access, identity fields masked on export where you require it, and cloud, private cloud or on-premise deployment where supported. ISO/IEC 27001-aligned practices; see the DocPro security page for the specifics.
Product connection
The product that delivers it
Document data extraction is DocPro, agent by agent. The solution is the right agents, your schema and your thresholds, with delivery into whatever comes next.
FAQ
Questions operations and IT teams ask
How is this different from OCR, or from the IDP tool we already have?
OCR gives you characters in reading order. Template-based IDP gives you named fields for as long as the layout matches a template somebody built. DocPro finds fields by context, validates the record against arithmetic and your masters, and puts a confidence score on every value, which is what lets you release most of a document and review one field of it. The difference shows least on a clean sample and most on the document nobody anticipated.
What accuracy do you get?
On your documents, we do not know yet, and we would rather say so than quote a figure measured on someone else's. The right test is a month of documents you have already processed, run through DocPro and compared with what your team recorded, field by field. That gives you an accuracy number per document type and per field, on your own paperwork, before any commitment. Published ranges for standard document formats exist, but yours is the number that matters.
What happens to a document the agent cannot read?
The fields it could not settle come back with a low score and go to a reviewer, who sees the value, the score and the region of the page, and settles that field alone. A document whose arithmetic does not hold, or whose type cannot be identified, is flagged rather than released. The design rule is that a flagged blank is always better than a plausible guess.
Can it handle our own document types?
Yes. Standard agents cover invoices, receipts, purchase orders, bank statements and identity documents. For anything else, a custom document agent is configured with your schema and your validation rules and tuned on your samples. Delivery notes, lab reports, lease agreements and insurance forms have all been done this way.
How do we get the data out?
However the next system wants it. JSON through the API, a webhook when a document completes or needs review, a file dropped to a folder in a format you specify, or a direct posting into the ERP through FinSuite. The document image and the extraction log stay attached to the record whichever route it takes.
Keep reading
Related solutions and products
DocPro
The product these agents live in, and the full list of document types.
Read more →Intelligent Document Processing
How classification, extraction and validation fit together underneath.
Read more →Document Workflow Automation
What happens after extraction: routing, approval and filing.
Read more →Test Your Document
Run one of yours through DocPro and see the fields and scores come back.
Read more →Next step
Send the document that breaks your current tool
The redesigned invoice, the six-page statement, the form with the handwritten amendment. See the fields and the scores come back, then decide.