Zero-touch processing: how far automation should go, and where it should stop
Straight-through processing lets a document skip human review entirely. The interesting engineering question isn't whether to build it — it's how to decide, document by document, when it's safe.
"Zero-touch" or "straight-through processing" (STP) means a document is extracted, validated, coded, and posted without a human looking at it at any point. It's the most automated a pipeline can be, and it's also the step where a badly designed system does the most damage the fastest — a wrong entry posted with no human in the loop is a wrong entry that's already in the ledger by the time anyone notices.
The case for it
Not every document needs a human. A recurring utility bill from a known vendor, at a predictable amount, with every field extracted cleanly and every structural check passed, doesn't benefit from a person re-reading it every month — the review adds latency and cost without meaningfully reducing error, because there's nothing left for a human eye to catch that a deterministic check didn't already catch. Reserving human attention for documents that actually need judgment, and letting the rest flow straight through, is the entire point of automating in the first place.
The case against doing it everywhere
The failure mode of over-applying STP isn't a dramatic crash — it's a wrong entry that looks completely normal, posted with nobody having verified it, discovered only during a reconciliation or an audit months later. The risk isn't that automation makes mistakes (any system does); it's that a mistake made with zero human checkpoint has no chance to be caught before it's already downstream.
What actually needs to be true before a document qualifies
A defensible STP decision isn't "the AI is confident" — confidence alone is a single, gameable signal. A document should only skip review when MULTIPLE independent checks agree:
- The structural validation passed — every mandatory field parsed cleanly, arithmetic reconciles, nothing is missing
- The trust/health check passed — no jurisdiction-specific red flag fired (invalid legal ID, suspicious bank detail, anomalous round amount)
- The fraud-risk assessment is low — no duplicate suspected, no unusual-amount-vs-history flag
- The proposed accounting entry is balanced — the coding the system would post actually reconciles, not just the source document's own arithmetic
Requiring agreement across independently-computed signals, rather than a single confidence number, is what keeps STP from becoming "the model said it was fine" dressed up as a control. A vendor's history is a reasonable SEPARATE input to how cautiously a document gets treated — but it's worth asking a vendor directly whether "first time we've seen this supplier" actually gates the STP decision in their system, or whether that's a plausible-sounding design that isn't actually wired in. The gap between the two is exactly the kind of claim worth verifying rather than assuming.
What should never be eligible, regardless of confidence
Some categories of document carry consequences serious enough that a human checkpoint should be structural, not conditional — a document above a defined amount threshold, for instance, or the very first transaction with a brand-new vendor, regardless of how clean the extraction looks. The threshold for "serious enough to always review" is a business decision, not a technical one — but the decision should be made deliberately, in advance, not left to whatever confidence number a model happens to produce on a given document.
The audit trail STP still owes you
A document that skipped review isn't exempt from being explainable later — if anything, it needs MORE documentation of why it was allowed to skip review, since there was no human decision to point back to. The system should record, for every zero-touch document, exactly which checks passed and why the decision to skip review was made — not just that it happened.
What to actually ask a vendor about their STP logic
| Question | Why it matters |
|----------|-----------------|
| How many independent signals gate the decision, and what are they, specifically? | Distinguishes a real control from a single confidence number |
| What categories are structurally excluded regardless of confidence? | Reveals whether "serious enough to always review" was a deliberate design choice |
| Is there more audit documentation for a skipped document, or less? | A weaker system logs less on the documents that most need scrutiny |
| What's the actual STP qualification rate, and how is it trending? | A suspiciously high or fast-rising rate is worth investigating, not celebrating |
Related reading
- How a document trust score actually works: what passes, what fails, and why
- AI bookkeeping in 2026: what it actually automates, and what it should never touch
FAQ
What percentage of documents should realistically qualify for zero-touch processing?
There's no universal target — it depends heavily on vendor concentration and document mix, and a system's own qualifying rate should be measured and watched over time rather than assumed. A rate that's suspiciously high across an entire book of business is itself worth investigating, not celebrating.
Can a document that qualified for zero-touch be flagged after the fact?
Yes, if it should be — a later-discovered duplicate or a vendor bank-detail dispute should still be catchable through the normal fraud/anomaly checks that run on an ongoing basis, not just at the moment of initial processing.
Does zero-touch processing eliminate the need for a periodic audit?
No — it changes what an audit needs to sample. Instead of reviewing every document, a periodic audit of a zero-touch pipeline should specifically sample the documents that skipped review, to confirm the qualifying logic itself is behaving as intended.