Cost Allocation Methods: Direct, Step-Down, and Reciprocal, With the Arithmetic

There are three cost allocation methods: direct, step-down, and reciprocal. The direct method allocates support department costs straight to operating departments and ignores the services support departments provide each other. Step-down allocates support departments in a chosen sequence, each one only downward. The reciprocal method solves mutual services simultaneously and is the only one that is arithmetically complete. Almost every cloud cost tool runs the direct method and does not tell you.

This distinction is old accounting, and it stopped being an academic exercise the moment IT became the largest shared cost in most organizations. If your platform team runs the cloud accounts that the data team uses to serve the finance team that pays for the platform team, you have a circular allocation problem, and the method you pick changes the number every department is charged.

Below is the same set of costs run through all three methods, with the arithmetic, so you can see exactly how much the choice moves and where it stops mattering.

What are the three methods of cost allocation?

Direct, step-down, and reciprocal. They differ in one respect only: how much of the service that support departments provide to each other they are willing to model. Direct models none of it, step-down models some of it in one direction, reciprocal models all of it in both directions. Everything else about them, the drivers, the cost pools, the output, is identical.

A fourth term, apportionment, gets used interchangeably with allocation in British and Commonwealth accounting. Where the two are distinguished, allocation means assigning a cost that belongs wholly to one cost center, and apportionment means splitting a shared cost across several. In American practice the word allocation covers both, which is how it is used here.

The setup for the worked example

Two support departments and two operating departments. The support costs are the pools to be spread. The percentages are the drivers, measured however you decide to measure them, and they are the part of this exercise where the real arguments happen.

Total to be allocated is $800,000 in every scenario. All three methods distribute the whole pool, so the totals always reconcile. What changes is who pays which share.

The direct method

The direct method ignores the IT to HR and HR to IT service entirely and reallocates each support pool across the operating departments in proportion to the service they received.

IT serves Retail 50 percent and Wholesale 30 percent, so relative to each other that is 62.5 percent and 37.5 percent. IT's $600,000 splits into $375,000 to Retail and $225,000 to Wholesale. HR serves Retail 54 percent and Wholesale 36 percent, which is 60 percent and 40 percent relative to each other, so HR's $200,000 splits into $120,000 and $80,000.

Result: Retail $495,000, Wholesale $305,000.

The appeal is that anyone can follow it and nobody can accuse you of hiding anything in an algorithm. The weakness is that it charges Retail and Wholesale for the entirety of IT, including the fifth of IT that exists to support HR, without ever saying so.

The step-down method

Step-down puts the support departments in a sequence and allocates them one at a time. Once a department has been allocated it is closed and cannot receive anything from a department later in the sequence. The usual convention is to go in order of cost, largest first.

IT goes first at $600,000: 20 percent, or $120,000, to HR, $300,000 to Retail, $180,000 to Wholesale. HR now holds its own $200,000 plus the $120,000 it just received, so $320,000. IT is closed, so HR's pool goes only to Retail and Wholesale, at 60 and 40 percent: $192,000 and $128,000.

Result: Retail $492,000, Wholesale $308,000.

Now run it the other way, HR first. HR's $200,000 sends $20,000 to IT, $108,000 to Retail, and $72,000 to Wholesale. IT's pool becomes $620,000 and splits 62.5 and 37.5 across the operating departments: $387,500 and $232,500.

Result: Retail $495,500, Wholesale $304,500.

Same costs, same drivers, same method, and Retail's charge moved by $3,500 because somebody chose a sequence. That is the practical problem with step-down and it is the thing a business unit head will find. If you use it, write the ordering rule down in the policy, apply it every period without exception, and be ready to explain why that rule is the right one.

The reciprocal method

The reciprocal method treats the mutual service as what it is, a simultaneous equation, and solves it. Each support department's total cost is its own cost plus whatever it receives from the other, and both statements have to be true at once.

IT equals $600,000 plus 10 percent of HR. HR equals $200,000 plus 20 percent of IT. Substituting the second into the first gives IT = 600,000 + 0.1(200,000 + 0.2 × IT), which simplifies to 0.98 × IT = 620,000, so IT = $632,653. HR is then 200,000 + 0.2 × 632,653 = $326,531.

Those grossed-up pools are what get distributed. IT sends 50 percent, or $316,327, to Retail and 30 percent, or $189,796, to Wholesale. HR sends 54 percent, or $176,327, to Retail and 36 percent, or $117,551, to Wholesale.

Result: Retail $492,653, Wholesale $307,347.

Note that the grossed-up totals exceed the $800,000 being allocated. That is correct and it confuses people the first time they see it. The extra is internal cross-charging between the two support departments, and it cancels out; only the amounts landing on operating departments are real, and those still sum to exactly $800,000.

How much does the method actually change the answer?

On this data the spread is about $3,500 on an $800,000 pool, under half a percent. That is worth knowing, because most writing on this topic implies the choice is enormous and it usually is not. The gap widens with two things: the size of the cross-service percentages, and the number of support departments in the cycle. Two departments swapping 10 and 20 percent barely moves. Six support departments each sending a third of their output to each other produces a difference nobody can wave away.

The practical read: if your support departments barely serve each other, use direct and spend the saved effort on better drivers, which will move the number far more than the method does. If they genuinely serve each other, the reciprocal method is the only one that will hold up when challenged, and it needs software because nobody solves a six-way simultaneous equation in a spreadsheet twice.

Why cloud cost tools only run the direct method

Open the allocation documentation for any major cloud platform and you will find a single proportional pass. Microsoft cost allocation rules move cost between subscriptions, resource groups, or tags by manual whole-number percentages or proportionally by total, compute, storage, or network cost. AWS split cost allocation data divides instance cost across ECS tasks and EKS pods by the CPU and memory each consumed. Both are one pass, both are excellent at what they do, and neither has any concept of a support department receiving cost from another support department.

That is a reasonable design choice, because inside the cloud estate there usually is no cycle. The problem appears when someone tries to use the cloud tool as the IT allocation model for the whole organization. The cloud bill is typically a minority of the IT budget; payroll, contractors, depreciation, licenses, and facilities are the rest, and those are exactly the pools that create the circularity. A tool that reads billing APIs will never see them. This is the dividing line between the two halves of the market, and it is the axis the IT cost allocation software comparison sorts on.

How do you choose a cost allocation driver?

Pick the measure that causes the cost, that the consuming department can see, and that you can source automatically every month. Those three tests eliminate most candidates. Headcount passes the third easily and fails the first for anything usage-driven, which is why it is both the most common driver and the most disputed one.

Better drivers for shared technology, roughly in order of how well they survive scrutiny:

Security is on that list as an honest exception. There is no usage measure for a control that protects everyone, so an agreed even split or a headcount driver is defensible precisely because nobody pretends it is causal. Say that out loud in the policy rather than dressing it up.

The automation test matters more than it sounds. A driver that requires somebody to export a report and paste it into a model on the third working day will be maintained for about four months. The same driver-based logic shows up well outside IT finance, which is why a business that has to split its emissions across the units that caused them ends up wrestling with exactly this problem: the method is easy and sourcing the driver every month is the whole job.

Should you use showback or chargeback with these methods?

Start with showback regardless of method. Showback reports the number without moving money, so a mistake in the model costs an awkward conversation rather than a journal entry that has to be reversed. Run it for two or three periods, let every department argue with its own figures, fix what they find, and only then move to chargeback if the departments genuinely control the spending behind the number. Charging a team for consumption it cannot influence produces resentment and no behavior change, which is the worst of both. The showback vs chargeback comparison goes through the decision in more detail.

Which method should you use?

Map your support departments and draw an arrow for every service one provides another. If the diagram has no cycles, use the direct method, document it, and move on. If it has cycles but they are small, step-down with a written and permanent ordering rule is a reasonable compromise. If the cycles are material, use reciprocal, because it is the only method whose answer does not depend on an arbitrary decision you will have to defend.

Then spend the rest of your time on the drivers. In every allocation review worth having, the argument is about whether the ticket count is right, not about whether the matrix was inverted correctly. Get the consumption data accurate and current, publish the method, and the arithmetic takes care of itself.

Costanalyst handles the consumption half of this: it connects your cloud accounts and SaaS subscriptions read-only and attributes spend to teams, products, and environments, including the untagged remainder, so the cloud and software portion of your model is current without a monthly export. See cost allocation software for how the attribution works, or the guide to cloud cost allocation software if you are comparing the cloud-native options. For allocating shared cloud costs specifically, how to allocate shared cloud costs covers the models that apply inside a single cloud estate.