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.

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 below.

VAT is applied per line at the rate set on the AMEF (Romanian fiscal law currently uses 19%, 9%, 5% 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.

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.

You can trigger an X or a Z remotely from the Portal — there is no need to walk to the cash register. The full procedure (filter row, Trigger Report modal, offline-queue behaviour) is documented in Reports — Triggering a report. Both reports produce a row in the matching tab as soon as the device confirms.

ANAF reporting (MF, JE, P7B)

Three artifacts leave each AMEF on top of receipts and Z reports. e-bon collects them so they are auditable from the Portal and queryable through the API.

• MF — Memorie Fiscală. A periodic archive of the fiscal memory contents. It captures the cumulative totals stored inside the AMEF for a given period (typically a calendar month or a date range you specify). MF entries carry an Archive Date and an Expires At so you know when the next one is due.
• JE — Jurnal Electronic. The daily electronic journal: a structured XML document the device produces for each fiscal day, listing every receipt and report. The JE is what ANAF actually reads.
• P7B. A PKCS#7 digital signature envelope wrapped around the JE XML. The signature proves the journal came from a specific certified AMEF and was not altered in transit. ANAF verifies the P7B before accepting the JE.

The data flow is: the AMEF produces the JE XML and the on-site device controller signs it into a P7B; the e-bon API stores the XML and the signature and tracks the ANAF submission status; the Portal lets you inspect every entry and download the artifacts. Submission status flows back as one of Pending, Accepted, Rejected or Error.

To check submissions or pull artifacts:

• From the Portal — use the MF Reports and JE Reports tabs on Reports. The JE detail modal shows the full XML and the P7B signature exactly as ANAF received them.
• From the API — GET /api/v1/reports/mf, GET /api/v1/reports/je and GET /api/v1/reports/je/:deviceId/xml return the same data programmatically. See the Reports API reference.

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 management card exposes three buttons — Depunere numerar, Ridicare numerar, and Sold numerar (to refresh the live balance). Each operation asks for an amount and an optional description.

Voids and reversals (Storno)

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.

Storno (reversal) applies after fiscalization — when the receipt is already in the fiscal memory and you need to cancel it. A storno is a separate, real fiscal document that prints on the AMEF, references the original receipt and posts equal-and-opposite values to the totals. Both the original and the storno stay in the fiscal memory; ANAF sees both and matches them via the original's coordinates.

The Portal storno modal collects exactly the coordinates the AMEF needs to bind the reversal to the original sale:

• Reason — Operator Error, Refund or Tax Base Reduction (the three reasons Romanian fiscal law recognises for a storno).
• Original Receipt Number — the fiscal ID printed on the original.
• Original Receipt Date/Time — when the original was fiscalized.
• Fiscal Memory Serial Number — the serial of the original AMEF's fiscal memory.
• Unique Sale Number (USN) — the unique fiscal sale number of the original receipt.
• Original Z-Report Number — optional; supply it when the storno crosses a Z-report boundary, i.e. the day of the original sale has already been closed.
• Items and Payments — pre-filled from the original; trim or edit if only part of the receipt is being reversed.

The full step-by-step (where the Storno button sits, the device picker, the device-offline behaviour) lives in Receipts — Storno (reversal). The corresponding API endpoint is POST /api/v1/devices/:deviceId/reversal — see Device commands and Receipts API.

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.