RO e-Factura Validator Romania
Descubra si ANAF rechazaría su factura — y con qué regla (BR-RO-001, BR-RO-100, ERRIdentif) — antes de enviarla al SPV.
¿Qué es RO e-Factura y por qué ANAF rechaza una factura?
RO e-Factura es el sistema rumano de facturación electrónica obligatoria: toda factura B2B pasa por la plataforma de ANAF (el SPV) desde el 1 de julio de 2024, y el B2C desde el 1 de enero de 2025. Una factura rechazada por la plataforma jurídicamente no ha sido emitida. El formato es RO_CIUS — una especificación nacional (CIUS) de la norma europea EN 16931, transportada en OASIS UBL 2.1 (factura = FACT1, nota de crédito = FCN). Este validador gratuito ejecuta las tres capas que ejecuta la propia ANAF, en el mismo orden: el XSD OASIS UBL 2.1; el Schematron OFICIAL CIUS-RO publicado por el Ministerio de Finanzas (ro16931-ubl-1.0.9, en vigor desde el 5 de junio de 2024), que contiene tanto las reglas del núcleo EN 16931 (BR-*, BR-CO-*) como las rumanas (BR-RO-001 para el CustomizationID, BR-RO-020 para el código de tipo de factura, BR-RO-100 para la grafía SECTOR1…SECTOR6 en Bucarest…); y el control de identidad fiscal que vive FUERA del Schematron y que la mayoría de las herramientas olvida — el dígito de control del CUI y el CNP, que ANAF rechaza con el código ERRIdentif. Todo se ejecuta en su navegador: la factura nunca sale de su equipo.
Acerca del validador RO e-Factura
RO e-Factura es el sistema obligatorio de facturación electrónica de Rumanía. Toda factura B2B pasa por la plataforma de clearing de la ANAF (el SPV) desde el 1 de julio de 2024, y toda factura B2C desde el 1 de enero de 2025. La plataforma acepta el archivo o lo rechaza — y una factura rechazada jurídicamente no es una factura. Así que la única pregunta que importa no es «¿está bien formado mi XML?», sino «¿lo aceptará la ANAF y, si no, por qué?». Esa es la pregunta que responde esta herramienta.
La responde ejecutando las tres capas que la propia ANAF ejecuta, en el mismo orden. Primero el XSD OASIS UBL 2.1 — el esquema detecta lo que ninguna regla de negocio ve, como un elemento en el orden equivocado, y la ANAF rechaza por eso antes que por nada más. Después el Schematron CIUS-RO OFICIAL publicado por el Ministerio de Finanzas (ro16931-ubl-1.0.9, en vigor desde el 5 de junio de 2024): no una reimplementación, sino el propio archivo del ministerio, compilado y ejecutado tal cual. Contiene las reglas troncales de la EN 16931 (BR-*, BR-CO-*) y las rumanas (BR-RO-*), y sus mensajes son exactamente los que el SPV le devolverá, palabra por palabra.
La tercera capa es la que casi todas las herramientas gratuitas omiten. El dígito de control del CUI (el número fiscal rumano) y del CNP (el número personal usado en B2C) NO forma parte del Schematron — la ANAF los verifica por separado y rechaza la factura bajo un código propio, ERRIdentif («CUI cumparator incorect», «CNP sau NIF vanzator incorect»). Un validador que solo ejecuta el Schematron declara, por tanto, válido un archivo que la ANAF rechazará. Nuestras reglas para estos dos identificadores se establecieron consultando el validador offline del Ministerio como oráculo — los algoritmos no están publicados en ninguna parte — y codifican lo que realmente hace: un CNP no solo debe superar su suma de control, sino que su fecha de nacimiento codificada debe existir (un 31 de abril se rechaza), mientras que un NIF (que empieza por 9) no lleva fecha alguna y queda exento de esa prueba.
Puntos clave
- Un veredicto verde aquí significa que el ARCHIVO está limpio. El SPV comprueba además quién lo deposita, si las partes están registradas y si está dentro del plazo (5 días hábiles desde el 1 de enero de 2026) — eso exige los sistemas de la ANAF y figura explícitamente en el resultado.
- BR-RO-001 es el rechazo más frecuente: una factura que sigue declarando CIUS-RO:1.0.0. Los dos archivos de ejemplo que publica el propio Ministerio llevan ese valor muerto — y el propio validador del Ministerio los rechaza.
- El control del CUI es puramente aritmético: un número bien formado pero inexistente supera la validación. Pasar aquí no significa que la empresa exista.
- El identificador B2C anónimo 0000000000000 (trece ceros) es legítimo y nunca debe rechazarse — está en producción desde el 16 de diciembre de 2024.
- RO_CIUS también cubre la sintaxis CII, pero el Ministerio no publica ni Schematron ni validador para ella: sus dos herramientas oficiales solo aceptan UBL. Lo decimos en lugar de simular un veredicto que no podemos reproducir.
Preguntas frecuentes
¿Por qué la ANAF rechaza mi factura con BR-RO-001?
Porque BT-24 (CustomizationID) no lleva el valor exacto que exige RO_CIUS: urn:cen.eu:en16931:2017#compliant#urn:efactura.mfinante.ro:CIUS-RO:1.0.1. El valor anterior, terminado en 1.0.0, fue retirado el 29 de diciembre de 2022 por la orden OMF 4092/2022 y se rechaza. Es, con diferencia, el rechazo más frecuente — y las dos facturas de ejemplo publicadas en mfinante.gov.ro siguen llevándolo.
¿Qué significa «CUI cumparator incorect»?
Significa que el número fiscal rumano (CUI) del comprador tiene un dígito de control erróneo. Este control no forma parte del Schematron: la ANAF lo ejecuta por separado y lo notifica bajo el código ERRIdentif — por eso un validador que solo ejecuta el Schematron le dirá que la factura está bien. Tenga en cuenta que el control es puramente aritmético: la ANAF no verifica en esta fase que la empresa exista, solo que el número esté bien formado. Los mensajes equivalentes son «CUI vanzator incorect» para el vendedor y «CNP sau NIF … incorect» cuando el identificador es un número personal de 13 dígitos.
Mi ciudad es Bucarest y la factura se rechaza (BR-RO-100). ¿Por qué?
Porque cuando el país es RO y la subdivisión (BT-39/BT-40) es RO-B, la ciudad (BT-37) debe ser una de SECTOR1, SECTOR2, SECTOR3, SECTOR4, SECTOR5, SECTOR6 — en mayúsculas, sin espacio. La propia orden ministerial las escribe «Sector 1», «Sector 2»…, pero el Schematron que la ANAF ejecuta realmente exige SECTOR1. Cuando el texto de la ley y la implementación no coinciden, es la implementación la que rechaza su archivo.
¿Qué códigos de tipo de factura (BT-3) acepta Rumanía?
En una Invoice: 380 (factura), 384 (factura rectificativa), 389 (autofacturación) y 751 (factura — información con fines contables). El código 381 (abono) solo se acepta en un documento CreditNote, nunca en una Invoice — el texto de la regla BR-RO-020 enumera los cinco juntos, lo que induce a error; su XPath no lo hace.
¿Esta herramienta envía mi factura a la ANAF?
No. Nada sale de su navegador: el XSD, el Schematron oficial y los controles de identidad se ejecutan localmente, en su máquina. Eso también significa que no podemos realizar los controles que requieren los sistemas de la ANAF — su autenticación, el registro de contribuyentes, el plazo de transmisión — y el resultado los enumera explícitamente en lugar de pasarlos por alto.
¿Puedo validar aquí una factura electrónica CII (UN/CEFACT)?
No, y es deliberado. RO_CIUS sí cubre la sintaxis CII, pero el Ministerio de Finanzas no publica ni Schematron ni validador para ella: sus dos herramientas oficiales — la aplicación offline y el servicio web /validare — solo aceptan UBL (FACT1 y FCN). No podríamos reproducir el veredicto de la ANAF sobre un archivo CII, así que lo decimos en lugar de inventarlo. Use el validador UBL/Peppol para las reglas EN 16931, o convierta la factura a 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.