Glossary

A single A→Z reference for the Romanian fiscal acronyms and the e-bon terms that appear across this documentation. If you bumped into a word on another page and you are not sure what it means, this is the right place to look.

Entries use English alphabetical order. Each entry is one paragraph in plain language, followed by a Where it appears line linking back to the relevant docs pages, and (for legal terms) a Source line pointing at ANAF.

A

AMEF (cash register)

AMEF stands for aparat de marcat electronic fiscal — Romanian for "electronic fiscal cash register". In everyday speech the same device is called a casă de marcat. Every business in Romania that sells to consumers must use an AMEF certified by the Ministry of Finance to issue bonuri fiscale. e-bon manages AMEF devices remotely from the cloud — every device you connect through the Controller becomes addressable from the portal and the API.

Where it appears: What is e-bon?, Devices.

ANAF

ANAF — Agenția Națională de Administrare Fiscală — is the Romanian tax authority. Every fiscal report e-bon generates (Z report, JE, MF, F4109) is ultimately destined for ANAF, either through the device's online MF↔ANAF connection or filed manually by the business owner via SPV.

Where it appears: Compliance, Reports. Source: anaf.ro.

Antet & footer (header & footer)

The first and last lines printed on every fiscal receipt. The antet typically carries the business name, address and CUI; the footer typically carries a thank-you line, loyalty information or a website. Both are configurable per device through e-bon — you push new lines from the portal without visiting the location. The header and footer are also what gets re-formatted when a new logo is uploaded.

Where it appears: Devices — header & footer commands.

API key prefix scheme (ebon_live_<orgId>_<hex>)

Every e-bon API key is a single string with a fixed shape: ebon_live_<orgId>_<hex>. The ebon_live_ prefix marks it as a production credential, the <orgId> segment binds the key to one organization (so a leaked key never crosses organization boundaries), and the trailing <hex> is 32 random hex characters. Only a hash of the key is stored server-side; the plaintext is shown to you exactly once at creation time.

Where it appears: API keys, Authentication.

B

Bon fiscal

A bon fiscal is a fiscal receipt — the legal proof that a sale was registered with the AMEF and committed to its memorie fiscală. A bon fiscal carries the device's fiscal series, the receipt number, the operator, the items with their VAT departments, the totals per VAT rate and the payment breakdown. e-bon stores every bon fiscal that any of your devices emits, and exposes them through the portal and the /receipts API.

Where it appears: Receipts, Portal — Receipts.

Bon nefiscal

A bon nefiscal is a non-fiscal print — for example a duplicate, a pre-bill, a logo test print or a service ticket. It looks like a receipt but does not commit to the memorie fiscală and cannot be used as proof of sale. e-bon dispatches non-fiscal prints through the same command pipeline as fiscal ones but flags them differently in the portal.

Where it appears: Devices — operations.

C

Cash in / Cash out / Sold numerar

Operator-driven cash drawer movements: cash in is a depunere numerar (cash deposit, e.g. opening float), cash out is a ridicare numerar (cash withdrawal, e.g. end-of-shift cash pickup), and sold numerar is the running cash balance the device thinks is in the drawer. All three are tracked per device through the e-bon portal and translate directly into the AMEF's own cash management commands.

Where it appears: Devices — cash management.

Command envelope

The standard request body shape for any command e-bon dispatches to a device. Every command carries a stable type (e.g. print_receipt, x_report, set_header), an idempotent payload and lifecycle metadata (status, result). The envelope is what allows the same command to be retried, queued while the device is offline, audited later in the portal and surfaced through webhooks.

Where it appears: Commands, Architecture — command pipeline.

Controller (E-BON Android app)

The Android app that sits next to each fiscal device and acts as its bridge to the e-bon cloud. It speaks to the printer over Bluetooth, USB, Serial or TCP, and to the portal over HTTPS. In the docs we call it the Controller (or simply the E-BON App) to distinguish it from the printer itself — the printer is the AMEF, the Controller is the Android device that drives it.

Where it appears: App overview, Devices — pairing.

D

Department (departament)

Each item on a fiscal receipt is assigned to a department — a numeric VAT bucket on the AMEF (commonly 1–8, depending on model). Departments are how the AMEF knows which VAT rate to apply to which item, and they are what the Z report totals up at the end of the fiscal day. In e-bon the department is part of every receipt item you push through the API.

Where it appears: Receipts.

F

F4109

Declaration F4109 — "Declarație privind AMEF neutilizate" — is the ANAF declaration that must be filed whenever an AMEF emits zero fiscal receipts in a calendar month. It is per-device and per-month, due by the 20th of the following month, submitted electronically through SPV. The MF↔ANAF online connection did not repeal this obligation.

Where it appears: F4109 — ANAF inactivity declaration. Source: OPANAF 627/2018, anaf.ro.

I

Idempotency-Key

The HTTP header that makes POS retries safe. When the network drops mid-request and the integrator retries, the second (and third, and twentieth) request carries the same Idempotency-Key value as the first. e-bon caches the original response per organization and replays it for the duration of the TTL window, so a retry never causes a second receipt to print or a second webhook to fire.

Where it appears: Idempotency, Receipts, Commands.

J

JE (Jurnal Electronic)

The Jurnal Electronic — Electronic Journal — is the cumulative, chronologically-ordered, ANAF-formatted XML log of every fiscal event a device has produced over a reporting period. It is the long-form companion to the memorie fiscală: the MF stores the rolled-up daily totals, the JE stores the underlying timeline. e-bon generates JE XML on demand per device and per period through the /reports/je endpoint and stores the resulting P7B-signed report for audit.

Where it appears: Reports — JE.

M

MF (Memorie Fiscală)

The Memorie Fiscală — Fiscal Memory — is the AMEF's tamper-protected on-device storage where every closed fiscal day's Z report totals are written. It is the device's source of truth and the basis for ANAF audits. e-bon exports MF reports through the /reports/mf endpoints and surfaces them in the portal alongside their archive date.

Where it appears: Reports — MF.

O

Operator

A named user identity on the AMEF — typically a cashier or a waiter. The operator logs in on the device with an operator ID and (optionally) a password before issuing receipts; every bon fiscal is then stamped with that operator. e-bon manages operators per device from the portal: you can add, replace and remove operators remotely, and filter receipts and reports by operator afterwards.

Where it appears: Devices — operators.

P

P7B

P7B is the file format used for ANAF-compliant detached digital signatures (PKCS #7 / CMS, DER-encoded). When e-bon generates a JE XML report for ANAF e-Reporting, the signed envelope is stored alongside it as a P7B blob — that is what proves the XML has not been altered after submission.

Where it appears: Reports — JE.

Plic de eroare (error envelope)

e-bon's name for the consistent JSON shape every API error response uses: { "error": { "code": "...", "message": "...", "details": ... } }. The Romanian plic (envelope) captures the idea — every error is wrapped in the same outer shape so integrators only have to write one error parser.

Where it appears: Errors.

R

Raport X (X report)

A raport X is a read-only, mid-day snapshot of a device's running totals: sales, refunds, VAT breakdown and receipt count since the last Z report. Issuing an X report does not close the fiscal day, does not reset the daily counters and does not write to the memorie fiscală. It is the right report to pull whenever you want a peek at where the day stands.

Where it appears: Reports — X.

Raport Z (Z report)

A raport Z closes the fiscal day. It freezes the day's totals, writes them into the memorie fiscală, resets the daily counters and increments the device's reset counter. Z reports are the daily fiscal close, not optional — every operating day a device has must end with one Z report. e-bon can trigger a Z remotely and stores every Z it sees.

Where it appears: Reports — Z.

S

SPV (Spațiul Privat Virtual)

The Spațiul Privat Virtual is ANAF's secure online portal at anaf.ro where Romanian taxpayers file declarations, receive correspondence and access fiscal records. SPV is where you go to submit F4109 and to retrieve the legal representative's qualified electronic signature artifacts. e-bon does not file directly into SPV — the business owner does, with the documents e-bon helps prepare.

Where it appears: F4109 — ANAF inactivity declaration. Source: anaf.ro.

Storno

A storno is a fiscal reversal — a receipt that cancels a prior sale (operator error, refund, tax-base reduction). A storno is itself a fiscal receipt: it is committed to the memorie fiscală, it appears in the Z report, and it must reference the original sale by USN and original receipt number. Issuing a storno is the only legally correct way to undo a previous fiscal receipt — you cannot just delete one.

Where it appears: Receipts — reversal, Devices — operations.

T

TVA / VAT

TVA — Taxa pe Valoarea Adăugată — is the Romanian Value-Added Tax. Each item on a fiscal receipt sits in a department with a configured TVA rate (commonly 19%, 9%, 5% or 0%). The Z report and the JE both break the day's sales down by TVA rate; ANAF reconciles those breakdowns against what the business declares.

Where it appears: Receipts, Reports.

U

USN (unique sale number)

The USN — număr unic de vânzare — is the unique identifier that ties a storno to its original sale. When you issue a reversal you pass the USN of the original receipt so the device (and ANAF) can correlate the two. In e-bon the USN flows through as uniqueSaleNumber on the relevant command payloads.

Where it appears: Receipts — reversal, Commands — reversal payloads.

W

Webhook event types

The list of fiscal events e-bon delivers as outgoing webhooks (receipt.created, command.completed, device.offline, etc.). Each event has a stable name, a documented payload shape and a guaranteed delivery contract (signed, retried, replayable). When something interesting happens on one of your devices, this is how your system finds out without polling.

Where it appears: Webhook events, Webhooks.