Invoice type not allowed in e-Factura
Romanian e-Factura only allows the following credit note type codes (BT-3): 380 (invoice), 389 (self-billed invoice), 384 (corrected invoice), 381 (credit note) and 751 (invoice for accounting purposes only). Prepayment or partial invoices (386, 326) do not exist there.
What to do now
Who has to fix this?
The issuer of the invoice has to fix this: the detail is missing or has the wrong form. The e-Factura portal rejects an invoice with a violation – in Romania it is then considered not issued.
Where this rule comes from
This rule does not come from EN 16931 itself but from CIUS-RO, the Romanian national specification. It applies to every invoice that passes through e-Factura, the state system of the tax administration ANAF – mandatory in Romania for invoices between businesses and to public authorities. Many of these rules limit the length of text fields or require details in a specific form, such as the county as a code.
- Rule ID
- BR-RO-020_2
- Rule set
- e-Factura (Romanian CIUS)
- Checked for
- e-Factura (RO CIUS)
- Consequence of a violation
- The invoice is considered non-compliant with the standard and is automatically rejected by many recipients.
Does BR-RO-020_2 occur in your invoice?
Upload the XRechnung or the ZUGFeRD/Factur-X PDF – the validator shows every violation with the same explanation as here. Free, no login, nothing stored.
Validate your invoice nowGeneral information, not tax or legal advice. As of October 2026. Validation rules: CEN/TC 434 (EN 16931, EUPL 1.2), KoSIT (XRechnung, Apache 2.0), FNFE-MPE/FeRD (Factur-X/ZUGFeRD, Apache 2.0), OpenPeppol AISBL (Peppol BIS), ANAF (CIUS-RO). Explanations: Billvox. Licence notices