`BR-DEC-13`A VAT amount in the document currency 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-13.

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-13]-The allowed maximum number of decimals for the Invoice total VAT amount (BT-110) 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.

A VAT amount in the document currency is written with more than two decimal places

Reported asmore_than_two_decimalsmore than two decimal places

What is wrong

A cbc:TaxAmount whose parent is a cac:TaxTotal block, and whose currencyID attribute matches the document's currency code, carries more than two characters after its first full stop, and ZATCA flags it under EN 16931 rule BR-DEC-13 as a warning, which does not by itself reject the document. The rule's own message names BT-110, the invoice total VAT amount, and that is usually what it means - but the pattern it matches with is not anchored to the top of the document. It selects a tax amount by its parent alone, so a cac:TaxTotal that sits inside a cac:InvoiceLine is matched exactly as the document's own is, and a line's VAT amount with three decimals is reported under this rule, and under BR-DEC-15 as well. That is measured rather than assumed: a line VAT amount of 15.000 on an invoice in Saudi riyals draws both. So look at the lines before concluding that the header total is at fault. 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. One element it does not reach is the VAT breakdown's own tax amount in cac:TaxSubtotal, whose parent is the breakdown rather than the total; that one belongs to BR-DEC-20.

What to check in your ERP

VAT is a rate applied to a base, and fifteen per cent of an ordinary amount is very often not a two-decimal figure, so this is a rounding policy question rather than a formatting one. Decide where the rounding happens and do it once: round each line's VAT amount to two decimals, then sum the rounded values into the VAT breakdown and into the header total, which is also the order BR-CO-14 needs. If the header total looks right on screen, the defect is on a line - go through the cac:TaxTotal inside each cac:InvoiceLine, because that copy is written directly by the tax engine and is the one least likely to pass through the totals routine that formats the header. Check as well that your XML writer is not indenting inside the element, because a line break and the spaces after it are characters in the element's text and count toward the limit.

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(.,'.'))<=2))

Reported test

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

Evaluated against: ubl:Invoice/cac:TaxTotal/cbc:TaxAmount[@currencyID = //cbc:DocumentCurrencyCode]
Source: vendor/zatca/schematron/CEN-EN16931-UBL.xsl:1746
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.

Where it differs from a document that passed

This example
A document that passed

 <cbc:InvoiceTypeCode name="0100000">388</cbc:InvoiceTypeCode> <cbc:DocumentCurrencyCode>SAR</cbc:DocumentCurrencyCode>+A document that passed: <cbc:TaxCurrencyCode>SAR</cbc:TaxCurrencyCode> <cac:AdditionalDocumentReference>   <cbc:ID>ICV</cbc:ID>⋯ </cac:PaymentMeans> <cac:TaxTotal>−This example:   <cbc:TaxAmount currencyID="SAR">15.000</cbc:TaxAmount>+A document that passed:   <cbc:TaxAmount currencyID="SAR">15.00</cbc:TaxAmount>   <cac:TaxSubtotal>     <cbc:TaxableAmount currencyID="SAR">100.00</cbc:TaxableAmount>

Document: bad-84-total-vat-decimals-no-tax-currency.xml
Mutabiq's verdict: Not 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.

ERP guides

Product names identify the systems only. Mutabiq is independent of their vendors and is not affiliated with or endorsed by any of them.

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