Fiscal receipts from a terminal with no cashier

With a person behind the till, fiscalisation is simple: there is a register, there is a cashier, the receipt prints. When the payment is taken by a box standing outdoors at three in the morning, and the receipt still has to reach the tax authority at the moment of payment, the problem is different. Here is how it works and where it fails most quietly.

Why this is not an ordinary till

Off-the-shelf software fiscalisation services are built around a person with a phone or tablet: the cashier rings it up, the receipt goes out. They do that job well, and for a shop or a café it is enough.

A self-service terminal, a vending machine or a wash bay differ in three ways. First, there is nobody to repeat the operation if something did not go through. Second, payment and delivery are separated in time: the money is taken now, the wash runs for another six minutes. Third, the device may be offline — and that is a normal, expected state, not an emergency.

That is why fiscalisation in such a system cannot be bolted on from the side. It has to live in the same flow as taking the money.

An order that must not be rearranged

Money taken and counted → receipt issued and sent → equipment starts. In that order. The temptation to start the bay immediately and send the receipt “afterwards” looks sensible: the customer waits two seconds less. But the moment the afterwards breaks, the system quietly sells without receipts, and from outside everything looks healthy.

If the delay genuinely hurts the customer experience, the right answer is not “start first” but to make sending asynchronous with a guarantee: the transaction is written locally, a queue exists, and any send that failed stays in the queue until it succeeds. The difference is that a lost receipt becomes visible — not that it never gets lost.

What happens when the link drops

A dropped line is not an exception, it is a normal mode. At a car wash it happens weekly. So the terminal has to work without the network: take cash, start bays, write transactions to local storage.

The question to answer at design time: what exactly happens to those transactions when connectivity returns. Do they reach the tax authority with the actual payment time or the send time? Is there a limit past which the backlog can no longer be filed retroactively? Who sees that the queue is growing?

A working system has a screen for precisely this: how many transactions are waiting, and how old the oldest one is. Without that screen, you learn about the problem from an inspection report.

Two logs, not one

The most common mistake is keeping a single “payments” log and assuming fiscalisation is in there too. There should be two: what was taken and what was fiscalised. The difference between them is the number anyone sorting out a mess will look at first.

While that difference is zero, the system is healthy. The moment it is non-zero and does not return to zero, something is broken — and it is better to learn that from your own dashboard than from a letter.

The same goes for the breakdown by channel. Cash, coins, card, QR — each counted separately. A single tidy total looks fine right up until you need to find where the discrepancy came from.

What to ask a fiscalisation provider

Whether there is an API, not only a cashier app. Whether a receipt can be issued on behalf of a device rather than a person. What comes back in the response, and whether that identifier can later be used to find the specific receipt. Whether there is a sandbox — filing real receipts while debugging is not an option.

And separately: what the limits are on filing retroactively. That determines how many hours offline the system survives without consequences, and therefore how reliable the connection at the site has to be.

Frequently asked

Does a terminal need a separate hardware fiscal register

Not necessarily. Software fiscalisation covers most self-service scenarios; a hardware register is needed where there are specific requirements to print a paper receipt on the spot. The choice depends on whether the customer must receive a slip in hand or an electronic receipt by link or email is enough.

The customer pays by QR from a phone — where does the receipt go

The most convenient route is an electronic receipt by link immediately after payment, in the same window where they paid. It is faster than printing and removes the problem of an empty paper roll in the middle of the night. Paper stays available as an option if your scenario calls for it.

What does it cost to add fiscalisation to an existing terminal

It depends on what is already there: whether the fiscalisation provider has an API, whether your terminal exposes payment data, whether there is local storage for offline mode. The most expensive case is a closed terminal with no external interface at all; the cheapest is when both sides have an API and the work is connecting them and adding a queue.