RO e-Factura Validator Romania
Scopri se l’ANAF scarterebbe la tua fattura — e con quale regola (BR-RO-001, BR-RO-100, ERRIdentif) — prima di inviarla al SPV.
Che cos’è RO e-Factura e perché l’ANAF scarta una fattura?
RO e-Factura è il sistema rumeno di fatturazione elettronica obbligatoria: ogni fattura B2B passa dalla piattaforma dell’ANAF (il SPV) dal 1° luglio 2024, e il B2C dal 1° gennaio 2025. Una fattura respinta dalla piattaforma giuridicamente non è emessa. Il formato è RO_CIUS — una specifica nazionale (CIUS) della norma europea EN 16931, veicolata in OASIS UBL 2.1 (fattura = FACT1, nota di credito = FCN). Questo validatore gratuito esegue i tre livelli che esegue l’ANAF stessa, nello stesso ordine: l’XSD OASIS UBL 2.1; lo Schematron UFFICIALE CIUS-RO pubblicato dal Ministero delle Finanze (ro16931-ubl-1.0.9, in vigore dal 5 giugno 2024), che porta sia le regole del nucleo EN 16931 (BR-*, BR-CO-*) sia quelle rumene (BR-RO-001 per il CustomizationID, BR-RO-020 per il codice tipo fattura, BR-RO-100 per la grafia SECTOR1…SECTOR6 a Bucarest…); e il controllo dell’identità fiscale che vive FUORI dallo Schematron e che quasi tutti gli strumenti dimenticano — la cifra di controllo del CUI e il CNP, che l’ANAF respinge con il codice ERRIdentif. Tutto gira nel browser: la fattura non lascia mai il tuo dispositivo.
Informazioni sul validatore RO e-Factura
RO e-Factura è il sistema di fatturazione elettronica obbligatorio della Romania. Ogni fattura B2B passa dalla piattaforma di clearing dell'ANAF (l'SPV) dal 1° luglio 2024, e ogni fattura B2C dal 1° gennaio 2025. La piattaforma accetta il file oppure lo respinge — e una fattura respinta giuridicamente non è una fattura. L'unica domanda che conta non è quindi «il mio XML è ben formato?», ma «l'ANAF lo accetterà, e se no perché?». È a questa domanda che risponde questo strumento.
Vi risponde eseguendo gli stessi tre livelli che l'ANAF esegue, nello stesso ordine. Prima l'XSD OASIS UBL 2.1 — lo schema intercetta ciò che nessuna regola di business può vedere, ad esempio un elemento nell'ordine sbagliato, e l'ANAF respinge su questo prima di ogni altra cosa. Poi lo Schematron CIUS-RO UFFICIALE pubblicato dal Ministero delle Finanze (ro16931-ubl-1.0.9, in vigore dal 5 giugno 2024): non una reimplementazione, ma il file stesso del ministero, compilato ed eseguito così com'è. Contiene le regole fondamentali della EN 16931 (BR-*, BR-CO-*) e quelle rumene (BR-RO-*), e i suoi messaggi sono esattamente quelli che l'SPV vi restituirà, parola per parola.
Il terzo livello è quello che quasi tutti gli strumenti gratuiti dimenticano. Il codice di controllo del CUI (il numero fiscale rumeno) e del CNP (il numero personale usato nel B2C) NON fa parte dello Schematron — l'ANAF li verifica separatamente e respinge la fattura sotto un codice proprio, ERRIdentif («CUI cumparator incorect», «CNP sau NIF vanzator incorect»). Un validatore che esegue solo lo Schematron dichiara quindi valido un file che l'ANAF rifiuterà. Le nostre regole per questi due identificativi sono state ricostruite interrogando come oracolo il validatore offline del Ministero — gli algoritmi non sono pubblicati da nessuna parte — e codificano ciò che esso fa realmente: un CNP non deve solo superare il proprio checksum, ma la data di nascita in esso codificata deve esistere (un 31 aprile viene rifiutato), mentre un NIF (che inizia per 9) non porta alcuna data ed è esente da quel test.
Punti chiave
- Un verdetto verde qui significa che il FILE è pulito. L'SPV verifica inoltre chi lo deposita, se le parti sono registrate e se siete nei termini (5 giorni lavorativi dal 1° gennaio 2026) — questo richiede i sistemi dell'ANAF ed è indicato esplicitamente nel risultato.
- BR-RO-001 è lo scarto più frequente: una fattura che dichiara ancora CIUS-RO:1.0.0. Entrambi i file di esempio pubblicati dal Ministero stesso portano quel valore morto — e il validatore del Ministero li respinge.
- Il controllo del CUI è puramente aritmetico: un numero ben formato ma inesistente supera la validazione. Passare qui non significa che l'azienda esista.
- L'identificativo B2C anonimo 0000000000000 (tredici zeri) è legittimo e non deve mai essere respinto — è in produzione dal 16 dicembre 2024.
- RO_CIUS copre anche la sintassi CII, ma il Ministero non pubblica per essa né uno Schematron né un validatore: i suoi due strumenti ufficiali accettano solo UBL. Lo diciamo, anziché simulare un verdetto che non possiamo riprodurre.
Domande frequenti
Perché l'ANAF respinge la mia fattura con BR-RO-001?
Perché BT-24 (CustomizationID) non porta il valore esatto richiesto da RO_CIUS: urn:cen.eu:en16931:2017#compliant#urn:efactura.mfinante.ro:CIUS-RO:1.0.1. Il valore precedente, terminante in 1.0.0, è stato ritirato il 29 dicembre 2022 dal decreto OMF 4092/2022 ed è rifiutato. È di gran lunga lo scarto più frequente — e le due fatture di esempio pubblicate su mfinante.gov.ro lo portano ancora.
Che cosa significa «CUI cumparator incorect»?
Significa che il numero fiscale rumeno (CUI) dell'acquirente ha un codice di controllo errato. Questo controllo non fa parte dello Schematron: l'ANAF lo esegue separatamente e lo segnala sotto il codice ERRIdentif — ecco perché un validatore che esegue solo lo Schematron vi dirà che la fattura va bene. Attenzione: il controllo è puramente aritmetico, in questa fase l'ANAF non verifica che l'azienda esista, ma soltanto che il numero sia ben formato. I messaggi equivalenti sono «CUI vanzator incorect» per il venditore e «CNP sau NIF … incorect» quando l'identificativo è un numero personale di 13 cifre.
La mia città è Bucarest e la fattura viene respinta (BR-RO-100). Perché?
Perché quando il paese è RO e la suddivisione (BT-39/BT-40) è RO-B, la città (BT-37) deve essere una fra SECTOR1, SECTOR2, SECTOR3, SECTOR4, SECTOR5, SECTOR6 — in maiuscolo, senza spazio. Lo stesso decreto ministeriale le scrive «Sector 1», «Sector 2»…, ma lo Schematron che l'ANAF esegue davvero pretende SECTOR1. Quando il testo della legge e l'implementazione divergono, è l'implementazione a respingere il vostro file.
Quali codici tipo documento (BT-3) accetta la Romania?
Su una Invoice: 380 (fattura), 384 (fattura rettificativa), 389 (autofatturazione) e 751 (fattura — informazione a fini contabili). Il codice 381 (nota di credito) è accettato solo su un documento CreditNote, mai su una Invoice — il testo della regola BR-RO-020 elenca tutti e cinque insieme, il che è fuorviante; il suo XPath no.
Questo strumento invia la mia fattura all'ANAF?
No. Nulla lascia il vostro browser: l'XSD, lo Schematron ufficiale e i controlli di identità girano localmente, sulla vostra macchina. Ciò significa anche che non possiamo eseguire i controlli che richiedono i sistemi dell'ANAF — la vostra autenticazione, il registro dei contribuenti, il termine di trasmissione — e il risultato li elenca esplicitamente invece di passarli sotto silenzio.
Posso validare qui una fattura elettronica CII (UN/CEFACT)?
No, ed è una scelta deliberata. RO_CIUS copre effettivamente la sintassi CII, ma il Ministero delle Finanze non pubblica per essa né uno Schematron né un validatore: entrambi i suoi strumenti ufficiali — l'applicazione offline e il servizio web /validare — accettano solo UBL (FACT1 e FCN). Non potremmo riprodurre il verdetto dell'ANAF su un file CII, quindi lo diciamo anziché inventarlo. Usate il validatore UBL/Peppol per le regole EN 16931, oppure convertite la fattura in 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.