Fix: ZATCA validation BR-CO-15 by adding custom_grand_total_without_rounding

[alaalsalam]

Summary

This pull request resolves the ZATCA validation error:

[BR-CO-15] - Invoice total amount with VAT (BT-112) must equal the sum of total without VAT (BT-109) and total VAT (BT-110)

Problem

ERPNext/Frappe by default applies rounding to the grand total amount (grand_total), which can lead to mismatch with ZATCA's expected precise values in the XML (UBL 2.1), especially in fields BT-109 + BT-110 ≠ BT-112.

Solution

A new custom field was added to Sales Invoice:

• Fieldname: custom_grand_total_without_rounding
• Label: Grand Total (Without Rounding)
• Purpose: Stores the exact computed total (without any system rounding)
• This value is now used when generating the UBL XML and reporting to ZATCA

Impact

✅ Fixes the BR-CO-15 error
✅ Ensures mathematical consistency in reported invoices
✅ Does not affect standard UI behavior or printed totals
✅ Transparent to end users

[mhaggag]

Hello, and thank you for your contribution. Before I review it from a technical standpoint, I'd like @omarashrafsarhan to discuss the business side of things. Am I correct in understanding that this new custom grand total field is used in both printed invoices and reporting to ZATCA? That is, it is considered the actual amount that customers actually pay. Or is that still the regular grand total?

[omarashrafsarhan]

@alaalsalam
Hello, thank you for your contribution.

The rounding issue may occur in several scenarios, such as with the 'Total taxes and charges' and sum of "Invoice line tax amounts. Could you clarify how this fix addresses those cases?

Additionally, will this workaround be suitable for instances involving tax rates of 15% and 0% in the same invoice.

[mhaggag]

I have set up a test instance containing frappe, erpnext, and ksa_compliance from Ala's fork and branch.

• @omarashrafsarhan The credentials are available on Bitwarden under the Test collection
• @alaalsalam I will share a Bitwarden Send with you through email so that you can access the instance as well.

I onboarded the sandbox environment and tried an example invoice without any rounding involved (10000 SAR, 11500 with VAT), but it failed validation for me with BR-CO-15:
Sales Invoice
Error Log

[alaalsalam]

Hi @mhaggag @omarashrafsarhan 👋

I'd like to first clarify the core issue this PR addresses.

⚠️ Root Cause

In ERPNext, even when rounding is disabled in the Sales Invoice settings, the system still applies rounding to the Grand Total (i.e., grand_total, which maps to BT-112 in ZATCA's XML). This behavior persists due to internal design logic and is known to cause BR-CO-15 validation failures.

ERPNext rounds the total after tax calculation — which often results in a mismatch with:

BT-112 ≠ BT-109 + BT-110

I understand this might be addressed in future ERPNext updates, but at the moment, it can result in false positives on valid invoices when reported to ZATCA.

---

✅ Why This Fix?

Rather than modifying ERPNext’s core behavior or overriding how grand_total is computed, I introduced a non-intrusive solution:

• A new custom field: custom_grand_total_without_rounding
• This field is calculated manually as:

Does it work with mixed tax rates (15% and 0%)?
Yes.

[alaalsalam]

Hi @mhaggag 👋

After reviewing the test XML, I found that the issue was not with the underlying calculation — it was due to the fact that the XML template still used invoice.grand_total for the cbc:TaxInclusiveAmount (BT-112).

As discussed earlier, ERPNext applies internal rounding to grand_total, which sometimes results in minor mismatches between:

✅ The Fix
I updated the XML template to instead use:

❌
<cbc:TaxInclusiveAmount currencyID="{{ invoice.currency_code }}">{{ rounded(invoice.grand_total, 2) }}</cbc:TaxInclusiveAmount>

✅
<cbc:TaxInclusiveAmount currencyID="{{ invoice.currency_code }}">{{ rounded(invoice.custom_grand_total_without_rounding, 2) }}</cbc:TaxInclusiveAmount>

[mhaggag]

Is this ready for review/testing, or are you still working on further fixes?