Support-Department Cost Allocation: Direct, Step-Down and Reciprocal Methods

Every factory and every group has departments that do not make the product: maintenance, IT, HR, finance, the Dubai head office. Their costs are real, and full product costs — for inventory valuation, long-run pricing and make-or-buy decisions — must include a fair share of them. But 'fair share' is where the arguments start, because any allocation is partly arbitrary: the support department's costs do not move with any single production measure in a clean causal line. The running example is Emirates Pack Group's shared-services centre (SSC) in Dubai, serving two production divisions — Flexible Packaging (FP) and Corrugated (CP) — through two support departments: IT (AED 900,000 annual cost) and HR (AED 600,000). IT serves FP, CP and HR (the HR system runs on IT infrastructure); HR serves FP, CP and IT (recruiting IT staff). Production bases: FP uses 6,000 IT service-units and has 300 employees; CP uses 4,000 IT service-units and has 200 employees; IT itself uses 1,000 service-units internally and has 20 employees served by HR; HR has 10 employees served by nobody (for simplicity, HR's own HR needs are ignored). Three methods will allocate the AED 1.5 million, and the differences will move product costs enough to matter for pricing.

The direct method allocates each support department straight to production, ignoring services between support departments. IT's AED 900,000 goes to FP and CP on IT service-units, excluding IT's own use and HR's use: FP gets 6,000/10,000 × 900,000 = AED 540,000; CP gets 4,000/10,000 × 900,000 = AED 360,000. HR's AED 600,000 goes on headcount, excluding IT staff: FP gets 300/500 × 600,000 = AED 360,000; CP gets 200/500 × 600,000 = AED 240,000. Totals: FP AED 900,000, CP AED 600,000 — a neat 60/40 split. The method's virtue is simplicity: explainable in one slide, auditable in one afternoon. Its blindness is the mutual service: IT's support of HR (the HR system, the payroll infrastructure) is ignored, so HR's 'cost' is understated and IT's allocation to production carries costs that partly belong to serving HR. When inter-support services are small, the error is small and the direct method is the pragmatic choice — most SMEs should stop here. When they are material (the IT department that is really the group's technology backbone serving every support function), the direct method systematically misstates, and the step-down or reciprocal method earns its complexity.

The step-down (sequential) method allocates support departments one at a time, in a chosen order, recognising services to departments later in the sequence — including other support departments — but never looking back. Order choice: IT serves HR materially (the HR systems), while HR's service to IT (recruiting 20 IT staff) is smaller, so IT goes first. Step 1: IT's AED 900,000 allocated on total service-units including HR's 1,000 (bases: FP 6,000, CP 4,000, HR 1,000; total 11,000): FP gets 6,000/11,000 × 900,000 = AED 490,909; CP gets 4,000/11,000 × 900,000 = AED 327,273; HR gets 1,000/11,000 × 900,000 = AED 81,818. Step 2: HR's total is now 600,000 + 81,818 = AED 681,818, allocated on headcount to FP, CP and IT — but IT is already 'closed' (allocated departments receive nothing further): FP gets 300/500 × 681,818 = AED 409,091; CP gets 200/500 × 681,818 = AED 272,727. Totals: FP 490,909 + 409,091 = AED 900,000; CP 327,273 + 272,727 = AED 600,000. Interesting — the same 60/40 totals as the direct method in this symmetric example, though the departmental composition differs. The order matters in asymmetric cases: reversing it (HR first) would give different product costs, which is the method's honest weakness — disclose the order and keep it consistent. Step-down is the workhorse of practice: materially better than direct where inter-support services are one-directional, and far simpler than reciprocal.

The reciprocal method recognises all mutual services simultaneously. Let I = IT's total cost including HR's service to it, H = HR's total including IT's service to it. IT's 11,000 service-units: FP 6,000, CP 4,000, HR 1,000 — so HR bears 1/11 of I. HR's 520 employees served: FP 300, CP 200, IT 20 — so IT bears 20/520 = 1/26 of H. Equations: I = 900,000 + H/26; H = 600,000 + I/11. Substituting: I = 900,000 + (600,000 + I/11)/26 = 900,000 + 23,076.92 + I/286. So I × (285/286) = 923,076.92, giving I = AED 926,316; then H = 600,000 + 926,316/11 = AED 684,210. Allocate to production: FP gets IT 6,000/11,000 × 926,316 = AED 505,263 plus HR 300/520 × 684,210 = AED 394,737, totalling AED 900,000; CP gets 4,000/11,000 × 926,316 = AED 336,842 plus 200/520 × 684,210 = AED 263,158, totalling AED 600,000. (The symmetry of the example again yields 60/40 — in real asymmetric cases the methods diverge meaningfully.) The reciprocal method is theoretically complete: every dirham of mutual service is recognised, no ordering judgement is needed, and the result is independent of sequence. Its cost is complexity — simultaneous equations for two departments, matrix methods for six — and the uncomfortable truth that the extra precision often changes product costs by less than the measurement error in the bases. Use it where inter-support services are large and multidirectional (the classic case: IT and HR genuinely serving each other heavily); otherwise step-down's approximation is the better economics.

The accuracy ranking is settled — reciprocal, then step-down, then direct — but the practical choice weighs accuracy against cost and behaviour. Direct wins on simplicity and auditability: any manager can follow it, any auditor can reperform it, and where inter-support services are under 10–15% of support costs the error is immaterial. Step-down wins the middle ground: it captures the dominant one-way services (IT serving everyone, facilities serving everyone) with a disclosed ordering rule, and most ERP systems support it natively. Reciprocal wins on theoretical purity and on independence from ordering choices — valuable where support departments genuinely serve each other in both directions and the amounts are material. A pragmatic selection rule: start with direct; estimate the inter-support services; if recognising them would move any production department's allocation by more than 5%, move to step-down; if services are strongly mutual and material, use reciprocal. And whichever method is chosen, apply it consistently — switching methods to flatter a particular division's costs is a governance failure, not a technical refinement. The allocation method should be documented in the cost-accounting policy with its bases, order and review cycle, approved at finance-director level.

All three methods above used single rates — total support cost on one base. The dual-rate refinement splits each support department's cost into fixed and variable and allocates them differently: fixed costs on budgeted or long-run capacity (the 'price' of having the support available), variable costs on actual usage. Emirates Pack's IT: AED 900,000 splits into AED 500,000 fixed (infrastructure, licences, core staff) and AED 400,000 variable (support hours, consumables). Fixed is allocated on budgeted service-units (say FP 6,500, CP 4,500 including normal support-department use); variable on actual units consumed. Why it matters: under single-rate on actual usage, if CP outsources its IT and leaves, FP's allocation absorbs IT's fixed costs — the death spiral, where the remaining user's bill rises because someone else left, prompting more departures. Dual-rate quarantines the effect: FP pays for the capacity it reserved (budgeted) plus what it used (variable), and CP's departure leaves its reserved-capacity share visibly idle — a management fact, not a hidden penalty on FP. The variable portion also gives the right short-run signal: the marginal cost of one more IT ticket is the variable rate, which is what should guide 'should we log this request?' decisions. Dual-rate costs more to administer (fixed/variable splits, budgeted bases to maintain), but for significant support departments it is the recommended practice — fairer, more stable, and behaviourally sounder.

The allocation base is not just arithmetic — it is an incentive. Charge IT on headcount and managers hire contractors instead of employees to dodge the charge; charge on actual tickets and they stop logging requests and let problems fester; charge facilities on floor space and they finally surrender the empty meeting rooms. Good bases share three properties: causality (the base drives the cost — tickets drive support cost, headcount drives HR cost), controllability (the user can influence the base — floor space yes, revenue no), and measurability at reasonable cost. Emirates Pack's SSC uses: IT — devices plus weighted tickets; HR — headcount plus recruitment cases; finance — transactions processed; facilities — square metres occupied. Two bases beat one where the cost has two drivers (HR: headcount for routine services, recruitment cases for hiring spikes). Review bases annually: the business changes, and a base that made sense when the SSC was built may now be gamed or obsolete. And publish the rates in advance — budgeted rates for the year, fixed before the year starts — so divisions can plan. Actual-rate allocation (dividing actual cost by actual usage) punishes efficient users when the support department overspends and rewards them when it underspends: the production manager's allocation should reflect her usage, not IT's budget discipline. Predetermined budgeted rates, exactly like the job-costing overhead rate, keep each party accountable for what it controls.

In UAE groups, the support departments usually live in a shared-services centre serving multiple legal entities — and the allocation becomes a service agreement with commercial overtones. Emirates Pack's SSC charges its divisions through annual service-level agreements: each service catalogued (payroll processing per payslip, recruitment per hire, IT support per ticket tier, month-end close per entity), each with a driver rate set from the budget, each division forecast its consumption. The three allocation methods sit underneath: the SSC's internal cost build uses step-down or reciprocal to get service costs right; the charging uses driver rates for transparency. Three SSC-specific disciplines: benchmarking — the SSC's rates are compared to outsourced alternatives annually, and divisions may contest charges above market (the contestability that keeps the SSC honest); unbundling — divisions see what they pay for and can decline discretionary services, which kills the empire-building that cost centres tend toward; and tax awareness — cross-border SSC charges between UAE and other GCC entities are related-party transactions subject to transfer-pricing documentation, so the driver rates need arm's-length support, not just internal convenience. Done well, the SSC's allocation system turns overhead from a tax on the divisions into a priced service they manage — which is the behavioural payoff of everything this page has computed.

A useful control on any allocation exercise: the total allocated to production must equal the total support-department cost — AED 1,500,000 in every method above (900,000 + 600,000). If the production departments receive AED 1,480,000, AED 20,000 leaked: usually a base defined inconsistently (IT service-units counted differently in step 1 and step 2) or a department accidentally left out of a denominator. Run the check every period before publishing the rates. A second check: no production department's allocation should move by more than a few percent when switching between step-down and reciprocal unless inter-support services are genuinely large — a big swing means the ordering assumption in step-down is doing heavy lifting and deserves explicit disclosure. These two reconciliations take minutes and catch the errors that silently distort product costs for years.

Allocated support costs flow into product costs through job costing and ABC — the ABC page's activity drivers are the refined version of this page's bases. The responsibility-accounting page governs who is judged on allocated costs, and the controllability principle limits their use in performance evaluation.