E-fiscalization and ESIR: what the software must satisfy

In conversations, fiscalization is often reduced to one question: "does our software do fiscalization". That is the wrong question, because fiscalization is not a feature a screen at the till either has or lacks. It is a service — the part of the system every sales channel calls the same way, regardless of whether the sale happens at a till in the shop, in a web store, or through a work order in a service department.

This text describes the architecture and the roles in the general e-fiscalization model, from a software point of view. It deliberately avoids specific numbers, deadlines and legal provisions — those change, and they are a matter of regulation, not software. For anything that needs certainty, the only authoritative source is the tax authority's published requirements and your accountant.

The roles in the model: ESIR, processor and tax authority

The model is easier to understand once you separate three roles. They are not three programs but three responsibilities, and it is worth keeping them distinct in your head even when a single system technically combines them.

For the software, the most important thing is to understand the boundary: the ESIR prepares and requests, the processor secures and returns, the tax authority sets the rules and receives. NG eFiscal is Konis Software's software ESIR — the part that assembles the invoice and talks to the processor. What exactly each role may and must do is prescribed by the tax authority, and that is the boundary at which software stops being the source of truth.

The invoice is fiscalized before it reaches the customer

The essence that shapes the whole checkout flow is simple: the invoice must be fiscalized before it is handed to the customer. That means at the moment the customer receives the document, the fiscal elements must already be on it. Fiscalization is not a step done later, in the evening, in a batch — it is inside the sale itself.

For the flow at the till that changes the order. Checkout does not end when the money is taken, but when the invoice is fiscalized and printed with all its elements. If the system takes the money first and then tries to fiscalize, and fiscalization fails, you are left with a charged sale and no valid invoice — the worst possible state. That is why the flow is designed so that handing the invoice to the customer is the last step, not the first.

Offline mode and the audit trail

The network will drop. Not as an exception you plan for once a year, but as a regular occurrence in the middle of the working day. The question is not whether, but what happens to the sale at that moment. A system that stops when the connection goes also stops the checkout — and the queue at the till does not wait for the internet to come back.

That is why offline mode is not a luxury. The sale must complete even when the processor is momentarily unreachable, on condition that everything is recorded properly and reconciled later once the connection returns. This carries a few obligations the software must meet:

• A durable record of every sale at the moment it happens, before any network communication, so that nothing depends solely on a successful connection.
• An audit trail that shows what happened and when — which sale was made offline and when it was later reconciled.
• Deferred submission that runs only once the connection returns, without manual intervention and without the risk that anything is left unrecorded.

Fiscalization behind a service, not in the POS screen

The most common design mistake is for fiscalization to live inside the screen at the till. It feels natural — the cashier presses a button, the invoice prints — but any logic built into a single screen becomes unreachable to everything else. The moment a company also gets a web store, a service module and field sales, fiscalization locked in the POS screen has to be rewritten for every channel.

The correct approach is for fiscalization to be a service behind the interface: one place that assembles the request, talks to the processor and returns the result, which every channel calls the same way. The till, NG Commerce and the service flow then share the same logic instead of three separate copies that drift apart. This is the same principle we discuss when we write about integration: the rule is written once, where it belongs.

Idempotency: never fiscalize the same sale twice

The same problem that plagues every integration returns here with higher stakes. The till sends a sale for fiscalization, the processor handles it, but the response is lost on the way back. The till does not know whether it succeeded. If it retries without protection, the same sale is fiscalized twice — and a duplicate fiscal invoice is an error that is hard and unpleasant to correct.

The solution is the same as in any serious integration: idempotency. Every sale carries a unique marker, so a repeated attempt with the same marker does not create a new invoice but returns the existing result. The retry then becomes harmless — and retries are precisely what inevitably follows when the network fails.

Corrections are not made by deletion. Returns, voids and corrective invoices exist precisely because a sale cannot simply be erased as if it never happened. The software must support them as separate, tracked actions tied to the original invoice, not as improvisation on top of it.

Integration with eCommerce and work orders

When fiscalization exists as a service, new channels plug in without reinvention. The web store calls the same service at checkout as the till does. A service flow — for example a work order in Fleet Stop, where labour and parts are billed on completion of the job — also calls the same service when it comes to charging.

The point is not the specific product but the pattern: a sale can originate in ten places, but fiscalization stays one. Every channel brings the line items and customer data, and the service turns them into a fiscalized invoice the same way. This avoids the worst scenario — ten different fiscalization implementations that behave slightly differently and fail each in its own way.

Testing without touching production

The last thing a team realises, usually after the first incident, is that fiscalization must not be tested on real data. Fiscalized turnover is official; once it exists, undoing it is not a matter of software. Testing must happen separately from production, so that no test invoice ever touches real fiscal data.

1. A separate environment in which the flows run without a single real fiscal record.
2. A clear boundary between test and real data, so a test cannot be sent to production by mistake.
3. Exercising the edge cases — a network drop mid-sale, a duplicate attempt, a return — before the system goes live.

Nothing in this text is legal advice, nor a claim that any product is approved or certified. We have described how software should be built to meet the requirements. For the requirements themselves — what is mandatory, by when and under what conditions — only the tax authority's published rules and your accountant are authoritative. If you would like to discuss how fiscalization sits in your sales flow, contact us or see the frequently asked questions.