Picture a bookkeeper in Riga, early in the morning, coffee going cold, trying to close out a month and unable to make it balance. Two receipts that should have been there were simply gone. Both were for nothing. Zero owed. The customer had used promotional credit that month, so her real balance genuinely was nothing, and our system, trying to be considerate, had decided not to bother her with a receipt for an empty amount. Lovely manners. Except her accounting software expects one receipt per active arrangement, every cycle, like clockwork. A missing receipt does not read as politeness. It reads as a gap. Her bookkeeper took one look and assumed we had quietly dropped the customer. Sorting it out took longer than the conversation that won her in the first place. We did this. It was our idea of being thoughtful, and it cost a customer her morning.
The obvious move with a receipt for nothing is to skip it. Why send someone a slip that says they owe you zero? Nearly every billing tool on earth skips it by default. Our first version did the same. It felt like good manners. Inside our own team it felt obviously right. The change that introduced the skip sailed through review in minutes, nodded along by people who all agreed it was tidy. Not one of us thought to ask a bookkeeper.
But a receipt for nothing is not the absence of anything. It is proof that a relationship is still alive. To a human it looks like junk mail. To a bookkeeper's software it is the slip that says, this arrangement is still running this month, here is your proof. Take the slip away and the software draws the only sensible conclusion: it must have ended. Our polite little optimization was deafeningly loud in the one ear that mattered. We had been tidying up the customer's inbox while quietly making a mess of the customer's books, which is a far worse place to leave a mess.
So we took the skip out. Now every cycle produces a receipt, whatever the amount, even nothing. And because we did not want the same machinery accidentally sending a slip twice if it stumbled and restarted partway through, we taught it to recognise work it had already done and never repeat itself. If it falls over after writing the receipt but before sending it, the next run simply picks up where it left off, no duplicate, no fuss. The funny part is that the version that prevents the bug is leaner than the nervous, second-guessing version it replaced. Less to it, and it does the right thing.
Here is the part worth carrying into your own business. Every tool you stitch into your operation has private opinions about what is boring and what is interesting. One thinks a zero receipt is boring. Another thinks a cancellation is fascinating. Your accountant thinks every period needs its row. Each tool's defaults are tuned to its own scoreboard, never to yours. Use them straight out of the box and you are silently agreeing that their idea of boring is also yours. It usually is not, and the gap is where the surprises live.
The cheap habit that pays off forever: when a system can either keep a record or quietly drop one, keep it. Storage costs nothing. Rebuilding a vanished record from memory and screenshots costs a morning. The same goes for receipts, for sign-in events, for the support note you almost did not write down, for the shift cancelled before it began. Skipping the boring case looks clean today. It looks like a detective puzzle in somebody else's audit later.
The second habit: when you change what a system does by default, walk the new behaviour past whoever actually lives at the receiving end of it. Not the person who built it. The bookkeeper. The dispatcher. The one who reads the output first thing in the morning with their coffee. They will tell you in half a minute what your own checks will never catch in days.