Erori e-Factura

CIUS-RO

Cod factură invalid: ANAF acceptă doar 380, 384, 389 sau 751

Codul regulii este BR-RO-020_1. În răspunsul de la ANAF vezi însă BR-RO-020: eticheta din mesaj nu coincide cu identificatorul regulii. Nu căuta după codul regulii, ci după textul mesajului.

Mesajul exact din validatorul ANAF

textEroare=[BR-RO-020]-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).

Ce înseamnă

În răspunsul ANAF eroarea apare sub etichetă [BR-RO-020], nu sub id-ul intern al regulii, pentru că acolo e afișată în lista de erori. Regula spune că elementul cbc:InvoiceTypeCode (BT-3) poate conține doar unul dintre codurile 380 (factură), 384 (factură corectată), 389 (autofactură) sau 751 (factură cu informații în scopuri contabile). Orice alt cod — inclusiv unul valid în alte liste de coduri sau un text de tipul "FACTURA" — face factura să fie respinsă la validare, chiar dacă restul documentului este corect.

Cum repari

În programul de facturare, caută câmpul "tip document" / "tip factură" din antetul facturii și setează-l pe 380 pentru o factură obișnuită. Verifică tabelul de mapare dintre tipurile interne de documente și codurile UNTDID 1001: dacă acolo există valori proprii (de exemplu "factură fiscală", "tax invoice" sau coduri numerice de 3 cifre care nu sunt în lista de mai sus), înlocuiește-le cu 380 sau 384.

Exemplu

Așa pică

<ubl:Invoice xmlns:ubl="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
             xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
  <cbc:InvoiceTypeCode>388</cbc:InvoiceTypeCode>
</ubl:Invoice>

Așa trece

<ubl:Invoice xmlns:ubl="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
             xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
</ubl:Invoice>
Verificat. Am pus fiecare din cele două fragmente într-o factură completă și le-am trecut prin validatorul oficial ANAF, versiunea ro16931-ubl-1.0.9. Factura cu fragmentul din stânga a fost respinsă cu exact mesajul de mai sus; cea cu fragmentul din dreapta a trecut fără nicio eroare. Verificarea s-a făcut pe 14.09.2026.

Alte reguli pe care ANAF le raportează tot ca BR-RO-020

Regula așa cum e scrisă în schematronul oficial

Textul oficial, în română

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)

Textul oficial, în engleză

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).

Unde se aplică

cbc:InvoiceTypeCode

Condiția care trebuie să fie adevărată

(. and ((not(contains(normalize-space(.), ' ')) and contains(' 380 384 389 751 ', concat(' ', normalize-space(.), ' ')))))
Ce nu rezultă din textul oficial al regulii

Textul oficial în română și cel în engleză enumeră și codul 381 (Notă de creditare), dar lista din testul XPath al regulii BR-RO-020_1 conține doar 380, 384, 389 și 751. Nu pot confirma din datele primite dacă 381 trece sau nu de validatorul ANAF; pentru notele de creditare verifică separat în validator. De asemenea, nu am confirmat ce semnificație are codul 388 în UNTDID 1001, l-am folosit doar ca exemplu de cod care nu apare în lista acceptată.