BR-KSA-50Line VAT amount is missing from an invoice line on this simplified invoice
This rule was retired in rule pack 2.0.0: ZATCA's SDK 3.4.8 no longer includes the assertion it mirrored, so Mutabiq no longer reports it. Reports produced by earlier rule packs may still name it; the explanations below are kept for them.
What kind of value was found — empty, not_15_digits and the like — never the value itself.
Line VAT amount is missing from an invoice line on this simplified invoice
Reported asline_vat_amount_missingthe line VAT amount is missing
What is wrong
A cac:TaxTotal inside a cac:InvoiceLine carries no cbc:TaxAmount. ZATCA's rule BR-KSA-50 requires the line VAT amount (KSA-11) to equal the line net amount (BT-131) multiplied by the line VAT rate (BT-152) divided by one hundred, and with no value written there is nothing to compare, so the rule fails rather than being passed over. The element is required by the UBL schema as well, so a document in this state is normally reported here and by the schema check together. One thing about this rule decides how far its silence goes: it is gated to simplified invoices, so a standard invoice is never judged by it, and the absence of this note on a standard invoice is not evidence that its line arithmetic is right.
What to check in your ERP
A line tax total with no VAT amount in it usually means the block was written from a template rather than from the tax engine's own result. Check the export mapping for cac:InvoiceLine/cac:TaxTotal and confirm it writes cbc:TaxAmount on every line, including lines at a zero rate, which must carry an amount of 0.00 rather than nothing at all. The other regular cause is a line that was never given a tax result - a free-text or non-stock line added by hand after the document was priced - so check whether the line carries a tax code in the first place. The document-level tax total is a different block and filling it in does nothing here.
Line net amount is missing from an invoice line on this simplified invoice
Reported asline_net_missingthe line net amount is missing
What is wrong
An invoice line carries no cbc:LineExtensionAmount, and that element is the left-hand side of the multiplication ZATCA's rule BR-KSA-50 performs: the line VAT amount (KSA-11) must equal the line net amount (BT-131) times the line VAT rate (BT-152) divided by one hundred. With the net amount absent there is nothing to multiply, a comparison against an absent value is false, and the rule fails. The element is required by the UBL schema, so the schema check normally reports the same line. Note that the rule reads the net amount from the line itself rather than from the tax total inside it. The rule is gated to simplified invoices: a standard invoice is never judged by it, so silence on a standard invoice is not evidence that its line arithmetic is right.
What to check in your ERP
The line net amount is the line total after discounts and before VAT, and its absence is normally a template gap rather than a pricing one - the figure exists in your system as soon as the line has been priced. Check that the invoice line template writes cbc:LineExtensionAmount on every line, and look particularly at zero-value and free-of-charge lines, because some templates suppress an element whose value is nought and that produces exactly this note. The same element name also appears in the document totals block, where it is a different field: filling that one in does not write the line's own.
Invoice line carries no VAT rate on this simplified invoice
Reported asline_rate_missingthe line's VAT rate is missing
What is wrong
A line's cac:Item/cac:ClassifiedTaxCategory carries no cbc:Percent. ZATCA's rule BR-KSA-50 multiplies the line net amount (BT-131) by that rate, a comparison against an absent rate is false, and the rule therefore fails whatever the line VAT amount says. Unlike the two amounts this rule reads, the rate is optional in the UBL schema, so a document in this state is otherwise well formed and the schema check says nothing about it. There is one shape of invoice where nothing can be done about it here: a line coded O for out of scope must not carry a rate, because EN 16931 rule BR-O-05 is raised on its mere presence, so a simplified out-of-scope invoice fails BR-KSA-50 however it is written. That is the same closed cycle the note for BR-O-02 sets out in full, and it is not repeated here. The rule is gated to simplified invoices: a standard invoice is never judged by it, so silence on a standard invoice is not evidence that its line arithmetic is right.
What to check in your ERP
If the line is not out of scope this is a mapping gap rather than a tax one: the rate exists in your VAT code table and is not reaching the line. Check that the export writes cac:Item/cac:ClassifiedTaxCategory/cbc:Percent and not only the category code beside it, and note that the rate in the VAT breakdown is a different element - filling that one in does not satisfy this rule, which reads the line's own rate. If the line genuinely is out of scope, read the note for BR-O-02 before changing anything: the question worth your time is whether the supply is really outside the scope of VAT, because zero-rated and exempt supplies each have a configuration that passes and out of scope does not.
Line VAT amount is not the line net amount times the line VAT rate
Reported asnot_net_times_ratenot the net amount times the rate
What is wrong
The line VAT amount (KSA-11), written in cbc:TaxAmount inside the line's cac:TaxTotal, does not equal the line net amount (BT-131) multiplied by the line VAT rate (BT-152) divided by one hundred. ZATCA's rule BR-KSA-50 requires that identity on a simplified invoice with no tolerance at all. One thing has to be said plainly, because it decides what you can usefully do next: the comparison ZATCA runs is not a decimal one. The expression carries no decimal conversion, so both sides are turned into binary floating-point numbers before they are compared, and a line whose arithmetic is exactly right to the halalah can still be refused. Measured on ZATCA's own tool: a line net of 33.33 at a rate of 15.00 with a VAT amount of 5.00 - the product correctly rounded to the halalah, and the only two-decimal value that is right - is refused. The single value that comparison accepts there is 4.999499999999999, fifteen decimal places, and rule BR-KSA-DEC-03 then refuses that same element for carrying more than two. So recomputing the amount more precisely does not clear the note either, and for line net amounts of this kind the two rules cannot both be satisfied. This is a defect in how the rules are written rather than anything wrong with your invoice, and the only thing that clears it is a different line net amount or a different rate. The rule is gated to simplified invoices: a standard invoice is never judged by it, so silence on a standard invoice is not evidence that its line arithmetic is right.
What to check in your ERP
Work through the ordinary causes before concluding that the rule is at fault, because they are far commoner. The rate written on the line may not be the rate the tax engine used for the amount, which happens when a default rate is written by the export template while the amount came from the tax code on the item; a discount may have been applied to the net amount and not to the VAT; and VAT computed once at document level and then spread back over the lines will rarely reproduce a line-by-line product. Note also that this rule reads the rate at cac:Item/cac:ClassifiedTaxCategory, not the rate in the VAT breakdown. If your own figures are right to the halalah, you are in the case described above: there is no setting in your system that clears it, and the only route is different priced amounts on the line.