The first thing to understand about rejection on the Fatoora platform: rejection deletes nothing. The rejected invoice has consumed its value from the invoice counter, taken its place in the hash chain, and its submission is on record. Rejection is a verdict on the document's tax validity — not an undo button.
Warning or error?
The platform's response distinguishes two severities:
- An error fails the document: a standard invoice does not pass clearance, and a rejected document is not a valid tax document for your customer.
- A warning lets it through: the document proceeds and the remark stays on record — an incomplete national-address detail, say, or a line missing its Arabic name. Letting warnings pile up is a bad habit: many of them flag incomplete data that will surface as a hard error in some other context later.
Why you never "resend" the same document
Because a stamped document is never modified — that is the rule the whole system is built on. Correcting an invoice that failed clearance means a new document with the corrected data: a new counter value, a new place in the chain. The rejected invoice stays in your record exactly as it is, in its rejected state — and that is entirely healthy: an honest record tells what actually happened.
The visible gap in the sequence of accepted documents is not a problem as long as your record explains it: counter value so-and-so was consumed by a rejected document, and that is on file.
What to do on rejection, practically
- Read the rule code in the platform's response — see our guide to the most common rejection codes.
- Fix the cause at its source: if it is stored data (a VAT number, an address), correct the record, not just this invoice — otherwise the rejection repeats on every following invoice.
- Issue the corrected document as a new document.
- Never hand a customer a rejected document: a standard invoice is shared after it passes clearance.
And simplified invoices?
A simplified invoice is handed to the customer at the sale and reported within 24 hours, so a reporting rejection arrives after the customer already has their copy. The treatment is the same — fix the cause at its source, correct through the lawful documents — but prevention is worth more here: pre-flight checks before issue stop the situation from arising at all.
Prevention beats treatment
Nearly every rejection rule can be checked before submission. In alFatora every document passes a pre-flight check against the standard's own rules before it is stamped or sent — so the mistake is caught while it is still an editable draft, not a stamped document that has consumed its place in the record. Run the full cycle, deliberate mistakes included, in the free sandbox.
Was this useful? Review alFatora on Google.
