What a system of record cannot do

"System of record" is the right way to describe an ERP, and it's also a phrase that sets people up to expect more than the system can deliver. A record is a statement of fact — this happened, at this time, for this amount. It is not, and was never designed to be, an account of judgement.

The phrase does real work, and hides a limit

Calling something a system of record tells you it's authoritative about facts. When there's a dispute about what a transaction was, the system of record wins. That's valuable and worth protecting — a business without a reliable single source of truth for its transactions is in genuine trouble.

The limit is that "record" only covers what can be reduced to structured fields: amounts, dates, parties, statuses. It has no field for "and here is why we did it this way," because that field would need to hold judgement, negotiation, and context — the kind of information that resists being reduced to a dropdown.

Three things a system of record cannot do, by design

It cannot tell you if a decision was still the right one. It can tell you a discount was applied. It cannot tell you whether the circumstances that justified the discount still apply, because it never recorded the circumstances in the first place.

It cannot transfer judgement between people. A system can transfer access — a login, a permission level, a dashboard. It cannot transfer the accumulated sense of "this customer is usually right when they push back" that a departing account manager carries and a replacement has to rebuild from scratch.

It cannot flag when its own data is stale. A supplier record might show terms set two years ago for reasons that no longer hold. Nothing about the record itself indicates it needs revisiting, because the system has no concept of "this was true given circumstances that have since changed."

Why this isn't a criticism of the software

Every one of these limits exists because the alternative — trying to make an ERP capture judgement as structured data — doesn't actually work. Judgement resists structure. The moment you try to force it into fields, you either lose the nuance that made it judgement in the first place, or you build a system so flexible it stops being useful as a system of record at all.

The honest position is that a system of record and a system that captures reasoning are different tools solving different problems, and expecting one to do both jobs is where the disappointment comes from — not from either job being done badly.

What fills the gap, realistically

Not a second piece of software bolted onto the first. A deliberate, lightweight practice that runs alongside the system of record rather than trying to become one.

A short written note at the point of judgement. Not a policy document — a sentence, attached to the record it explains, written by whoever made the call, at the moment they made it.

A standing habit of re-checking old exceptions. Since the system can't flag staleness on its own, someone has to. A quarterly look at active exceptions — is this still the right call, given what's changed — catches what the record can't.

Explicit handover, not just access transfer. When someone leaves a role, giving their replacement the login is the easy part. The harder, more valuable part is walking through the exceptions and judgement calls currently live under their name — see onboarding a new staff member.

The realistic scope of the fix

This isn't a project to document everything the business has ever decided. Most transactions don't carry enough judgement to be worth capturing — they're routine, and routine is exactly what a system of record handles well. The scope is the minority that involved a real judgement call: exceptions, negotiated terms, write-offs, anything a reasonable person could have decided differently. That's a manageable list, and it's the only part of the gap actually worth closing.

Common questions

Why can't an ERP capture the reasoning behind a decision?

Because reasoning is contextual judgement, not structured data. An ERP is built to record facts reliably — amounts, dates, parties — and trying to force judgement into that same structure either strips out the nuance that made it judgement, or breaks the system's usefulness as a reliable record of fact.

Is this a flaw in the software?

No. It reflects what a system of record is actually good at, and expecting it to also capture reasoning sets an expectation neither the software nor any alternative software is realistically going to meet. The fix is a separate, lightweight human habit, not better software design.

What kind of decisions actually need this captured?

Not routine transactions — those are exactly what a system of record handles well. The minority worth capturing are judgement calls: exceptions, negotiated terms, write-offs, anything a reasonable person in the same position could plausibly have decided differently.

How do you stop old exceptions from going stale unnoticed?

Since the system has no way to flag that circumstances behind an old decision have changed, someone has to check deliberately. A periodic review of currently active exceptions — asking whether each one is still justified — catches what the record itself cannot.

Related: what your ERP does not record · onboarding a new staff member · transactions are not decisions