Your records show who made a change and when. They almost never show what the change actually was, or what it replaced. Here is the difference between a log and an audit trail, and the three lines that turn one into the other.

Somebody changed a price. The system helpfully records that Sam changed it, at 9:14pm on Tuesday.

It does not record what the price was before.

⚠️ You now know who to ask and nothing else. If Sam remembers, you are fine. If Sam has left, the old price is gone and the only way to recover it is to find an old receipt.

The short version

Most systems log who and when, not what and from what
That is enough to assign responsibility and not enough to fix anything
The missing piece is almost always the previous value
An outcome with no method recorded cannot be checked, only believed
Three fields turn a log into something useful

The difference, stated plainly

A log says	An audit trail says
Sam edited this record	Sam changed price from 8,000 to 6,000
Changed at 21:14	Changed at 21:14, was 8,000 since March
46 invoices closed	These 46, by this method, approved by this person

⚠️ The left column is a list of events. The right column lets you undo one.

One: the three lines that matter

Whatever you are recording, these three turn it from a note into a record.

One   What it was before
Two   What it is now
Three Who decided, and when they decided

⚠️ Line one is the one everybody omits, and it is the only one that cannot be reconstructed later.

Why line three has two halves

Who actioned it   usually recorded automatically
Who decided it    almost never recorded

⇒ These are frequently different people, and when somebody asks questions months later it is the second that matters. "The manager approved it on the 14th" is a complete answer; "the system says I did it" is not.

⇒ On approvals that covered less than the eventual work: the approval that covered less than you did.

Two: the case where this bit us

A batch of old billing items was closed here recently — forty-six of them, a substantial total, across five accounts.

Recorded    how many, the total, which accounts, the date
Not recorded exactly what was run to do it

⚠️ The outcome can be read. It cannot be verified. Reproducing the check, or proving the right items were selected, is no longer possible from the record — only by going back to the source system and hoping it still shows the same thing.

⇒ The rule we took from it: anything touching money gets saved as a named file, not typed once and discarded. That applies to a spreadsheet filter or a query just as much as anything else.

Three: what a venue actually needs to keep

You do not need enterprise software. You need four categories covered.

Prices          what changed, from what, who approved
Guest records   what was edited, and the previous value
Money           what moved, why, on whose decision
Access          who was given or removed access, by whom

⚠️ The fourth is the one most venues have nothing at all for, and it is the one that matters when something goes missing.

The minimum viable version

A dated notebook. One line per change.
"14/3 - house fee 8,000 to 6,000 - agreed with [owner]"

⇒ Genuinely sufficient for a small venue, and better than most systems, because it captures the previous value and the decision — the two things software usually omits.

Four: the change nobody can find

The specific failure worth planning around.

Something is wrong today
It was right at some point
Nobody can say when it changed, or to what

⚠️ Without a previous value, fixing it means guessing. Somebody picks a number that seems right and now the record has two errors in it: the original change and the guess.

How to answer it properly

One   Find when it was last definitely correct
Two   Find what it was then
Three Restore that, and record the restoration as a change

⇒ Step three is skipped constantly. A correction is a change and needs the same three lines, otherwise the next person investigating sees a value that appeared from nowhere.

⇒ Related: the edit that said saved.

Five: logs that exist and are never read

Many systems do record more than you think. The problem shifts from recording to retrieval.

The log exists
Nobody knows how to open it
Nobody has ever opened it
⇒ functionally, there is no log

⚠️ Find out now, not during an incident. Ask your provider to show you, once, how to see the history of one record.

The test

Pick a record you changed recently.
Ask to see what it was before.
Time how long it takes.

⇒ If nobody can produce it in ten minutes on a calm afternoon, it will not be produced at all on the night you need it.

Six: the person who left

Records that depend on somebody's memory expire when they do.

"Sam would know why that price is like that"
Sam leaves
The price is now a mystery with a number attached

⚠️ Every undocumented decision has an expiry date, and it is the last day of somebody's notice period.

The leaving checklist

Before their last week: sit down and ask
"What do you know that isn't written down?"

⇒ It is a twenty-minute conversation and it is the highest-return twenty minutes in any handover. Write the answers where the records live, not in an email.

⇒ On notes that outlive the person who wrote them: the note that was true when you wrote it.

Seven: recording without blame

There is a cultural risk in all of this, and it is worth naming.

If the record is used to find fault, people stop recording
If people stop recording, nothing can be fixed

⚠️ The purpose is recovery, not attribution. Say so, repeatedly, and mean it — the first time a record is used to discipline somebody, the quality of every future record drops.

The framing that works

"We need to know what it was before, so we can put it back."

⇒ Nobody objects to that. "Who changed this" invites defensiveness; "what was it before" invites help.

Numbers worth keeping

One   Can you see the previous value of a price? Yes or no
Two   Can you see who was given system access, and when?
Three How long does it take to retrieve one record's history?
Four  How many current settings can nobody explain?

⚠️ Four is a good yearly question. Every unexplained setting is a decision whose reasoning has already expired.

The card for the office

────────────────────────
  Recording a change

  1. What was it before?
  2. What is it now?
  3. Who decided, and when?

  A correction is also a change.
  Record it the same way.
────────────────────────

Common objections

"The system logs everything"

⚠️ It logs who and when. Check whether it keeps the previous value — most do not, and that is the one you will want.

"We're too small for audit trails"

⇒ A notebook is an audit trail. The size question is about the tooling, not about whether the three lines are worth writing.

"It feels like we don't trust people"

⚠️ Frame it as recovery, not surveillance. "So we can put it back" is true and nobody argues with it.

"Nobody would ever need that history"

⇒ Until a price is wrong, a guest disputes a charge, or somebody leaves. All three are certainties over a few years.

"We'd remember"

⇒ You would remember the big ones. The one that matters will be a small change from eighteen months ago that nobody thought was significant.

What to do this week

One   Ask your provider to show you one record's change history.
Two   Time it. If it takes more than ten minutes, you have no history.
Three Start a dated notebook for price and access changes.
Four  For anything you run against money, save the file you used.
Five  Book twenty minutes with anybody who is leaving.

Summary

Logs record who and when; audit trails record what and from what
The previous value is the only part that cannot be reconstructed later
Who actioned and who decided are different people — record both
An outcome with no method saved can be believed but not checked
Undocumented decisions expire on somebody's last day
Frame records as recovery, never as blame

Knowing who did it does not help you undo it. The useful record is the one that says what the world looked like before.

Who Did It Is Not What They Did