BR-KSA-EN16931-11 Warning — the invoice is accepted

Line net amount not equal to quantity times unit price — the rounding trap

The invoice line net amount (BT-131) must equal the quantity times the item net price over the base quantity, plus line charges minus line allowances. The validator the Authority ships lets the written net sit one halala either side of that product rounded to two decimals; from two halalas on it warns. It is a warning: the document is accepted and the warning is recorded. The commonest cause is not a multiplication mistake but a rounding one: a price recovered from a VAT-inclusive amount and written to two decimals, while the net was computed from the price before rounding — harmless on one unit, a warning once enough units add the halalas up.

The message text as the Authority sends it in English, unedited

Invoice line net amount (BT-131) must equal (Invoiced quantity (BT-129) * (Item net price (BT-146) / item price base quantity (BT-149))-) + Sum of invoice line charge amount (BT-141) - Sum of invoice line allowance amount (BT-136).

What does this mean?

Four fields on one line enter this equation, all under cac:InvoiceLine. The line net amount (BT-131) is cbc:LineExtensionAmount; the quantity (BT-129) is cbc:InvoicedQuantity; the item net price (BT-146) is cac:Price/cbc:PriceAmount; and the base quantity (BT-149) is cac:Price/cbc:BaseQuantity — optional, and absent it means one. Then the line allowances (BT-136) and charges (BT-141): cac:AllowanceCharge blocks directly under the line, with the indicator false for an allowance and true for a charge. The equation: the net equals the quantity times (the price over the base quantity), plus the charges, minus the allowances. Most lines carry no base quantity, no allowance and no charge, so it collapses to: quantity times price equals the net.

The rule's text says «must equal», but the test the Authority's SDK actually runs is looser by one halala: it multiplies the quantity by the price, cuts the product to three decimals, rounds it to two, and accepts a written net equal to that figure or one halala either side of it. We measured the edge on the Authority's sandbox on 23 September 2026: three units at 3.00 written beside a net of 8.99 passed clean; four units at 3.00 beside 11.98 — two halalas — raised the warning, and so did three. A warning we once blamed on a five-unit line (five times 0.89 against 4.44, one halala) came from its neighbour in the same basket: seven units at 2.99 against 20.91, two halalas off.

Where does the halala come from? From the net having two decimals, the price having two decimals, and the quantity multiplying. A price recovered from a VAT-inclusive amount rarely lands on a halala: one riyal including VAT is 0.869565… net, written as 0.87. Twelve units are truly worth 10.434783…, that is 10.43 — but 12 times 0.87 is 10.44. One halala is inside the validator's margin; the same drift over more units is not: twenty-four bottles at 1.50 including VAT are worth 31.30 net, and 24 times 1.30 is 31.20 — ten halalas, and the warning, for someone who got nothing wrong except the direction of the arithmetic. A document discount spread into the lines is a second form of the same thing: 20.91 over seven units is 2.987 per unit, and no two-decimal price gives it.

The direction of the arithmetic is the whole cure. The net is derived from the written price times the quantity, never the price from the net by division. And whatever the rounding puts between the written net and the line's true value is neither folded into the line nor charged to the customer: it is declared as a document-level allowance (BT-92), where the European totals rule BR-CO-13, which the Authority's SDK applies, reads it — the taxable amount equals the sum of the line nets minus the document allowances. The document's VAT is computed from the true base and rounded once, as section 10 of the Authority's XML Implementation Standard states: rounding on final results, never on an intermediate one, half-up.

It is a warning: the document is accepted and the warning is recorded in the response. The message names no family, so the equation is checked on the tax invoice, the simplified invoice and their notes alike. The line VAT amount and the line total with VAT have their own rule, BR-KSA-51, which adds on top of the net this rule checks.

Why does it happen?

Ordered from the most common to the least — your cause is most likely the first or the second.

  • The net computed from the price before rounding while the price is written rounded, on a line with enough units for the gap to pass a halala: twenty-four units at 1.50 including VAT leave as a net of 31.30 beside a price of 1.30, and 24 times 1.30 is 31.20.
  • A price rounded to the nearest halala after a document discount was spread into the lines: 20.91 over seven units gives 2.987, written 2.99, and seven times 2.99 is 20.93, not 20.91.
  • The net taken from the source system — a POS total — and the price recovered from it by division and rounded: the reverse direction exactly.
  • The base quantity ignored or applied twice: a price quoted per hundred units (12.50 per 100) with a quantity of 250, where the net is 31.25 and not 3125.00 — or a base quantity written while the price is already per unit.
  • A line allowance (BT-136) declared under the line and also taken off the price, so it is subtracted twice; or declared and never subtracted from the net at all.
  • A price with a third decimal of its own, written at two: 0.045 a message is written 0.05, and a thousand messages leave as a net of 45.00 beside a price that makes 50.00.

How to fix it

3 steps, then send the invoice again.

  1. 1
    Round the price first, then derive the net from it

    Order the arithmetic: the item net price first, rounded to two decimals half-up, then the net is the quantity times that very price, the one you will write in cbc:PriceAmount. Do not compute the net from the exact price, and do not recover the price from the net by division. One riyal including VAT, twelve units: the price is 0.87 and the net is 12 × 0.87 = 10.44, not 10.43.

  2. 2
    Declare what the rounding left over as a document-level allowance

    Those units are truly worth 10.43 and their written net is 10.44, and the halala between the two is not folded into the line: write it as a document-level allowance in a cac:AllowanceCharge directly under the invoice, amount 0.01, under the lines' tax category and rate. The taxable amount then becomes 10.44 minus 0.01, that is 10.43; its VAT is 1.57, computed from 10.434783 and rounded once; and the total is 12.00, as on the shelf. The line holds under this rule, the document holds under the totals rules, and what the customer paid is what the invoice says.

  3. 3
    Then put the base quantity and the allowances where they belong

    If your price is per hundred or per thousand, write cbc:BaseQuantity and divide by it; if it is not, leave it out. A discount on the whole line belongs under the line, not on the price — the difference is in BR-KSA-EN16931-07 — and it is subtracted once. Then check every line before sending: quantity times price, plus charges, minus allowances, equals the net as written. How to read the whole response when more than one code arrives is in ZATCA error codes explained.

This code does not block acceptance, so the invoice you have is compliant. Correct the data so the warnings disappear from future invoices.

Does ZATCA Tools prevent it?

Yes, by construction, and without leaning on the validator's one-halala margin. Our net is always derived from the signed price times the quantity: LineItems::normalize rounds the unit price to two decimals half-up and then computes the net from it; a basket priced with VAT — or sent through the API as net prices the sender divided by 1.15 itself, every digit kept — has its nets fitted to their true base by moving a unit price one or two halalas and recomputing the net from the moved price (fitToBase); and a document discount is spread into the unit prices and the net re-derived from the price after it is raised to the next halala (DiscountAllocator::settle) — that raising came after this warning on the seven-unit line above. What the lines cannot carry is declared as a document-level allowance equal to the sum of the nets minus the taxable amount, so the totals hold whichever way the halala fell, and the document's VAT is computed from the base before rounding and rounded once. Our documents write no base quantity and no line-level allowance at all: a line discount is taken off the unit price before signing. And a test over four hundred random baskets with VAT-inclusive prices and discounts asserts the equality on every line to decimal precision, not to the halala. Two cases the construction does not close, stated plainly: a fractional quantity whose product with the price carries a third decimal (1.5 times 0.87 is 1.305, written 1.31), which stays inside the validator's margin; and a net price sent through the API with a third decimal that is not a divided shelf price — 0.045 a message — which is written at two decimals beside a net computed from all three, so a thousand messages carry the warning. Send such a price at two decimals. At worst it is the warning, never a rejection.

Related codes

BR-KSA-51 Warning
Line amount with VAT (KSA-12) not equal to line net plus line VAT
BR-KSA-EN16931-07 Rejects the invoice
Item net price not equal to gross price minus the price discount
BR-KSA-EN16931-12
The official message text is in the Full reference.

Frequently asked questions

Was my invoice rejected because of this code? +
No. It is a warning, and the document is accepted with the warning recorded. If your invoice really was rejected, the reason is another code in the same list with the severity of an error.
My shelf prices include VAT. How do I write the line? +
Divide by 1.15 and round the price to two decimals, then derive the net from the rounded price. 10.00 including VAT: the price is 8.70, the net 8.70, the VAT 1.30 and the total 10.00, with nothing left over. Twelve units at one riyal: the price is 0.87 and the net 10.44, and the extra halala is declared as a document allowance so the total comes back to 12.00. Extracting the net from an inclusive amount is what the VAT calculator does.
Why not write the exact net and leave the price? +
Because the rule multiplies the written price by the quantity, and it knows nothing of the exact price. 12 times 0.87 is 10.44, so if you write 10.43 the two sides differ — by one halala, which the validator happens to let through, and on twenty-four units at 1.50 by ten, which it does not. The truth belongs in the document allowance and the document VAT, not in the line net.
Does the rule tolerate a halala? +
Its text says «must equal», but the validator the Authority ships accepts a written net one halala either side of the product rounded to two decimals, and warns from two halalas on. We probed the edge on the sandbox: one halala passed clean, two and three raised the warning. Build to exact equality anyway — the margin lives in the validator's code, not in the rule, and a later version can close it.
My quantity is fractional — 1.5 kg at 0.87? +
The product is 1.305, and no two-decimal net equals it. The validator cuts it to three decimals, rounds it to 1.31 and accepts 1.30, 1.31 or 1.32, so the line passes either way. Write the product rounded half-up, 1.31, and the net is the figure the validator computes itself.
How does it relate to BR-KSA-51? +
That one adds on top of the net this one checks: the line total with VAT equals the net plus the line VAT. The net written here is the same net summed there, so fixing this rule by changing the net calls for redoing the sum in that one — BR-KSA-51.
You fixed this one — now avoid the next

ZATCA Tools builds the signature, the PIH, the counter and the encoding for you, and validates your data before it is sent. Start free, with no credit card.

Start for free

← All ZATCA error codes