The driver handed the car back and collected nothing
A rental app told a driver nothing was owed at the kerb. Five thousand rupees was owed, then twenty. Forty-five thousand exposed across six bookings, and why.
Your driver meets a customer at the kerb, takes the car back, checks his phone, and the phone says nothing is owed. So he collects nothing and the customer leaves. Five thousand rupees was owed on that booking. On the next one it was twenty thousand.
Nobody in the office saw a problem, because the office screen showed the right figure. Only the driver’s screen was wrong, and the driver’s screen is the one that decides whether money changes hands. By the time it was noticed, six live bookings were carrying the same mistake and forty-five thousand rupees was exposed. Two of those handovers had already happened. That money is not a software fix; it is a phone call to a customer asking for a deposit after the fact.
This was the third time in three months that the same kind of mistake had appeared in this rental business’s system. It is worth telling all three, because the pattern is what an owner can look for in their own.
What was actually going on
A security deposit in this system has two parts: the amount, and a note saying whether it has been collected yet. When a booking is created the deposit is written down as agreed but not yet taken. That is correct — the customer has not paid it. The office’s settlement screen understood that. The driver’s “amount to collect” did not: it added up every deposit on the booking, including the ones marked not yet taken, and concluded the customer had already paid.
The number on the driver’s phone was a real number from a real record. It just meant something different from what the screen said it meant.
The first time the same shape appeared, it was the advance payment. Bookings come into this system from a larger rental platform, which reports an advance amount on every booking. The ledger read the amount and treated it as paid. But the platform sends that amount whether or not the customer has paid it — a separate marker says which. One booking made it obvious: total 13,216, advance 13,216, paid nothing, and the ledger reported the customer as fully settled. Fifty-six bookings were in that state when we looked.
The second time it was tax. The office can mark a charge type as taxable, and did, for extension charges. The entry screen read that setting and told the operator the customer would bear 18% GST. The part of the system that actually books the charge ignores that setting for rentals, because rental prices are tax-inclusive by design. Twenty-one charges worth 72,454 rupees went through with a promise of tax that was never applied. Only one booking lost money — because an operator had noticed the discrepancy months earlier and had been quietly typing tax-inclusive figures to compensate, without telling anyone.
What we changed
One question — how much has actually been received on this booking — is now answered in exactly one place, and every screen that needs the answer asks that place. The driver’s phone, the settlement page and the invoice cannot disagree, because none of them does its own arithmetic any more.
For the tax setting, the rule is now that a setting a screen cannot honour is refused rather than displayed. The master screen will not let a rental charge be marked taxable, so the entry form can no longer promise a tax the system will not charge.
What it did not fix
The two handovers that had already happened under the wrong figure could not be fixed by any deploy. Money not collected at the kerb had left the system and become a conversation. The fifty-six bookings carrying an unpaid advance were not corrected by hand; they put themselves right on the next sync from the platform, which was a deliberate choice and a safe one.
And the operator who had been compensating for the tax bug by hand was doing the right thing with the information they had. The system had given them a control that worked on one screen and was decorative on another, and nothing anywhere reported the contradiction.
The pattern, for anyone running a system like this
In all three cases a number sat next to a second piece of information that said whether the number counted — collected or not, paid or not, taxable or not — and one part of the system honoured the second piece while another part did not. The mistake is invisible on every screen, because the number that appears is real. It only becomes visible when somebody acts on it.
Three things follow, and they are the transferable part. An amount and the marker that says whether it happened are one fact, not two, and the moment the amount can be read on its own, somebody eventually will. Where two screens work out the same figure independently, they will disagree one day, and the less-watched screen — usually the one in the field — is the one that moves money. And a setting that some part of the system ignores is worse than no setting, because it teaches operators to work around the software rather than trust it.
The exercise that would have caught all three takes an afternoon: list every place an amount is stored, write down beside each the marker that says whether it is real, and check every screen that shows the amount honours the marker.
The ledger in question is the one behind Sazinga Rentals, where a deposit is read by the office on a settlement screen and by a driver standing at a kerb, and both now agree about what has actually been collected.