`BR-DEC-01`Document level allowance amount is written with more than two decimal places

Mutabiq checks Saudi ZATCA Phase 2 e-invoice XML before you submit it: pre-validation against published ZATCA requirements, not an approval by the authority. This page explains one rule, BR-DEC-01.

Validate 5 invoices free

Five checks a month on the Free plan. The file is checked in memory and is never stored.

The message ZATCA prints

[BR-DEC-01]-The allowed maximum number of decimals for the Document level allowance amount (BT-92) is 2.

What Mutabiq reports

One entry for each way this rule can be reported.

Reported as: What kind of value was found — empty, not_15_digits and the like — never the value itself.

Document level allowance amount is written with more than two decimal places

Reported asmore_than_two_decimalsmore than two decimal places

What is wrong

The cbc:Amount of a document level allowance - BT-92, the discount that applies to the invoice as a whole rather than to any one line - carries more than two characters after its first full stop, and ZATCA flags it under EN 16931 rule BR-DEC-01 as a warning, which does not by itself reject the document. The rule counts the characters after the first full stop in the element's text rather than judging the value, so a third digit fails even when it is a nought, and a value written with no full stop at all passes however large it is. An absent or empty element passes as well. Scope is worth being precise about, because this element name appears in several places in a UBL invoice: the rule reads only an allowance that is a direct child of the invoice element and whose cbc:ChargeIndicator is false. A line's allowance was BR-DEC-24's subject, a rule SDK 3.4.8 no longer reaches, and an allowance sitting under cac:DeliveryTerms or inside a billing reference is read by neither. The base amount that sits beside this one in the same block, BT-93, is checked by BR-DEC-02, so the two are commonly reported together.

What to check in your ERP

A document level discount is computed rather than typed, and that is where the extra digits come from: a percentage applied to an order total rarely lands on a two-decimal figure, and the result is written out at whatever precision the decimal field holds. Round the discount where it is calculated rather than on the way out of the XML writer, because two other numbers have to agree with it - cbc:AllowanceTotalAmount sums the document allowances and cbc:TaxExclusiveAmount is computed net of them - and rounding only the printed copy leaves those sums a fraction out, which draws an arithmetic finding under BR-CO-11 or BR-CO-13 instead. Check also whether the discount is being carried in the currency of the order rather than the currency of the invoice, since a converted figure is the other common source of a long fraction in this element.

The clause that runs

Quoted from the validation-rule stylesheet ZATCA publishes, at the file and line named below. The executed guard is what the check runs; the reported test is what it prints when it fails, and the two are not always the same.

Executed guard

not(string-length(substring-after(cbc:Amount,'.'))<=2)

Reported test

string-length(substring-after(cbc:Amount,'.'))<=2

Evaluated against: /ubl:Invoice/cac:AllowanceCharge[cbc:ChargeIndicator = false()] | /cn:CreditNote/cac:AllowanceCharge[cbc:ChargeIndicator = false()]
Source: vendor/zatca/schematron/CEN-EN16931-UBL.xsl:220
As shipped in ZATCA SDK 3.4.8: the copy quoted here is, byte for byte, the file that release ships. The date in the file name is the name ZATCA gives the file; the rules in it are those of SDK 3.4.8.

A worked example

A synthetic document from the measured test corpus that trips this rule, shown where it differs from one that passed. Mutabiq's report names the class of the value, never the value itself.

Document: bad-85-document-allowance-amount-decimals.xml
Mutabiq's verdict: Passed
Reported as: more_than_two_decimalsmore than two decimal places

Download this example (.xml)Check it in Mutabiq

This page's example, checked by the same rules your own upload goes through. No upload and no sign-in.

Rules evaluated against the same part of the document. One wrong value often reports several of them at once.

Check an invoice

Check your own invoice