Erori e-Factura

CIUS-RO

Codul tipului facturii trebuie să fie 380, 389, 384, 381 sau 751

Codul regulii este BR-RO-020_2. Î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ă

ANAF afișează regula sub eticheta [BR-RO-020] (în schematron este varianta _2, cea care verifică codul din nota de creditare), nu sub id-ul BR-RO-020_2, așa că mesajul de respingere îl vei găsi doar după eticheta scurtă. Regula limitează codul tipului de document (BT-3) la cinci coduri din lista UNTDID 1001: 380 (Factura), 389 (Autofactura), 384 (Factura corectată), 381 (Nota de creditare) și 751 (Factură — informații în scopuri contabile). Orice alt cod din UNTDID 1001, de pildă 383 (notă de debit), este respins, chiar dacă restul facturii este perfect. Într-o factură XML codul stă în cbc:InvoiceTypeCode, iar valoarea 381 este valabilă doar în cbc:CreditNoteTypeCode, adică în nota de creditare.

Cum repari

Verifică în programul de facturare tipul de document selectat pentru factura respinsă și pune-l pe Factură (cod 380). Dacă documentul este într-adevăr o notă de creditare, codul corect este 381 și se emite ca document de tip credit note, nu ca factură. Nu edita manual fișierul XML: schimbă tipul în datele facturii și regenerează fișierul, ca să rămână sincron cu restul datelor.

Exemplu

Așa pică

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

Așa trece

<Invoice xmlns="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>
</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). ({element} = '{valoare}')

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:CreditNoteTypeCode

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

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

Contextul oficial al variantei _2 este cbc:CreditNoteTypeCode, element care nu există în factura de referință (document de tip Invoice, care folosește cbc:InvoiceTypeCode); am presupus că pentru factura respinsă elementul vizat este cbc:InvoiceTypeCode. Valoarea 383 folosită ca exemplu greșit este un cod real UNTDID 1001 (notă de debit), nu un cod inventat, dar nu am putut confirma din datele primite că exact această valoare a apărut în fișierul respins.