BR-KSA-EN16931-06A charge is written on an invoice line's price
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-EN16931-06.
Five checks a month on the Free plan. The file is checked in memory and is never stored.
The message ZATCA prints
[BR-KSA-EN16931-06]-Charge on price level (BG-29) is not allowed. The value of Indicator should be 'false'.
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.
A charge is written on an invoice line's price
Reported ascharge_indicator_truethe indicator marks a charge
What is wrong
A cac:AllowanceCharge under cac:InvoiceLine/cac:Price carries a cbc:ChargeIndicator of true, which marks it as a charge rather than an allowance. ZATCA's rule BR-KSA-EN16931-06 governs the price level specifically and requires false there. Under rule packs before 2.0.0 the document-wide charge rule BR-KSA-F-02 reported the same indicator as well; in SDK 3.4.8, which rule pack 2.0.0 reads, that rule accepts both true and false, so this note now stands alone. The block itself is not the problem - a price-level allowance with an indicator of false was measured passing with no findings at all - it is the value. The contradiction between two published ZATCA documents is at its sharpest here, because it is one sentence written twice with opposite meanings. Section 13.3.4 of the XML Implementation Standard v1.2 of 19 May 2023, page 67, states this rule as: a charge on price level, group BG-29, is allowed, and the value of the indicator should be True. The rule of the same identifier in the published validation rule files states it as: a charge on price level, group BG-29, is NOT allowed, and only the value false is allowed. Same identifier, same group, opposite verdict. The rest of that standard is built on the first reading - its change log lists the charges specification as a headline addition of the version (page 1), section 9.2 gives a formula that sums the charge amounts into a total (page 16), section 11.2.8 supplies a recommended code list for the reason for a charge (page 34), and its own worked invoice carries an indicator of true on a line (page 18) and on the document (page 26). The validation rule files are what decides, because they are what a submitted document is actually run through. So a system that implemented the published charges specification correctly is refused by them. That has to be said plainly, so that no time is spent auditing a mapping which is doing exactly what one of the two documents told it to do.
What to check in your ERP
A price-level allowance-charge block is where a system usually puts an adjustment that belongs to the unit rather than to the line: a handling or packing fee, a fuel or delivery uplift, a surcharge folded into the unit price. If the adjustment is a discount, the indicator is simply the wrong way round and false is the fix; check for an export template that writes true on every block it emits. If it is a surcharge, it has to leave this block, and there are two honest places for it. Fold it into cbc:PriceAmount, so that the unit price carries it and cbc:LineExtensionAmount follows from the price and the quantity as it should. Or bill it as an invoice line of its own with its own tax category and rate, which is the clearer document when the customer is meant to see the charge itemised. For a delivery charge specifically, cac:FreightAllowanceCharge under cac:Delivery/cac:Shipment is measured to pass with an indicator of true, with one limit: the amount does not enter the totals or the VAT breakdown, so it records the charge without billing it. Check the tax side once the amount has moved. A surcharge folded into the unit price is taxed at the line's own category and rate, which is right when the charge follows the goods and wrong when it does not. A charge whose VAT treatment differs from the item's needs a line of its own so that it can carry its own cac:ClassifiedTaxCategory.
An allowance-charge block on an invoice line's price has no indicator at all
Reported ascharge_indicator_missingthe allowance-or-charge indicator is missing
What is wrong
A cac:AllowanceCharge under cac:InvoiceLine/cac:Price carries an amount but no cbc:ChargeIndicator element. Only rule packs before 2.0.0 report this: SDK 3.0.8's BR-KSA-EN16931-06 compared the indicator to false, and an absent element gave nothing to compare, so the rule was raised. In SDK 3.4.8, which rule pack 2.0.0 reads, the rule tests for an indicator that is true (KSA:3140-3141), and an absent one is not true, so a report produced under 2.0.0 never carries this note. UBL 2.1 makes cbc:ChargeIndicator mandatory inside the block, so a document in this state still fails the schema check, and that note is the one to read.
What to check in your ERP
Write cbc:ChargeIndicator as the first child of every cac:AllowanceCharge your export emits, at every level, with the value false for a discount. It is a constant written literally rather than a value read from a field, and that is why it goes missing: the discount record in your system holds an amount and a reason but no direction, so there is nothing for the template to map and the element is left out. Two causes are worth checking. A serialiser configured to drop any element whose backing value is empty or boolean false will remove precisely the value you meant to write. And a template with a condition around the indicator will only satisfy it on some code paths. Element order matters as well: UBL puts the indicator first in the block, before the reason and the amount.
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.
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.
Where it differs from a document that passed
− This example
+ A document that passed
<cbc:PriceAmount currencyID="SAR">100.00</cbc:PriceAmount><cac:AllowanceCharge>−This example: <cbc:ChargeIndicator>true</cbc:ChargeIndicator>+A document that passed: <cbc:ChargeIndicator>false</cbc:ChargeIndicator> <cbc:AllowanceChargeReasonCode>95</cbc:AllowanceChargeReasonCode> <cbc:AllowanceChargeReason>Discount</cbc:AllowanceChargeReason>