RO e-Factura Validator Romania
Erfahren Sie, ob ANAF Ihre Rechnung ablehnen würde — und mit welcher Regel (BR-RO-001, BR-RO-100, ERRIdentif) — bevor Sie sie an das SPV senden.
Was ist RO e-Factura, und warum lehnt ANAF eine Rechnung ab?
RO e-Factura ist das verpflichtende rumänische E-Rechnungssystem: Jede B2B-Rechnung läuft seit dem 1. Juli 2024 über die ANAF-Plattform (SPV), B2C seit dem 1. Januar 2025. Eine von der Plattform abgelehnte Rechnung gilt rechtlich als nicht ausgestellt. Das Format ist RO_CIUS — eine nationale CIUS der europäischen Norm EN 16931, übertragen in OASIS UBL 2.1 (Rechnung = FACT1, Gutschrift = FCN). Dieser kostenlose Validator führt dieselben drei Schichten aus wie ANAF, in derselben Reihenfolge: das OASIS-UBL-2.1-XSD; das OFFIZIELLE CIUS-RO-Schematron des Finanzministeriums (ro16931-ubl-1.0.9, gültig seit 5. Juni 2024), das sowohl die EN-16931-Kernregeln (BR-*, BR-CO-*) als auch die rumänischen Regeln enthält (BR-RO-001 für die CustomizationID, BR-RO-020 für den Rechnungstyp, BR-RO-100 für die Schreibweise SECTOR1…SECTOR6 in Bukarest…); und die Prüfung der Steueridentität, die AUSSERHALB des Schematrons liegt und die die meisten Werkzeuge übersehen — die CUI-Prüfziffer und der CNP, die ANAF unter dem Code ERRIdentif ablehnt. Alles läuft im Browser: Die Rechnung verlässt Ihr Gerät nie.
Über den RO e-Factura-Validator
RO e-Factura ist das verpflichtende E-Rechnungssystem Rumäniens. Jede B2B-Rechnung läuft seit dem 1. Juli 2024 über die Clearing-Plattform der ANAF (das SPV), jede B2C-Rechnung seit dem 1. Januar 2025. Die Plattform nimmt die Datei an oder lehnt sie ab — und eine abgelehnte Rechnung ist rechtlich keine Rechnung. Die einzig relevante Frage lautet daher nicht „ist mein XML wohlgeformt?“, sondern „wird ANAF es annehmen, und wenn nicht, warum?“. Genau diese Frage beantwortet dieses Tool.
Es beantwortet sie, indem es dieselben drei Schichten ausführt wie ANAF selbst, in derselben Reihenfolge. Zuerst das OASIS UBL 2.1 XSD — das Schema erkennt, was keine Geschäftsregel sehen kann, etwa ein Element in falscher Reihenfolge, und ANAF lehnt darauf noch vor allem anderen ab. Dann das OFFIZIELLE CIUS-RO-Schematron des Finanzministeriums (ro16931-ubl-1.0.9, in Kraft seit dem 5. Juni 2024): keine Neuimplementierung, sondern die Originaldatei des Ministeriums, unverändert kompiliert und ausgeführt. Sie enthält die Kernregeln der EN 16931 (BR-*, BR-CO-*) und die rumänischen Regeln (BR-RO-*), und ihre Meldungen sind genau jene, die das SPV Ihnen wortgleich zurückspielen wird.
Die dritte Schicht ist die, die fast jedem kostenlosen Tool fehlt. Die Prüfziffer der CUI (der rumänischen Steuernummer) und der CNP (der im B2C verwendeten Personenkennziffer) ist NICHT Teil des Schematrons — ANAF prüft sie separat und lehnt die Rechnung unter einem eigenen Code ab, ERRIdentif („CUI cumparator incorect“, „CNP sau NIF vanzator incorect“). Ein Validator, der nur das Schematron ausführt, erklärt somit eine Datei für gültig, die ANAF zurückweisen wird. Unsere Regeln für diese beiden Kennungen wurden ermittelt, indem wir den Offline-Validator des Ministeriums als Orakel befragt haben — die Algorithmen sind nirgends veröffentlicht — und sie bilden ab, was er tatsächlich tut: Eine CNP muss nicht nur ihre Prüfsumme bestehen, auch das darin kodierte Geburtsdatum muss existieren (ein 31. April wird abgelehnt), während eine NIF (führende 9) überhaupt kein Datum enthält und von dieser Prüfung ausgenommen ist.
Das Wichtigste
- Ein grünes Ergebnis hier bedeutet, dass die DATEI sauber ist. Das SPV prüft darüber hinaus, wer sie einreicht, ob die Parteien registriert sind und ob Sie die Frist einhalten (5 Werktage seit dem 1. Januar 2026) — dafür sind die Systeme der ANAF nötig, und das Ergebnis weist ausdrücklich darauf hin.
- BR-RO-001 ist die häufigste Ablehnung: eine Rechnung, die noch CIUS-RO:1.0.0 deklariert. Beide Beispieldateien, die das Ministerium selbst veröffentlicht, tragen diesen toten Wert — und der eigene Validator des Ministeriums lehnt sie ab.
- Die CUI-Prüfung ist rein arithmetisch: Eine wohlgeformte, aber nicht existierende Nummer besteht die Validierung. Ein Bestehen hier heißt nicht, dass das Unternehmen existiert.
- Die anonyme B2C-Kennung 0000000000000 (dreizehn Nullen) ist legitim und darf nie abgelehnt werden — sie ist seit dem 16. Dezember 2024 im Produktivbetrieb.
- RO_CIUS deckt auch die CII-Syntax ab, doch das Ministerium veröffentlicht dafür weder ein Schematron noch einen Validator: Seine beiden offiziellen Werkzeuge akzeptieren ausschließlich UBL. Wir sagen das, statt ein Ergebnis zu simulieren, das wir nicht reproduzieren können.
Häufige Fragen
Warum lehnt ANAF meine Rechnung mit BR-RO-001 ab?
Weil BT-24 (CustomizationID) nicht den exakten Wert trägt, den RO_CIUS verlangt: urn:cen.eu:en16931:2017#compliant#urn:efactura.mfinante.ro:CIUS-RO:1.0.1. Der vorherige Wert, endend auf 1.0.0, wurde am 29. Dezember 2022 durch den Erlass OMF 4092/2022 zurückgezogen und wird abgelehnt. Es ist die mit Abstand häufigste Ablehnung — und die beiden auf mfinante.gov.ro veröffentlichten Beispielrechnungen tragen ihn noch immer.
Was bedeutet „CUI cumparator incorect“?
Dass die rumänische Steuernummer (CUI) des Käufers eine falsche Prüfziffer hat. Diese Prüfung ist nicht Teil des Schematrons: ANAF führt sie separat durch und meldet sie unter dem Code ERRIdentif — deshalb erklärt ein Validator, der nur das Schematron ausführt, die Rechnung für in Ordnung. Beachten Sie: Die Prüfung ist rein arithmetisch, ANAF prüft in dieser Phase nicht, ob das Unternehmen existiert, sondern nur, ob die Nummer wohlgeformt ist. Die entsprechenden Meldungen lauten „CUI vanzator incorect“ für den Verkäufer und „CNP sau NIF … incorect“, wenn die Kennung eine 13-stellige Personenkennziffer ist.
Meine Stadt ist Bukarest und die Rechnung wird abgelehnt (BR-RO-100). Warum?
Weil bei Land RO und Verwaltungseinheit (BT-39/BT-40) RO-B die Stadt (BT-37) einer der Werte SECTOR1, SECTOR2, SECTOR3, SECTOR4, SECTOR5, SECTOR6 sein muss — in Großbuchstaben, ohne Leerzeichen. Der Ministerialerlass selbst schreibt sie zwar „Sector 1“, „Sector 2“…, doch das Schematron, das ANAF tatsächlich ausführt, verlangt SECTOR1. Wenn Gesetzestext und Implementierung auseinandergehen, ist es die Implementierung, die Ihre Datei ablehnt.
Welche Rechnungsartcodes (BT-3) akzeptiert Rumänien?
Auf einer Invoice: 380 (Rechnung), 384 (korrigierte Rechnung), 389 (Gutschriftsverfahren) und 751 (Rechnung — Information für Buchhaltungszwecke). Der Code 381 (Gutschrift) wird nur auf einem CreditNote-Dokument akzeptiert, nie auf einer Invoice — der Text der Regel BR-RO-020 zählt alle fünf gemeinsam auf, was irreführend ist; ihr XPath tut das nicht.
Sendet dieses Tool meine Rechnung an ANAF?
Nein. Nichts verlässt Ihren Browser: Das XSD, das offizielle Schematron und die Identitätsprüfungen laufen lokal auf Ihrem Rechner. Das bedeutet zugleich, dass wir jene Prüfungen nicht durchführen können, die die Systeme der ANAF erfordern — Ihre Authentifizierung, das Steuerpflichtigenregister, die Übermittlungsfrist — und das Ergebnis listet sie ausdrücklich auf, statt sie zu verschweigen.
Kann ich hier eine CII-E-Rechnung (UN/CEFACT) validieren?
Nein, und das ist bewusst so. RO_CIUS deckt die CII-Syntax zwar ab, doch das Finanzministerium veröffentlicht dafür weder ein Schematron noch einen Validator: Beide offiziellen Werkzeuge — die Offline-Anwendung und der Webdienst /validare — akzeptieren ausschließlich UBL (FACT1 und FCN). Wir könnten das Urteil der ANAF zu einer CII-Datei nicht reproduzieren, also sagen wir das, statt eines zu erfinden. Nutzen Sie den UBL-/Peppol-Validator für die EN 16931-Regeln, oder wandeln Sie die Rechnung in UBL um.
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.