Something is wrong with an invoice you sent last week. The buyer returned half the order, or the price was wrong, or the wrong company name is printed on it. The instinct is the same every time: open the invoice, fix it, save. Failing that, delete it and issue a clean one.
Both instincts are wrong here, and acting on either turns a small problem into an expensive one.
The rule underneath everything
An invoice that has been cleared or reported is no longer only yours. Once your system has signed it and transmitted it, it cannot be edited and it cannot be deleted — not by you, not by your software, not by support.
Each document carries a signature over its contents, a counter value and the hash of the document before it: change one character and the signature stops matching; remove one and every document after it is orphaned.
So corrections work the way accounting has always corrected a document that already left the building: you issue another document that points back at the first. The original stays where it is; the correction sits beside it, names it, and the two are read together.
Credit note or debit note
There are two corrective documents, and one question separates them: after the correction, does the buyer owe less or more?
A credit note, document type 381, reduces what the buyer owes: goods came back, the order was cancelled, you agreed a discount after issuing, you charged too much.
A debit note, document type 383, increases it: you charged too little, work was added after the invoice went out, a price was corrected upward.
Those two and the invoice itself (388) are the only document types Phase 2 accepts; anything else is rejected by BR-KSA-05, an error-severity rule. There is no cancellation type: cancelling an invoice means a credit note for its full value.
The two fields that make a note a note
A note is not an invoice with a minus sign. Two fields exist on notes that do not exist on invoices, and they are where most first attempts fail.
The reason for issuing (field KSA-10) is a data field inside the document, not a remark printed on the page. Its absence is an error: BR-KSA-17 rejects the note outright, so a note with no reason never comes into existence. One honest sentence is enough — goods returned, price correction, order cancelled.
The billing reference (BT-25) carries the number of the invoice being corrected, and its severity differs in a way that matters. BR-KSA-56 is classified as a warning: the note is accepted, and the warning is returned alongside that acceptance. Read that correctly. It is not permission to leave the field empty — it means nothing will stop a broken note entering your records, and a correction that does not say what it corrects is worthless to your buyer and to an auditor.
A note inherits the type of its invoice
A note is never standard or simplified on its own account: it takes the type of the document it corrects. A note against a standard tax invoice goes to the Authority for clearance, and you share it with the buyer only once it comes back cleared. A note against a simplified invoice is handed over immediately and reported within 24 hours. If you are unsure which you originally issued, standard versus simplified settles it with one question.
A note is a full electronic document
It is signed exactly like an invoice. It takes its own counter value — BR-KSA-33 makes that counter an error-level requirement on every document — and it enters the same hash chain, where the previous-document hash is checked and returned as a warning under BR-KSA-61. And the issued format must be retained for six years, exactly like the invoice it corrects.
Which document for which situation
| What happened | What you issue | Why |
|---|---|---|
| Customer returns the whole order | Credit note (381) for the full invoice value | The invoice stays; the note cancels its effect |
| Customer returns part of the order | Credit note for the returned lines only | The rest of the supply stands |
| You charged too much | Credit note for the difference | Only the overcharge was wrong |
| You charged too little | Debit note (383) for the difference | The buyer owes more than the original said |
| Extra work agreed after invoicing | Debit note, or a new invoice | A debit note corrects an existing supply |
| Wrong buyer name, VAT number or address | Credit note for the full value, then a new invoice with the correct details | Buyer identity cannot be edited in place |
| Customer has not paid | Nothing | Non-payment is not a correction |
| The Authority rejected the invoice | Nothing — fix the data and send the same invoice again | A rejected invoice was never registered |
That last row is the trap. A rejection feels like a failure that needs clearing up, so people reach for a credit note — creating a corrective document that references an invoice the Authority has never heard of. Read the code that came back, fix the field it names, resubmit: Reading the code it sent back covers the common ones, and the error code index has the rest.
What a note does not do
It does not erase history. The original invoice remains issued, transmitted and visible, and a credit note beside it tells the truth about what happened.
It does not make a debt disappear. If a customer simply has not paid, the supply still took place and the invoice is still correct; a credit note would assert that the sale shrank, which is false. Bad-debt relief is not a credit note. It is a separate mechanism with its own conditions, and the people to ask are your accountant and zatca.gov.sa — not invoicing software, ours included.
When the correction counts, for VAT
VAT becomes due at the earliest of three moments: the supply, the invoice, or the payment. A correction issued weeks later therefore has a tax effect that belongs in a particular period, and which period depends on what happened and when. That is the principle; the specifics belong with your accountant, and a guide that invented a rule here would be doing you harm.
Making this automatic
Raise corrections from the invoice rather than from a blank form: the reference is filled in, the type is inherited, the counter and hash follow, and only the reason is left to a human.
That is how ZATCA Tools does it: signed invoices with a compliant QR code, cleared or reported, credit and debit notes raised against the original, signed XML archived six years and downloadable, and rejections shown with the official code and a link to its guide — 135 codes documented, 24 with full guides. Quotations, receipt vouchers with paid, partial and unpaid status, per-customer statements, per-branch devices, WooCommerce, Shopify, n8n, WHMCS, the REST API and a Partner API are all there. It is not an accounting system. It is free during the launch period, starting at 50 invoices and expanding, and connecting takes one OTP from the Fatoora portal — start here, or read the Phase 2 walkthrough first.