Bulgaria's 2026 fiscalization update: a practical guide for POS vendors

The National Revenue Agency's updated fiscalization ordinance took effect in January and introduces two structural changes that POS and fuel automation vendors will feel across the year. The first is a near real time transmission requirement for transactions above a threshold; the second is a tightened spec for the fiscal device ↔ POS protocol, which retires several legacy variants.

What actually changed

Three items account for most of the engineering work. One: the device sends a signed package per transaction to a NAP endpoint within five minutes of close, not at end of day. Two: receipt QR codes now encode a verification URL that customers can hit to confirm the transaction was reported, which shifts customer service expectations onto the merchant. Three: firmware signatures on fiscal devices must be verifiable by the operator on demand, which in practice means keeping a signed manifest alongside the deployed firmware.

Where teams are getting stuck

We have reviewed a dozen vendor implementations in the last quarter. The common pitfalls are all in the same neighbourhood: clock drift on the fiscal device causing signature mismatches; the "five minutes" clock starting at close rather than at queue time, which penalises high volume sites with intermittent connectivity; and retry policies that double submit on 5xx responses from the NAP endpoint, creating duplicates that the operator has to reconcile manually.

A practical checklist

Before you ship to a customer: confirm NTP on the device with a known good stratum 2 source, not the router. Treat the transmission queue as durable sqlite with WAL mode on local storage is enough. Use idempotency keys on every submission; the NAP accepts them and rejecting duplicates is your friend. And verify the QR code URL works from a phone on a non merchant network before declaring a site live.

What this means for fuel retailers

Forecourts with poor cellular coverage are disproportionately affected, because the five minute window is tight when an LTE modem has to retry. We recommend a local fiscal cache that survives power loss and a separate quality of service class for fiscal traffic on the site router the same pattern we use for payment authorisation.