BR-KSA-51 Warning — the invoice is accepted

Line amount with VAT (KSA-12) not equal to line net plus line VAT

The rule is a sum, not a derivation: the line amount with VAT equals the line net plus the line VAT amount, the two figures already written on the line. It is a warning, so the document is accepted and the warning is recorded. What breaks it most often is computing the total from a VAT-inclusive unit price, or writing a rounding difference into a field whose UBL name is RoundingAmount.

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

The line amount with VAT (KSA-12) must be Invoice line net amount (BT-131) + Line VAT amount (KSA-11).

What does this mean?

Three fields on one line. The line amount with VAT (KSA-12) is cac:InvoiceLine/cac:TaxTotal/cbc:RoundingAmount; the line VAT amount (KSA-11) is the cbc:TaxAmount in the same block; and the line net amount (BT-131) is cbc:LineExtensionAmount directly under the line. The rule: the first equals the third plus the second. The presence of the first two is required by two other rules — BR-KSA-52 and BR-KSA-53 — and this rule reads their values.

It adds what was written, not what «ought» to be: the validator takes the two numbers from the file as they are, adds them, and compares. So the total is computed from the rounded net and the rounded line VAT, after both are rounded — not from the unit price times the quantity times 1.15, and not from the document total divided among the lines. Every other route reaches the same number on a plain invoice and then parts from it by a halala the moment there is a discount or a price recovered from an inclusive amount.

What the rule does not check deserves saying: it does not tie the line's VAT to its net at the rate. In the extract we read from — 136 rules — no rule says KSA-11 equals the net times the rate over one hundred; what is checked on the line is this sum and the two decimals of each figure (BR-KSA-DEC-03 and BR-KSA-DEC-04), and the document's VAT as a whole is checked in the totals. So a line whose VAT sits a halala away from its net at 15% — because the document's VAT was computed once and then shared out among its lines — passes here as long as the sum is right.

A net-priced example: three units at 43.48 have a net of 130.44 and VAT of 19.57, so the line total is 150.01 — the figure to write, however odd it looks to someone expecting 150.00. A VAT-inclusive example: twelve units at one riyal including VAT are signed at a price of 0.87, a net of 10.44 and a line VAT of 1.57, so the line total is 12.01 — while the document total is 12.00, because the halala was declared as a document-level allowance. Writing 12.00 on the line because it is «what the customer paid» is exactly this warning: the line adds its two figures, and the document corrects itself in its totals.

It is a warning: the document is accepted and the warning is recorded in the response. The message names no family; the two fields are mandatory on the tax invoice and its notes by the text of BR-KSA-52 and BR-KSA-53, and wherever they are written, on any document, their sum is checked.

Why does it happen?

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

  • The total computed as the quantity times a VAT-inclusive unit price: 12 times 1.00 is 12.00, while the file carries a net of 10.44 and VAT of 1.57, which add to 12.01.
  • Reading RoundingAmount at face value: a rounding difference, or a zero, written in it instead of the line total.
  • Adding the values before they were rounded: 10.434783 plus 1.565217 is 12.00, while what was written is 10.44 and 1.57.
  • The line VAT computed from a net other than the one written — from the net before the document discount was spread, say — so the sum holds on figures that are not in the file.
  • A floating-point sum serialised with all its digits: 130.44 plus 19.57 comes out as 150.01000000000002, and the field fails BR-KSA-DEC-04 and this rule together.
  • The line total taken from the document total shared out among the lines in proportion, so it matches no line's net plus its VAT.

How to fix it

3 steps, then send the invoice again.

  1. 1
    Add the two written figures, literally

    Take the value of cbc:LineExtensionAmount and the value of cbc:TaxAmount as they will be written in the file — each already rounded to two decimals — add them, round the sum to two decimals, and write it in cbc:RoundingAmount. 130.44 plus 19.57 is 150.01, and 10.44 plus 1.57 is 12.01.

  2. 2
    Order the arithmetic: net, then VAT, then the sum

    The net first, from the quantity times the written price — which is what BR-KSA-EN16931-11 checks — then the line VAT, rounded, then the total as a sum. Never go back to the unit price or to the document total in any step after the first. And if the lines add up to a halala away from what the customer paid, that is corrected by a document-level allowance, not by editing a figure on the line.

  3. 3
    And check every line before sending, the zero-rated ones too

    Walk all the lines: the net plus the VAT equals the total, to two decimals. A zero-rated or exempt line has VAT of 0.00 and a total equal to its net — and the zero is written, not dropped. If the document is a credit or debit note the requirement stands on it exactly as on an invoice; notes are covered in credit and debit notes.

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. The payload builder writes every line's total with VAT as the line net plus its VAT, rounded to two decimals, from the same two figures it writes on the line — never from the unit price and never from the document total — on every line of every document, tax invoice, simplified invoice and their notes alike. The line VAT is derived here: from the written net at the rate of the line's category when the prices are net, and from the document's VAT computed once and then shared out among the lines when the prices include VAT — and in both cases what was written is what is added. No door in the product accepts a line VAT amount or a line total from outside: the invoice form and the API read a line's name, quantity, price, category and discount, and nothing else. Three tests walk every line of every payload — one of them four hundred random baskets with VAT-inclusive prices and discounts — and assert that the total equals the net plus the VAT on each line. We know of no case that escapes.

Related codes

BR-KSA-52 Rejects the invoice
Line VAT amount (KSA-11) missing
BR-KSA-53 Rejects the invoice
Line amount with VAT (KSA-12) missing
BR-KSA-EN16931-11 Warning
Line net amount not equal to quantity times unit price — the rounding trap
BR-KSA-DEC-04
The official message text is in the Full reference.

Frequently asked questions

My customer paid 12.00 and the sum gives 12.01. Which do I write? +
12.01 on the line. The written net is 10.44 and its VAT is 1.57, and their sum is 12.01, which is what the rule checks. 12.00 is the document total, and the document reaches it through a document-level allowance of that halala — the details are in BR-KSA-EN16931-11. What is corrected in the totals is not corrected on the line.
My line VAT is not exactly 15% of its net. Does this rule catch that? +
No. This rule adds; it does not multiply: the net plus the VAT equals the total, whatever the VAT is. And in the extract we read from there is no line-level rule tying the VAT to the rate; what is checked against the rate is the document's VAT in its totals.
Was my invoice rejected because of this code? +
No. It is a warning, and the document is accepted with the warning recorded. If it really was rejected, the reason is a code with the severity of an error in the same list — possibly BR-KSA-52 or BR-KSA-53, if one of the two fields was missing rather than wrong.
Does it apply to simplified invoices? +
The message names no family. The two fields are mandatory on the tax invoice and its notes by the text of BR-KSA-52 and BR-KSA-53, and wherever they are written, on any document, the sum is checked. Write them on every document and make the sum right on every document.
The line is zero-rated. What do I write as the total? +
Its net, exactly. Its VAT is 0.00 and the total equals the net plus zero. Both fields are written with their values, not dropped.
The line has a discount. Do I add before or after it? +
After. The net written in cbc:LineExtensionAmount is the net after the line discount, the line VAT is the VAT on that net, and the total is their sum. Always add the two written figures, never work from the original price.
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