Nearly every organisation we talk to is tracking equipment and its paperwork in a spreadsheet, and it usually works. It is worth being precise about why it stops working, because the answer is not that spreadsheets are bad.
One tab, four different things
A typical tracking sheet has a row per asset, a column for the certificate expiry, a column for the last service, and a column called Notes holding everything that did not fit. Four distinct concepts — the asset, the obligation, the recurring plan, the evidence — are flattened into one row.
That flattening is what makes the sheet unable to answer the questions you eventually need. An asset with three certificates needs three rows or three column groups, and both choices break something. A certificate that was renewed needs its history somewhere, so the old value gets overwritten and the history is gone. A failed inspection has no natural home at all.
One date where there are three
Most sheets have a single expiry column. In practice at least three dates matter, and they land on different days and on different people:
- The expiry itself, which is when you are non-compliant.
- The cancellation deadline, after which a contract quietly rolls over for another term.
- The renewal lead time, which is how long the authority actually takes to process it.
The expensive failures are not the ones you see coming thirty days out. They are the permit that takes twelve weeks to process and the contract whose cancellation window shut in March. A single expiry column cannot represent either.
A sheet cannot tell you it is stale
This is the failure mode that actually causes incidents. A spreadsheet has no concept of being out of date. If the person who maintained it left in February, the file looks exactly as authoritative in September as it did in January — same rows, same colours, same confident green cells.
The dangerous state is not an empty register. It is a register that is wrong and looks maintained.
A system that watches dates should be able to say when it last checked, and should surface a notification that failed rather than letting it die in a log. That is not a feature a spreadsheet is missing; it is a category of thing a file cannot do.
And the shared login
The last one is organisational rather than technical. Shared sheets tend to acquire a shared login, and a shared login destroys attribution. When an inspector asks who changed the calibration interval, the answer has to be a person. The file will tell you it was the account everybody uses.
None of this means you should migrate the day you read it. It means the moment to move is before the incident, and the signal is not the size of the sheet — it is the first time somebody asks a question about the past that the sheet cannot answer.