Transaction type not allowed on a simplified invoice — export and self-billing

What does this mean?

Field KSA-2 is seven digits in the structure NNPNESB, and every digit is explained in BR-KSA-06. The first two say which family the document belongs to: 01 tax invoice, 02 simplified tax invoice. The remaining five are properties, each answered 0 or 1. This rule looks only at documents whose first two digits are 02, and it governs only two of the five.

What a simplified document may carry is three properties the message names explicitly: third party (digit three), nominal supply (digit four) and summary transaction (digit six). What it forbids is two: export (digit five) and self-billing (digit seven). So what gets rejected is not a strange value or a mistyped letter — it is the digit 1 in one of those two positions on a simplified document.

The validator reads the digit, not your intention. A system that derives the export digit from the customer's nationality or from a shipping country will raise it on a cash sale to a tourist standing at the counter, and the document is rejected while the seller sees an ordinary local sale. This is by far the commonest shape of this code.

And if the transaction really is an export or a self-billing arrangement, the fault is not in the digit but in the family: both are arrangements between businesses, and their document is a tax invoice at 01 with the full buyer details, not a counter receipt. What separates the two families, and what each one requires, is set out in standard versus simplified tax invoices.

The QR code does not carry KSA-2 at all, so do not go looking for the seven digits in it. What it carries is the seller name, the seller VAT number, the invoice date and time, the total with VAT and the VAT amount, plus the invoice hash, the digital signature and the public key in phase two. It does answer a neighbouring question, though: the ninth field — the Authority's signature over the public key — appears on a tax invoice that went through clearance and not on a simplified one, so its presence or absence tells you which path the document took, which is the same fork that 01 and 02 express.

Why does it happen?

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

• The export digit derived from the customer's country or a shipping address, in a point of sale that issues simplified documents.
• One shared transaction-code template for both families, so digits set for a business-to-business document are copied onto a counter receipt.
• The self-billing digit left raised by an integration built for the buyer side and then reused for ordinary issuing.
• The digits written in the wrong order: summary raised in position five instead of six, where it reads as export. NNPNESB is counted from the left.
• Issuing the transaction as simplified to avoid buyer details — no VAT number to hand — when it is in fact an export.

How to fix it

4 steps, then send the invoice again.

1. 1
   Read the seven digits off your own rejected document

   They live in the name attribute on the cbc:InvoiceTypeCode element in the XML. Count from the left: one and two the family, three third party, four nominal, five export, six summary, seven self-billed. If the first two are 02 and the fifth or the seventh is 1, you are looking straight at the rejection.

2. 2
   Then decide whether the digit is wrong or the family is

   An ordinary cash sale: drop the digit to 0 so the code reads 0200000. A genuine export or self-billing arrangement: the document is not a simplified one, so issue it as a tax invoice with the buyer details that requires, and check BR-KSA-05 so the document type does not contradict its transaction code. Note too that BR-KSA-07 forbids combining export with self-billing even on a tax invoice.

3. 3
   And cut the derivation off at its source

   The digit comes from the transaction type — never from a country field, a customer record or a currency. And if you do raise the summary digit on a simplified document, which is allowed, know that it drags two conditions in with it: BR-KSA-72, an error, requires a supply date (KSA-5) and a supply end date (KSA-24), and BR-KSA-71, a warning, asks for the buyer name.

4. 4
   And check a document you are already holding

   If you are reviewing an invoice a supplier sent you and have no XML, the QR code reader decodes the code and shows its fields in your browser. It will not show you the seven digits — the code does not carry them — but it shows the seller name, the VAT number and the amounts, and the presence of the ninth field tells you the document went through clearance, which puts it in the 01 family rather than 02.

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