FBR and your accounting software can both say debit note and mean different documents issued by different parties. Under rule 20(1) of the Sales Tax Rules 2006, where a supply is cancelled or returned it is the buyer who issues the debit note and sends the original copy to the supplier. In ordinary bookkeeping language a debit note is something the seller raises to charge a customer more. Both usages are correct in their own world, and confusing them produces a document that balances your books and does not match what FBR expects.
This page sets out both meanings, cites the rule behind each, and gives you a mapping you can hand to whoever configures your system. The mechanics of the documents themselves, the fields and the reference number, are in FBR debit notes and credit notes explained. This page is about the naming.
FBR uses debit note for two different events
The enabling provision is section 9 of the Sales Tax Act 1990, which allows a registered person to issue a debit or credit note and make a corresponding adjustment against output tax where a tax invoice needs to be modified. The detail is delegated to Chapter III of the Sales Tax Rules 2006, headed credit and debit note and destruction of goods. Rule 19 states that the chapter applies where a registered person has issued a tax invoice and, as a result of any of the events specified in section 9, the amount shown in the tax invoice or the return needs to be modified. The chapter then splits the world in two, and this is the part that catches people.
Rule 20: a supply is cancelled or returned
Rule 20(1) provides that where a registered person has made a supply and that supply or part of it is cancelled or returned, the buyer or the recipient shall issue a Debit Note in duplicate. It has to show the quantity being returned, its value determined on the basis of the value of supply shown in the supplier's tax invoice, the related sales tax, the National Tax Numbers of both parties, the number and date of the original sales tax invoice, the reason for issuing the note, and the signature and seal of the authorised person. Rule 20(2) requires the original copy to go to the supplier and the duplicate to be retained.
Rule 20(3) covers the case where the other side is not registered. Where supplies made to an unregistered person are cancelled, or goods are returned by one, the supplier shall issue a credit note with the same particulars. A proviso added by SRO 350(I)/2024 dated 7 March 2024 tightened this considerably: that credit note shall only be issued with the prior approval of the Commissioner. No accounting package we have seen asks for that approval before letting you post it.
Rule 21: the value or the tax changes
Rule 21 deals with revisions rather than returns, and here the roles reverse. Where the value of supply or the amount of sales tax in the invoice has increased, the supplier shall issue a Debit Note, showing the original value and tax, the revised value and tax, the difference adjustable, and the reason for the revision. Where it has decreased, the supplier shall issue a Credit Note with the same particulars.
Rule 21(3) then adds a step that has no equivalent in most software at all: in the case of a credit note issued under sub rule (2), the recipient shall issue a Debit Note with reference to the Credit Note as an acknowledgment of receipt, giving the same details. One commercial event, two documents, one from each side.
What accounting software usually means
Terminology in accounting systems is not standardised, so check your own before assuming, but the common convention runs like this. A credit note is a seller's document that reduces what a customer owes, typically raised for a sales return or an after the fact discount. A debit note is either a seller's document that adds to what a customer owes, sometimes called a supplementary invoice, or a buyer's document raised against a supplier on a purchase return, depending on the package.
Line that up against the rules and the mismatch is easy to see. A customer returns goods. Your software records a credit note against the customer. The rules say a debit note should be coming to you from the buyer. The numbers agree, the paperwork does not, and an integration that reads the software's document type as the thing to transmit will pick the wrong one.
The mapping, event by event
| What happened | What the Sales Tax Rules 2006 require | Where software usually differs |
|---|---|---|
| A registered buyer cancels or returns a supply | Rule 20(1): the buyer or recipient issues a Debit Note in duplicate, original copy to the supplier | Recorded as the seller's credit note. The buyer's document, if any, is called a purchase return |
| An unregistered buyer returns goods, or a supply to one is cancelled | Rule 20(3): the supplier issues a credit note, and since SRO 350(I)/2024 only with the prior approval of the Commissioner | Raised on demand, with no approval step anywhere in the workflow |
| The value of supply or the sales tax has increased | Rule 21(1): the supplier issues a Debit Note showing original value, revised value, difference and reason | This is the one case where the common software meaning and the rule agree |
| The value of supply or the sales tax has decreased | Rule 21(2): the supplier issues a Credit Note, and rule 21(3): the recipient issues a Debit Note back as acknowledgment | One document is produced, not two. The acknowledgment leg is usually missing entirely |
| A genuine mistake on an invoice already accepted by FBR | STGO 01 of 2026: cancel, delete or edit within seventy two hours, Commissioner approval after that | Would normally be edited or voided in place with no time limit |
What the digital invoicing API actually accepts
There is a third vocabulary in play, and it is narrower than either of the first two. In the DI API Technical Specification version 1.12, the invoiceType field is documented with exactly two values: Sales Invoice and Debit Note. The invoiceRefNo field, which carries the reference back to the original invoice, is described as required only in the case of a debit note. PRAL's Digital Invoicing User Manual is consistent with that: the invoice value graph on the dashboard is offered in two formats, Sale Invoice and Debit Note.
So whatever your system calls its correction document, the field it populates on the way out is one of two values. Getting it wrong produces error code 0003, "Provide proper invoice type", or 0109, "Wrong invoice type is selected in invoice no". Sending a debit note without the reference produces 0026, whose explanation reads that the invoice reference number is a mandatory requirement for a debit or credit note. Those codes and the rest are in the FBR error codes glossary.
What we could not confirm
Where the credit note lives. The same specification whose invoiceType field offers only Sales Invoice and Debit Note contains error codes that refer to credit notes repeatedly: 0026 and 0027 speak of a debit or credit note, 0036 and 0037 cap a credit note against the original invoice, 0064 says a credit note is already added to an invoice, and 0071 is explained as a credit note being allowed only for specific users. The two halves of the document do not line up, and nothing we read explains how a credit note is transmitted, or whether it is handled outside the API through IRIS. Ask your licensed integrator to demonstrate the credit note path in the sandbox before you design a process around it.
Whether a debit note is capped at the original invoice. Error 0067 is explained in the specification as the sales tax value of a debit note being greater than the original invoice's sales tax, listed as a rejection. Read literally that is a ceiling, which is the behaviour of a document that gives value back rather than one that adds value on top, and it would sit oddly with rule 21(1), where a supplier's debit note exists precisely to increase an invoice. The published documents do not resolve it, and the message text is a shared template with placeholders, so we are not prepared to state a rule either way. If your business regularly issues upward revisions, test that specific case in the sandbox before you rely on it.
The two clocks you have to watch
One hundred and eighty days. Rule 22(4) of the Sales Tax Rules 2006 provides that adjustments which reduce output tax or increase input tax can only be made if the corresponding debit note or credit note is issued within one hundred and eighty days of the relevant supply. The digital invoicing system enforces the same limit at the point of submission: error code 0034 is explained as a debit or credit note only being allowed within 180 days of the original invoice date. Rule 22(2) tells you where the adjustment goes, which is the return for the period in which the note was issued, not the period of the original supply.
Seventy two hours. Sales Tax General Order 01 of 2026, dated 30 March 2026, issued under sub sections (5) and (6) of section 23 of the Sales Tax Act 1990, directs that an integrated person shall only be allowed to cancel, delete or edit a valid electronic sales tax invoice generated due to a bonafide mistake, through the Board's computerized system, within a period of seventy two hours from the time of its generation. Anything after that is subject to the prior approval of the concerned Commissioner Inland Revenue. The same order confirms that a registered person may engage one or more licensed integrators.
What to do about it in your own system
The fix is a mapping exercise. It is cheap done once and expensive done per invoice.
- Write down which business event each of your document types represents, before you look at anything FBR publishes. A return is not the same event as a price revision even if your software produces the same document for both.
- Map each event to the rule that governs it, using the table above, and note who is supposed to issue the document. If that is the buyer, your process needs a step for receiving and recording their note, not just for issuing your own.
- Map both onto the two invoiceType values the API accepts, explicitly in the integration rather than leaving it to whatever label a user picked on screen.
- Add the approval step where the rules require one, specifically for a credit note to an unregistered buyer under rule 20(3), and for any correction after seventy two hours.
- Put the 180 day test in front of the user, not behind it. A note that is refused by FBR after the fact is worse than one your own system refused to raise.
If most of your rejections are on ordinary sales invoices rather than corrections, those patterns are in why FBR invoices get rejected, and our approach to validating before submission is on the FBR digital invoicing page.
Get the document type right the first time
AxiomSquare maps your business events to the document types FBR accepts, and validates each submission before it goes out. Tell us what your corrections actually look like and we will tell you what has to change.
See FBR digital invoicingLast verified: 27 August 2026. Primary sources read directly for this page: the Sales Tax Rules 2006 as consolidated and updated to 6 August 2025, specifically Chapter III, credit and debit note and destruction of goods, at rule 19 application, rule 20 cancellation or return of supply including sub rule (3) and the proviso added by SRO 350(I)/2024 dated 7 March 2024, rule 21 change in value of supply or amount of sales tax including sub rules (1), (2) and (3), and rule 22 adjustment of input and output tax including the one hundred and eighty day limit in sub rule (4); section 9 of the Sales Tax Act 1990 as the enabling provision; Sales Tax General Order 01 of 2026 of the IR Operations Wing, dated 30 March 2026, read in full, for the seventy two hour correction window, the requirement of prior approval of the concerned Commissioner Inland Revenue after that period, the reference to sub sections (5) and (6) of section 23 of the Sales Tax Act 1990, and the reference to SRO 1413(I)/2025 dated 1 August 2025; the PRAL Technical Specification for DI API, document version 1.12, last updated 24 July 2025, for the invoiceType and invoiceRefNo field descriptions and for error codes 0003, 0026, 0027, 0034, 0036, 0037, 0064, 0067 and 0109; and the PRAL Digital Invoicing User Manual, document version 1.6, for the Sale Invoice and Debit Note formats on the invoice dashboard. The two open questions identified above could not be resolved from any published FBR or PRAL document and are deliberately left unanswered rather than guessed. Descriptions of accounting software conventions are general observations, not statements about any particular product. General information, not tax advice. Confirm the correct treatment of your own transactions with your tax consultant.