What Is a True-Up Cost Calculator, and Why It Matters

A true-up cost calculator is the model that reconciles the offshore cost you projected against the cost you actually incurred, line by line, over a defined period. It is not a budgeting tool and it is not a savings calculator. Its job is to close the gap between the business case that got a capability centre approved and the invoice reality that arrives eighteen months later.

The term comes from contract accounting, where a true-up is the adjustment made once actual figures replace estimates. Applied to a capability centre it does something uncomfortable and valuable: it forces every assumption in the original business case to be restated against what happened, and it makes the omissions visible rather than absorbing them into a general overhead line.

This matters because offshore business cases fail in a predictable way. They are rarely wrong about salary, which is the number everyone scrutinises. They are almost always wrong about everything that sits around salary, and those omissions compound quietly until somebody asks why the saving on the slide does not appear in the accounts.

What a true-up calculator actually does

It takes every cost assumption in the original business case, restates it as an actual figure for the period, and reports the variance with an explanation. That is all. The discipline is in the completeness rather than the arithmetic.

The reason it is valuable is that offshore costs arrive on different schedules. Salary appears monthly from month one. Statutory and compliance costs appear annually and scale with headcount. Replacement costs appear when attrition starts, typically from month nine. Onshore management overhead never appears on any invoice at all, because it is time rather than spend. A model that only captures what shows up on an invoice will understate the true cost by a margin that grows over the first two years.

The line items that break business cases

The table below lists the components a complete true-up model needs. The right hand column indicates how often each is missing from the original case in practice. The pattern is consistent: the further a cost sits from payroll, the more likely it is to have been left out.

The bottom four rows are the ones that turn a modelled saving into a disputed one. They are all real, and none of them appear on an invoice.

Ramp cost, the item that hides in plain sight

Ramp cost is the fully loaded cost of the team during the period before it produces useful output. It is not a rounding item. A team that takes four months to reach productive output carries four months of full cost against near zero delivery, and if the business case assumed output from month one, that gap has to land somewhere.

The reason it is omitted so often is that it feels like a one off, and one offs get excluded from run rate comparisons by habit. But it recurs with every expansion, and in a centre that grows over three years there is almost always a ramp cohort in flight. Treating it as a permanent line rather than a start up cost produces a far more honest model.

The practical modelling approach is to assume a productivity curve rather than a switch. A common planning assumption is that a new hire delivers a small fraction of steady state output in the first month, rising over the following three to five months depending on domain complexity and how well knowledge transfer was structured.

Knowledge transfer drag, the cost that lands on the wrong team

When an onshore team teaches an offshore team, the onshore team slows down. That lost output is a genuine cost of the transition and it is almost never modelled, partly because it appears in a different budget from the one being scrutinised. The people paying it are not the people presenting the business case.

It matters most because it is concentrated in exactly the people you can least afford to slow down. Knowledge transfer is done by the engineers who hold the most context, who are usually also the ones carrying the most critical work. A model that ignores this consistently understates the cost of the first two quarters and, worse, creates the impression that the offshore team is underperforming when the real effect is that the whole system slowed down temporarily by design.

How to build one

The calculator itself is straightforward. The work is in capturing the baseline honestly and committing to a review cadence before the numbers become politically inconvenient.

A worked example of where the gap opens

Consider a twenty person capability centre where the original case modelled only salary, benefits, workspace and recruitment. The four omitted components below are the ones that typically surface between month nine and month eighteen, which is precisely when the first serious review happens.

None of these are exotic. Each is an ordinary consequence of running a team, and each was foreseeable when the case was written. What makes them damaging is not their individual size but the fact that they all land after the saving has already been announced.

What good looks like

A healthy true-up shows variance, and the variance is explicable. A true-up that reconciles perfectly is usually evidence that the model was adjusted to match the outcome rather than that the outcome matched the model.

• Every cost component has a named owner who supplies the actual figure
• Ramp and transfer drag are separate visible lines rather than absorbed into overhead
• The baseline is dated, circulated and unchanged since before the first hire
• Variance is explained in words, not just quantified
• The model is reviewed on a fixed cadence rather than when someone asks a difficult question
• Cost per delivered outcome is tracked alongside cost per head

Frequently asked questions