Transaction Based Pricing
Definition
Transaction Based Pricing
Transaction based pricing builds a catalogue of transaction types, each with its own unit rate, so a mixed workload can be priced properly without averaging everything into one number. Complexity weighting is the design problem, not the rate itself.
It is the architecture behind a per-transaction deal rather than the deal itself. The buyer signs a price per unit; someone first had to decide what the units are and how they relate to each other.
That design work is unglamorous and decisive — a catalogue with too few types mis-prices half the work, and one with too many becomes impossible to administer.
Baselines then matter as much as rates. A rate card built against last year’s mix stops being accurate the moment the mix shifts, and nobody notices until margin moves.
Key takeaways
- The output is a catalogue of transaction types with weighted rates, not a single price.
- Complexity weights should come from measured effort, not from negotiation.
- A volume and mix baseline must accompany the rate card or the pricing drifts.
- Re-basing on a stated cycle keeps the card honest as the work changes.
How it works
Catalogue design starts with observation. Effort per transaction type is measured over a representative period, weights are derived from that data, and rates fall out of applying a target cost and margin to the weights.
Six to twelve transaction types is the usual practical range. Fewer and the averaging problem returns; more and the classification effort costs more than the precision is worth.
The volume baseline is the second half of the card. Public procurement handles this by requiring a “realistic estimated total quantity” in the contract, while making clear the estimate is not a promise to order it.
| Design step | What it produces | Common error |
|---|---|---|
| Effort study | Measured minutes per type | Using supplier estimates instead |
| Weighting | Relative complexity factors | Negotiating weights rather than measuring |
| Rate build | Cost plus margin per type | Ignoring the mix in the margin |
| Volume baseline | Expected units by type | A single blended volume figure |
| Re-basing trigger | When the card is rebuilt | No trigger written at all |
Should-cost thinking belongs here. UK guidance notes that a should-cost estimate “provides a better understanding of the costs associated with different service delivery models and helps to protect government from ‘low cost bid bias'”.
Re-basing is the clause most often missing. A card should be rebuilt when the mix shifts beyond a stated tolerance — commonly ten or fifteen percent — rather than only at renewal.
Automation makes re-basing urgent. As simple transactions get automated, the residual mix becomes harder and the old weights systematically under-price the remaining work.
Examples
Rate card design decides whether a per-transaction deal ages well or badly. These four cases show a card built from evidence, two built from negotiation, and one re-based in time.
A finance shared service builds nine transaction types from a six-week effort study. Weights hold for three years and the supplier’s margin stays within a point of plan.
An insurer negotiates weights with its supplier without measuring anything. Simple claims are over-weighted, complex ones under-weighted, and the supplier optimises accordingly.
A utility prices all customer transactions at one blended rate. Automation removes the simple half of the volume, and the remaining work is priced well below its cost.
A bank writes a re-basing trigger at a 12% mix shift. It fires in year two, the card is rebuilt in six weeks, and neither side ends up subsidising the other.
Related terms
Unit-priced work is described in several ways, and the distinction between the deal and its design is the one that matters. The entries below separate them.
- Transactional outsourcing: the work being priced, rather than the pricing structure.
- Activity based costing: the costing technique that produces credible weights.
- Unit cost of production: the supplier-side number each rate is built from.
- Rate card: the artefact this design process produces.
- Benchmarking: the external evidence used to test the rates.
- Case volume: the baseline quantity the card is built against.
- Finance and accounting outsourcing: the function where transaction catalogues are most developed.
FAQ
How many transaction types should a card have?
Usually six to twelve. Fewer reintroduces the averaging problem the card exists to solve, and more costs more to classify than the accuracy is worth.
Where should complexity weights come from?
A measured effort study over a representative period. Weights arrived at through negotiation reflect bargaining power rather than work content.
Why does the mix matter so much?
Because the blended price only holds if the mix holds. A card priced on last year’s mix under-prices the work as soon as the easy volume disappears.
When should a card be re-based?
On a stated trigger, typically a mix shift beyond ten to fifteen percent. Waiting for renewal leaves one party subsidising the other for months.
Does automation break the model?
It changes it. Automating simple transactions leaves a harder residual mix, so the card has to be rebuilt rather than simply repriced downward.
How does this differ from pay per transaction?
This describes designing the catalogue and its weights. Pay per transaction is the arrangement a buyer signs once that design exists.
Find delivery partners who build rate cards from measured effort in the Outsource Accelerator hubs.
Independent
