RO e-Factura Validator Romania
Find out whether ANAF would reject your invoice — and with which rule (BR-RO-001, BR-RO-100, ERRIdentif) — before you send it to the SPV.
What is RO e-Factura, and why does ANAF reject an invoice?
RO e-Factura is Romania’s mandatory e-invoicing system: every B2B invoice has gone through the ANAF clearing platform (SPV) since 1 July 2024, and B2C since 1 January 2025. An invoice the platform rejects is legally not issued. The format is RO_CIUS — a national CIUS of the European standard EN 16931, carried in OASIS UBL 2.1 (Invoice = FACT1, CreditNote = FCN). This free validator runs the three layers ANAF itself runs, in the same order: the OASIS UBL 2.1 XSD; the OFFICIAL CIUS-RO Schematron published by the Ministry of Finance (ro16931-ubl-1.0.9, in force since 5 June 2024), which carries both the EN 16931 core rules (BR-*, BR-CO-*) and the Romanian ones (BR-RO-001 for the CustomizationID, BR-RO-020 for the invoice type code, BR-RO-100 for the SECTOR1…SECTOR6 spelling in Bucharest…); and the fiscal-identity check that lives OUTSIDE the Schematron and that most tools miss — the CUI check digit and the CNP, which ANAF rejects under the code ERRIdentif. Everything runs in your browser: the invoice never leaves your machine.
About the RO e-Factura validator
RO e-Factura is Romania's mandatory e-invoicing system. Every B2B invoice has passed through ANAF's clearing platform (the SPV) since 1 July 2024, and every B2C invoice since 1 January 2025. The platform either accepts the file or rejects it — and a rejected invoice is legally not an invoice. So the only question that matters is not 'is my XML well-formed?' but 'will ANAF accept it, and if not, why?'. That is the question this tool answers.
It answers it by running the three layers ANAF itself runs, in the same order. First the OASIS UBL 2.1 XSD — the schema catches what no business rule can see, such as an element in the wrong order, and ANAF rejects on it before anything else. Then the OFFICIAL CIUS-RO Schematron published by the Ministry of Finance (ro16931-ubl-1.0.9, in force since 5 June 2024): not a reimplementation, the ministry's own file, compiled and executed as-is. It carries the EN 16931 core rules (BR-*, BR-CO-*) and the Romanian ones (BR-RO-*), and its messages are the ones the SPV will quote back at you, word for word.
The third layer is the one almost every free tool misses. The check digit of the CUI (the Romanian tax number) and the CNP (the personal number used for B2C) are NOT part of the Schematron — ANAF verifies them separately and rejects the invoice under a code of its own, ERRIdentif ('CUI cumparator incorect', 'CNP sau NIF vanzator incorect'). A validator that only runs the Schematron therefore declares valid a file ANAF will refuse. Our rules for these two identifiers were established by querying the Ministry's own offline validator as an oracle — the algorithms are published nowhere — and they encode what it actually does: a CNP must not only pass its checksum, its encoded date of birth must exist (a 31 April is refused), while a NIF (leading 9) carries no date at all and is exempt from that test.
Key takeaways
- A green verdict here means the FILE is clean. The SPV still checks who is depositing it, whether the parties are registered, and whether you are within the deadline (5 working days since 1 January 2026) — those need ANAF's systems and are listed explicitly in the result.
- BR-RO-001 is the most common rejection: an invoice still declaring CIUS-RO:1.0.0. Both example files the Ministry itself publishes carry that dead value — and the Ministry's own validator rejects them.
- The CUI check is purely arithmetic: a well-formed but non-existent number passes validation. Passing here does not mean the company exists.
- The anonymous B2C identifier 0000000000000 (thirteen zeros) is legitimate and must never be rejected — it has been in production since 16 December 2024.
- RO_CIUS also covers the CII syntax, but the Ministry publishes neither a Schematron nor a validator for it: its two official tools accept UBL only. We say so rather than simulate a verdict we cannot reproduce.
Frequently asked questions
Why does ANAF reject my invoice with BR-RO-001?
Because BT-24 (CustomizationID) does not carry the exact value RO_CIUS requires: urn:cen.eu:en16931:2017#compliant#urn:efactura.mfinante.ro:CIUS-RO:1.0.1. The previous value, ending in 1.0.0, was retired on 29 December 2022 by order OMF 4092/2022 and is refused. It is the single most common rejection — and the two example invoices published on mfinante.gov.ro still carry it.
What does 'CUI cumparator incorect' mean?
It means the buyer's Romanian tax number (CUI) has a wrong check digit. This check is not part of the Schematron: ANAF runs it separately and reports it under the code ERRIdentif — which is why a validator that only runs the Schematron will tell you the invoice is fine. Note that the check is purely arithmetic: ANAF does not verify at this stage that the company exists, only that the number is well formed. The equivalent messages are 'CUI vanzator incorect' for the seller, and 'CNP sau NIF … incorect' when the identifier is a 13-digit personal number.
My city is Bucharest and the invoice is rejected (BR-RO-100). Why?
Because when the country is RO and the subdivision (BT-39/BT-40) is RO-B, the city (BT-37) must be one of SECTOR1, SECTOR2, SECTOR3, SECTOR4, SECTOR5, SECTOR6 — uppercase, no space. The ministerial order itself writes them 'Sector 1', 'Sector 2'…, but the Schematron that ANAF actually runs demands SECTOR1. When the text of the law and the implementation disagree, the implementation is what rejects your file.
Which invoice type codes (BT-3) does Romania accept?
On an Invoice: 380 (invoice), 384 (corrected invoice), 389 (self-billed invoice) and 751 (invoice — information for accounting purposes). The code 381 (credit note) is accepted only on a CreditNote document, never on an Invoice — the text of rule BR-RO-020 lists all five together, which is misleading; its XPath does not.
Does this tool send my invoice to ANAF?
No. Nothing leaves your browser: the XSD, the official Schematron and the identity checks all run locally, on your machine. That also means we cannot perform the checks that require ANAF's systems — your authentication, the taxpayer registry, the transmission deadline — and the result lists them explicitly instead of passing them over in silence.
Can I validate a CII (UN/CEFACT) e-invoice here?
No, and that is deliberate. RO_CIUS does cover the CII syntax, but the Ministry of Finance publishes neither a Schematron nor a validator for it: both of its official tools — the offline application and the /validare web service — accept UBL only (FACT1 and FCN). We could not reproduce ANAF's verdict on a CII file, so we say so rather than invent one. Use the UBL/Peppol validator for the EN 16931 rules, or convert the invoice to UBL.
ValidateFin is an independent tool, neither certified nor endorsed by ANAF or the Romanian Ministry of Finance. “Official” refers to the artefacts it runs — the CIUS-RO Schematron (ro16931-ubl-1.0.9) and the OASIS UBL 2.1 schemas published by the Ministry — not to any accreditation of this tool. A file that passes here still has to be accepted by the SPV, which additionally checks the depositor’s identity, the taxpayer registry and the transmission deadline; those checks are listed explicitly in the result rather than passed over in silence. Validating a file here does not transmit it to ANAF.