Technology
Document AI
From pixels to validated fields: what each layer of document AI contributes, and what it cannot do alone.
The concept
What document AI returns that OCR does not
Document AI is a stack of readers, each handing the next one something more useful than it received, until pixels have become typed fields with a score and a check on each.
Optical character recognition answers one question: which characters are on the page, and where. On clean print it answers well, and there it stops. It does not know that the second date is the due date, or that the figure at the foot of page two is the grand total and the one above it a subtotal. Document understanding answers those questions, reading the words and the layout together, and returns typed fields that software can test.
The understanding is done in layers, each with a job. Vision cleans the image and finds the regions. Classification settles what the document is before a field is read, because a credit note read as an invoice passes every arithmetic check and is still wrong. Extraction reads key-value pairs and tables by meaning rather than position, so a supplier you have never seen works on their first invoice. A score is attached to each field, and validation checks the values against arithmetic, formats and your own masters.
None of these layers can tell you whether the invoice should be paid. That is a question for rules and the purchase order, and it belongs to orchestration. The reader's job is narrower and more testable: the right value for each field, and an honest score, including when it cannot read the field at all. For a CIO, the useful test is fifty of your own documents with the scores inspected field by field, rather than a demo on a clean sample.
Where it sits
Two stages of five, and a hand-off between them
Every PTAS AI workflow runs as Perception, Intelligence, Orchestration, Action and Verification. Reading starts in the first stage, ends in the second, and the other three work from what it returns.
In the products
What the reading layers do inside DocPro and FinSuite
The reading layers are DocPro. FinSuite starts where the record ends, taking the fields, their scores and the validation results into the finance workflow.
DocPro
Classification before extraction
Tax invoice, proforma, credit note, challan, statement or a custom type: settled first, because the type decides the schema, the validations and the thresholds. A scanned bundle is split into its documents at the same step.
DocPro
Key-value fields and line tables
Header values are found by meaning, so Inv No and Bill number both land in the invoice number field. Line tables keep rows as rows, and a table that runs onto page two stays one table.
DocPro
Handwriting, stamps and signatures
Detected as marks, read where legible, flagged where not. A stamp over the total lowers that field's score rather than hiding the fact that something covers it.
FinSuite
Vendor and GST validation
The supplier is resolved to your vendor master, bank details compared with what you hold, the GSTIN checked for format and status. A failed check holds the record, with the check named, before matching.
FinSuite
Thresholds set the queue
You set the score each field must reach, per field and document type. A grand total sits near the top; a remarks line can pass lower. The queue is the fields that fell short, with reasons.
FinSuite
Matching on scored fields
Quantities and prices are matched to the purchase order and goods receipt within your tolerances. A quantity read below threshold waits for a person first, so a doubtful read is never recorded as a price variance.
Worked example
One invoice and one receipt, read field by field
A two-page supplier invoice with one handwritten row, and a creased receipt photographed under a restaurant lamp. The same layers read both; the scores say where the doubt landed. Values are illustrative.
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.
Regions before fields
Header, line table and tax block are located first, so a date in the footer cannot be taken for the invoice date.
A table stays a table
Fourteen rows across two pages, in printed order, each quantity and rate on its own row.
One row to a person
The handwritten amendment on row nine fell below threshold and went to review alone. Thirteen clear fields were never touched.
A creased receipt, photographed at an angle · Illustrative example
One faded field goes to a person. The other seven post. An invented tax amount would have been worse than a flagged blank.
Image quality becomes a score
Skew and glare were corrected first. The faded tax line still could not be settled, so it came back empty with a flag.
Resolved against your data
The merchant was matched to a vendor record you hold, and the claim checked against earlier claims for the same merchant, amount and time.
Checked before the claim
Category assigned and the duplicate check cleared before an approver saw it. Validation ran on the way in.
Limits and controls
Where the reader stops
A reader cannot read what is not on the page. A faded tax line gets a flag, and the right output for it is that flag. Nor can a reader judge its own correctness beyond the score, and the score is worth exactly as much as its calibration. Calibrated means it behaves like a probability: among fields given the same score, the share that turn out right matches it. A reader that says 0.9 and is wrong half the time has a threshold that means nothing.
Two more limits are structural. Document AI does not know your vendor master or your open orders unless it is given them, so validation is as good as that data and no better. And a supplier who redesigns an invoice shows up as score drift before anyone notices, so scores are watched by supplier rather than averaged across the queue. The quickest way to see all of this is to test one of your own documents. The controls below exist because of these limits.
Calibrated on your documents
A sample of your documents is read and checked by hand before go-live. Thresholds per field and document type come from that measured curve, not from a default.
Validation before hand-off
Totals recomputed, dates checked for order, identifiers for format, names against your masters. A failed check is written into the record, never corrected silently.
Region and score on every field
Each value carries its score and the page region it was read from. A reviewer sees the line beside the value; an auditor sees the same a year later.
Flagged, never invented
A field the reader cannot settle returns empty, flagged, with a reason. A flagged blank is a control working; an invented value that passes arithmetic is a defect in your ledger.
FAQ
Questions evaluators ask about document AI
What is the difference between OCR and document AI?
OCR turns the pixels of a page into characters and positions, and stops. Document AI starts from that text and the layout and returns meaning: which document this is, which number is the invoice number, which of three totals is the one to pay. On a two-column invoice OCR returns two columns of unrelated text. Document AI returns a header, a line table and a tax block you can validate.
How is a confidence score calibrated, and can we rely on a threshold?
A score is the reader's estimate for one field on one document. It is useful when calibrated: fields scored at a given level turn out right at about that rate when checked. We measure that on a sample of your documents during onboarding, by field and document type, and set thresholds from the curve. Raising a threshold sends more fields to people; lowering it sends fewer; neither changes what the reader extracts.
Can it handle a file holding several documents, or a document running over several pages?
Both, and they are different problems. An invoice whose line table continues onto page two is read as one record, with the page-two figures recognised as the totals. A scanned bundle, or forty receipts in one PDF, is split first: each page is assigned to a document and each document is classified before any field is read. An ambiguous page boundary goes to review instead of merging two invoices into one.
What happens with handwriting, stamps and signatures?
They are detected as marks before any text is read, then read where legible. A clear handwritten quantity comes back as a value with a lower score than print; an unclear one comes back as a flag. A received stamp is returned as a stamp with its date, not as the invoice date. A signature across the grand total lowers that field's score, so the total goes to a person. We would not post on a handwritten total without review, and we say so.
Keep reading
Where document AI shows up
DocPro
The product the reading layers are built into: six agents, one pipeline, structured JSON out.
Read more →Intelligent Document Processing
Beyond OCR, framed as the business problem: classify, extract, cross-check, review.
Read more →Computer Vision
The perception layer in detail: image quality, regions, tables, stamps and signatures.
Read more →Document Data Extraction
Structured data from any business document, scored per field and validated before hand-off.
Read more →Next step
Test the reader on your own documents
Upload one document now and read the fields and scores it returns. For a proper evaluation, bring a sample of real invoices, receipts or statements and we will show you, field by field, where the thresholds would sit.