A straight-through rate is not accuracy
Intelligent document pipelines in 2026 love one dashboard number: straight-through processing — the share of documents that clear with zero human touch. It looks like a health meter. It is not accuracy. On BuilderHelp's supplier-invoice path and Deerman's purchase-order extraction, a rising STP can mean the gates got looser, not that totals, remits, and part codes got better. The rate tells you how often a person was skipped. Accuracy tells you whether the fields that move money and inventory were correct when they were.
Two questions wearing one metric
Straight-through processing answers: how often did this document leave the pipeline without a reviewer? Accuracy answers: for the fields that matter, how often was the extracted value correct against a labeled set, a catalog, or a deterministic check? Those are related operational concerns. They are not the same measurement.
You can raise STP by lowering thresholds, collapsing field bands into one cutoff, or auto-posting anything that looks like an invoice. The queue shrinks. The wrong total still posts. You can also keep STP modest while field accuracy on totals and vendor IDs is high — because you route the ambiguous cases and refuse to celebrate silence as success.
Production IDP write-ups keep repeating the pattern: treat STP as the north-star scoreboard and teams optimize for empty inboxes. Treat field accuracy and named failure rates as the scoreboard and teams optimize for correct posts. Pick which behavior you want before you put either number on a slide.
BuilderHelp: a quiet post is not a correct budget line
BuilderHelp's OCR path proposes line items from supplier invoices so builders can match spend against budget lines. A document that never opens in review contributes to STP. A misread amount that lands in the budget as fact is an accuracy failure — and the builder will plan from it.
If the dashboard only shows STP climbing, the incentive is to let more invoices skip the person. That is the opposite of how the product earns trust. The useful pair is: how often did we need a human, and among the fields we auto-posted, how often did arithmetic, vendor identity, and line totals hold up against checks and corrections.
When a reviewer does correct a total, that delta is accuracy telemetry. Fold it back into the eval set. An STP chart that ignores correction rate is a vanity funnel.
Deerman: reconcile failures are signal, not STP drag
Deerman staff turn vendor PDFs into manufacturer PO lines that have to resolve against price files before anything emails out. A line that fails reconciliation belongs in review. Counting that document against STP is fine. Treating the review as a defect to engineer away with a looser gate is not.
The accuracy question on that path is whether reconciled codes and quantities match what the manufacturer will ship — not whether the queue went quiet. A perfect STP with one confident wrong part code is still a wrong order. A lower STP where every auto-cleared line passed reconcile is the healthier system.
Keep the reconcile failure visible as its own rate. If STP rises while reconcile-fail rate falls for the wrong reason — fewer checks, not better parses — you are measuring the wrong recovery.
What to put on the scoreboard instead
Report STP, but never alone. Pair it with field-level accuracy on the dangerous fields — totals, tax, remit-to, quantities, identifiers — measured on a golden set that includes the ugly scans, not just clean PDFs. Add the rate of named rule failures: sum mismatch, unknown vendor, unresolved part code.
Split STP by document type and by consequence band. Invoice under a small amount clearing straight through is a different claim than a high-value remit clearing without eyes. One blended percentage hides that difference the same way a global confidence float does.
When STP moves week to week, ask which dial turned: model change, threshold change, volume mix, or review staffing. A rate without a cause is not an operating signal.
What we ask before we chase STP
Which fields, if wrong, corrupt a budget, a payment, or a manufacturer order — and are those fields measured separately from the document-level clear rate? What named checks must pass before a document can count as straight-through? When a reviewer corrects a value, does that correction enter the eval set, or does it vanish into a closed ticket?
If you cannot answer those, do not put STP on the steering slide yet. Build the field accuracy harness and the failure taxonomy first. Then STP becomes what it should be: a capacity and routing metric, not a substitute for being right.
The milestone is a pipeline that can say how often people were needed and how often the auto-cleared fields were correct. Until both answers exist, a rising straight-through rate is just a quieter queue.
Questions
- Is a high STP bad?
- No — if the fields that matter are accurate and the named checks still run. High STP with loose gates and no field eval is the failure mode. Measure both.
- How is this different from confidence thresholds?
- Confidence is an input to routing. STP is an outcome count of untouched documents. Accuracy is whether values were right. You can misuse all three; this note is about not mistaking the outcome count for correctness.
- What should replace STP on a dashboard?
- Nothing replaces it — pair it. Field accuracy on money-moving fields, named rule-failure rates, and STP by document type and amount band.
Sources
- Intelligent Document Processing in 2026: 7 Production Patterns — STP vs per-field accuracy; global thresholds as a shortcut failure.
- Intelligent Document Processing in 2026 — practical guide — Straight-through-processing rate as an ops metric, not a substitute for field evals.
- Related: A confidence score is not a gate
- Related: Human-in-the-loop is a design decision