Devices

Fiscal operations

Plain-language guide to fiscal receipts, X and Z reports, ANAF artifacts, cash operations and storno reversals — and where each one lives in e-bon.

Fiscal operations

This page is the business-owner's map of every fiscal operation an AMEF (casa de marcat) carries out for you, and where each one lives in e-bon. It is the what and the why — for the how (the buttons in the Portal), each section links into the Portal walkthroughs you already know.

If you are an integrator looking for endpoint signatures, jump to the API reference instead — the same operations are exposed there too.

e-bon does not replace the AMEF. The fiscal printer remains the legal source of truth: it holds the fiscal memory, prints the paper receipts and signs the journal that ANAF expects. e-bon is the remote control and the audit shelf around it.

Fiscal operations overview — a tablet middleware device connected via emerald and blue lines to a fiscal printer with a paper receipt and an open cash drawer, with X, Z and ANAF document icons floating above and a cloud silhouette linked through the tablet, illustrating the cloud → middleware → printer chain

Receipts (Bonuri)

A bon fiscal is a fiscal receipt — a paper document printed by the AMEF and committed to its fiscal memory. Once printed, you cannot edit it; the only way to undo it is a storno (see below). Three flavours exist in e-bon, and they map to three different legal situations:

Bon fiscal (Sale) — a normal sale. Each line carries a name, a quantity, a unit price, a VAT rate and an optional discount. Payment is split across one or more methods (Numerar, Card, Voucher). The AMEF assigns a fiscal serial (the Unique Sale Number, USN) and increments the day's counters.
Bon nefiscal (non-fiscal) — a slip with free text used for things that are not a sale (a quote, an internal note, a header on top of a fiscal receipt). It does not touch the fiscal memory and ANAF will never see it.
Storno (reversal) — a fiscal document that cancels a previously issued sale. It prints on the AMEF, references the original receipt's coordinates, and shows up to ANAF as a negative entry against the original. Storno is described in Voids and reversals (Storno) below.

VAT is applied per line at the rate set on the AMEF (Romanian fiscal law currently uses 21%, 11%, 9% and 0% rates; the e-bon Portal does not enforce a list — it accepts whatever rate the device supports). The receipt detail view in the Portal shows the VAT breakdown by rate, the per-method payments and the line-level subtotal with discounts already applied.

The full Portal walkthrough for the receipts list, filters, the manual issue flow and the storno modal lives at Receipts. The integrator-facing endpoints (GET /api/v1/receipts, POST /api/v1/receipts, POST /api/v1/devices/{deviceId}/reversal) are documented in the Receipts API reference.

X and Z reports

Two reports run on every fiscal day, and they do very different things.

X report (Raport X) is a read-only intra-day snapshot. Running an X does not touch the fiscal memory and does not move any counters; it just prints the totals so far on this fiscal day. You can run as many X reports per day as you like — typical use is a hand-over between operators or a mid-shift reconciliation.

Z report (Raport Z) is the end-of-day fiscal close. Running a Z increments the device's reset counter, locks the day's totals into fiscal memory and starts a new fiscal day on the AMEF. Exactly one Z is required for each fiscal day on which the AMEF was used, and the Z is the document an inspector or your accountant will ask for.

This will close the fiscal day. This action cannot be undone. Are you sure? — that is the literal warning the Portal shows before sending a Z. Triggering a Z mid-day will close the day on that AMEF and start a new one. Do not run a Z unless you actually want to close the fiscal day.

You can trigger an X or a Z remotely from the Portal — there is no need to walk to the cash register. Both live on the Reports page's Actions tab (Print X report and Run Z report, the latter behind a confirmation dialog) — see Reports — Actions. The result prints on the device's paper — no rows appear in any tab; past closures are read back live from fiscal memory on the Z History tab.

Romanian fiscal law requires one Z per fiscal day on which the device was used; the cadence and the consequences of a missed Z are defined by ANAF. e-bon raises a missing Z alert when a device that took sales has not closed the day — see Notifications. For the legal text and any updates, consult the official ANAF reference at https://www.anaf.ro.

ANAF reporting (MF, JE, P7B)

Three artifacts exist on each AMEF on top of receipts and Z reports. All three live on the device — e-bon reads and exports them live so they are auditable from the Portal and queryable through the API.

MF — Memorie Fiscală. The device's tamper-protected fiscal memory, where every Z closing is written. It is the Z-history record: the Portal and the API read its rows live for any date or Z-number range.
JE — Jurnal Electronic. The per-operation electronic journal the device records for each fiscal day, listing every receipt and report. The JE is what ANAF actually reads.
P7B. The PKCS#7 digital signature the AMEF applies to its monthly ANAF archive with its own fiscal certificate. The signature proves the archive came from a specific certified AMEF and was not altered — ANAF verifies it on submission.

The data flow is: the AMEF maintains the MF and JE and assembles the signed monthly ANAF archive (a ZIP with the ANAF-format XML, .p7b and JE artefacts); e-bon exports that archive live from the device; you download the ZIP and submit it in SPV. e-bon stores none of it and tracks no submission status — SPV is the system of record.

To read or export the artifacts:

From the Portal — use the Z History, Journal and ANAF Export tabs on Reports. Z History and Journal read the MF and JE live; ANAF Export downloads the signed archive ZIP.
From the API — GET /api/v1/devices/{deviceId}/reports/mf, GET /api/v1/devices/{deviceId}/reports/ej and POST /api/v1/devices/{deviceId}/reports/anaf-export return the same data programmatically. See the Reports API reference.

ANAF defines the submission cadence and the deadlines for fiscal artifacts; those rules change over time. Treat the official ANAF reference at https://www.anaf.ro as canonical, and use the ANAF rejection troubleshooting guide when a submission is refused.

ANAF e-Factura (electronic invoicing for B2B/B2G) is a separate ANAF system, not part of fiscal-printer reporting. MF/JE/P7B come from the AMEF; e-Factura applies to invoices, not receipts.

Cash operations

The AMEF tracks cash in its drawer independently of your POS. The fiscal printer needs to know how much physical cash is in the till at any moment so the Z report's cash declared vs cash received line reconciles. Two operations move that balance without printing a sale:

Depunere numerar (cash deposit / cash-in) — money put into the drawer that is not a sale: opening float at start of shift, change brought from the safe, an operator topping up the till.
Ridicare numerar / Retragere numerar (cash withdrawal / cash-out) — money pulled out of the drawer that is not a refund: end-of-day pickup, transfer to the safe, paying a supplier in cash from the till.

Both record on the AMEF and feed the Sold numerar (cash balance) line on the next Z. From the Portal device-detail page, the Cash in Drawer card on the Overview tab shows the live balance and exposes the two operations — Withdraw and Deposit — each asking for an amount and an optional description. The balance refreshes automatically once the device confirms the operation.

A cash operation on the AMEF is not a fiscal sale and is not a substitute for one. Use cash-in/cash-out only for the float and for non-sale movements. Selling something for cash and recording a cash-in on the side hides the sale from the fiscal memory — that is exactly what an inspection looks for.

The cash operations are also exposed as commands on the API: cash_in and cash_out in Device commands, and the live balance is available at GET /api/v1/devices/{deviceId}/cash-balance.

Voids and Proces Verbal

There are two distinct ways to cancel a receipt, and they are not interchangeable.

Void (void_receipt) applies before fiscalization — while a receipt is still open on the AMEF and has not been finalised. The line items have not yet been committed to fiscal memory, so the void simply discards them. Once the AMEF cuts the paper and writes the receipt to memory, void is no longer an option.

Proces Verbal de anulare applies after fiscalization — when the receipt is already in the fiscal memory and you need to cancel it. Under Romanian fiscal law there is no "storno receipt" printed on the AMEF; the correct procedure is to draw up a Proces Verbal de anulare a bonului fiscal — a signed declaration stating that the receipt was closed erroneously, which is sent to accounting together with the original fiscal receipt and a copy of the Z report.

The Portal generates the Proces Verbal PDF prefilled with the receipt and organisation data. The full step-by-step lives in Receipts — Proces Verbal.

The Proces Verbal is a legal document that must be signed and sent to accounting. Make sure the original receipt really needs to be cancelled before generating the document.

What next

Integrators — the Receipts API, Reports API and Device commands give you the same operations programmatically.
Real-time events — wire up the Webhooks page to get notified when a receipt is created, a Z is closed or a JE is accepted by ANAF.
When ANAF refuses a submission — the ANAF rejection troubleshooting guide walks through the common causes and how to recover.

Device history

See every fiscal command sent to a single device, filter by type, and check whether failures can be safely retried.

Locations

Manage every shop, restaurant or office in one place — add locations, assign devices, compare performance and give each manager scoped access from the e-bon Portal.