Pay Per Transaction
Definition
Pay Per Transaction
Pay per transaction charges an agreed price every time a defined piece of work completes — an invoice posted, a claim adjudicated, a record keyed. Volume risk moves to the provider, because a month with no work in it earns nothing.
It is the natural model for back-office work — where the output is countable, repeatable and produced in bulk. Both sides can audit the number from the same system.
The definition of the transaction carries all the weight. A transaction that quietly expands in scope becomes a loss-maker, and one that fragments becomes a billing argument.
This is also where it differs from transaction based pricing. That term describes designing a catalogue of transaction types and their rates; this one describes the arrangement a buyer actually signs.
Key takeaways
- The buyer pays per completed unit, so provider revenue falls when volume falls.
- The transaction definition must state a start event, an end event and exclusions.
- Rework and exceptions need separate treatment or they are absorbed silently.
- The model needs a system of record both parties can query independently.
How it works
A workable transaction price rests on four agreements: the trigger that starts a billable unit, the event that completes it, what is explicitly excluded, and how exceptions are handled. Most disputes trace back to a missing exclusion list.
Fixed pricing of this kind puts the efficiency risk squarely on the supplier. Federal rules describe a firm-fixed-price contract as providing “a price that is not subject to any adjustment on the basis of the contractor’s cost experience in performing the contract”.
Volume risk runs the other way, and buyers rarely commit to a number. A requirements contract handles this by filling all actual requirements from one supplier, with the buyer required to “state a realistic estimated total quantity” that is not a promise to order it.
Exception handling is where margin disappears. A clean invoice and an invoice with three missing fields are not the same work — and pricing them identically guarantees one side loses.
| Definition element | What to specify | Why it matters |
|---|---|---|
| Start trigger | The event creating a billable unit | Stops double counting |
| Completion | The observable end state | Decides when payment is due |
| Exclusions | Work outside the unit price | Protects both margins |
| Exceptions | Rework, missing data, escalation | Where cost actually sits |
| Audit source | The single system of record | Prevents invoice disputes |
Baseline volumes still belong in the contract, even without a commitment. Providers price fixed cost recovery against an expected range, and a collapse to a third of forecast will bring them back to the table.
Examples
Transaction pricing works cleanly where the unit is obvious and badly where it is a matter of judgement. These four cases show a well-defined unit, two definitional failures and one renegotiation that worked.
A manufacturer pays per supplier invoice processed through accounts payable. The unit is unambiguous, the system counts it, and the rate has held for three renewal cycles.
An insurer pays per claim handled without separating simple and complex claims. The provider’s average handling cost drifts upward as the easy claims get automated away in-house.
A bank pays per account opened but leaves remediation of failed checks undefined. Roughly one application in six needs follow-up work that nobody priced.
A utility renegotiates to three transaction types at three rates after a year of arguing. Invoice disputes fall to near zero, and the blended cost barely changes.
Related terms
Several terms describe counting work by the piece, and the differences sit in what is being counted and who designed the count. The entries below separate the arrangement from the measurement.
- Transactional outsourcing: the type of work this model prices, rather than the pricing itself.
- Unit cost of production: the internal cost measure, as against the price charged.
- Activity based costing: the technique used to work out what a transaction really costs.
- Payment processing outsourcing: a common setting for per-transaction pricing.
- Claims outsourcing: where complexity banding matters most.
- Data entry outsourcing: the simplest unit-priced work of all.
- Back office outsourcing: the wider function these transactions sit inside.
FAQ
What makes a good transaction unit?
One that starts and ends with an observable system event, happens frequently, and varies little in effort. Anything requiring judgement to count will eventually be disputed.
Who carries volume risk?
The provider carries it under this model, because revenue falls with volume. That is the main reason providers ask for a baseline or a minimum alongside the unit rate.
How should exceptions be priced?
Separately, at a higher rate, with a defined trigger. Bundling exceptions into the standard price means the provider is betting on your data quality.
Is this the same as transaction based pricing?
They overlap. Pay per transaction names the arrangement a buyer signs; transaction based pricing describes designing the rate card of transaction types behind it.
Does the price fall over time?
Usually, through an agreed productivity commitment. A common structure reduces the unit rate by a small percentage each year in exchange for a longer term.
What kills this model?
Scope creep inside the unit. Work added to a transaction without a price change converts a sound contract into a loss for one side.
Compare providers who will define the transaction in writing before quoting, through the Outsource Accelerator directory.
Independent
