Invoice total with VAT is not the total without VAT plus the VAT

What does this mean?

Three figures at the foot of the invoice, under cac:LegalMonetaryTotal and the tax block: the total without VAT (BT-109) in cbc:TaxExclusiveAmount, the VAT amount (BT-110) in cac:TaxTotal/cbc:TaxAmount, and the total with VAT (BT-112) in cbc:TaxInclusiveAmount. The rule is plain addition: the third equals the first plus the second, with no halala of tolerance.

The code is not one of the Authority's Saudi rules (BR-KSA) but one of the European EN 16931 rules it applies alongside them, which is why the response files it under category EN_16931. Its message, as the Authority returns it, ends at Invoice total amount with VAT (BT-112) with nothing after it; the full sentence in the standard is that the total with VAT equals the total without VAT plus the total VAT.

Its severity is error: a simplified invoice comes back NOT_REPORTED and a tax invoice is not cleared, so it never enters the Authority records. It often arrives with the QR code error invoiceTotal_QRCODE_INVALID in the same response, because the QR code carries the total with VAT: change the total in the file and not in the code, and the two disagree.

Why does it happen?

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

• An amount edited in the file after signing: a system that changes the total with VAT or the amount due in the signed XML, as a correction or a test, which breaks the sum and the QR code at once.
• The total with VAT copied from another source instead of computed: what the customer paid at the till, or the sum of shelf prices, while the total without VAT and the VAT are computed from the lines. Three items at 9.99 including VAT: net 26.07, VAT 3.91, together 29.98, and the file says 29.97 because that is what was paid.
• Document VAT computed two ways: the sum of line VAT amounts rounded one by one in one place, and the VAT on the taxable base rounded once in another, so they drift apart by a halala or more.
• A document-level discount taken off one of the two totals and not the other, or taken off twice.

How to fix it

3 steps, then send the invoice again.

1. 1
   Compute the total with VAT last, as a sum

   Never copy BT-112 from anywhere. Compute the total without VAT from the lines less any document discounts, then the VAT on that base rounded once, then write the total with VAT as exactly their sum. Make sure the VAT amount in the cac:TaxTotal block is the same figure you added, not the sum of the line VAT amounts.

2. 2
   If what the customer paid differs by a halala, declare it as a discount

   In the example of three items at 9.99 including VAT: the true base is 29.97 divided by 1.15, which is 26.0609, and the written line nets add up to 26.07. Write the 0.01 difference as a document-level discount in a cac:AllowanceCharge directly under the invoice, so the total without VAT becomes 26.06, the VAT is 3.91 computed from 26.0609 and rounded once, and the total with VAT is 29.97, what the customer paid. How to derive the net from an inclusive price is covered under BR-KSA-EN16931-11.

3. 3
   Do not edit an invoice after signing it: rebuild it

   Any change to an amount after signing breaks the sum and the QR code together. If an amount has to change, rebuild the invoice from its data, sign it again and generate its QR code from the new file. A rejected invoice was never recorded by the Authority, so it needs no credit note: correct it and issue it again as a new invoice, since the rejected one already took its place in the invoice chain.

Once corrected, send the invoice again. A rejected invoice was never recorded with the Authority, so it needs no credit note — send the corrected invoice itself.

Frequently asked questions