The honest count was the one that looked wrong
A refunded cash sale left the drawer twice: once when the order stopped counting, once when the refund arrived. The manager who counted right read as over.
A cash-up screen has one job. It tells the person closing the till what the drawer ought to hold, they count what it does hold, and the difference is written down under their name. If the expected figure is wrong, the honest count is the one that gets flagged, and the member of staff who did nothing wrong is the one explaining a surplus or a shortage.
Ours was wrong, and it had been wrong in a way that only showed when somebody gave money back. Four cash sales of ten pounds, three of them refunded in cash. Forty pounds came in, thirty went out, the drawer holds ten. The screen asked the manager to expect minus twenty.
The same money left twice
A full refund does two things in our records. It writes a refund row, and it moves the order from paid to refunded. The list of cash taken selected paid orders only, so the refunded sale dropped out of what came in. The refund row then arrived in what went back. Thirty pounds of refunds were subtracted from a figure that had already lost the same thirty pounds. Nobody wrote a bug; two correct-looking filters disagreed about what a drawer is.
We checked the live venue read-only before changing anything. Its drawer carried twenty-six paid sales, one refunded and one voided, and the expected figure sat seventeen pounds fifty below the truth. Under our alert threshold, so nothing fired. An honest count would have read as an unexplained surplus and stayed that way.
A drawer records money moving
The fix is a single definition shared by the list and the total: an order took cash if cash was paid on it, whatever its status is now. The cash came in when it came in. The refund is its own outgoing movement, counted once, in its own column. An order voided before anybody paid has no cash on it and is excluded by that fact alone, not by its status.
The refunded sale now appears in the cash list, labelled refunded, because a refunded sale sitting unlabelled in a list of cash taken is the next version of this bug. And the test we added does not check that the list and the total agree. They agreed before, while both were wrong. It checks both against the one fact that does not move: what came in, less what went back.