Compliance

Bon fiscal digital — 2026 readiness

ANAF's mandatory QR code on every fiscal receipt becomes enforceable on 1 November 2026. What we know about the JSON payload spec, what's still pending, and e-bon's stance.

Understand what this page covers

A briefing on the bon fiscal digital — the QR code that Romanian fiscal legislation will require on every receipt printed by an AMEF (aparat de marcat electronic fiscal) starting 1 November 2026.

Audience. Romanian merchants, POS integrators (Magister, SmartCash, BistroPOS, etc.), and partners who need to decide whether to act before the 2026-11-01 deadline.

Not covered. How to integrate the QR encoder into your printer firmware (no e-bon implementation exists yet), and generic QR-code placement rules outside Romania.

Review the legal base

OUG 69/2024 — primary in-force legislation. Amends OUG 28/1999 to require a QR code on every fiscal receipt issued by an AMEF.
Hotărâre de Guvern (HG) — draft 17 aprilie 2026 — the implementing regulation. Confirms the JSON, single-hierarchical-level payload format and the bottom-of-receipt placement. Currently in public consultation.
Pending Ordin al Președintelui ANAF — the technical-detail order that will fix the full key list, signing rules, and any optional fields. Not yet published as of 27 April 2026.

The canonical structural specification used by this page is SpecificatiiQR.docx, published on chat.anaf.ro alongside the HG draft.

Track the deadline timeline

2026-11-01 — mandatory enforcement. Every fiscal receipt issued by an AMEF must carry a compliant QR code from this date.
SICE (Inspecția Economică) fines were active from 1 September 2026 and were then suspended until the 2026-11-01 deadline (clarification widely cited in the legal press).
Today: 27 April 2026 — approximately 6 months of runway remain before enforcement.

Understand the QR payload

The HG draft and the accompanying SpecificatiiQR.docx define the QR payload as JSON, single hierarchical level, formed strictly of pereche cheie-valoare (key-value) entries — no nested objects, no arrays.

Three keys are confirmed mandatory for every receipt:

t — Data și ora emiterii (the moment the transaction is finalised). ISO 8601, format YYYY-MM-DDThh:mm:ss.
sf — Seria fiscală a aparatului. The 10-character alphanumeric unique identifier of the AMEF.
idB — Identificatorul de bon. A fixed-length 32-character string built by sequential concatenation, without separators, of:
- sf — Seria fiscală (10 chars)
- Date and time as AAAALLZZHHMMSS (14 chars)
- Number of the daily fiscal closing report Z (4 chars, zero-padded left)
- Sequential receipt number within the working day (4 chars, zero-padded left)

Verbatim example from the ANAF specification:

{ "t": "2026-01-30T10:15:30", "idB": "11123456782026013010153000450024", "sf": "AD12345678" }

Earlier draft recommendations differed. A widely circulated recommendation referred to keys named data, numar_unic_id, and cif_beneficiar. The canonical ANAF specification (SpecificatiiQR.docx) confirms a different, simpler key set: t, sf, idB. The cif_beneficiar (customer-CIF-on-request) field may yet appear in the pending Ordin al Președintelui ANAF; this page will be updated when that order lands.

Place the QR at the bottom of the receipt

The HG draft mandates the QR code at the bottom of the receipt, after all transactional lines and totals. This is a hard placement rule — top-of-receipt or side placements are non-compliant.

See what's still pending

The full key list and signing rules await the Ordin al Președintelui ANAF. Until that order is published, the spec is incomplete: optional keys, hashing/signing semantics, and any merchant-side cryptographic obligations are not yet fixed.A QR-encoder library / SDK helper from e-bon is blocked until then. Building one against the current partial spec would risk shipping the wrong key list and forcing a breaking change later.

Read e-bon's stance

e-bon is tracking the specification and the pending Ordin al Președintelui ANAF. When the order lands, we will ship a QR encoder, an SDK helper, and a Portal preview before the 2026-11-01 deadline.Honesty: e-bon does not ship a QR encoder today. No customer action is required during the transition window; once we ship, integration guidance will be published here and cross-linked from /en/api/receipts.

Suppress printing for card-only and vending receipts

Receipt printing for card-only and vending transactions became optional under OUG 138/2024 (in force since December 2024) and is re-affirmed by the 2026-04-17 HG draft. Merchants may suppress paper printing for these flows provided the underlying fiscal receipt is still emitted by the AMEF and reported to ANAF. The QR-on-receipt obligation applies only when a receipt is actually printed.

For the related obligation when a device sits idle for an entire calendar month, see F4109 — ANAF inactivity declaration.

Retain documents for 5 years

Z reports, fiscal-memory printouts, and the registru special were previously retained for 10 years. The 2026-04-17 HG draft reduces this to 5 years. The reduction does not affect the underlying obligation to keep the records intact, signed, and retrievable on ANAF request — only the duration shortens.

F4109 — ANAF inactivity declaration — neighbouring compliance topic for unused AMEF.
Receipts API — the API surface that will eventually carry the QR payload.
Troubleshooting · ANAF rejection — existing trouble page for reporting failures.
Architecture · Receipt emission — cloud-side receipt flow that will eventually emit the QR.

Consult the legal sources

OUG 69/2024 — amendment to OUG 28/1999 introducing the QR-on-receipt requirement.
HG draft, 17 aprilie 2026 — implementing regulation in public consultation.
SpecificatiiQR.docx — canonical structural specification published on chat.anaf.ro.

Edit this page

Terms & Conditions

Terms and conditions for using the E-BON platform operated by Crisposoft SRL — acceptance, service description, user obligations, billing, liability, termination and governing law.