Cost per transaction
Objective. Define cost per transaction and the cleaner cost-per-clean-unit variant, show what cost and volume go into it, and separate unit cost from a total-savings claim.
A dictionary entry. Cost per transaction divides a cost base by a volume of completed work; cost per clean unit divides it by work that met quality, so rework is not rewarded. Both are unit economics, not total savings.
See it in the demo
What it is
Cost per transaction expresses what it costs to complete one unit of work - a claim, a case, a call - by dividing a cost base over a period by the number of units completed in that period. Cost per clean unit is the more honest variant: it divides by work that met the quality standard, so items that had to be reworked do not make the unit cost look better than it was. It is a unit-economics measure that lets a leader reason about efficiency and price, not a statement of money already saved.
How it is calculated
At app-logic level: a defined cost base (typically labour cost for the scope, sometimes loaded) divided by completed volume for the same scope and period; the clean variant divides by clean (quality-passing) output only (see clean output and rework, MET-11). Included: the cost components the account has chosen and the counted, in-scope work. Excluded or adjusted: out-of-scope work types, and - for the clean variant - reworked or failed items from the numerator of 'good' output. Which cost components are loaded in, how labour is allocated, and the completion and quality definitions are configurable and change the figure materially - confirm with product. Keep capacity value separate from this cash-based cost figure.
How to read it and the common misread
Read cost per transaction against the customer's own baseline and trend, and prefer cost per clean unit so rework is not hidden. Falling unit cost at stable quality is the healthy signal. Targets are the customer's own, not an industry number you should quote. The common misread is treating a lower cost per transaction as total savings - it is a per-unit figure, and savings depend on volume and on whether freed capacity is actually acted on. A second misread is quoting plain cost per transaction while rework is high: the unit looks cheap only because failed work is counted as completed. A third is comparing unit cost across teams before aligning cost components, work type and quality.
Where it appears
In Work Output (cost views, cost per clean unit, planning) and in RCM Operations reasoning (for example cost per claim in outcome briefings). It connects to Value Leakage, where a cost opportunity becomes cash only after verified recovery. Demo figures are seeded illustrations.
Interpretation check
Cost per transaction is a unit cost, not total savings. Prefer cost per clean unit so rework is not rewarded, and keep this cash figure separate from capacity value.
In the field
Cost per claim is central to the KnackGlobal case: the displacement argument rests on output-per-FTE and cost per clean claim, but only once the cost base, work type and quality definition are aligned so the comparison with the incumbent is fair.
Practical task
In the Work Output demo, find a cost view and write down the plain cost per transaction and, if visible, the cost per clean unit, then one sentence on why the clean-unit figure is the one you would show a customer and what cost components you would confirm with product.
Self-check
What is the difference between cost per transaction and cost per clean unit?
Cost per transaction divides cost by all completed units; cost per clean unit divides by work that met the quality standard, so rework does not make the unit cost look artificially low.
Why is a falling cost per transaction not the same as total savings?
It is a per-unit figure. Total savings depend on volume and on whether any freed capacity is actually acted on; the unit cost falling does not by itself put money on the table.
How can high rework distort a plain cost-per-transaction figure?
If reworked or failed items are counted as completed, the denominator is inflated and the unit looks cheaper than the real cost of good output. Cost per clean unit avoids this.
What must you confirm with product before quoting a cost-per-transaction figure?
Which cost components are included and how labour is allocated, plus the completion and quality definitions - all configurable and all able to move the number materially.
Verified vs demo. The demo shows unit-cost views on seeded data. A customer's cost per transaction depends on their cost components, labour allocation and quality definitions, which must be validated in their instance.