Issue a Credit Note That ZIMRA Accepts
Overview. A credit note reverses a sale that was already declared to ZIMRA, so it must point at the receipt it reverses. Every connector handles the sign and the linking for you — your only job is to raise the credit note from the original invoice in your own system, so it carries that reference.
The Original Must Already Be Fiscalised
On the same device. If it is not there — because it was never sent, or it failed and still shows as an error — the credit note is refused with RCPT015 and the message "Invoice … has not been fiscalised on this device". Fix and resend the original first, then re-send the credit note.
Say Which Invoice It Reverses
In your accounting system this is automatic: Odoo's Reverse Entry, Zoho's invoices_credited, QuickBooks' applied credit memo (LinkedTxn), or the credited_invoice_no column in the CSV template. Over the REST API you send a credited_invoice object, in any one of three shapes:
"credited_invoice": {"invoiceNo": "INV-2026-0042"} // your invoice number
"credited_invoice": {"receiptID": 5001} // the ZIMRA receipt ID
"credited_invoice": {"sourceRef": "146"} // the source system's internal ID We resolve any of them to what ZIMRA actually wants — the receipt ID, or the device ID + global number + fiscal day number together.
Write a Reason
ZIMRA requires a note on every credit and debit note (RCPT034). The connectors fill a default one; over the API, send notes with the real reason — "Goods returned, damaged in transit" is better than "Credit note".
Send Positive Numbers
Set receipt_type to CreditNote and send your quantities, prices and totals as normal positive figures. The negation is applied for you across the lines, the tax table and the payments, exactly as ZIMRA requires. Sending negatives as well double-negates the document.
receipt_type: "DebitNote" follows all four rules identically and also requires credited_invoice.“The invoice is wrong. Can I just edit it?”
No, and no system may. A fiscalised invoice has been signed with your device key, chained by hash to the receipt before it, given a number out of a sequence ZIMRA reconciles, and filed under your taxpayer number. It cannot be withdrawn, cancelled, deleted or amended — not by us, not by ZIMRA, and not by any other fiscalisation provider. A gap or a change in that chain reads to FDMS as a missing or tampered receipt.
That is not a limitation of ThatFiscal. It is the point of fiscalisation: the document your customer holds and the document ZIMRA holds are the same document, for ever.
So a wrong invoice is corrected with a second fiscal document, not by changing the first. Which one depends on what is wrong:
- Charged too much, wrong price, wrong quantity, goods returned, the sale cancelled, or the invoice raised twice — a credit note. Credit the whole invoice and raise a correct one, or credit only the lines that were wrong.
- Charged too little — a debit note, which adds to the original rather than reversing it. Raising a second invoice for the difference also works and is what most businesses do in practice.
- The customer’s name, address or TIN is wrong — credit the invoice in full and raise it again correctly. The buyer’s details are part of the signed document; there is no way to amend them in place.
- Nothing is wrong and they have simply lost it — that is not a correction at all. Re-print or re-email the original from your portal, as many times as you like. The QR code and verification code stay valid, because it is the same receipt.
Everything above is done from Billing Studio → Invoices → open the invoice → Issue Credit Note, and from the till with Return. You never type the link yourself: we read it off the original, file the credit note on the device that issued the original, refuse to credit more than the invoice was worth, and refuse to credit goods that were not on it.