Pricing the deferral: a technical debt statement your finance director can interrogate

Every organisation of any size carries a set of known compromises: the interface held together by a scheduled file transfer, the finance system two releases behind, the reporting database nobody owns, the payroll process that depends on one person remembering a step. Each was a reasonable decision at the time. Collectively they form a liability that rarely appears in the management accounts until it converts into an incident, an audit finding or an emergency capital request.

The reason is not that IT leaders are reluctant to raise the subject. It is that the subject arrives at the finance table in a form finance cannot work with — a register of items, each described in engineering terms, with no common scale and no money attached. A finance director can challenge a cost, a range or an assumption. It is far harder to challenge a list.

Why engineering language fails at the finance table

A technical debt register typically records what is wrong and how it might be fixed. It rarely records what carrying the debt costs, what clearing it would cost, or what the organisation receives in return for either. Without those three elements there is no decision to make, only a backlog to acknowledge — and backlogs are deferred by default.

There is a second problem. Registers tend to expand until they become unreadable. When a document lists eighty items across six systems, the reader concludes that the position is broadly as expected and moves on. Selectivity is not dishonesty; it is what makes the document usable.

What the statement contains

A technical debt statement should fit on one page and answer four questions.

What is the exposure? A short list of the components where failure, or the inability to change, would materially affect the organisation. Six to ten items is usually right.

What does carrying it cost each year? Ranges are acceptable and expected.

What would clearing it cost, and over what period? Again in ranges, with dependencies named.

What are the options? At least three, including the option to carry the exposure deliberately.

The statement is not an engineering artefact with a financial summary attached. It is a financial and operational document that draws on engineering evidence.

Building the inventory without a rewrite

The starting material almost always exists. Support contracts and renewal dates reveal unsupported or soon-to-be-unsupported components. Change logs and incident records show where effort is repeatedly absorbed. Project estimates show where upgrades carry a premium because of local customisation. Rota records and exit interviews reveal single-person dependencies.

Consolidate ruthlessly. Group related items that share a cause: a set of customisations which together block a platform upgrade should be one line, not twelve. Then apply a simple test — if this item disappeared tomorrow, would anyone outside IT notice? Items that fail the test belong in a maintenance plan, not a board paper.

A scoring approach that admits uncertainty

False precision is the fastest route to losing a finance audience. A score of 7.3 out of 10 invites an argument about the decimal rather than the substance. Use small integers and bands.

Score each retained item from 1 to 3 on four dimensions:

• Consequence — what stops if this fails or cannot change. Three means a core process, statutory reporting or a customer-facing service.
• Evidence — how close failure is. Three means support has already lapsed or incidents recur; one means the risk is theoretical.
• Breadth — how much of the organisation is affected.
• Exit difficulty — how hard and how slow replacement or workaround would be.

Totals run from 4 to 12. Map them to three bands: monitor (4–6), contain (7–9), prioritise (10–12). The bands, not the individual scores, are what the board should see.

Turning bands into money

Four cost lines are usually enough, and all should be presented as ranges.

Support premium. Extended support, cover for unsupported components, or the uplift on a replacement contract entered without commercial leverage.

Resilience spend. Additional backup, monitoring or manual controls that exist only because of the exposure.

People cost. Hours absorbed by workarounds and rework, converted at a loaded day rate. Estimate conservatively, state the assumption, and let finance adjust it.

Change drag. The percentage uplift on projects touching the affected area. A range of 15 to 30 per cent is defensible for heavily customised platforms; anything more specific needs evidence behind it.

Add clearing cost as a separate range, with the delivery dependency named — a constrained supplier market, a migration window, or an internal team already committed elsewhere.

Sample wording for the finance paper

‘Of the six exposures listed, two sit in the priority band. Together they account for an estimated £X–£Y of annual carrying cost, principally resilience spend and absorbed staff time, and they add an estimated 20–30 per cent to the cost of any change in the finance and payroll estate. Clearing both is estimated at £A–£B over three quarters, with the constraint being supplier availability rather than internal capacity. Management recommends clearing one and containing the other, for the reasons set out below.’

That paragraph is challengeable. It names a range, an assumption, a constraint and a recommendation, and it is short enough to survive a board pack.

Three options, not one number

Presenting a single remediation figure invites either refusal or deferral. Presenting three options moves the conversation to sequencing and risk appetite, which is where it belongs: carry and monitor with an agreed trigger for review; contain through targeted work that reduces consequence without full replacement; clear in one or two tranches.

Each option should state what the organisation accepts. Carrying debt is a legitimate choice when the exposure is understood and the trigger for revisiting it is written down.

Traps to avoid

Do not present a single point estimate. Do not double count — support premium and staff time are distinct, but resilience spend often overlaps with an existing control. Do not frame technical debt as a moral failing, or the audience will hear criticism of past decisions rather than a forward choice. Do not rely on end-of-support dates as the only evidence of urgency. And do not let the statement become an annual audit artefact; refresh it alongside renewal dates, because that is when the numbers move.

Ownership and refresh

The statement is owned jointly. IT supplies evidence and scoring; finance supplies rates, ranges and challenge. Refresh it before each significant renewal and once a year alongside the budget. The value is not the number on the page. It is that the organisation can no longer say ‘we will fix it later’ without an agreed figure attached to the delay.