- IT chargeback fails when usage can’t be tied to the cost center that pays for it. The rate can be fair and the invoice still lands on the wrong budget.
- A wrong mapping doesn’t show in the totals. They still reconcile, so nobody notices until someone measures it, or disputes the bill.
- Build the user-to-cost-center map before you set rates, and keep it current.
Projektengagemang AB is a Stockholm-based engineering firm serving architecture, construction, electrical and telecommunications engineering, HVAC, energy and infrastructure. Its IT department delivers the engineering software for 38 subsidiaries: mainly Autodesk and SOLIDWORKS, plus PTC and MagiCAD. It used to split the cost of each application by the number of users each subsidiary had. So a subsidiary that ran an application for 3 to 4 hours a week paid the same as one that used it 8 hours a day. When Projektengagemang started invoicing on measured use, itemized by user and summarized over cost centers, some subsidiaries turned out to have been undercharged. They'd used more than anyone thought.
The old split added up. It just didn’t follow the use. Metering showed how much each subsidiary used. Putting that use on the right budget took the map behind it: every invoice listed users and summed them by cost center. The guides that rank for IT chargeback best practices cover showback, simplicity and buy-in. None names the org map as a failure point.
Before you argue about rates, prove that every unit of use you charge for maps to the right cost center, whether you charge by the hour, the user or the peak. A wrong mapping moves cost between budgets all year, and the totals still reconcile, so nobody sees it until someone measures it, or disputes the bill.
Why IT chargeback fails: the map, not the rate
One of the least visible reasons IT chargeback fails: usage can’t be tied to the unit that pays for it. Every charge joins three records: who used the software, which team or department that person belongs to, and which cost center funds that team. If the middle record is missing or out of date, the invoice lands on the wrong budget, however fair the rate is.
It’s tempting to start with the rate. The rate matters, since the allocation model and the billing interval decide whether a charge is fair. But a rate multiplies whatever usage it’s handed. Point it at the wrong cost center and it charges the wrong budget, accurately.
So start with a different question: how does each user map to a cost center? Through Active Directory, an HR system such as SAP HR, the name of the computer, or a project code the user registers for their work.
Finance teams outside engineering hit the same problem. In its 2026 research on FinOps and IT financial management, the FinOps Foundation found that when the hierarchy used to tag technical costs doesn’t map to IT finance’s cost structure, “every chargeback reconciliation downstream requires manual intervention.”
Why a CFO should care who pays
If the total is right, does it matter which department carries it? At group level, maybe not. Below group level, it decides what every project and every unit thinks its work costs.
In engineering and manufacturing firms, software cost is meant to land on the work that used it: the project, the business unit, the subsidiary. A headcount split can’t do that. It’s often used because it’s the only key available when nobody can attribute usage. So the office that barely opens an application pays for the one that lives in it, and a project’s real software cost doesn’t reach its margin.
At Projektengagemang the units were separate subsidiary companies. A wrong split didn’t just move a line inside one budget. It moved cost from one company’s accounts to another’s.
Headcount does have one real advantage: it’s predictable. A usage-based charge can be predictable too, if the rates are set in advance and held (see practice 5).
The same FinOps Foundation research describes one organization where IT finance and the Finance department reported different income statements for several months, because each bucketed the same costs differently.
What an org hierarchy means in chargeback terms
For chargeback, the org hierarchy is a lookup. For every unit of software use, it answers one question: whose budget is this?
The chain usually runs person, team, department, business unit or subsidiary, cost center. Projects cut across it. An engineer can sit in one department and work on several projects in the same week.
The record behind that chain already exists somewhere in most firms:
- the directory, such as Active Directory or Microsoft Entra ID
- the HR system, such as SAP HR
- the name of the computer, where each workstation belongs to one person
- a project code the user registers for their work
Any of these sources will do. What fails is keeping the lookup right while people, teams and projects change.
Five ways the map breaks
- People change departments. If the map keeps only the current department, last quarter’s usage moves with the person. LicenseAnalyzer™ can keep the history of a user’s department for this reason.
- People work for several units at once. Users who belong to several groups, departments or cost centers are the hard case. One answer is to have users register the project they’re working on, so their usage carries a project code.
- The organization merges or splits. A reorganization can change cost centers on a single day. A map kept by hand lags behind, and the usage in between lands on the old structure.
- Cost centers cross legal entities. A cost center can belong to one division or legal entity, or span several. If the map doesn’t say which, cost crosses company lines.
- A team shares one login. The license log records the account, not the person. The computer name can resolve it when each workstation belongs to one person. When two people share a workstation, nothing can tell them apart.
IT chargeback best practices that start with the map
- Map before you price. Agree the cost centers first, then the key that ties each user to one of them. Settle the hard cases (movers, shared people, shared logins) before the first invoice, not after the first dispute.
- Charge usage where the cost is material. Measure and charge the expensive engineering applications. Leave small items in overhead, where tracking them isn’t worth the effort.
- Fit the allocation basis to the license. Common bases are distinct users, elapsed time, and peak concurrent use per group, counted per hour, day or month. The wrong basis creates its own unfairness. A user who keeps an application open for 8 hours on a quiet Sunday shouldn’t pay the same as one holding 8 licenses for an hour at peak.
- Show before you charge. Run the model on last year’s usage and share the figures before anyone is billed. Compare each unit’s total with what a headcount split would have charged it, and ask each budget holder to check the names listed under their cost center. That surfaces mapping errors while nobody has paid for them yet. Next week’s post, Showback First, Chargeback Later, covers the sequence.
- Hold the rates. Once a model is tested and the rates are set, change them rarely. Budget holders need to predict what they’ll pay, and predictability is what headcount splits do well.
- Give the map an owner. Someone has to keep the user-to-cost-center key current as people and projects move.
Where LicenseAnalyzer and LicensePlanner fit
LicenseAnalyzer™ records who used which engineering application, when, and for how long. It reads each user’s department, location and other details from Active Directory or a text file, refreshes them nightly, and can keep their history so a move between departments doesn’t rewrite last quarter.
LicensePlanner™, its plugin, turns that usage and that map into charges. It allocates software maintenance cost to departments, projects or business units based on actual use, for showback or chargeback, and produces the invoices: cost center, period, fixed and usage charges, and the total. That’s IT chargeback built on the map rather than on a headcount.
Projektengagemang’s quarterly invoices came from LicenseAnalyzer usage data. See how LicensePlanner works as IT chargeback software.
Preguntas frecuentes
Why does IT chargeback fail?
One of the least visible reasons: usage can’t be tied to the unit that pays for it. Chargeback joins who used the software, which team that person belongs to, and which cost center funds the team. If the org record in the middle is wrong, the invoice lands on the wrong budget, however fair the rate.
What is an internal chargeback model?
It’s the method for charging departments, projects or business units for the IT and software they use. Common bases are distinct users, elapsed time and peak concurrent use per group, counted per hour, day or month.
What data does IT chargeback need?
Three things: usage records per user and application, an org map that ties each user to a team, department and cost center, and a price per application or feature, often taken from the vendor’s price book.
Should you start with showback or chargeback?
Showback. Run the model on past usage and share the figures before anyone is billed. That’s where mapping errors surface while they’re still free to fix.
See your usage mapped to your cost centers
You know what the invoices add up to. The question is whose budget each line belongs to. Schedule a live demo and we’ll show how LicenseAnalyzer and LicensePlanner allocate usage to departments, projects and cost centers.
Next in this series: Showback First, Chargeback Later: A Sequence That Survives Contact With Finance
