An employee comes to you and says they worked eight hours of overtime last month and weren't paid for it.
You open the payroll sheet. It says they didn't. They say they did — they remember the evening, they remember who asked them to stay, they remember the supervisor agreeing.
Now what?
You are not in a data problem. You are in a memory contest, and the person who remembers more confidently is going to win it. That is an uncomfortable way to run a business, and it is the normal state of affairs in most companies I have worked in.
The instinct is to blame record-keeping. We should have written it down. But plenty of companies do write it down, in a spreadsheet, and still cannot settle the dispute. The problem is deeper than diligence.
State versus events
A spreadsheet stores state. It tells you what is true right now.
Ahmed — Casual leave remaining: 6
That is a fact. It is also, for the purpose of every argument you will ever have, useless.
Because the question is never “how many days does he have left?” The question is “he says he was approved for four days in March, who approved that, and what was the balance before?” And the spreadsheet cannot answer, because when those four days were deducted, the cell changed from 10 to 6 and the 10 stopped existing.
You did not record a decision. You overwrote a number.
An event record works the opposite way. It never overwrites. It adds:
Opening balance 10 days 1 January Approved: 4 days −4 days 12 March approved by [manager], ref REQ-4471
The balance is not stored anywhere. It is calculated — opening, plus what was earned, minus what was used. Every number the system shows you can be traced back to the decisions that produced it.
Same information. Completely different capability.
Why this matters more than it sounds
When I designed the HR system for Rafiq Jamil Textile Industries, my first version used balance fields. It was simpler and it seemed obviously right. Every employee record had a number for each leave type; approving a request decremented it.
It survived until the first disputed request. An employee's balance looked wrong, and there was no way to determine whether the system had made an error, someone had entered something incorrectly, or the employee was misremembering. The system could report the balance with total confidence and could not justify it at all.
I rebuilt it as a ledger. Every approval writes a row. The balance became a calculation over history rather than a stored figure.
That change did three things I did not fully anticipate:
Disputes became queries.“Show me every leave transaction for this employee since January” replaced “let's ask around.” The conversation stopped being about who remembered better.
Delegation became safe.When approval authority is a rule with a record rather than a habit in someone's head, other people can exercise it. Work stopped concentrating on whoever was trusted to remember correctly.
Audits became boring.For a business certified under international labour standards, “boring audit” is worth a great deal.
The general rule
Here is the test, and it applies far beyond HR:
Are the questions your business asks questions about the present, or about the past?
“How much stock do we have?” is a present question. A spreadsheet handles it.
“Why did stock go missing between Tuesday and Thursday, and who signed for the outbound shipment?” is a past question. A spreadsheet cannot handle it, and no amount of discipline in filling in the spreadsheet will fix that, because the tool does not retain what it needs to retain.
Most businesses discover this the same way I did — not during planning, but during the first argument they cannot resolve. By then the history that would have settled it was never recorded.
What to do about it
You do not need to build software to apply this. Three things help immediately:
Record decisions, not just outcomes. When an approval happens, capture who approved it, when, and what the state was beforehand. Even in a spreadsheet — a second tab that only ever gets appended to, never edited, is dramatically better than one that gets overwritten.
Never edit a row that represents something that happened. If a mistake was made, add a correcting entry. The wrong entry and its correction together are the truth. Silently fixing the original destroys the only evidence that anything went wrong.
Notice which arguments keep recurring. The disputes you have repeatedly are telling you exactly which events you are failing to record. That list is your requirements document.
The uncomfortable version of all this: if your business cannot reconstruct how a decision was made, you do not have a process. You have a set of habits that usually work — and no way of knowing when they stop.