Anatomy of a Till: What Software Is Not Allowed to Get Wrong

A till looks simple. That is its biggest lie. It has to be faster than the queue, never lose a sale, respect tax law on every receipt, and keep working when everything else gives up.

At Softavera, I worked on the complete redesign of the till: sales journey, catalogue, settings, payments and audits. R&D built it. I carried the specifications, the design and the trade-offs. Here is what you really have to master to build this kind of product.

A till lives at the pace of a gesture

The person at the till repeats the same gestures hundreds of times a day, often without looking at the screen. Every extra click costs time, and an interface that requires thought is already a failure.

The session opens with a personal code, because every action has to be attached to someone, with their permissions. Next comes the sale mode, and it does more than change a label. It changes prices, permitted items and the rest of the journey. Moving from one mode to another has to recalculate everything without anybody thinking about it.

Composing an item follows the same logic. Each step has a minimum and maximum number of choices, and when the maximum is reached the till moves on by itself. The price updates live. Two identical items with the same composition merge automatically in the cart.

Taking payment is never a single payment

From a distance, taking payment means asking for an amount. In reality, one receipt can be paid by card, cash, vouchers, a credit note or a customer balance, all at once.

Each method has its rules. A card goes through a connected terminal or not, with clear feedback on success or failure. Cash opens the drawer. Vouchers are entered in one gesture, three vouchers at seven euros for example, and a surplus becomes a credit note, never change. Split payment has to allow one part to be cancelled without touching the others.

NF525, rule by rule

This is the invisible part, and the one that forgives nothing. NF525 certification exists to prevent VAT fraud, and it translates into very concrete product behaviour.

As soon as the first item is added to the cart, the till checks that the daily, monthly and annual closures have been done. If one is missing, the sale is blocked and the screen says which.

A sale is never deleted. A cancellation requires a reason, and a receipt that has been paid is corrected by a reverse entry, so that there is no gap in the sequence. Every action goes into a tamper-proof audit journal: who, when, what amount, what item, what reason.

VAT is the detail that separates serious software from the rest. On a global discount, it has to be allocated pro rata across each item and each rate. Rounding sometimes leaves an orphan cent, and a fixed rule has to decide which line it falls on. Even a reprint is regulated: the word "duplicate", a copy number and a mandatory reason.

Four gestures to walk through

The simplest way to understand a till is to follow what it does at each gesture.

The life of an order after payment

An order does not end with the receipt. You have to be able to find it, transfer it to another till without two people editing it at once, and correct it after payment within a precise framework. A credit note carries over the VAT allocation of the original receipt. In the evening, the Z report brings everything together, by payment method and by person.

The catalogue and settings control everything

A till is not set up screen by screen. It reads the same card as the kiosk: same items, same steps, same visibility rules by mode and channel. That is what lets a network change a price just once. I describe how this works in the anatomy of the kiosk.

The hardware nobody sees

A till talks to receipt and label printers, a drawer, a payment terminal and a barcode scanner. Each device has to be paired, and each can fail at any moment. The software has to say so clearly, and carry on when it can.

There is one deliberate limit, however. When the fiscal check on closures cannot be done, the sale stops. Here, carrying on at all costs would be the wrong decision.

What it taught me

Building a till teaches a discipline: everything must be provable, nothing may disappear silently, and every correction leaves a trace. That is exactly what I now require of an AI agent.

A corrected error is never erased. It is recorded, with its reason, after what happened.