Eroare BR-RO-020 e-Factura: cod tip document invalid

Daca ai primit "Codul tipului documentului (BT-3) trebuie sa fie un cod valid din lista UNTDID 1001", problema este in elementul XML <cbc:InvoiceTypeCode>. Valoarea completata acolo nu se afla in lista de coduri acceptate de implementarea romaneasca a standardului CIUS-RO. Aceasta este una din erorile care apar frecvent cand software-ul de facturare este configurat gresit sau cand se incearca emiterea unui document de stornare cu codul de factura normala.

Ce inseamna eroarea BR-RO-020

Regula BR-RO-020 din CIUS-RO valideaza elementul BT-3, care in XML se gaseste ca <cbc:InvoiceTypeCode>. Acesta indica tipul documentului: factura normala, nota de credit, factura corectiva sau autofactura.

Lista internationala UNTDID 1001 contine zeci de coduri posibile. Romania, prin standardul CIUS-RO, a restrans lista la patru coduri valide. Orice alt cod declanseaza eroarea BR-RO-020.

Codurile acceptate in Romania sunt:

• 380 - Factura normala (Invoice)
• 381 - Nota de credit, factura de stornare (Credit note)
• 384 - Factura corectiva (Corrected invoice)
• 389 - Autofactura (Self-billed invoice)

De ce apare aceasta eroare

Sunt patru cauze principale.

1. Stornare trimisa cu codul 380. Cel mai frecvent caz. Documentul este o nota de credit (stornare), dar software-ul a completat InvoiceTypeCode cu 380 (factura normala). Stornarile trebuie sa foloseasca codul 381.

2. Cod personalizat sau inventat. Unele sisteme vechi de ERP folosesc coduri proprii de tipuri de documente (de exemplu: 100, 200, PROFORMA) care nu exista in lista UNTDID 1001. Aceste valori sunt respinse imediat.

3. Cod depreciat sau din versiune veche. Liste mai vechi de coduri UBL includeau coduri care au fost eliminate sau reclasificate. Daca software-ul nu a fost actualizat, poate folosi un cod care nu mai este valid.

4. Codul 383 (nota de debit). Nota de debit este un tip de document uzual in contabilitate, dar codul 383 nu face parte din lista CIUS-RO pentru Romania. Nu este permis. Daca trebuie sa emiti un document de majorare a valorii, foloseste o factura corectiva (384) sau o noua factura (380).

Exemplu XML

Elementul InvoiceTypeCode se gaseste in antetul documentului XML, imediat dupa identificatorul facturii.

XML incorect (cod 383, nota de debit, nepermis in Romania):

<!-- INCORECT: cod tip document invalid (383 nu este permis in Romania) -->
<cbc:InvoiceTypeCode>383</cbc:InvoiceTypeCode>

XML incorect (stornare trimisa cu codul 380):

<!-- INCORECT: stornare trimisa cu cod 380 in loc de 381 -->
<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>

XML corect pentru factura normala:

<!-- CORECT: factura normala -->
<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>

XML corect pentru stornare (nota de credit):

<!-- CORECT: factura de stornare (nota de credit) -->
<cbc:InvoiceTypeCode>381</cbc:InvoiceTypeCode>

XML corect pentru factura corectiva:

<!-- CORECT: factura corectiva -->
<cbc:InvoiceTypeCode>384</cbc:InvoiceTypeCode>

XML corect pentru autofactura:

<!-- CORECT: autofactura -->
<cbc:InvoiceTypeCode>389</cbc:InvoiceTypeCode>

Cum o rezolvi pas cu pas

1. Identifica ce tip de document incerci sa trimiti. Este o factura normala? O stornare? O corectie? Raspunsul determina codul corect.
2. Mapeaza tipul la codul CIUS-RO:
   • Factura normala sau proforma transformata in factura: 380
   • Stornare, anulare partiala sau totala, nota de credit: 381
   • Factura care corecteaza o alta factura anterioara: 384
   • Autofactura (emisa de cumparator in numele vanzatorului): 389
3. Actualizeaza elementul XML. Inlocuieste valoarea din <cbc:InvoiceTypeCode> cu codul corect din lista de mai sus.
4. Daca folosesti un ERP sau un software de facturare, verifica setarile de mapare a tipurilor de documente. Poate exista o configuratie explicita pentru "tip storno" sau "tip corectie" care trimite un cod gresit.
5. Retrimite factura dupa corectare.

Citeste si articolul despre eroarea BR-07 e-Factura pentru alte cauze frecvente de respingere la validarea cumparatorului.

Previne eroarea cu Billyou

Billyou selecteaza automat codul corect de tip document. Cand creezi o factura normala, sistemul completeaza InvoiceTypeCode cu 380. Cand emiti o stornare dintr-o factura existenta, foloseste automat codul 381. Nu exista posibilitatea de a trimite un cod invalid.

Daca folosesti Billyou API, poti specifica explicit tipul documentului prin parametrul invoiceTypeCode: 381 pentru note de credit. Daca nu il specifici, sistemul il deduce din contextul cererii. Documentatia completa este la billyou.ro/dev.

Citeste si eroarea BR-RO-100 si BR-RO-101 despre adresele Bucuresti, alta sursa frecventa de respingeri.

Intrebari frecvente

Pot folosi codul 383 pentru o nota de debit in Romania?

Nu. Codul 383 (Debit note) nu este inclus in lista de coduri valide din CIUS-RO pentru Romania. Daca trebuie sa majorezi valoarea unei facturi deja emise, emite o noua factura (380) cu diferenta, sau o factura corectiva (384) care inlocuieste documentul original.

O stornare trebuie sa aiba valorile negative in XML?

Nu neaparat. O nota de credit (cod 381) poate avea valori pozitive, cu conditia sa faca referire explicita la factura originala si sa specifice motivul reducerii. Cu toate acestea, practica uzuala in Romania este sa se foloseasca valori negative pentru claritate. Ambele variante sunt acceptate de ANAF daca codul BT-3 este 381.

Codul 384 difera de 381? Cand folosesc fiecare?

Codul 381 este pentru stornarile si notele de credit care reduc sau anuleaza o factura anterioara. Codul 384 este pentru facturile corective care inlocuiesc o factura anterioara cu una noua, corecta. In practica romaneasca, diferenta este adesea interpretata flexibil, dar CIUS-RO le defineste ca documente distincte.

Am primit BR-RO-020 si BR-07 in acelasi timp. In ce ordine le rezolv?

Rezolva intai BR-RO-020, deoarece un cod de tip document invalid face ca intreaga factura sa fie respinsa fara a fi procesata mai departe. Dupa ce codul este corect, ANAF va valida si celelalte campuri, inclusiv CUI-ul cumparatorului de la BR-07.