RO e-Factura glossary, in English
Romania’s e-Factura, term by term.
If you run a Romanian entity from abroad, the mandate arrives wrapped in acronyms — SPV, UBL, FACT1, CIUS-RO, the P filter, SAF-T. This is a plain, accurate glossary of the six terms that explain how the whole system actually works.
- SPV, UBL, FACT1, CIUS-RO, the P filter and SAF-T — defined plainly
- The legal original is XML; the PDF is rendered by ANAF itself
- Written for foreign operators, not for EDI specialists
A working glossary, written for foreign operators · general information, not legal advice
Search this in English and you get advisories and enterprise EDI. Here is a plain glossary instead.
The foreign-operator corner of RO e-Factura is dominated by VAT consultancies and heavyweight EDI platforms. What is missing is a straight explanation of the vocabulary — and a lightweight tool you can set up yourself. This page is the first; eFacturaSPV is the second.
The glossary
Six terms that explain the whole system
From the channel you receive on to the report ANAF cross-checks it against — each defined once, plainly.
SPV — Spațiul Privat Virtual
ANAF’s secure online portal and messaging system. RO e-Factura runs inside it: issued invoices are uploaded to SPV, received invoices are pulled from it. It is the single government channel — and a transmission channel, not an archive (≈60 days).
UBL — the XML invoice
Universal Business Language, the standardized XML the invoice travels in. In RO e-Factura the UBL file is the legal original; ANAF returns only XML from SPV, never a PDF. (CII is an accepted alternative syntax on upload.)
transformare / FACT1
ANAF’s official conversion service. It renders the human-readable PDF from the UBL XML. Because ANAF does the rendering, the PDF is identical to what a tax inspector sees — and the conversion is one-way: XML → PDF, never the reverse.
CIUS-RO
The Romanian Core Invoice Usage Specification — the national adaptation of the EU standard EN 16931. It fixes which fields and business rules a valid Romanian e-invoice must satisfy. A UBL file that fails CIUS-RO is rejected at upload.
The „P” filter (filtru P)
When you query ANAF’s message-list endpoint, a code selects direction: P = primite (received), T = trimise (sent), plus E for errors. The P filter isolates the supplier invoices sent to you — the inbound side this product is built around.
SAF-T (D406)
Standard Audit File for Taxation — a separate, large XML report (declaration D406) that hands ANAF a structured extract of your accounts. A different obligation from e-Factura, phased in for small taxpayers and micro-enterprises from January 2025.
How they connect
One flow: SPV → UBL → FACT1
Three of the terms aren’t separate facts — they’re three stages of the same received-invoice journey.
SPV — the channel
Spațiul Privat Virtual is ANAF’s secure portal. Every B2B and B2C invoice transits it, and your suppliers’ invoices land there for you to pull. But documents stay downloadable for only ≈60 days — it is a channel, not your archive.
UBL — the original
What you pull is UBL XML: the structured, legally valid original of the invoice. ANAF returns only XML, never a PDF. Every field — supplier, lines, VAT, totals — is machine-readable, in any language.
FACT1 — the PDF
ANAF’s transformare/FACT1 service renders the official PDF from that XML. Because ANAF does the rendering, the PDF matches what an inspector sees. The conversion is one-way: from UBL you regenerate the PDF, never the reverse.
Worth getting right
Two distinctions people trip on
The two terms most often misread — a standard mistaken for a different standard, and a filter mistaken for a status.
CIUS-RO is not a different standard from EN 16931 — it is a stricter reading of it. EN 16931 defines the core of a compliant European e-invoice; CIUS-RO is Romania’s usage specification on top, deciding which optional fields become mandatory and adding national business rules (for example around the buyer’s and seller’s tax identifiers). A UBL file can be valid XML yet still be rejected if it breaks a CIUS-RO rule — which is why validation matters before you rely on a document.
The filter letters describe direction, not status. ANAF’s message-list endpoint groups everything in your SPV mailbox; the filter narrows it. P (primite) returns invoices sent to you, T (trimise) the ones you issued, and E the error messages. Everything eFacturaSPV does on your behalf starts from the P filter — the received side you are obliged to retrieve and keep, but that ANAF deletes from SPV after roughly 60 days.
From terms to practice
The one consequence that ties them together
SPV is a channel, UBL is the original, FACT1 is the rendering — and none of them is your archive.
Put the terms together and a single obligation falls out: the legally valid invoice is the UBL XML that passed through SPV, ANAF renders its PDF through FACT1 on demand, and you must keep both for 5 years — yet ANAF only keeps them downloadable from SPV for about 60 days. The platform you receive on is not the archive you are required to hold.
This is the gap eFacturaSPV closes: connect ANAF once, and we pull every invoice from the P filter, render the official ANAF PDF through transformare/FACT1, and archive both to your own Google Drive by year and month — for all the companies on your certificate. See how downloading works or how archiving works.
Where it shows up
From glossary to product
Each term maps to something you actually do — receive, render, validate, archive.
Download from SPV
The P filter in action: every received invoice pulled automatically, before the 60-day window closes.
Archive to Google Drive
UBL and the official PDF stored by month in your own Drive, covering the 5-year retention duty.
XML → PDF tool
Render any UBL as the official ANAF PDF through the transformare/FACT1 service.
e-Factura for foreign companies
What the mandate means if you run a Romanian entity from abroad — in practice.
RO e-Factura API
The SPV endpoints behind the terms — listaMesaje, the P filter, FACT1 — for developers.
Full Romanian glossary
Every term in depth, in Romanian: SPV, UBL, FACT1, CIUS-RO, the P filter and more.
FAQ
Frequently asked questions
What is SPV in Romanian e-Factura?
What is the difference between the UBL XML and the PDF?
What does transformare/FACT1 do?
What is CIUS-RO, and how is it different from EN 16931?
What is the „P” filter (filtru P)?
Is SAF-T the same as e-Factura?
Do I need to read Romanian to deal with any of this?
Know the terms. Now let the invoices handle themselves.
Connect ANAF once. We pull every received invoice from the P filter, render the official PDF through FACT1, and archive it to your own Google Drive — across all your companies, in English.
Free to start · no card · your data stays in your own Google Drive