Per-device revenue reconciliation: catching shortfalls

Three numbers per device

For every bay, vacuum station or machine there are three independent sources of truth each day. First, what the controller recorded: how many starts, for what amount, paid how. Second, what the money channel confirmed: the acquirer for cards, the bank for QR, the counted notes and coins for cash. Third, what went into fiscal records: how many receipts and for what amount.

While the three numbers agree, the system is healthy. When they diverge, the difference itself tells you where to look. More starts than payments: the equipment is giving away the service. More payments than starts: customers pay and get nothing, and the complaints are already on their way. Fewer receipts than payments: a fiscal problem that will eventually become a fine.

Why a daily total shows nothing

A terminal or a bank reports one figure per site, or even per network. Ten devices are blended into it, and a bay that has been running unpaid for three days hides behind the other nine. The owner sees revenue “slightly down”, blames the weather, and never learns the cause.

Device-level reconciliation unpicks that figure. It becomes visible that on an eight-bay wash, bay seven brought in a third less than its neighbours at the same traffic, or that the bill acceptor on machine two counts less than it holds. This is not analytics for its own sake; it is a way to find a specific unit and a specific date.

Cash: the biggest hole and how to close it

Cards and QR reconcile automatically because every transaction has a bank record. Cash does not: between the bill acceptor and the owner’s till stands a person who empties the box. So cash accounting has to start inside the acceptor: the controller counts every note and coin and sends the total to the server before the cassette is opened.

Collection then becomes a check, not the source of data: the person brings a sum, and the system already knows what it should be. A difference within the acceptor’s error margin is normal; a systematic difference on the same machine is a reason to look at the person or at the acceptor. In the car-wash network we built the payment layer for, this per-shift reconciliation closes more than a dozen bays every day, and it, not the camera, is what shows a problem first.

Fault or abuse: how to tell

A fault is random. It is scattered in time, touches different devices, disappears after a restart or a repair, and leaves a technical trace in the logs: a dropped link, an acceptor error, a controller reboot.

Abuse repeats. It is tied to one device, to particular hours or shifts, and in the data it looks like a stable gap between starts and payments, or like a “breakdown” that only happens when a particular person is around. The system does not make the diagnosis; it shows the repetition. The owner then looks at the shift schedule and draws the conclusion.

Making reconciliation a daily habit

It has to arrive on its own. Every morning, a short summary per site: three numbers per device, discrepancies highlighted, nothing else. If reconciliation requires “logging in to have a look”, nobody will look after two weeks.

Thresholds must be specific to each device type: a bill acceptor has an acceptable error, a cashless bay has none. And every discrepancy needs a status: seen, explained, closed. A month later you can see not just “how much” but “what was done about it”.

Frequently asked