Wednesday, August 26, 2026
1 change · 17.0
Resolved issues and error corrections
Saudi e-invoices in SAR now keep the required second tax total entry so they match ZATCA validation rules. This prevents compliant invoices from being rejected when the invoice and tax currency are both SAR.
Original PR description
This reverts commit 77280860a3a3557619ac13c853c37a66e9d19f2e. The reverted commit removed the second cac:TaxTotal node (in company currency, without tax subtotals) whenever the invoice currency…
This reverts commit 77280860a3a3557619ac13c853c37a66e9d19f2e. The reverted commit removed the second cac:TaxTotal node (in company currency, without tax subtotals) whenever the invoice currency matched the company currency (SAR), based on the assumption that it was an optional node only needed for foreign-currency invoices. This is wrong. Business rule BR-KSA-EN16931-09 is currency-agnostic: it requires exactly one TaxTotal without subtotals whenever cbc:TaxCurrencyCode is present in the document, regardless of whether the document and tax currencies match. Since l10n_sa_edi always sets TaxCurrencyCode, the second TaxTotal node is always required, even when both TaxTotal amounts end up identical (which is normal and expected for a same-currency invoice). ZATCA's own official "Standard Invoice" sample confirms this: a plain SAR invoice (DocumentCurrencyCode = TaxCurrencyCode = SAR) contains two TaxTotal nodes with the same TaxAmount. After the reverted commit was deployed, ZATCA started returning: [202] BR-KSA-EN16931-09 : Only one tax total (BG-22) without tax subtotals (BG-23) must be provided when tax currency code is provided. opw-6409881