`BR-KSA-DEC-04`Line amount with VAT 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-KSA-DEC-04.

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-KSA-DEC-04]-Amount with VAT at line level (KSA-12) must have a maximum two decimals.

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.

Line amount with VAT is written with more than two decimal places

Reported asmore_than_two_decimalsmore than two decimal places

What is wrong

The cbc:RoundingAmount inside a line's cac:TaxTotal - KSA-12, the line's amount including VAT - carries more than two characters after its first full stop, and ZATCA flags it under its rule BR-KSA-DEC-04 as a warning, which does not by itself reject the document. The element name is the trap here and is worth stating plainly: at line level cbc:RoundingAmount does not hold a rounding adjustment, it holds the line net amount plus the line's VAT, which is the figure a customer recognises. 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 this rule, though a simplified invoice must carry the element for a different reason, under BR-KSA-51. This is a ZATCA rule rather than an EN 16931 one, and no EN rule reads this element, so unlike most of the two-decimal findings it can arrive on its own with the rest of the document clean. It shares a template with the line VAT amount check under BR-KSA-DEC-03, and both are evaluated for every line, so one badly formatted line can draw both; under rule packs before 2.0.0 the item net price check under BR-KSA-DEC-05, which SDK 3.4.8 removed, shared that template too.

What to check in your ERP

This figure is the line net plus the line VAT, so it inherits the precision of both: round each of those to two decimals and add the rounded values rather than adding first and rounding the sum, which is also what BR-KSA-51 needs, since that rule compares this element against those same two. Because the element is not what its name suggests, check the mapping before the formatting: an ERP that writes a genuine rounding difference into it is writing the wrong number entirely, and the place for a rounding difference on what the customer pays is cbc:PayableRoundingAmount in the document totals block. Removing the element is not a way out on a simplified invoice, where it is required. 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(cac:TaxTotal/cbc:RoundingAmount,'.'))<=2)

Reported test

string-length(substring-after(cac:TaxTotal/cbc:RoundingAmount,'.'))<=2

Evaluated against: cac:InvoiceLine
Source: vendor/zatca/schematron/20210819_ZATCA_E-invoice_Validation_Rules.xsl:2400
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-99-line-amount-with-vat-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