Erori e-Factura

EN16931

Prea multe zecimale la baza de calcul a majorării de pe linie

Codul regulii este BR-DEC-28.

Mesajul exact din validatorul ANAF

textEroare=[BR-DEC-28]-The allowed maximum number of decimals for the Invoice line charge base amount (BT-142) is 2.
textEroare=[UBL-DT-01]-Amounts shall be decimal up to two fraction digits
textEroare= [BR-RO-Z2]-Numarul maxim permis de zecimale pentru Valoarea de baza a taxei suplimentare la linia facturii (BT-142) este 2. #The allowed maximum number of decimals for the Invoice line charge base amount (BT-142) is 2.

Ce înseamnă

Regula limitează la două zecimale baza de calcul a unei majorări (taxe) de pe linia facturii - BT-142, adică elementul cbc:BaseAmount din cac:AllowanceCharge cu cbc:ChargeIndicator true, aflat în interiorul liniei. Nu este vorba despre preț, ci despre valoarea pe care se calculează majorarea respectivă. Dacă programul scrie acolo 1000.005, fișierul este respins, deși sumele facturii sunt corecte: majorările de linie sunt doar informative în EN 16931, iar totalurile rămân calculate din cantitate × preț (1000,00 + 19% = 1190,00).

Cum repari

Setează la două zecimale câmpul în care programul scrie baza de calcul a majorării de linie și verifică la export că acolo ajunge valoarea rotunjită (1000.00), nu cea brută rezultată din calcule (1000.005). Nu umbla la suma majorării (BT-141) și nici la totalurile facturii, fiindcă regula se referă strict la baza de calcul.

Exemplu

Așa pică

<ubl:Invoice>
  <cac:InvoiceLine>
    <cbc:ID>1</cbc:ID>
    <cbc:InvoicedQuantity unitCode="H87">10</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="RON">1000.00</cbc:LineExtensionAmount>
    <cac:AllowanceCharge>
      <cbc:ChargeIndicator>true</cbc:ChargeIndicator>
      <cbc:AllowanceChargeReason>Transport</cbc:AllowanceChargeReason>
      <cbc:Amount currencyID="RON">100.00</cbc:Amount>
      <cbc:BaseAmount currencyID="RON">1000.005</cbc:BaseAmount>
    </cac:AllowanceCharge>
    <cac:Item>
      <cbc:Name>Serviciu de consultanta</cbc:Name>
      <cac:ClassifiedTaxCategory>
        <cbc:ID>S</cbc:ID>
        <cbc:Percent>19.00</cbc:Percent>
        <cac:TaxScheme>
          <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
      </cac:ClassifiedTaxCategory>
    </cac:Item>
  </cac:InvoiceLine>
</ubl:Invoice>

Așa trece

<ubl:Invoice>
  <cac:InvoiceLine>
    <cbc:ID>1</cbc:ID>
    <cbc:InvoicedQuantity unitCode="H87">10</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="RON">1000.00</cbc:LineExtensionAmount>
    <cac:AllowanceCharge>
      <cbc:ChargeIndicator>true</cbc:ChargeIndicator>
      <cbc:AllowanceChargeReason>Transport</cbc:AllowanceChargeReason>
      <cbc:Amount currencyID="RON">100.00</cbc:Amount>
      <cbc:BaseAmount currencyID="RON">1000.00</cbc:BaseAmount>
    </cac:AllowanceCharge>
    <cac:Item>
      <cbc:Name>Serviciu de consultanta</cbc:Name>
      <cac:ClassifiedTaxCategory>
        <cbc:ID>S</cbc:ID>
        <cbc:Percent>19.00</cbc:Percent>
        <cac:TaxScheme>
          <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
      </cac:ClassifiedTaxCategory>
    </cac:Item>
  </cac:InvoiceLine>
</ubl:Invoice>

Greșeala asta strică și alte verificări, deci în același răspuns vei găsi și: BR-DEC-RO-28, UBL-DT-01. Le repari pe toate odată cu asta.

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.
Regula așa cum e scrisă în schematronul oficial

Textul oficial, în engleză

The allowed maximum number of decimals for the Invoice line charge base amount (BT-142) is 2.

Unde se aplică

$Invoice_line_charges

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

$BR-DEC-28
Ce nu rezultă din textul oficial al regulii

Factura de referință nu are nicio reducere/majorare pe linie, deci grupul cac:AllowanceCharge (plasat înaintea lui cac:Item, după cbc:LineExtensionAmount) și valorile 100,00 / 1000,005 sunt exemplificate de mine, nu preluate din EA. Nu am putut confirma dacă validatorul numără zecimalele ca text sau numeric; am ales o valoare cu a treia zecimală nenulă, care pică în ambele variante.