Your order completes, the customer pays, then the invoice fails. Under ZATCA's Fatoora Phase 2, standard tax invoices must be cleared by ZATCA before sharing with the buyer, and simplified invoices reported after issue, within the 24-hour window ZATCA's published model sets. A rejection is not an accounting footnote: an uncleared standard invoice is not yet valid for your buyer, and a reporting failure leaves a finished sale stuck in a compliance queue. Almost every rejection traces to five cause families.
The short answer: the five cause families behind almost every rejection
Work through them in order; earlier families are most common and cheapest to fix.
| Cause family | Where it starts | First place to look |
|---|---|---|
| Buyer and VAT data | Checkout and customer records | Buyer VAT number, name, address on the order |
| Hash chain, ICV and UUID | The invoicing integration | Previous hash, counter sequence, reused identifiers |
| Timestamps and totals | Invoice generation | Issue time format, line rounding, unreconciled totals |
| Wrong invoice type | Checkout customer logic | Standard vs simplified for this customer |
| QR, stamp and certificate | Signing material | QR contents, stamp, certificate validity |
Fix the family, not the single invoice: a hand-repaired rejection recurs on the next order with the same bad data.
First, read the rejection properly: code, invoice type and clearance vs reporting
Capture three facts before changing anything: the exact rejection code and message, the invoice type, and which flow it was in. ZATCA's BR-KSA business rules in its Fatoora documentation are specific: a code identifies the rule broken. Treat the code as the diagnosis, everything else as confirmation.
The flow matters because the two models fail differently. A standard invoice goes through clearance — submitted, validated and stamped before the buyer receives it — so rejection blocks the document. A simplified invoice is issued first and reported afterwards, so rejection leaves a transaction still to be accounted for correctly.
Cause 1 — Buyer and VAT data your checkout captured badly
The largest family starts at checkout. A standard invoice carries buyer details — name, address and, for a VAT-registered buyer, their VAT registration number — and whatever checkout captured is what the invoice submits. Free-text fields and copied records feed the same failures: a VAT number in the wrong format, a buyer record duplicated from your own company record so buyer and seller VAT numbers match, or an address too incomplete for a standard invoice.
Fix it at capture, not submission. Format-check the VAT field as the customer types, reject your own VAT number in the buyer field, and make the requirement follow the invoice type: a consumer on a simplified invoice is not forced through a business form, and a business buyer cannot check out with the field blank. Clean existing records too — one mistyped record fails every invoice raised against it.
Cause 2 — Hash chain, ICV and UUID discipline broken upstream
Phase 2 invoices chain together: each document carries the previous invoice's hash, a sequential invoice counter value (ICV), and its own UUID. In ZATCA's model a rejected document stays in the chain — its hash is recorded, its counter value and UUID are used up and never reused, and the next document references the rejected one's hash, not the last accepted one's.
Most chain failures are operational. A restore or failover replays an old counter; retry logic resubmits with a fresh UUID but stale previous hash; an integration "helpfully" rolls back to the last accepted document, breaking the chain for everything after it. The discipline: treat chain state as production data with its own backup, and advance it exactly once per generated document, accepted or not.
Cause 3 — Timestamps, totals and rounding that do not reconcile
ZATCA validates arithmetic and the clock as strictly as identities. Timestamp failures include an issue time in a format the schema rejects, or one disagreeing between the XML and its QR code. Totals failures are usually rounding: VAT calculated once on the total instead of line by line, line extensions that do not sum to the stated subtotal, or a discount applied at a different level in your store than in the generator.
Fix both at generation. Synchronise the issuing system's clock, generate the timestamp once and reuse it in the XML and QR payload, and apply one rounding rule — line-level, per ZATCA's published specification — in both store and generator. If recomputing a rejected invoice's totals by hand shows your arithmetic disagrees with the document, no resubmission will save it.
Cause 4 — Wrong invoice type for the customer in front of you
Standard and simplified invoices are not interchangeable: they follow different flows and carry different data requirements. A standard invoice to a retail consumer loads a B2C checkout with business data demands it cannot satisfy; a simplified invoice to a VAT-registered business buyer fails that customer even when ZATCA accepts it.
The cause is usually checkout logic: the type is fixed by channel or platform default instead of by customer. Set the rule explicitly — customer type determines invoice type: a business buyer supplying a VAT registration number gets a standard invoice through clearance; a consumer gets a simplified invoice through reporting. Edge cases follow ZATCA's current Fatoora guidance, verified there rather than improvised.
Cause 5 — QR, stamp and certificate material that fails validation
The final family is cryptographic. Phase 2 documents carry a cryptographic stamp, and the QR code carries more than Phase 1 fields: alongside seller name, VAT number, timestamp and totals, it encodes hash and signature material that must match the invoice. Failures include a QR generated from different values than the XML, stamp material produced with the wrong key, and certificate problems — expired, revoked, or compliance material used in production.
Check simple causes first. Confirm the certificate is the production one for this invoicing unit and still valid; confirm the QR is generated from the final signed document, not a draft; and confirm nothing modifies the invoice after stamping, because a late totals adjustment invalidates the stamp. Recurring failures here mean the integration needs review, not another retry — see our Saudi Arabia overview.
Fix the system, not the invoice: validate before you submit
Every cause above is cheaper on your side of the API than on ZATCA's. The durable fix is pre-submission validation: before any document is signed and sent, run the same checks ZATCA will apply — mandatory fields present and correctly formatted, buyer and seller data valid and distinct, totals reconciled line by line, timestamp well-formed, invoice type correct, chain state advanced exactly once. ZATCA publishes its rules, SDK and sandbox material for this purpose: test the document mix you actually issue, and keep validation in the live path, not only in testing.
For the monitoring layer, see our companion guide to one dashboard for ZATCA invoices, mada settlements and store inventory once it publishes.
Handling the invoices already rejected: notes and traceability, never edit or delete
Opening the issued invoice, correcting it and resending it is the one move the regime prohibits: issued e-invoices are not edited or deleted. Corrections are made with electronic notes — a credit or debit note referencing the original — so the record shows what was issued and what replaced it. Treat this as operational guidance, not tax advice, and confirm treatments against ZATCA's current documentation and your tax adviser.
For a standard invoice rejected at clearance, the buyer never received a valid invoice: correct the underlying fault, then generate and submit a corrected document properly. For a simplified invoice already issued that failed reporting, correct the cause and handle the transaction through the route ZATCA prescribes, not a duplicate reissue. Keep the full trail — original, rejection code, note, corrected document.
Common mistakes that turn one rejection into a cascade
Four habits multiply rejections. Resubmitting unchanged: a rejection is deterministic, so the same document fails the same way while staff lose hours. Fixing the invoice instead of the source, leaving the customer record, rounding rule or chain state broken for the next order. Rolling the chain back to the last accepted document, breaking every later submission. And mixing environments — test documents cleared into production, live certificates used in testing. Stores cross-checking their wider build can use our guide to web development in Saudi Arabia.
FAQ
Why was my invoice rejected if the order and payment succeeded?
Because payment and invoicing are separate validations. Your gateway approved the money, but ZATCA validates the document itself — buyer data, totals, timestamps, chain state and cryptographic material — against its business rules. A checkout can take money perfectly and still hand the invoicing layer bad data.
Can I edit or delete a rejected e-invoice and resend it?
No. Issued e-invoices are not edited or deleted under the Fatoora regime; corrections are made with credit or debit notes referencing the original. If a standard invoice was rejected at clearance, correct the cause and submit a properly generated document, keeping the rejected attempt in the chain and your records.
What happens to the hash chain when an invoice is rejected?
The rejected document stays in the chain: its hash is the one the next document must reference, and its counter value and UUID are used up permanently. Rolling back to the last accepted document, or reusing either value, breaks the chain.
What is the difference between a clearance rejection and a reporting rejection?
A clearance rejection hits a standard invoice before the buyer receives it, so the document is blocked until corrected and resubmitted. A reporting rejection hits a simplified invoice the customer already holds, so the fix is to correct the cause and account for the transaction as ZATCA prescribes.
How do we stop the same rejection code coming back?
Trace the code to its family, then fix the source — the checkout field or customer record, the chain-state handling, the rounding rule, the invoice-type logic, or the certificate material — and add pre-submission validation.
Get your store's invoicing integration fixed at the source (CTA)
If the same codes keep returning, the defect is in the checkout data or the integration, and resubmitting will not cure it. WebStackRank's ecommerce development service covers the store side of that fix — checkout data capture, integration review and the validation layer — alongside our ecommerce website development and custom web application development work. Send us your codes and platform, and we will name their family.
