The most common Fatoora rejection errors — and how to fix them

When the Fatoora platform rejects a document, it returns the code of the validation rule that failed — a code like BR-KSA-40 from the published implementation standard. The code is precise but terse. Here is a practical guide to the rules invoices actually fail on, ordered by where they live in the invoice.

The VAT number — the most common cause

• BR-KSA-39 / BR-KSA-40: the seller's VAT registration number exists and is 15 digits, starting and ending with 3. A truncated or mistyped number fails the invoice immediately.
• BR-KSA-44: the same rule for the registered buyer's number on a standard invoice.

The fix: validate numbers once, at data entry — a wrong number stored in a customer record repeats itself on every invoice automatically.

The national address

• BR-KSA-09: the seller's address is a full national address, district included — a warning in the validator.
• BR-KSA-37: the building number is exactly four digits.
• BR-KSA-66: the postal code is exactly five digits.
• BR-KSA-10: a standard invoice carries the buyer's postal address.

The fix: copy the address from the national-address certificate verbatim, and never let a free-text field stand where the standard wants a fixed digit count.

Date and time

• BR-KSA-04 / BR-KSA-F-01: the issue date is a real YYYY-MM-DD date and not in the future — a till with a mis-set clock is enough to fail an invoice.
• BR-KSA-70: the issue time is mandatory, hh:mm:ss.
• BR-KSA-15: a standard invoice states the supply date; simplified invoices are exempt.

Amounts and lines

• BR-KSA-F-04: quantities positive, amounts never negative — a reduction belongs in a credit note, not a minus sign.
• BR-KSA-F-03: no field present but blank — an empty XML element fails validation; an unused field is omitted, not left empty.
• BR-KSA-18: accepted VAT categories are S, Z, E and O only.

The transaction type code — the classic technical trap

Alongside the numeric invoice type, the document carries a seven-position flag string (BR-KSA-06): the first two positions are 01 for standard or 02 for simplified, followed by one flag each for third-party, nominal, export, summary and self-billed. The classic failures: flags that contradict the invoice type, an export marked self-billed (BR-KSA-07 forbids the combination), or flags a simplified invoice does not accept (BR-KSA-31).

Counter, chain and currency

• BR-KSA-33 / BR-KSA-61: the invoice counter (ICV) and previous-invoice hash (PIH) are present before sealing.
• BR-KSA-EN16931-02: a non-SAR invoice declares SAR as its tax currency.

The rule behind all the rules

Every item here can be checked before submission. A system that validates locally with the same rules does not spend a round-trip to the platform discovering a three-digit building number. That is what alFatora does: a pre-flight check against these rules before anything is sent, so what reaches the platform arrives correct — try it hands-on in the free sandbox.