At a glance
- Challenge
- Central IT buys for leverage and compliance, business units consume freely, and nobody owns the consequence of the demand they create.
- Approach
- Map consumption to application, owner and cost centre, apply an approved allocation rate card, run showback for a cycle, then post chargeback through finance.
- Primary KPI
- % of centrally held software cost accurately allocated to identified business units and cost centres.
- Impact
- Demand moderates once it carries a visible cost, and renewal quantities are forecast from owned consumption rather than central guesswork.
01
Executive Summary
Centralising software procurement is the right commercial decision. One agreement with a publisher beats fourteen, the volume discount is real, and compliance is manageable from one place. The side effect is that consumption becomes free at the point of use. A business unit that wants SQL Server Enterprise on a sixteen-core cluster for a low-criticality application has no reason to consider Standard edition, because the cost lands somewhere else entirely.
This playbook works the problem through Microsoft SQL Server, which is a useful example because the cost drivers are unambiguous: edition, licensed cores, virtual core allocation, cluster membership and environment. Getting from a central entitlement pool to a defensible per-cost-centre figure requires mapping every instance to an application, every application to an owner and every owner to a cost centre — and that mapping, not the arithmetic, is the hard part.
The sequencing matters. Showback runs for at least one full cycle before anything is charged, so the allocation method is challenged and corrected while the stakes are still zero. Organisations that go straight to chargeback spend the following year arguing about the model instead of acting on it.
02
Business Challenge
The visible symptom is a central IT budget line that grows every year with no corresponding accountability. The underlying problem is that consumption decisions and cost consequences sit in different organisations. An application team specifies Enterprise edition because it might need a feature; a project provisions a four-node cluster because that is the template; a non-production environment is built at production scale and never resized. Each decision is locally rational and collectively expensive.
The second problem is renewal forecasting. Central IT is asked to forecast next year's SQL Server requirement without knowing which business units will grow, which applications will be decommissioned and which projects will provision new clusters. The forecast becomes last year's quantity plus a margin, and the margin becomes permanent.
03
Typical Symptoms
Organisations that need this playbook usually recognise several of the following.
- Central IT holds a growing software budget line that no business unit recognises as theirs.
- SQL Server Enterprise is deployed where Standard would serve, because edition choice carries no local cost.
- Non-production environments are licensed at production scale and never reviewed.
- Nobody can state the software cost of a named application, only of a publisher.
- A material share of database instances has no confirmed application owner in the CMDB.
- Cluster allocation is not modelled, so licensed core counts and deployed core counts diverge.
- Renewal quantities are forecast centrally as last year plus a percentage, with no business input.
- Cost centre hierarchies change during the year and the allocation model is never updated.
04
Business Risks
Business risks by domain, with the risk and its impact
| Domain | Risk | Impact if unaddressed |
|---|
| Operational |
Instances without a confirmed application owner or cost-centre mapping |
A share of cost cannot be allocated at all and falls back to the central pool, which undermines the credibility of the whole model and gives every disputing unit an easy argument. |
| Commercial |
Consumption decisions made without visibility of their cost |
Higher editions and oversized clusters are specified by default, and the central renewal grows each cycle with no business owner accountable for the increase. |
| Compliance |
Chargeback posted on an allocation method finance has not formally approved |
Postings are disputed and reversed, the model is suspended, and accountability reverts to the central pool — usually permanently. |
| Technology |
Cluster and virtual-core allocation not modelled against the licence metric |
Allocated cost bears no relationship to licensable consumption, so the figures cannot be reconciled to the entitlement position or defended to a business unit. |
05
Operating Workflow and Reference Architecture
Operating workflow
11 stages, each producing a defined output. This workflow is specific to this
playbook; the category lifecycle on the
Software Value index is an overview of how the playbooks relate,
not how any one of them runs.
↔ Wide diagram — scroll horizontally, or use the
arrow keys once it has focus. A text description is available to screen readers.
Illustrative cross-charge workflow using Microsoft SQL Server as the worked example. Showback runs for at least one full cycle before any financial posting. Rate cards, allocation rules and dispute routes must be approved by finance. Outcomes are not guaranteed.
Reference architecture
The systems, data and controls the workflow above runs on.
↔ Wide diagram — scroll horizontally, or use the
arrow keys once it has focus. A text description is available to screen readers.
Illustrative reference architecture. Microsoft SQL Server is used as the worked example because its cost drivers — edition, cores, cluster membership, environment — make each allocation decision explicit. The same structure applies to any centrally-held, business-consumed product.
06
Implementation Approach
A representative implementation sequences in 5 phases. Duration and overlap
vary with estate size, data quality and the number of source systems in scope.
Phase 1
Baseline and mapping foundation
Establish what is centrally held and, far harder, who consumes it. Mapping completeness determines whether the model is credible or arguable.
- Entitlement baseline. Establish the central SQL Server position by edition, metric and agreement, including true-up history and effective dates.
- Instance discovery. Discover every SQL instance with edition, version, host, cluster membership and allocated virtual cores — the licence metric depends on all of them.
- Application mapping. Map each instance to a CMDB application record, and treat every unmapped instance as an exception with a named owner and a closure date.
- Ownership and cost-centre mapping. Map each application to a named business owner and a cost centre, with effective dating so mid-year reorganisations do not corrupt history.
- Environment classification. Classify production, non-production, DR and passive instances, since each attracts different licensing and allocation treatment.
Business value
Mapping completeness becomes a measured figure rather than an assumption, and the unmappable residue is a named, shrinking list.
Phase 2
Allocation model and rate card design
Design the calculation with finance in the room. A model finance has not co-authored will not survive its first dispute.
- Rate card definition. Agree the unit rate basis — per licensed core, per instance, per environment tier — and have finance formally approve it before any statement is issued.
- Shared infrastructure rules. Define how shared clusters and consolidated instances are apportioned, and document the rationale; this is the single most disputed area.
- Non-production and DR treatment. Decide explicitly whether non-production and passive DR instances are charged, discounted or absorbed centrally.
- Reserved capacity treatment. Decide how headroom provisioned for future growth is treated, so business units are not charged for capacity they did not request.
- Calculation frequency and effective dates. Fix the calculation cadence and the effective-date rules for mid-period changes.
Business value
The allocation method is documented, finance-approved and defensible before a single figure reaches a business unit.
Phase 3
Showback operation
Run visibility-only for at least one full cycle. Showback is where the model gets corrected at zero cost.
- Statement design. Issue a monthly statement per business unit showing cost by application, instance, edition and environment — not a single number.
- Owner validation. Ask owners to confirm or dispute mapping, edition and environment, and record the response as evidence of acceptance.
- Dispute adjudication. Log every dispute with its value, adjudicate against the approved rules, and adjust with an audit trail rather than by side agreement.
- Model correction. Feed dispute themes back into the allocation rules, and reissue the corrected statement rather than carrying the error forward.
- Acceptance gate. Do not proceed to chargeback until showback acceptance and mapping completeness clear an agreed threshold.
Business value
The model is stress-tested by the people who will be charged, before anything is charged — which is what makes the subsequent chargeback stick.
Phase 4
Chargeback activation
Post to the ledger. From here the model has to be operationally reliable every cycle, not just accurate in principle.
- Finance posting integration. Post approved allocations to consuming cost centres through the ERP on a fixed cycle, with finance owning the posting method.
- Billing-cycle discipline. Complete calculation, validation and posting inside the agreed close window every cycle, since a late cycle undermines confidence quickly.
- Reconciliation to central spend. Reconcile total allocated cost back to actual central software spend, and investigate the residual rather than absorbing it.
- Dispute process in production. Operate the dispute route with a published resolution target and a defined adjustment mechanism.
- New application onboarding. Define how newly provisioned instances enter the model, so the unmapped residue does not regrow.
Business value
Cost lands with the unit whose decisions created it, on a schedule finance can rely on for its own close.
Phase 5
Consumption review and forecast integration
Close the loop. The point of chargeback is changed behaviour and better forecasts, not cost recovery.
- Post-showback consumption review. Review consumption change with each owner after visibility is introduced — edition downgrades and environment resizing typically appear here first.
- Rightsizing opportunities. Surface Enterprise instances that would run on Standard, and oversized non-production environments, as an owned optimisation backlog.
- Decommission triggers. Use the statement to prompt decommissioning of instances supporting retired applications, which is where the cleanest reductions usually sit.
- Renewal forecast input. Build the central renewal quantity from validated per-BU demand and owner-confirmed growth rather than from last year plus a margin.
- Governance reporting. Report allocation completeness, disputes, recovery rate and consumption trend to the software governance forum.
Business value
Demand moderates because it is visible and owned, and the renewal quantity is built from business-confirmed consumption rather than central extrapolation.
07
Technology Components
Microsoft SQL Server is used as the worked example because its licence metrics make each allocation decision explicit. Products are named as representative examples of a capability category, not as recommendations. The allocation method must be approved by finance before any posting.
Entitlement and contract
- Central entitlement repository
- Agreement and metric definitions
- Approved rate card
- True-up and effective-date tracking
Discovery and infrastructure
- SQL Server instance discovery
- VMware vCenter cluster and host data
- Virtual core allocation
- Environment tagging
- SAM platform inventory
Business mapping
- ServiceNow CMDB application register
- Application ownership record
- Business unit and cost-centre hierarchy
- Effective-dated org data
Financial
- Finance ERP (e.g. SAP, Oracle ERP)
- Allocation engine
- Showback dashboard (Power BI)
- Dispute register
- Reconciliation and audit trail
08
Governance Considerations
Governance should be proportionate. The six areas below are the minimum set that has to be
explicit for this capability to hold up under internal review.
Ownership
A named allocation model owner in technology finance; an application owner per mapped application accountable for their consumption; finance owns the posting method and the rate card.
Decision rights
Finance approves the rate card and any change to it; the model owner approves allocation rule changes; disputes above a value threshold are adjudicated by the software governance forum.
Policies
Allocation policy covering shared infrastructure, non-production, DR and reserved capacity; ownership policy requiring a named owner before provisioning; dispute policy with resolution targets.
Approvals
Rate card approved annually by finance; allocation rule changes approved before the cycle they affect; mid-year cost-centre changes approved with an effective date rather than backdated.
Evidence
Every statement retains the instance-level detail, the rules applied and the version of the rate card used, with the full dispute and adjustment history attached.
Controls
Mapping completeness threshold before chargeback activation, reconciliation of allocated total to central spend each cycle, dispute ageing limits, and onboarding control for newly provisioned instances.
09
Success Metrics
Primary KPI
Cost allocation accuracy
Share of centrally held software cost accurately allocated to an identified business unit and cost centre, with the unallocated residue named and shrinking.
≥ 95% of central software cost
Operational KPIs
Mapping completeness
≥ 98% of instances
Instances mapped to application, owner and cost centre.
% consumption with named app owner
≥ 98%
Consumption attributable to a named business owner.
Billing-cycle completion
100% within close window
Cycles calculated, validated and posted on time.
Chargeback accuracy
≥ 99% of posted value
Postings not subsequently adjusted.
Governance KPIs
Disputes raised
Count and value per cycle
Formal disputes logged against statements.
Dispute resolution time
< 10 working days
Elapsed time from dispute to adjudication.
Showback acceptance
≥ 90% of statements
Statements confirmed by the business owner.
Reconciliation variance
< 1% of central spend
Allocated total against actual central spend.
Value KPIs
Cost recovery rate
Tracked per cycle
Allocated cost successfully posted and retained.
Cost per business unit
Trend per cycle
Allocated software cost by consuming unit.
Cost per application
Trend per cycle
Allocated software cost by mapped application.
Consumption reduction post-showback
Measured against baseline
Change in consumption after visibility.
Forecast accuracy
Within ±10%
Forecast renewal quantity against realised demand.
Indicative targets
Every target above is an indicative KPI for a typical enterprise, intended to support
planning discussions. Baselines should be measured in the first operating cycle and targets
set from them. These are not benchmarks, commitments or achieved client results.
10
Positive Business Impact
Central leverage retained, local accountability added
The organisation keeps one agreement and one compliance position, while the units that generate demand see and own its cost.
Edition and sizing decisions change
Enterprise-where-Standard-would-do and production-sized non-production environments are the first things to move once a business owner sees the line item.
Transparent, defensible consumption data
Statements go to instance level with the rules applied and the rate card version attached, so a dispute is a conversation about facts rather than about the model.
Renewal forecasts built from owned demand
Quantities come from business-confirmed consumption and growth rather than last year's number plus a protective margin.
Duplicate procurement reduced
When a unit can see what it already consumes centrally, the case for buying its own instance usually disappears.
A finance-grade audit trail
Every posting traces to instance-level consumption, an approved rate card version and a named owner's validation — which is what makes the model survive an internal audit.
Outcomes depend on estate, contracts, data quality and organisational context, and are not guaranteed.
11
Related Playbooks
Playbooks commonly delivered alongside, before or after this one.
Important — please read
This playbook describes a typical implementation approach and a representative operating
model. It is illustrative guidance, not a statement of results. Any figures, targets or
ranges shown are illustrative and are intended to support planning discussions rather than
to predict or promise an outcome. Outcomes are not guaranteed and depend on the estate,
contracts, data quality and organisational context of each engagement.
No client names, client data, engagement detail or confidential delivery material is
disclosed anywhere in this library. Technology named in these pages appears only as an
illustrative example of a capability category and does not imply a partnership,
certification or recommendation.
