Every document-AI demo ends on the same triumphant frozen frame: the extracted invoice, each field lit with a colored box that traces the number back to the exact pixel it came from, a confidence score beside every value. It is genuinely impressive work — and it stops one step short of the only step your auditor asks about. Grounding proves where the number came from. It says nothing about who let it post. The liability in regulated finance was never in the read. It is in the act.
The part the demo never shows
Let me give the category its due first, because it has earned real credit and any honest argument has to start there. The move to expert-guided labeling and rapid model training genuinely put computer vision within reach — teams that could never have stood up a bespoke extraction model now train one on their own document set in an afternoon. Pixel-level grounding and source citations are a genuine advance: an extracted field that points back to the precise region of the page it was read from is a verifiable read, and that verifiability is a real answer to hallucination. Confidence scores paired with human-in-the-loop review are a pragmatic, honest middle path — the model tells you where it is unsure and a person adjudicates the rest. And edge deployment behind enterprise certifications — SOC 2, HIPAA, zero-data-retention — is real assurance for documents you cannot send to somebody else's cloud.
All of that is true. All of it governs the same thing: the model and the read. Accuracy, drift, labeling quality, provenance of the pixel. It is a rigorous, well-instrumented answer to the question "is this the right number?" Then the demo ends — and the extracted JSON leaves the frame. Somewhere off-screen, an RPA bot picks it up and keys it into accounts payable, or an ERP interface table ingests it and a posting job commits it, or a workflow engine routes it to a payment run. The invoice gets paid. And not one of the controls that made the read trustworthy travels with the number into the system that acts on it.
'Agentic' stops at the page edge
Watch how the newest positioning describes its own reach and you can see exactly where the ambition ends. The document-AI platforms call themselves agentic — and the agency, precisely scoped, is reading: the agent plans the extraction, verifies its own fields, retries the low-confidence ones, cites its sources. That is a better reader. It is still a reader. The managed OCR and IDP endpoints are even plainer about it — they emit clean structured fields and hand them to "your downstream system." In both cases the consequential act, the posting, is quietly reclassified as the customer's integration problem. It is drawn as an arrow leaving the diagram.
The most advanced vendors do close that arrow, and I will not pretend otherwise — piping structured fields straight into an ERP, an MES, or an RPA bot is genuinely more end-to-end than handing back a JSON blob and wishing you luck. Concede it plainly. Then look at what actually got built. The extraction lives in one tool, governed as a model. The decision-and-action logic — the approval limits, the segregation of duties, the "who is allowed to release this payment" — lives in a different tool, authored by different people, on a different schedule. No policy crosses the wire; only data does. What you are left with is a split-brain audit: one system can tell you, in beautiful detail, what it read off the page, and a second system can tell you what it did — and nothing owns the sentence that joins them. The read is provable. The act is orphaned.
- The read is governed; the posting is not. Confidence and grounding gate whether a field is correct. They never gate whether the resulting entry is authorized — that check, if it exists, happens later, in another system, under another owner.
- A confidence score is not an approval. "98% sure this is $4,812,000" is a statement about the pixels. It is not a statement that this vendor is on file, that this amount sits under the approver's limit, or that the person releasing it is not the person who entered it.
- The wall has no memory. Once the JSON is thrown over it, the extractor cannot know whether the bot posted once, twice, or to the wrong period — and the bot cannot know how sure the extractor was. Reconciling the two is a quarter-end project.
The liability is in the act, not the read
If you run accounts payable, or you sign the SOX certification, you already know this in your bones: no regulator has ever fined a company for a low-confidence bounding box. They fine you for the payment. The liability lives entirely in the act — who let this invoice post, under what policy, above which approval limit, and whether the person or agent that read it is the same one that released it. Those are not questions about pixels. They are questions about authorization, segregation of duties, and threshold control, and they attach to the moment money moves — not the moment a field was extracted.
This is why "extraction accuracy" is table stakes and quietly the wrong scoreboard. A perfectly extracted invoice for a vendor that is not on file, or for an amount above the approver's limit, or keyed by the same identity that approves it, is a flawless read of a transaction that should never have posted. The document-AI stack graded the read and passed. The posting — the part that carries the fine — was handled by a bot running under a shared service account, with the control logic, if any, sitting in yet another system. When the auditor asks "who approved this, under what policy," the honest answer is assembled after the fact from two logs that were never designed to be one sentence.
One invoice, one governed transaction
Entroid is built so the read and the act are the same accountable transaction, on one runtime, rather than a signal thrown over a wall. This is an architectural property of how the primitives compose — state it at that altitude, not as a promised result. The vision model that reads the invoice runs as a Function — governed extraction executing inside the process rather than at an endpoint outside it. Its output is consumed immediately by a Deterministic Workflow that carries the governance inline, as preconditions of the posting itself.
Consider how an AP posting would run on the fabric — illustrative, not a claimed deployment or metric:
- Read, as a governed Function. The invoice is extracted with the same grounding and confidence you already value — provenance of every field preserved, because verifiable reads are worth keeping.
- Adjudicate the uncertainty, inline. Where a field falls below the confidence the policy requires, the workflow pauses and an Atomic Agent routes it to a human — human-in-the-loop as a first-class step before commit, not a courtesy screen bolted on afterward.
- Enforce the authorization, inline. The Deterministic Workflow checks segregation of duties — the identity that read or entered the invoice cannot be the identity that releases it — and evaluates threshold approvals against the amount: under a limit it proceeds, above it, it routes to the controller, above a higher one, it requires dual approval. This is policy on the posting, not a confidence score on the pixel.
- Act, through a governed Connector. Only the Connector primitive touches the ERP, and it commits the entry only after the controls have passed. A posting that fails SoD or exceeds an unapproved limit never reaches the ledger — there is no non-compliant entry to detect later, because it was never allowed to commit.
- Audit, as a byproduct. The immutable per-action audit records read through posting as one chain — what was extracted, how confident, who adjudicated, which policy fired, who approved, what posted. Not two logs stitched together at quarter-end. One transaction, one record, one owner.
Detect the field, decide under policy, act through the Connector, audit inline — one accountable transaction, not a detection thrown into a system that posts without oversight.
Be precise about what this claim is not
Be precise about what this claim is and is not. It is not that ES reads a document better than a purpose-built, expert-guided extraction model — that lineage is genuinely strong, and grounding plus confidence plus HITL is a real, verifiable answer to the read. It is not that ES floats above your estate and needs no integration; it runs over your existing ERP, AP system, and document stores through governed Connectors. The integration does not vanish — it becomes a governed step instead of an ungoverned handoff.
The wedge is narrower and sharper than "we extract better," and it survives any competitor's roadmap because it is structural. When the control that makes a read trustworthy lives in the model, and the control that makes an act authorized lives in a separate system reached across a wall, you can have a perfect read and an unaccountable posting at the same time — and in regulated finance, the posting is the part with your name on it. ES closes that gap by making the corrective, consequential action a governed step in the same workflow as the read, on the same runtime, under the same audit. The extraction proves the number. The workflow owns the consequence.
Grounding proves where the number came from. It never proves who was allowed to pay it — and that is the only line your auditor reads.
See what this looks like for your enterprise.
Not a demo. A strategic conversation about how your enterprise could operate
when every process runs on one governed fabric.
