ArchitectureOperations
Raising the straight-through processing rate in back-office operations
Straight-through processing is the share of items that move from intake to posting without a person touching them. When the rate stalls, the cause is rarely the automation alone: upstream data, master data, over-strict rules and low model confidence all push items out. This page maps where fall-outs happen, classifies their causes and orders the fixes by payoff, while keeping the controls that should never be automated away.
On this page
- Measuring straight-through processing so the rate means something
- Where items leave the automated path
- A root-cause taxonomy for automation fall-outs
- Fixes in order of payoff
- Route the exception, not the item
- Controls that should stay with a person
- A hypothetical distributor raising order-entry STP
- Questions and answers
- Sources
Measuring straight-through processing so the rate means something
Two teams can report very different rates for the same process because they count differently. Agree these terms first.
- Touch
- Any human action on an item between intake and posting: correcting a field, approving, re-keying or opening it to check. Viewing a dashboard is not a touch; overriding a decision is.
- STP rate
- Items completed without a touch, divided by all items that entered the process in the period, including those still open and those rejected.
- Denominator
- The population the rate is measured against. Quietly excluding items routed out early, such as unusual document types, inflates the rate without changing the work.
- Segment
- A slice that behaves differently: sender, channel, document type or product line. Rates by segment show where fall-outs originate.
- Fall-out reason
- The coded cause recorded when an item leaves the automated path. Without reason codes, every improvement discussion starts from anecdote.
Where items leave the automated path
- Intake
Documents, messages or portal submissions arrive and are classified.
- Validation
Mandatory fields, formats and duplicates are checked.
- Enrichment
Master data, orders, contracts and reference data are attached.
- Decision
Rules and models match, price, approve or score the item.
- Posting
The result is written to the system of record.
- Exception queue
Items that fail any stage wait here for a person, with a reason code.
A root-cause taxonomy for automation fall-outs
| Root cause | Typical signal | Who owns the fix | First fix to try |
|---|---|---|---|
| Upstream data quality | Missing or malformed fields from the same senders, week after week | Process owner, with the senders | Intake standards, portals or structured formats |
| Master data | Unknown supplier, customer or item; mismatched prices or units | Master data owner | Governed creation and change, with duplicate checks |
| Over-strict rules | Exceptions that reviewers approve unchanged almost every time | Policy owner | Evidence-based tolerance review within policy |
| Low model confidence | Extraction or classification uncertain on specific layouts or languages | Automation team | Targeted training data and layout-specific handling |
| System and integration errors | Time-outs, locked records, failed postings | Platform team | Retries, idempotent posting, alerting |
| Mandatory controls | Items routed for review by design, such as new bank details | Control owner | None: measure separately and keep |
Code every exception to one of these causes when it is resolved; the distribution tells you which fix comes first.
Fixes in order of payoff
Work from the source downstream: each fix upstream removes exceptions at every later stage.
Fix at source
Agree intake standards with high-volume senders, move them to portals or structured submission and adopt structured formats where they exist. For invoices, the European standard EN 16931 defines the core semantic model of an electronic invoice, and Directive 2014/55/EU requires public contracting authorities to accept invoices that comply with it1; networks such as Peppol carry such formats between trading partners2.
Govern master data
Most enrichment failures are master data failures. Put supplier, customer and item creation behind a governed workflow with duplicate checks, and name owners who correct records when the exception queue points to them.
Tune tolerances and thresholds with evidence
Sample exceptions that reviewers approved unchanged and test what a wider tolerance or lower threshold would have let through, errors included. Change settings only within written policy and with the policy owner's sign-off; human-in-the-loop approvals covers threshold design for AI agents in depth.
Improve extraction and classification
Target the layouts, languages and document types that generate the most low-confidence cases instead of retraining on everything. Add corrected exceptions to the evaluation set so improvements are measured, not assumed.
Close the loop from the exception queue
Require a reason code on every resolved exception and review the top reasons on a fixed cadence. Each recurring reason should end in a change to a rule, a model, master data or a sender standard.
Route the exception, not the item
ColdAI's published use cases for accounts payable and support triage share one pattern: automation handles the routine, and each exception reaches the person who can resolve it with the evidence attached3. A price variance goes to the buyer and a missing receipt to the warehouse; a ticket's category and urgency decide its queue.
For STP, the design detail that matters is that the reviewer answers a specific question and the answer is captured in structured form. A free-text note fixes one item; a coded decision can become a rule, a training example or a master data correction that keeps the next item on the automated path.
Controls that should stay with a person
A higher STP rate is not always better. Some exceptions exist because a person must decide.
Changes to bank details or payment instructions
Early signalRequests arriving by email or from a new contact.
MitigationVerify through an independent channel and keep a person on the approval, whatever the automation's confidence.
Broken segregation of duties
Early signalOne automated identity can create a supplier, approve an invoice and release payment.
MitigationSeparate service identities and approvals so no single path both creates and pays.
Auto-cleared sanctions matches
Early signalScreening hits on counterparties or beneficiaries closed on similarity scores alone.
MitigationRoute every potential match to a trained reviewer and log the decision.
Credit and authority overrides
Early signalOrders above credit limits or approval thresholds released without the authority holder.
MitigationKeep overrides with the delegated authority holder and record each decision with its reason.
A hypothetical distributor raising order-entry STP
Questions and answers
What is a good straight-through processing rate?
There is no universal benchmark worth trusting, because rates depend on how a touch and the denominator are defined, the mix of senders and the controls the process must keep. Compare your own rate by segment over time instead. A segment that stays low after fixes at source and in master data usually has a structural cause, such as a mandatory control, that should be measured separately.
Should mandatory reviews count against the STP rate?
Report them separately. If policy requires a person to review an item, such as a new bank account or a sanctions match, counting it as a failure invites pressure to weaken the control. Publish two numbers instead: the STP rate for items eligible for automation, and the volume routed to mandatory review, each with its own trend.
Will a better AI model fix a low STP rate?
Only when low model confidence is the main cause. In many processes the bigger causes are upstream data, master data and rules stricter than policy requires, which a new model cannot fix. Classify fall-outs by reason code first; if extraction or classification uncertainty dominates for specific layouts or senders, targeted model work pays off there.
How does process mining help raise STP?
The event log shows where items leave the automated path, how long they wait in exception queues and which segments generate the most rework. It turns reason codes into a ranked list of causes and shows whether a fix actually reduced fall-outs. The method is set out in process mining for automation.
Sources
- Directive 2014/55/EU on electronic invoicing in public procurement — EUR-Lex · checked 10 October 2026
- Peppol: network and specifications for electronic procurement documents — OpenPeppol · checked 10 October 2026
- AI Invoice Processing for Accounts Payable: route the exception, not the invoice — ColdAI