Number7 research · Finance buyer / AP operations leader
How to Calculate Straight-Through Processing in Accounts Payable
DIRECT ANSWER Accounts-payable straight-through processing is the percentage of in-scope transactions that reach an agreed terminal state with no human intervention. Calculate it only after fixing the transaction unit, terminal state, eligibility rules, measurement period, and manual-rescue policy. When exclusions are material, report both eligible-population STP and all-received STP.
ORIGINAL NUMBER7 MODELPublished 7 September 2026Vishal Rajput · Founder, Number7 AI
Compare automation rates honestly
One numerator. Two honest rates.
Illustrative model · not a measured customer result
Eligible population
760÷ 1,000 eligible
76.0%
All received
760÷ 1,100 received
69.1%
760 touch-free verified bills. 240 eligible invoices needed human work. 100 received inputs were outside the predeclared supported envelope.
“Captured automatically” is not end-to-end AP STP.
The numerator includes only transactions that reach the terminal state with zero hidden human rescue.
The denominator must be frozen before results are observed.
Unsupported or rejected business inputs should appear in all-received reporting even if a narrower eligible rate is also useful.
Pair STP with silent-error sampling, reopen rate, touch intensity, and stage fallout.
Worked example: two STP rates, one honest story
An illustrative AP operation receives 1,100 genuine, in-scope invoice transaction attempts. Before the run, it declares 1,000 eligible for the supported workflow and 100 genuine business inputs outside the current product envelope.
Of the 1,000 eligible transactions:
760 reach a verified bill-posting state without a person;
80 appear automated upstream but require a human correction, verification, or posting repair;
160 require other human intervention before the terminal state.
The results are:
Metric
Calculation
Result
Eligible-population STP
760 ÷ 1,000
76.0%
All-received STP
760 ÷ 1,100
69.1%
Eligible transaction-touch rate
240 ÷ 1,000
24.0%
Unsupported-input share
100 ÷ 1,100
9.1%
Reporting only 76% would be incomplete for workforce capacity planning. Reporting only 69.1% would hide how well the supported envelope performs. Publishing both makes the boundary explicit.
This example is illustrative, not a Number7 or market benchmark.
The final rate is important, but stage fallout tells the team what to improve. It also prevents an extraction vendor and an end-to-end workflow vendor from appearing comparable when they measure different terminal states.
Formal definition
For a defined AP workflow:
Eligible-population STP = eligible in-scope transactions reaching the terminal state without human intervention ÷ all eligible in-scope transactions × 100
For transparency:
All-received STP = touch-free transactions reaching the terminal state ÷ all genuine in-scope transaction attempts received × 100
The rates answer different questions. Eligible STP measures performance inside a declared operating envelope. All-received STP shows how much of the actual business workload reached the outcome without people.
Define “through” before measuring “straight-through”
AP has many possible terminal states:
document classified;
fields extracted;
invoice validated;
invoice approved;
accounting-ready transaction created;
bill posted to the target ledger;
payment state recorded;
payment executed and reconciled.
A system can achieve high extraction STP and low posting STP. Both can be valid metrics if named accurately. The misleading move is to label an upstream stage “end-to-end.”
Number7 recommends a complete metric name:
Eligible invoice-receipt-to-verified-bill-posting STP, September 2026, supported QBO workflow.
The label tells the reader what began, what finished, when it was measured, and where the product boundary sits.
The frozen-denominator protocol
Write and version these rules before the run:
Rule
Decision to record
Transaction unit
Economic payable, invoice, credit note, or another explicit unit
Entry event
First controlled receipt, not later system acceptance
Terminal state
Observable, verified outcome in the intended target system
Follow-up window
How long transactions are allowed to reach the terminal state
Supported envelope
Document types, channels, languages, entities, integrations, and size limits
Legitimate exclusions
Test files, spam, exact transport duplicates, corrupt files with no recoverable business content
Unsupported business inputs
Retained in all-received reporting; optionally excluded from eligible rate if predeclared
Human touch
Correction, decision, evidence supply, manual route, manual post, or required verification
Retry rule
Automatic idempotent retry may remain touch-free; human-triggered repair does not
Reopen rule
A corrected/reopened transaction loses touch-free status for the measured outcome
The eligibility manifest should be published with a benchmark or available to the buyer. “We excluded unsuitable documents” is not enough.
What cannot enter the numerator
an invoice corrected by an operations team before the buyer sees it;
a bill manually re-keyed after an integration failure;
a transaction that reached a target system but was later reopened for an error related to the measured flow;
an item approved by a person when zero-touch approval is part of the claim;
a failed or parked transaction merely because the reporting window ended;
an unsupported business document removed after observing the result.
If a person invisibly rescued the transaction, the system did not process it straight through.
A platform reads 95% of invoices without field correction. Half of those still need vendor resolution, evidence, coding, approval, or posting repair. Advertising “95% STP” without the terminal state encourages a buyer to model labor savings that will not occur.
The correct claim is “95% touch-free extraction within the tested field and document scope.” The posting outcome must be measured separately.
How to compare two STP claims
Ask for:
transaction unit;
start event and terminal state;
all-received count;
eligible count and exclusion manifest;
touch definition;
manual rescue and reopen treatment;
product version and integrations;
sample composition and measurement period;
silent-error sampling method;
stage-level fallout.
If those fields differ, the percentages are not directly comparable.
Sample accepted transactions against source and accounting outcome, including identity, coding, duplicates and target state.
Go deeper where you need to
Technical appendix: Accepted is not the same as correct.
Sample accepted outcomes
01
Wrong identity
Sample accepted bills for the intended vendor and client entity; correctly read text can still be assigned to the wrong master record.
02
Plausible field error
Check a representative sample of accepted values against their source. A plausible date or amount can evade a low-confidence review queue.
03
Duplicate accepted
Inspect the economic obligation and source lineage, including resubmissions. Different invoice numbers alone do not establish that two payables are distinct.
04
Wrong coding
Compare the accepted ledger, tax and dimensions with the intended client treatment. Correct transcription does not prove correct accounting.
05
Unverified execution
Check the actual target object and returned state. A sent request or timeout cannot establish whether the intended bill was created once.
Validation questions for this model
Freeze the population and workflow boundary.
Define required evidence and successful exit state.
Measure exceptions, human touches and silent errors.
Separate modeled outcomes from production measurements.
Method, sources and limitations
Limitations
High STP is not automatically safe or valuable. A system could increase STP by weakening controls, auto-approving low-quality proposals, or narrowing eligibility. STP does not measure material error, duplicate exposure, fraud, cycle time, supplier experience, or accounting quality.
Some organizations intentionally require human approval for all items. In that workflow, zero-touch posting may be the wrong goal. Measure the automated path to the control boundary and the efficiency of the required decision instead.