RO e-Factura Validator Romania
Sachez si l’ANAF rejetterait votre facture — et sur quelle règle (BR-RO-001, BR-RO-100, ERRIdentif) — avant de la déposer sur le SPV.
Qu’est-ce que RO e-Factura, et pourquoi l’ANAF rejette-t-elle une facture ?
RO e-Factura est le système roumain de facturation électronique obligatoire : toute facture B2B passe par la plateforme de l’ANAF (le SPV) depuis le 1er juillet 2024, et le B2C depuis le 1er janvier 2025. Une facture rejetée par la plateforme est juridiquement non émise. Le format est le RO_CIUS — une spécification nationale (CIUS) de la norme européenne EN 16931, portée par OASIS UBL 2.1 (facture = FACT1, note de crédit = FCN). Ce validateur gratuit exécute les trois couches que l’ANAF exécute elle-même, dans le même ordre : le XSD OASIS UBL 2.1 ; le Schematron OFFICIEL CIUS-RO publié par le ministère des Finances (ro16931-ubl-1.0.9, en vigueur depuis le 5 juin 2024), qui porte à la fois les règles du socle EN 16931 (BR-*, BR-CO-*) et les règles roumaines (BR-RO-001 pour le CustomizationID, BR-RO-020 pour le code de type de facture, BR-RO-100 pour l’orthographe SECTOR1…SECTOR6 à Bucarest…) ; et le contrôle d’identité fiscale qui vit HORS du Schematron et que la plupart des outils oublient — le chiffre de contrôle du CUI et le CNP, que l’ANAF rejette sous le code ERRIdentif. Tout s’exécute dans votre navigateur : la facture ne quitte jamais votre machine.
À propos du validateur RO e-Factura
RO e-Factura est le système de facturation électronique obligatoire de la Roumanie. Toute facture B2B passe par la plateforme de clearing de l'ANAF (le SPV) depuis le 1er juillet 2024, et toute facture B2C depuis le 1er janvier 2025. La plateforme accepte le fichier ou le rejette — et une facture rejetée n'est juridiquement pas une facture. La seule question qui compte n'est donc pas « mon XML est-il bien formé ? » mais « l'ANAF va-t-il l'accepter, et sinon pourquoi ? ». C'est à cette question que répond cet outil.
Il y répond en exécutant les trois couches que l'ANAF exécute lui-même, dans le même ordre. D'abord le XSD OASIS UBL 2.1 — le schéma attrape ce qu'aucune règle métier ne voit, par exemple un élément dans le mauvais ordre, et l'ANAF rejette là-dessus avant tout le reste. Ensuite le Schematron CIUS-RO OFFICIEL publié par le ministère des Finances (ro16931-ubl-1.0.9, en vigueur depuis le 5 juin 2024) : non pas une réimplémentation, mais le fichier même du ministère, compilé et exécuté tel quel. Il porte les règles socles d'EN 16931 (BR-*, BR-CO-*) et les règles roumaines (BR-RO-*), et ses messages sont ceux que le SPV vous renverra, mot pour mot.
La troisième couche est celle que presque tous les outils gratuits oublient. Le chiffre de contrôle du CUI (le numéro fiscal roumain) et celui du CNP (le numéro personnel utilisé en B2C) ne font PAS partie du Schematron — l'ANAF les vérifie séparément et rejette la facture sous un code qui lui est propre, ERRIdentif (« CUI cumparator incorect », « CNP sau NIF vanzator incorect »). Un validateur qui n'exécute que le Schematron déclare donc valide un fichier que l'ANAF refusera. Nos règles pour ces deux identifiants ont été établies en interrogeant le validateur hors ligne du ministère comme oracle — les algorithmes ne sont publiés nulle part — et elles encodent ce qu'il fait réellement : un CNP doit non seulement passer sa somme de contrôle, mais sa date de naissance encodée doit exister (un 31 avril est refusé), tandis qu'un NIF (commençant par 9) ne porte aucune date et échappe à ce test.
À retenir
- Un verdict vert ici signifie que le FICHIER est propre. Le SPV vérifie encore qui le dépose, si les parties sont enregistrées et si vous êtes dans les délais (5 jours ouvrables depuis le 1er janvier 2026) — cela exige les systèmes de l'ANAF, et le résultat le mentionne explicitement.
- BR-RO-001 est le rejet le plus fréquent : une facture qui déclare encore CIUS-RO:1.0.0. Les deux fichiers d'exemple publiés par le ministère lui-même portent cette valeur morte — et le propre validateur du ministère les rejette.
- Le contrôle du CUI est purement arithmétique : un numéro bien formé mais inexistant passe la validation. Passer ici ne signifie pas que l'entreprise existe.
- L'identifiant B2C anonyme 0000000000000 (treize zéros) est légitime et ne doit jamais être rejeté — il est en production depuis le 16 décembre 2024.
- RO_CIUS couvre aussi la syntaxe CII, mais le ministère ne publie pour elle ni Schematron ni validateur : ses deux outils officiels n'acceptent que l'UBL. Nous le disons plutôt que de simuler un verdict que nous ne pouvons pas reproduire.
Questions fréquentes
Pourquoi l'ANAF rejette-t-il ma facture avec BR-RO-001 ?
Parce que BT-24 (CustomizationID) ne porte pas la valeur exacte qu'exige RO_CIUS : urn:cen.eu:en16931:2017#compliant#urn:efactura.mfinante.ro:CIUS-RO:1.0.1. La valeur précédente, terminée par 1.0.0, a été retirée le 29 décembre 2022 par l'arrêté OMF 4092/2022 et elle est refusée. C'est le rejet le plus fréquent de tous — et les deux factures d'exemple publiées sur mfinante.gov.ro la portent encore.
Que signifie « CUI cumparator incorect » ?
Que le numéro fiscal roumain (CUI) de l'acheteur a un chiffre de contrôle faux. Ce contrôle ne fait pas partie du Schematron : l'ANAF l'exécute séparément et le signale sous le code ERRIdentif — c'est pourquoi un validateur limité au Schematron vous dira que la facture est bonne. À noter : le contrôle est purement arithmétique, l'ANAF ne vérifie pas à ce stade que l'entreprise existe, seulement que le numéro est bien formé. Les messages équivalents sont « CUI vanzator incorect » pour le vendeur, et « CNP sau NIF … incorect » lorsque l'identifiant est un numéro personnel à 13 chiffres.
Ma ville est Bucarest et la facture est rejetée (BR-RO-100). Pourquoi ?
Parce que lorsque le pays est RO et la subdivision (BT-39/BT-40) vaut RO-B, la ville (BT-37) doit être SECTOR1, SECTOR2, SECTOR3, SECTOR4, SECTOR5 ou SECTOR6 — en majuscules, sans espace. L'arrêté ministériel les écrit pourtant « Sector 1 », « Sector 2 »…, mais le Schematron que l'ANAF exécute réellement exige SECTOR1. Quand le texte de la loi et l'implémentation divergent, c'est l'implémentation qui rejette votre fichier.
Quels codes de type de facture (BT-3) la Roumanie accepte-t-elle ?
Sur une Invoice : 380 (facture), 384 (facture rectificative), 389 (autofacturation) et 751 (facture — information à des fins comptables). Le code 381 (avoir) n'est accepté que sur un document CreditNote, jamais sur une Invoice — le texte de la règle BR-RO-020 énumère les cinq codes ensemble, ce qui induit en erreur ; son XPath, lui, ne les confond pas.
Cet outil envoie-t-il ma facture à l'ANAF ?
Non. Rien ne quitte votre navigateur : le XSD, le Schematron officiel et les contrôles d'identité s'exécutent localement, sur votre machine. Cela signifie aussi que nous ne pouvons pas effectuer les contrôles qui exigent les systèmes de l'ANAF — votre authentification, le registre des contribuables, le délai de transmission — et le résultat les énumère explicitement au lieu de les passer sous silence.
Puis-je valider ici une facture électronique CII (UN/CEFACT) ?
Non, et c'est délibéré. RO_CIUS couvre bien la syntaxe CII, mais le ministère des Finances ne publie pour elle ni Schematron ni validateur : ses deux outils officiels — l'application hors ligne et le service web /validare — n'acceptent que l'UBL (FACT1 et FCN). Nous ne pourrions pas reproduire le verdict de l'ANAF sur un fichier CII : nous le disons plutôt que d'inventer une réponse. Utilisez le validateur UBL/Peppol pour les règles EN 16931, ou convertissez la facture en 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.