Transactions are not decisions

A journal entry is a transaction. The choice to write off that debt, rather than chase it another quarter, was a decision. The system captures the first perfectly and has no representation of the second at all — and because the transaction is right there, it's easy to mistake it for a record of the decision behind it.

The confusion is understandable

A transaction looks like it explains itself. A discount was applied: 15%, to this customer, on this date. That looks like a complete fact. What it hides is everything that made 15% the right number rather than 10% or 20% — a negotiation, a competitor's offer, a relationship worth protecting, a mistake someone is quietly correcting.

None of that is in the transaction. The transaction is the output of a decision, not a description of it, in the same way a receipt is the output of a purchase and not an account of why you bought the thing.

Why this matters more than it sounds

If you treat the transaction as if it were the decision, you lose the ability to evaluate the decision on its own terms. Was 15% the right call? You can't tell from the transaction alone — you need the context that produced it, and that context is exactly what doesn't get recorded.

This is most damaging with exceptions, because exceptions are precisely the transactions most likely to need re-evaluating later. A standard process rarely needs its reasoning questioned — it's standard because it's been agreed and repeated. An exception is, by definition, a one-off judgement call, and one-off judgement calls are the ones most worth being able to reconstruct.

Where it shows up operationally

Pricing exceptions accumulate silently. Each one made sense on its own. Reviewed together, a year later, without the reasoning attached, they look inconsistent or worse — arbitrary — even if every single one was defensible at the time.

Write-offs get treated as routine once there are enough of them. The transaction for writing off a debt looks identical whether it followed six months of collection effort or five minutes of convenience. Only the decision distinguishes the two, and the decision isn't in the ledger.

Approvals get rubber-stamped because the transaction, not the reasoning, is what gets reviewed. An approval workflow confirms someone signed off. It doesn't confirm they engaged with why the request existed in the first place — see approval workflows people actually follow.

What separates the two in practice

The test is simple: could someone who wasn't in the room reconstruct why this happened, using only what's in the system? If the answer is yes, the decision is effectively recorded. If the answer is "only if you ask the person who did it," the system holds the transaction and nothing else.

Most businesses, tested against every exception currently live in their operations, would fail this test for the majority of them — not because anyone did anything wrong, but because nothing forced the distinction to be made.

Closing the gap

Treat exceptions differently from standard transactions. A standard transaction doesn't need its reasoning captured every time — that would be pure overhead. An exception does, precisely because it's the case a standard process didn't anticipate.

Attach the decision to the transaction it produced, not to a separate log that drifts out of sync. The closer the reasoning sits to the record it explains, the more likely it survives.

Ask "why" before approving, not after reviewing. An approval step that requires a reason at the point of approval captures it while it's cheap. Reconstructing it after the fact, during an audit or a review, is where the real cost shows up.

Common questions

What's the difference between a transaction and a decision?

A transaction is the recorded output — an amount, a date, a party. A decision is the judgement that produced it — why this amount, why this exception, why now. Systems capture transactions completely and decisions not at all, because decisions are contextual reasoning rather than structured data.

Why does this matter most for exceptions rather than standard transactions?

Standard transactions follow an agreed process that rarely needs re-justifying. Exceptions are one-off judgement calls by definition, which makes them exactly the transactions most likely to need re-evaluating later — and exactly the ones whose reasoning is least likely to be written down anywhere.

How do you test whether a decision is actually recorded?

Ask whether someone who wasn't involved could reconstruct why it happened using only what exists in the system. If the honest answer is "only by asking the person who did it," the decision lives in that person's memory, not in any record.

What's the most practical fix?

Require a short written reason at the point an exception is approved, rather than trying to document every transaction. This captures the reasoning while it's fresh and cheap, and concentrates the effort on the transactions most likely to need explaining again later.

Related: approval workflows people actually follow · what your ERP does not record · segregation of duties when software posts