A VAT amount in the accounting 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 tax currency code the document declares in cbc:TaxCurrencyCode, carries more than two characters after its first full stop, and ZATCA flags it under EN 16931 rule BR-DEC-15 as a warning, which does not by itself reject the document. The element the message names is BT-111, the invoice total VAT amount restated in the currency the seller keeps books in. Two things follow that are worth knowing before you go looking. First, if the document declares no tax currency at all, this rule's pattern matches nothing and it cannot fire, so seeing it means a tax currency is declared somewhere in the file. Second, on a Saudi invoice the tax currency is usually the same code as the document currency, in which case a single element satisfies both this pattern and BR-DEC-13's and the two rules are raised together over one figure - two findings, one defect. And as with BR-DEC-13, the pattern is not anchored to the top of the document: a cac:TaxTotal inside a cac:InvoiceLine is matched too, so a line VAT amount with three decimals is reported here even though the message names an invoice total. 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.
What to check in your ERP
Start by establishing which of the two figures you are looking at, because the fix differs. If the tax currency and the document currency are the same code, this is the defect BR-DEC-13 describes and the fix is the one given there: round each line's VAT once and sum the rounded values. If the two currencies genuinely differ, the accounting-currency amount is a converted figure and the conversion is what produces the long fraction, since a rate carrying four or six decimals applied to a two-decimal amount almost never lands on two. Round after converting, and convert the total rather than converting a figure that was already rounded elsewhere, so that what you print is what your ledger holds. Check as well that the currencyID attribute on each amount is the one you intend: an amount tagged with the tax currency by a template that hard-codes it is a common way for an ordinary figure to end up under this rule.