Every company carries technical debt it can count: the legacy to rewrite, the licences to migrate, the tickets in the backlog. It also carries a debt no monitor will ever show, because people absorb it for free. The manual export. The knowledge that lives in one head. The workaround nobody wrote down. This second debt has no functional owner. It surfaces only when someone leaves, a system breaks, or an audit finally drags it into the light. By then it is no longer a line item. It is a crisis with a calendar that does not wait.

A balance sheet only tells you half of what a company owes

Accountants solved this problem a long time ago. A balance sheet shows what a company owns and what it owes. It does not show everything the company is committed to. A nine year lease. A pension obligation. A guarantee given to a partner. A lawsuit in progress. None of it sits in the liabilities column. All of it is real.

This is what the off-balance-sheet annex is for. The accounting rule does not ask for it out of caution. It asks for it because without it, the balance sheet lies. The international standard that governs this, IAS 37 (Provisions, Contingent Liabilities and Contingent Assets), exists precisely to force what is owed but uncertain back into the open. The French Plan Comptable Général carries the same demand in its annex on off-balance-sheet commitments. Different rulebooks, one principle: what is not recorded is still owed.

The most expensive lesson on this point was Enron, in 2001. The company moved enormous obligations into special purpose entities that never appeared on the main balance sheet. On paper, the group looked healthy. The obligations were real the whole time. When they came back into view, the company did not slow down. It imploded. I cite it as a textbook case, not as a thriller. The mechanism is what matters: what you keep off the books does not disappear. It waits for the conditions that make it visible.

A company’s information system has the same two layers. There is the technical balance sheet: servers, licences, contracts, open tickets. Things you can name and cost. And there is the technical off-balance-sheet: everything that keeps the company running without appearing anywhere. That second layer is the one I want to talk about.

The debt people absorb has no owner, and that is what makes it dangerous

Recorded technical debt has a strange virtue. It is honest by construction. It only contains what teams know how to name and agree to report. A module flagged for a rewrite, an old framework past its support window: those make it into the register because someone can describe them.

The off-balance-sheet layer never makes it in, because describing it would require someone to notice it first. The export reworked by hand every month, because two systems do not talk to each other. The knowledge of an old subsystem that nobody ever wrote down. The process workaround learned on the job, passed on by word of mouth, never documented. The team that has been compensating for a broken tool for three years no longer sees it as debt. They see it as doing their job well.

There is a name for this in the research on work itself. Susan Leigh Star and Anselm Strauss, in 1999, described the invisible work that keeps systems running and never appears in the formal account of who does what. Their point was not technical. It was organisational. Some work only becomes visible when it stops. Until then, it is absorbed, silently, by the people doing it.

That is the heart of it. This debt has no owner. Ward Cunningham coined the technical debt metaphor to talk about code you ship fast and pay for later, and Martin Fowler has spent years refining it. The metaphor holds, but it stops at the code. The version that hurts a non-technical CEO the most is not in the code. It is in the gap between what the organisation depends on and what the organisation actually owns. A skill in one person’s head is not an asset. It is a commitment with no maturity date, payable on the worst possible day.

A clean modernisation project dies on what nobody wrote down

Here is how it plays out. Names and details changed, the shape is one I have seen more than once.

A mid-sized company decides to modernise. The plan is sound. Replace an ageing platform, connect the systems that do not talk, retire the manual steps. The budget is approved. The timeline is tight but reasonable. On paper, it is a clean project. Everyone signs off.

The first audit phase is supposed to be a formality. Map the existing processes, confirm the dependencies, start building. It is not a formality. It is where the off-balance-sheet comes out.

The monthly closing, it turns out, depends on a spreadsheet. Not a system. A spreadsheet, built and maintained by one person, who pulls data from three places, reconciles it by hand, and produces the file the whole finance chain waits for. No one above that person knows the spreadsheet exists in this form. They know the number arrives on time. They never asked how.

The same audit finds five more of these. A reporting flow that only runs because someone manually triggers it. A customer onboarding step that lives in a checklist on one laptop. A nightly job that breaks twice a year, and only one engineer knows the sequence to bring it back. Each one, on its own, looks small. Together, they are the load-bearing structure of the company. And not one of them is in the project plan, because the plan was built from the recorded debt, not the absorbed one.

Now the project has a choice it did not budget for. Modernise on top of dependencies it does not understand, and risk breaking the closing in month two. Or stop, document everything first, and blow the timeline. Both options cost more than the original estimate. The debt that never showed up on a dashboard just became the single most expensive variable in the project. It was always there. It only acquired a price the moment the conditions changed.

This is the off-balance-sheet, exactly as an accountant would recognise it. A commitment that costs nothing while everything holds, and everything the day it moves.

Some people do not just hold the debt, they guard it

There is a sharper version of this, and it is the one most organisations refuse to name.

Sometimes the debt is not absorbed by accident. It is cultivated. A person works out, consciously or not, that knowledge kept private becomes power. So they keep it private. They do not document. They make the process a little more complicated than it needs to be, just enough to stay the only one who can run it. They present dependency as expertise.

The signals are easy to miss because they look like competence. The person delivers. They are precious. People around them say, with admiration, that they are irreplaceable. Irreplaceable is rarely a compliment. It is a diagnosis.

The hardest cases add hostility to opacity. Challenge the work, and it does not turn into a technical debate. It turns into a political one. So people stop challenging. And every month, a little more of the company runs through one head, with the organisation quietly agreeing not to look. Management complicity is part of the mechanism. It is easier to keep the person happy than to confront what their indispensability is costing.

This is where the absorbed debt becomes almost impossible to see from the top. Ordinary invisible work is just unrecorded. Guarded invisible work is actively hidden, by someone with an interest in keeping it hidden. A CEO cannot audit what no one will describe, and the one person who could describe it is the one person who never will.

A CEO cannot audit what they do not know exists

Here is the trap, stated plainly. The non-technical leader is asked to govern a risk they cannot see, through people who, for different reasons, will not show it to them.

It is not a competence problem. You do not need to read code to run a company that depends on code. You need to know which questions to ask, and you need someone who can ask them without triggering the war. The leader sitting in the chair sees the top layer: the dashboards, the recorded debt, the reassuring sentence that the number always arrives on time. The layer underneath does not rise on its own. It comes out at the audit, at the departure, at the crisis. Always late. Always under pressure.

The fix is not heroic. It is patient. You map where the company actually depends on individuals rather than systems. You make the implicit explicit, one process at a time. You turn what lives in two or three heads into something the company owns. You do it without putting anyone on trial, because the goal is not to punish the person who absorbed the debt. The goal is to stop the company from depending on an accident.

That last word matters. An organisation that runs on accident eventually discovers the exact cost of that accident. The only real choice is whether you learn the number on your own terms, with time to act, or on the day someone hands in their notice and the inventory you never made becomes due all at once.

Hidden load-bearing structure

Put the off-balance-sheet back on the books

The discipline an accountant applies to commitments is the discipline a leader should apply to dependencies. Not because it is elegant. Because the alternative is a balance sheet that lies.

Start with one question, asked of the right people, in a way that does not feel like an accusation: if this person were out for a month, what would stop? Then follow the answers, because they are never as narrow as the first response suggests. What stops is the map of your real off-balance-sheet. Write it down. Give each item an owner who is not a single irreplaceable individual. Turn the spreadsheet into a system, the tribal knowledge into documentation, the workaround into a decision someone made on purpose.

None of this shows up on a monitor, which is exactly why it gets skipped. The debt people absorb is the cheapest thing in the company until the day it is the most expensive. A leader who learns the number before that day keeps the choice. A leader who waits inherits a debt they never signed.

Sources

  • IFRS Foundation, IAS 37 Provisions, Contingent Liabilities and Contingent Assets, 2001 (à jour 2026). https://www.ifrs.org/issued-standards/list-of-standards/ias-37-provisions-contingent-liabilities-and-contingent-assets/
  • Autorité des Normes Comptables, Règlement ANC n° 2014-03 relatif au Plan Comptable Général, version consolidée au 1er janvier 2026 (section informations relatives aux engagements hors bilan). https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/Reglements/Recueils/PCG_janvier2026/PCG–1er-janvier-2026.pdf
  • Peter Bondarenko, Enron scandal, Encyclopædia Britannica, 2026. https://www.britannica.com/event/Enron-scandal
  • Susan Leigh Star & Anselm Strauss, Layers of Silence, Arenas of Voice: The Ecology of Visible and Invisible Work, Computer Supported Cooperative Work, 1999. https://link.springer.com/article/10.1023/A:1008651105359
  • Martin Fowler, Technical Debt, 2019. https://martinfowler.com/bliki/TechnicalDebt.html

FAQ

What is 'off-balance-sheet' technical debt?

It’s the technical debt that never gets recorded anywhere because it has no functional owner: the manual export nobody automated, the knowledge that lives in one person’s head, the workaround nobody wrote down. Like the off-balance-sheet commitments accounting standards such as IAS 37 force companies to disclose, this debt is real and owed even though no register captures it — and it surfaces only when someone leaves, a system breaks, or an audit drags it into the light.

Why is unrecorded technical debt more dangerous than the debt on your official backlog?

Because recorded debt is honest by construction — it only contains what teams can name and agree to report — while unrecorded debt has no owner and stays invisible until a crisis forces it into view. As the Enron collapse showed with financial obligations moved into special purpose entities, what you keep off the books does not disappear; it waits for the conditions that make it visible, and by then it’s a crisis with a calendar that doesn’t wait, not a line item you can plan around.