Line VAT amount is written with more than two decimal places
Reported asmore_than_two_decimalsmore than two decimal places
What is wrong
A cac:TaxTotal/cbc:TaxAmount on an invoice line has more than two characters after its first full stop, and ZATCA flags it under BR-KSA-DEC-03 as a warning, which does not by itself reject the document. The rule counts characters as they are written rather than judging the value, and nothing in it is normalised: a value with a trailing space after two decimals is three characters and fails, a value carrying two full stops fails, and a value with no full stop at all passes however large it is. An absent line VAT amount passes this rule too; its absence is a different rule's subject. Where you are likely to be reading this from is worth saying, because it will save you looking in the wrong place. EN 16931 applies the same two-decimal test to a tax amount whose currency attribute is the document currency or the tax currency, and those checks run in an earlier phase, so on an ordinary invoice they are raised first and this rule is never reached. What is left for it is a line VAT amount tagged with a currency that is neither of those two, which means the document you are holding is an unusual one. This rule is not gated by invoice type: a standard invoice is judged by it exactly as a simplified one is. Under rule packs before 2.0.0, on a simplified invoice, this rule and BR-KSA-50, which required the line VAT amount to equal the net amount times the rate, could be jointly impossible to satisfy for some line net amounts; SDK 3.4.8 removed BR-KSA-50.
What to check in your ERP
Start with the currency attribute on the line's cbc:TaxAmount, because a line VAT amount tagged in a currency other than the invoice's is what makes this rule reachable, and it is nearly always wrong on its own account - look for a currency taken from the item, the price list or the customer record instead of from the document. Then treat the decimals as a formatting setting rather than a calculation one: a decimal field serialised at its full stored precision prints every digit it holds unless the export formats it, and a locale or template fixing every number in the file to three places does the same. Format the amount to at most two decimals on the way out. 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.