RO e-Factura Validator Romania
Saiba se a ANAF rejeitaria a sua fatura — e com que regra (BR-RO-001, BR-RO-100, ERRIdentif) — antes de a enviar para o SPV.
O que é a RO e-Factura e porque é que a ANAF rejeita uma fatura?
A RO e-Factura é o sistema romeno de faturação eletrónica obrigatória: todas as faturas B2B passam pela plataforma da ANAF (o SPV) desde 1 de julho de 2024, e o B2C desde 1 de janeiro de 2025. Uma fatura rejeitada pela plataforma não foi juridicamente emitida. O formato é o RO_CIUS — uma especificação nacional (CIUS) da norma europeia EN 16931, transportada em OASIS UBL 2.1 (fatura = FACT1, nota de crédito = FCN). Este validador gratuito executa as três camadas que a própria ANAF executa, pela mesma ordem: o XSD OASIS UBL 2.1; o Schematron OFICIAL CIUS-RO publicado pelo Ministério das Finanças (ro16931-ubl-1.0.9, em vigor desde 5 de junho de 2024), que contém tanto as regras do núcleo EN 16931 (BR-*, BR-CO-*) como as romenas (BR-RO-001 para o CustomizationID, BR-RO-020 para o código de tipo de fatura, BR-RO-100 para a grafia SECTOR1…SECTOR6 em Bucareste…); e o controlo de identidade fiscal que vive FORA do Schematron e que a maioria das ferramentas esquece — o dígito de controlo do CUI e o CNP, que a ANAF rejeita com o código ERRIdentif. Tudo corre no seu navegador: a fatura nunca sai do seu dispositivo.
Sobre o validador RO e-Factura
O RO e-Factura é o sistema obrigatório de faturação eletrónica da Roménia. Todas as faturas B2B passam pela plataforma de clearing da ANAF (o SPV) desde 1 de julho de 2024, e todas as faturas B2C desde 1 de janeiro de 2025. A plataforma aceita o ficheiro ou rejeita-o — e uma fatura rejeitada juridicamente não é uma fatura. A única pergunta que importa não é, portanto, «o meu XML está bem formado?», mas «a ANAF vai aceitá-lo e, se não, porquê?». É a essa pergunta que esta ferramenta responde.
Responde executando as três camadas que a própria ANAF executa, pela mesma ordem. Primeiro o XSD OASIS UBL 2.1 — o esquema apanha aquilo que nenhuma regra de negócio consegue ver, como um elemento na ordem errada, e a ANAF rejeita nesse ponto antes de tudo o resto. Depois o Schematron CIUS-RO OFICIAL publicado pelo Ministério das Finanças (ro16931-ubl-1.0.9, em vigor desde 5 de junho de 2024): não uma reimplementação, mas o próprio ficheiro do ministério, compilado e executado tal como está. Contém as regras nucleares da EN 16931 (BR-*, BR-CO-*) e as romenas (BR-RO-*), e as suas mensagens são exatamente as que o SPV lhe devolverá, palavra por palavra.
A terceira camada é aquela que quase todas as ferramentas gratuitas ignoram. O dígito de controlo do CUI (o número fiscal romeno) e do CNP (o número pessoal usado em B2C) NÃO faz parte do Schematron — a ANAF verifica-os separadamente e rejeita a fatura sob um código próprio, ERRIdentif («CUI cumparator incorect», «CNP sau NIF vanzator incorect»). Um validador que apenas execute o Schematron declara assim válido um ficheiro que a ANAF vai recusar. As nossas regras para estes dois identificadores foram estabelecidas interrogando o validador offline do Ministério como oráculo — os algoritmos não estão publicados em lado nenhum — e codificam o que ele realmente faz: um CNP não só tem de passar a sua soma de controlo, como a data de nascimento nele codificada tem de existir (um 31 de abril é recusado), ao passo que um NIF (começado por 9) não contém qualquer data e está isento desse teste.
A reter
- Um veredicto verde aqui significa que o FICHEIRO está limpo. O SPV verifica ainda quem o deposita, se as partes estão registadas e se está dentro do prazo (5 dias úteis desde 1 de janeiro de 2026) — isso exige os sistemas da ANAF e é indicado explicitamente no resultado.
- BR-RO-001 é a rejeição mais frequente: uma fatura que ainda declara CIUS-RO:1.0.0. Os dois ficheiros de exemplo publicados pelo próprio Ministério contêm esse valor morto — e o validador do próprio Ministério rejeita-os.
- O controlo do CUI é puramente aritmético: um número bem formado mas inexistente passa a validação. Passar aqui não significa que a empresa exista.
- O identificador B2C anónimo 0000000000000 (treze zeros) é legítimo e nunca deve ser rejeitado — está em produção desde 16 de dezembro de 2024.
- O RO_CIUS também cobre a sintaxe CII, mas o Ministério não publica para ela nem Schematron nem validador: as suas duas ferramentas oficiais só aceitam UBL. Dizemo-lo, em vez de simular um veredicto que não conseguimos reproduzir.
Perguntas frequentes
Porque é que a ANAF rejeita a minha fatura com BR-RO-001?
Porque o BT-24 (CustomizationID) não contém o valor exato que o RO_CIUS exige: urn:cen.eu:en16931:2017#compliant#urn:efactura.mfinante.ro:CIUS-RO:1.0.1. O valor anterior, terminado em 1.0.0, foi retirado a 29 de dezembro de 2022 pela portaria OMF 4092/2022 e é recusado. É de longe a rejeição mais frequente — e as duas faturas de exemplo publicadas em mfinante.gov.ro ainda o contêm.
O que significa «CUI cumparator incorect»?
Significa que o número fiscal romeno (CUI) do comprador tem um dígito de controlo errado. Este controlo não faz parte do Schematron: a ANAF executa-o separadamente e reporta-o sob o código ERRIdentif — é por isso que um validador que só execute o Schematron lhe dirá que a fatura está correta. Note-se que o controlo é puramente aritmético: nesta fase a ANAF não verifica se a empresa existe, apenas se o número está bem formado. As mensagens equivalentes são «CUI vanzator incorect» para o vendedor e «CNP sau NIF … incorect» quando o identificador é um número pessoal de 13 dígitos.
A minha cidade é Bucareste e a fatura é rejeitada (BR-RO-100). Porquê?
Porque quando o país é RO e a subdivisão (BT-39/BT-40) é RO-B, a cidade (BT-37) tem de ser uma de SECTOR1, SECTOR2, SECTOR3, SECTOR4, SECTOR5, SECTOR6 — em maiúsculas, sem espaço. A própria portaria ministerial escreve-as «Sector 1», «Sector 2»…, mas o Schematron que a ANAF realmente executa exige SECTOR1. Quando o texto da lei e a implementação divergem, é a implementação que rejeita o seu ficheiro.
Que códigos de tipo de fatura (BT-3) aceita a Roménia?
Numa Invoice: 380 (fatura), 384 (fatura retificativa), 389 (autofaturação) e 751 (fatura — informação para fins contabilísticos). O código 381 (nota de crédito) só é aceite num documento CreditNote, nunca numa Invoice — o texto da regra BR-RO-020 enumera os cinco em conjunto, o que induz em erro; o seu XPath não o faz.
Esta ferramenta envia a minha fatura à ANAF?
Não. Nada sai do seu navegador: o XSD, o Schematron oficial e os controlos de identidade são executados localmente, na sua máquina. Isso significa também que não podemos efetuar os controlos que exigem os sistemas da ANAF — a sua autenticação, o registo de contribuintes, o prazo de transmissão — e o resultado enumera-os explicitamente em vez de os omitir.
Posso validar aqui uma fatura eletrónica CII (UN/CEFACT)?
Não, e é deliberado. O RO_CIUS cobre efetivamente a sintaxe CII, mas o Ministério das Finanças não publica para ela nem Schematron nem validador: as suas duas ferramentas oficiais — a aplicação offline e o serviço web /validare — só aceitam UBL (FACT1 e FCN). Não conseguiríamos reproduzir o veredicto da ANAF sobre um ficheiro CII, por isso dizemo-lo em vez de o inventar. Use o validador UBL/Peppol para as regras EN 16931, ou converta a fatura para 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.