Skip to content

Fatal

BR-RO-020_2: A credit note must have the type code 381

In short

Fatal: fails the selected checks.

BR-RO-020_2 means the type code of a credit note is not 381. Fix it by setting the type code of the credit note (BT-3) to 381.

On this page

What it means

In a credit note document, the type code (BT-3) must be exactly 381 (credit note). The official text lists several codes for BT-3, but for a credit note document the test accepts only 381.

Why it matters

The type code tells the recipient what kind of document this is.

How to fix it

In your invoicing software, check the document type of the file. If it is a credit note, make sure it is created as a credit note and set its type code to 381. If you build the XML yourself, put 381 in cbc:CreditNoteTypeCode. If you intended an invoice instead, use the UBL Invoice format with the appropriate cbc:InvoiceTypeCode from 380, 384, 389 or 751, as checked by BR-RO-020_1.

Once the file is corrected, check it again for free: Check an e-invoice

Or fix the invoice in a form and download the corrected file, for 1 credit: Fix a rejected e-invoice Beta

The rule as published

Codul tipului facturii (BT-3) trebuie sa fie unul dintre urmatoarele coduri din lista de coduri UNTDID 1001: 380 (Factura), 389 (Autofactura), 384 (Factura corectata), 381 (Nota de creditare), 751 (Factura - informatii în scopuri contabile). ( = ' … ') #The invoice type code (BT-3) must be one of the following codes in the UNTDID 1001 code list: 380 (Invoice), 389 (Self-invoice), 384 (Corrected invoice), 381 (Credit note), 751 (Invoice - information for accounting purposes).

Business terms: BT-3

Where this rule applies

Rule set Version
CIUS-RO UBL Invoice 1.0.9 1.0.9
CIUS-RO UBL Credit Note 1.0.9 1.0.9
Rule text from phive-rules 4.6.4.

Check your file

Drop your e-invoice to see whether BR-RO-020_2 still fails, and which other rules do.

Updated 7 November 2026