Fiscalization for unattended machines

What the requirement means

Several markets require an unattended machine to register each sale with a fiscal service and make a receipt available to the customer. Rules differ by country and change, so treat the specific obligation as something to confirm with your own tax advisor — what does not differ is the engineering consequence.

That consequence is this: something in the machine has to know the amount and the moment of every sale, and has to be able to reach a network. A payment reader alone does not qualify, because it never sees the cash.

Cash is the hard half

Cashless payment is straightforward to fiscalize: the reader already handles the amount, so the receipt can be raised from the same event. Cash is harder. Notes and coins are taken by devices that report to the machine controller, not to the payment terminal, so a fiscalization module has to sit where it can see the bill validator and coin changer too.

This is why the fiscal module belongs on the controller side of the loom rather than on the payment terminal: FisLight is wired between the controller and the serial periphery, where both the terminal and the cash devices report.

Cloud receipt services

Our boards register sales through cloud fiscal receipt services rather than a printer inside the machine — there is no paper to run out and no printer to jam on an unattended site. The integrations currently in production are with Checkbox and Vchasno.Kasa. Support for a fiscal service used in your market is a scoping question: ask us and we will tell you what is involved.

Where integrations fail

• The receipt is raised before the product is dispensed, so failed vends still get fiscalized.
• Only cashless payment is covered, and cash sales quietly go unrecorded.
• The machine loses connectivity and has no queue, so receipts are lost rather than sent late.
• Tariffs are changed in the back office but the fiscal side keeps the old price.