Nobody has ever approved their own count, and the schema is why.
Counting the money and signing off the count are two jobs, and the system will not let one person do both. What that separation caught, and what it has not caught yet.
- Client
- A cash drawer that closes twice
- Practice
- ERP Systems
- Published
- 26 August 2026
At closing time somebody counts the drawer and writes the number down.
They already know what it should be. The figure is on the screen in front of them, and it is a long day, and the difference between what is in the till and what the screen says is a hundred rupees they cannot explain and do not want to argue about. So the number that gets written down is the number on the screen.
Nothing about that requires a dishonest person. It is the path of least resistance for a tired one, and it destroys the only thing a daily count is for. A count that is copied from the expectation cannot disagree with the expectation, so it can never tell anyone that something has gone wrong. The business now has a ritual where it thought it had a control.
The usual answer is a rule: staff must count first, then check. A rule is a sentence in somebody’s head at eleven at night. It has no way to be true.
- 01A count taken while the expected figure is visible tends to become that figure
- 02One person doing both jobs means the second job checks nothing at all
- 03The evidence a dispute needs is a name and a time, not a remembered conversation
Two jobs, two people, and the database keeps them apart.
Closing the drawer and approving the close are separate records written by separate people, and they are separate in the schema rather than in the training. The close carries who counted. The approval carries who signed. They are different rows, written at different times, by accounts with different reach.
Sign-off runs at two levels, and the numbers show it plainly: of the hundred and fifty-nine sign-offs recorded, eighty-five came from the audit level and seventy-two from the administrative one, with two closes flagged rather than passed. Sixty-seven of the closes have been through both.
Ten people have counted a drawer. Three people have approved one. Those two groups do not overlap on any single close, and no memo is holding that in place.
Across all one hundred and fifty-nine sign-offs, in seventeen distinct pairings of an approver with a counter, the number of times the approver was the counter is zero. That is worth stating carefully, because it is not a compliment to anybody’s diligence. It is a shape. The people involved were never in a position to do it, so no month ever comes where somebody is short-staffed and does it just this once.
Days when the drawer is not counted are recorded too, rather than being absences. Six days were skipped in this window and every one of the six carries a written reason. A gap with a sentence attached is a fact; a gap with nothing attached is a question nobody can answer three weeks later.
Eleven days did not balance, and thirty-eight are still waiting.
One hundred and forty closes have been counted over thirty days. Eleven of them did not balance against what the system expected. Those eleven are the entire point of the exercise: they exist because somebody counted the drawer rather than copying the screen, and every one of them is a real disagreement between the money and the record, attached to a date and a name. On the digital side the count and the record agreed every single time.
The number that matters more, and the reason this page is not simply a good-news page: thirty-eight of those closes still carry no sign-off at all, and twenty-eight of the thirty-eight have been waiting more than a week. Ninety have been approved. Twelve more closes were re-counted and superseded, which is a normal correction and not a gap.
Nobody has ever approved their own count. A third of the counts have not been approved by anybody. Both of those come out of the same query, and publishing only the first one would be a sales page.
Those two facts are different in kind, and the difference is the useful thing an owner can take away. The zero is structural: it holds because the system cannot express the alternative, so it will still hold next year when everyone involved has changed. The backlog is behavioural: it is a queue that people work through, it grows when they are busy, and no schema will fix it. Separation of duties is a design problem and it is solved. Review latency is an operations problem and it is open.
What that buys the owner is narrow and real. On any day in the window he can see what was counted, by whom, whether a second person agreed, and which eleven days need a conversation. What it does not buy him is the assurance that somebody has actually looked at all of them yet, and the system is honest with him about which of those two he has.
- Next.js
- TypeScript
- Supabase