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

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.

And the comparison is a comparison of decimals, not a comparison to the nearest halala: the validation schematron in the SDK the Authority publishes tests the two sides for equality as written, so a single halala of difference raises the warning. We have seen it ourselves on a five-unit line: a net of 4.44 and a unit price rounded to the nearest halala, 0.89 — and five times 0.89 is 4.45, not 4.44.

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. Whoever writes the «true» net of 10.43 beside the price of 0.87 fails here, having got nothing wrong except the direction of the arithmetic. A document discount spread into the lines is a second form of the same thing: 4.44 over five units is 0.888 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: twelve units at one riyal including VAT leave as a net of 10.43 beside a price of 0.87, and 12 times 0.87 is 10.44.
• A price rounded to the nearest halala after a document discount was spread into the lines: 4.44 over five units gives 0.888, written 0.89, and five times 0.89 is 4.45, not 4.44.
• 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 fractional quantity whose product with the price carries a third decimal: 1.5 times 0.87 is 1.305, and no two-decimal net equals it.

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.

Frequently asked questions