Finance software is the operating system of the firm, not a tool the firm uses

A finance system is usually bought the way a laptop is bought. Someone compares two products, picks the one with the better demonstration, and the decision is considered closed. Eighteen months later, that product holds the revenue history, the customer list, the bank feed, the approval trail, and the only complete version of what the business did last year. Nobody made a decision to put it there. It arrived by use.

At that point the question is no longer which product is better. It is what the business now depends on, whether those dependencies are owned, and how anyone would find out if one of them quietly stopped working.

A tool is chosen once, an operating system is depended on daily

The distinction matters because it changes who has to care about the software.

A tool can be replaced on a weekend. An operating system carries state — history, permissions, integrations, and the assumptions of every process built on top of it. Replacing it means migrating what it knows, not just what it does. That is why owners who describe their accounting package as "just the bookkeeping software" are usually describing something that would take a quarter to move and would lose fidelity in the process.

Two consequences follow. The first is that selection criteria should include exit: what the export contains, in what format, and whether the audit trail survives it. The second is that the system deserves the same governance as any other operational dependency — a named owner, a review date, and a documented recovery route. Neither of these is a large piece of work. Both are almost always skipped, because the software was categorised as a purchase rather than as infrastructure.

Three dependencies most owners have never named

Ask three questions of any finance system and the shape of the risk becomes visible.

Where is the source of truth? If revenue is recorded in an invoicing tool, settled in a bank portal, summarised in a spreadsheet, and reported from a ledger, then four systems hold a version of the same number. When they disagree, one of them has to win by declaration rather than by argument. Declaring it costs a sentence. Not declaring it costs a week every time a reconciliation goes wrong.

Who holds administrative access? Administrative rights are usually granted in the first month and never reviewed. The list tends to include a departed employee, an outsourced bookkeeper, an agency that built an integration once, and the owner's personal email address on an account that predates the company. Each of those is a route in, and each is a route the business cannot close without knowing it exists.

What is the audit trail, and does it survive an export? A finance system that records what changed, when, and by whom is producing evidence. One that only stores the current state is producing a snapshot. The difference is invisible during normal operation and decisive during a review — including the internal kind, when an owner wants to know who altered a posting after a period was closed.

The failure is always discovered late, and usually at the worst point in the calendar

Software failures in a small firm are rarely dramatic. There is no outage. What happens instead is that an integration silently stops syncing in February, and nobody notices until the numbers stop reconciling in the autumn. Or a bookkeeper leaves, and the handover covers the process but not the accounts, so the first renewal notice goes to an inbox nobody monitors.

The pattern is consistent: the failure is quiet, the discovery is late, and the discovery point is the close, the audit, or the filing — the moment the business needs the record most and has the least slack to rebuild it.

That timing is not bad luck. It is structural. A finance system is only truly interrogated when someone needs it to prove something. Every other day it is simply used, and use does not test whether the evidence behind the numbers is intact.

The control is equally structural. Something must check the system when nobody needs anything from it. A monthly reconciliation between the source of truth and one downstream system will find a broken sync in weeks rather than quarters. An access review each quarter will find the departed bookkeeper before the renewal does.

Five checks that establish ownership

None of the following requires technical expertise. All of them can be completed by the owner, and each produces a document rather than an impression.

1. Name the source of truth in writing. One system per category, stated plainly, with the rule for what happens when another system disagrees.
2. List every system that holds financial or customer data, with its legal account holder, its administrator, a backup administrator, and its renewal date.
3. Verify access before changing anything. Confirm that a second person can genuinely log in and perform an administrative action. An access list that has never been tested is a belief, not a control.
4. Check that the audit trail exists and exports. Ask for a record of who changed what in a closed period, and confirm it is included in a full export.
5. Set a review date and an owner for the list itself. Quarterly is sufficient. Without a date, the list is accurate for one week and historical thereafter.

Software is the layer where accounting discipline either becomes durable or evaporates. A clean process running on a system nobody owns is one departure away from being undocumented. The systems do not need to be sophisticated. They need to be named, owned, and legible to the person ultimately answerable for what they contain.