Software chargeback — how IT cost becomes a business-unit conversation.

Why central-pool software budgets have stopped working.

For most of the SaaS era, enterprise software cost has sat in a central IT budget. The CIO owned the contract, the CFO owned the budget line, and the business unit consumed the software without a P&L impact. That model worked when software was a fixed central overhead; it stopped working when SaaS turned software into a variable per-user, per-transaction, per-token cost that the business unit could expand without internal friction. By 2026, the central-pool model is the single largest source of shelfware and over-deployment we see across the engagements we run.

In our experience across 340+ engagements, the enterprises that have moved fastest to a sustainable software cost base are the ones that built a chargeback or sophisticated showback model on the largest 8–12 vendor lines. The chargeback does not change the contract; it changes the demand signal. Business units with a visible software cost line typically reduce headcount entitlements 8–15% within the first year, which compounds into renewal leverage on the second.

Showback vs chargeback — the two distinct mechanics

The two terms are often used interchangeably and they should not be. Showback presents consumption data to the business unit without crossing the general-ledger boundary — it is a transparency mechanism, and it changes behaviour where the business-unit leader is engaged. Chargeback transfers cost from IT to the business-unit P&L via a journal entry — it changes incentives, and it does so much more aggressively. Most enterprises should run showback for 6–12 months before moving to chargeback. The interim period exposes the data-quality issues, the allocation-driver disputes, and the boundary cases (shared infrastructure, multi-business-unit users) that need to be resolved before any P&L cost actually moves.

Allocation drivers — picking the right one for each product family

No single allocation driver works across the software estate. The right driver depends on the contract metric, the consumption pattern, and the boundary cases that exist in the deployment. Across the engagements we have run, four drivers cover roughly 90% of the estate:

1. Named user count — most defensible for per-user software (Microsoft 365, Salesforce, ServiceNow, Workday). Track active users by business-unit cost-centre. Re-allocate monthly.
2. Transaction or consumption volume — for usage-priced lines (cloud, AI tokens, e-discovery GB, transactional databases). The vendor's billing data is typically the source.
3. Headcount — for employee-scope tools where every employee is licensed regardless of active use (HR systems, broad collaboration suites). Track total business-unit headcount monthly.
4. Revenue or operating cost — for shared infrastructure where direct attribution is impossible (network, identity, core platform). Use a defensible business-unit ratio (revenue, operating cost or FTE share).

The boundary cases — where chargeback models break

Every chargeback model breaks at the same five places, and the design has to anticipate each. Shared users that belong to multiple business units. Service accounts and batch processes that are not attributable to any single business unit. Indirect access through downstream systems. Long-tail products where the chargeback admin cost exceeds the chargeback value. And the central platform layer (identity, security, data integration) that has to remain a central cost. The disciplined design carves these five categories out explicitly and runs them on a defensible default allocation rather than attempting to chargeback them directly.

Sequencing the build so it actually lands.

Chargeback build is rarely a technology problem — the cost-allocation tooling has been available for a decade. It is an organisational problem. The CIO, the CFO, and the business-unit CFOs have to agree on the allocation drivers before any cost moves, and that agreement is the part most programs underestimate. The disciplined sequence we have used most often runs:

1. Months 1–2: Data-quality baseline. Confirm that consumption data exists and is reconcilable to the contract for each of the top 8–12 vendor lines.
2. Months 3–4: Allocation-driver design. Workshop the driver for each product family with the business-unit CFOs. Document the boundary-case treatment.
3. Months 5–7: Showback. Run for 90 days with no P&L impact. Resolve data issues, allocation disputes, and boundary-case treatments.
4. Months 8–9: Chargeback dry-run. Mirror the journal entries without posting. Validate against an independent cost-controller review.
5. Months 10–12: Go-live. Post the journal entries to the business-unit P&L. Establish the monthly cadence and the dispute resolution path.

The compounding effect on renewal leverage

The reason chargeback matters at the renewal table is the compounding effect on demand signal. Business units with a visible software cost line typically reduce headcount entitlements 8–15% within the first year, and the reduction is documented. At renewal, the documented reduction becomes a credible counter-position — "our user base has declined; the contract should follow." Vendors will resist; vendors will move. Across the engagements we have run, chargeback-enabled renewals deliver 8–14% additional savings versus comparable renewals without a chargeback baseline.