Every finance team runs on something nobody documented

Somewhere in every finance department there is a spreadsheet nobody fully understands. It was built by someone who left three years ago, it runs every month-end close, and the standing instruction is: do not touch the macros. This is not a pathology. It is the normal consequence of giving a powerful calculation engine to people whose job is accounting, not software engineering, and then walking away.

Dan Bricklin and Bob Frankston created VisiCalc in 1979 as a tool for modelling, not a deployment platform. What changed was that businesses used it as both. By the time Lotus 1-2-3 arrived in 1983 and Excel followed for Windows in the late 1980s, the spreadsheet had become the fastest way to automate a financial process without raising a capital project. A macro recorded in an afternoon could replace a week of manual work. No procurement, no IT ticket, no specification document. That frictionlessness was the feature, and it is also why the resulting artefact was never treated as software.

The professional category for what these files actually are is end-user computing — applications built and maintained by people whose primary role is not development. Regulators have had a view on this for longer than most finance teams realise. The Sarbanes-Oxley Act of 2002 introduced internal control requirements that, read carefully, extend to spreadsheets used in financial reporting. A model that feeds a published number is part of the control environment. Its logic should be documented, its inputs validated, its version history maintained. Almost none of the spreadsheets that actually do this work were built with any of that in mind.

Why they persist

The persistence of undocumented spreadsheet infrastructure is not irrational. These files work. They have been tested by years of monthly execution, and the person who built them optimised them for the actual problem rather than an imagined general case. The knowledge encoded in the cell references, the hidden columns, the macro that reformats the bank extract before the pivot runs — all of it is domain knowledge. It just happens to be stored in a format that makes it nearly invisible to anyone trying to audit or transfer it.

What makes them load-bearing is the same thing that makes them hard to replace: they sit at joints in the process. The ERP exports a file; the spreadsheet transforms it into the format the consolidation tool expects. When the ERP vendor changes the export schema, someone updates the macro. When the consolidation tool is replaced, someone adjusts the output. The spreadsheet absorbs compatibility work that was never assigned to anyone as a formal task. This is the mechanism by which informal tooling accumulates structural importance — not through any decision, but through continuous small adaptations that leave no record.

The month-end close is where the exposure becomes acute. Finance teams operate under hard deadlines, and the spreadsheet that breaks at 10pm on day three of the close is not a curiosity; it is a crisis. The institutional response is typically to find the person who last touched it, apply a fix and move on. Documentation comes later, which means it never comes. The organisational knowledge of how the file works lives in one person's head, and when that person leaves, the team is left with something that must be preserved exactly because it cannot be understood.

The audit implications of this are predictable. An auditor asking to trace a reported figure back to its source will eventually arrive at a cell formula or a Visual Basic module that nobody can fully explain. The trail does not stop at the spreadsheet; it stops inside it. Remediation — proper documentation, version control, a formal change process — is expensive and time-consuming, and it is almost always deferred until something goes wrong. Which is why, in finance departments everywhere, the instruction remains the same: do not touch the macros.