Export refund error codes: SB000 to SB006, and the fix
The export refund is not an application anyone reads. It is a machine comparison between a shipping bill held by Customs and a return held by GSTN, and when the two disagree the money stops with a code attached. This guide takes each code in turn: what caused it, which pair of documents diverged, and who has to move.
An export refund on the with-payment route is not a claim anybody assesses. Rule 96(1) of the CGST Rules provides that the shipping bill filed by an exporter of goods shall be deemed to be an application for refund of integrated tax, and that the application is deemed to have been filed only when the person in charge of the conveyance has filed a departure manifest or an export manifest covering the number and date of the shipping bills, and the applicant has furnished a valid return in FORM GSTR-3B. Nothing is submitted. Two systems compare two records, and where the records disagree the money stops.
Why does an export refund fail with a code rather than an order?
Because there is no adjudicating officer in the path. Rule 96(2) of the CGST Rules provides that the details of the relevant export invoices contained in FORM GSTR-1 are transmitted electronically by the common portal to the system designated by the Customs, and that the Customs system transmits back a confirmation that the goods covered by those invoices have been exported out of India. That is a comparison of two data sets against each other, and a comparison has only two outcomes. Where they agree, the scroll follows. Where they do not, the record is parked and labelled.
The proviso to rule 96(1) states what the label costs. Where there is a mismatch between the data furnished by the exporter of goods in the Shipping Bill and those furnished in the statement of outward supplies in FORM GSTR-1, as amended in FORM GSTR-1A if any, the refund application is deemed to have been filed on the date on which the mismatch is rectified by the exporter. So the code does not merely delay the payment. It resets the date the application counts as filed, which is the date every downstream expectation hangs off.
What does each SB code actually mean?
ICEGATE publishes the list in its own IGST refund frequently asked questions, and it is short enough to hold in your head. These six are the whole vocabulary.
- SB000, successfully validated. The shipping bill and the return agree. It is a pass, not a payment, for reasons set out below.
- SB001, invalid shipping bill details. The shipping bill identified in the return does not resolve at Customs.
- SB002, EGM not filed. The export general manifest for the vessel or flight has not been filed.
- SB003, GSTIN mismatch. The GSTIN on the shipping bill is not the GSTIN that filed the return.
- SB004, record already received. The same invoice data has been transmitted from GSTN more than once.
- SB005, invalid invoice number. The invoice number in the return is not the invoice number on the shipping bill.
- SB006, gateway EGM not available. The manifest at the gateway port is missing, on a consignment that moved through an inland container depot first.
Read as a set, they sort into three kinds of problem: two codes that mean a field you typed diverged, two that mean a manifest somebody else files is missing, and two that describe the identity of the filer rather than the shipment. The route back is different for each kind, and treating them as one queue of errors is why refund follow-up takes so long in most export desks.
SB001 and SB005: the two codes that mean a field diverged
These are the re-keying codes. SB005, invalid invoice number, is the most common of the six in practice, and its cause is stated plainly in the GST portal's own guidance on refund for export of goods with payment of tax: the invoice numbers provided in Table 6A of FORM GSTR-1 must be the same as those given in the Shipping Bill. Not equivalent, not obviously the same document, the same string. An invoice raised as INV/2026/0417 in the accounting system and entered as 417 by whoever prepared the shipping bill data is a divergence, and the comparison has no way to know they are one invoice.
SB001 is the same failure one field over: the shipping bill number, the shipping bill date or the port code in Table 6A does not resolve to a live shipping bill at Customs. The GST portal's guidance requires the shipping bill number, the shipping bill date and the port code to be correctly provided for each invoice, and records that the port code is an alphanumeric six-character code as prescribed by ICEGATE. Both codes clear the same way, by amending the export invoice in the return so that it matches the shipping bill, and the rectification date becomes the deemed filing date under the proviso to rule 96(1).
SB002 and SB006: the two codes that are not yours to fix
These are manifest codes, and no amount of work on your own returns will move them. ICEGATE's IGST refund frequently asked questions state that filing of the export general manifest confirms that the export goods have physically left India, and that refund processing starts only after the manifest is successfully filed. SB002 means it has not been. The same document says the action is to contact your shipping line, airline or carrier immediately to file it, because the manifest is the carrier's filing and not the exporter's.
SB006 is the inland version of the same gap. Where a consignment is stuffed at an inland container depot and railed or trailered to a gateway port, there are two manifests, and the gateway one is the one Customs needs to confirm departure. ICEGATE's guidance says to contact the shipping line or carrier to file the gateway export general manifest electronically and, if required, to follow up with the gateway port Customs. Both codes are worth watching by port rather than by shipment, because a carrier who has missed one manifest has usually missed a batch of them.
SB003 and SB004: identity, and the duplicate
SB003 is a GSTIN mismatch, and it is a registration problem wearing a refund problem's clothes. ICEGATE's guidance notes that any user can take multiple GST registrations, but that use of an incorrect GSTIN on the shipping bills causes validation errors which stall the refund process. An exporter with a registration in more than one state, or one that has moved its principal place of business, will meet this the first time a shipping bill carries the old registration while the return is filed from the new one. The comparison is not lenient about which arm of the same legal person exported the goods.
SB004 is the code that mostly does not need you. ICEGATE describes it as duplicate transmission of invoice data from GSTN, and says no action is usually required if the earlier record has already been validated with SB000. It appears when the same invoice reaches Customs twice, typically after an amendment cycle. The discipline it argues for is checking what the earlier record did before you touch anything, because re-amending a duplicate that has already passed is how a settled shipping bill re-enters the queue.
Why can a shipping bill show SB000 and still pay nothing?
Because SB000 only says the comparison passed. ICEGATE's own frequently asked questions list the reasons a validated shipping bill still does not pay: the export was made under a letter of undertaking or bond, in which case there is no integrated tax to refund at all; the refund amount is below Rs 1,000; the bank account is not validated with the Public Financial Management System; or the importer exporter code is under suspension. The same document says separately that if an importer exporter code has any alert or suspension, the refund will not be processed until the suspension is revoked.
There is a further state after the scroll. ICEGATE records that where a shipping bill is rejected by the Public Financial Management System after scroll generation, it is marked PC, permanently cancelled, and pushed to the SCROLL_PC menu of the electronic data interchange system on the dashboard of the concerned Customs port officer for re-scrolling. The remedy at that point is a bank account detail on the ICEGATE portal, not a return amendment, which is why treating every unpaid refund as a return problem wastes the most time on the cases nearest to being paid.
The failure that never gets a code at all
The worst class of refund failure carries no SB code, because the record never reached Customs to be compared. The GST portal's own manual for tracking refund status describes a ledger based approach: it cumulates the integrated tax and cess from export and special economic zone invoices in Tables 6A, 9A and 6B of FORM GSTR-1 or GSTR-1A and compares that against the tax paid under Table 3.1(b) of FORM GSTR-3B across all periods. Eligible invoices are transmitted to ICEGATE only if the amount under Table 3.1(b) is equal to or greater than the amount from those tables, and in case of a negative balance the portal will not transmit any eligible invoice.
That is a single condition capable of silencing an entire book of refunds without producing one error code, and it is repaired in FORM GSTR-3B rather than in the export data. The portal exposes it under Services, then Refunds, then track status of invoice data to be shared with ICEGATE, where the export ledger can be viewed and failed invoices downloaded. Checking that ledger before working through codes is the correct order, because a shipping bill that was never transmitted has no status to explain. Table 6A of GSTR-1 takes that comparison apart field by field.
Where to go from here
Every code on this page is one pair of documents disagreeing, so the guides below pick up the same disagreement at the point where it was still cheap to prevent.
- The fields the codes are testing. Table 6A of GSTR-1 sets out which values must agree with the shipping bill, and how a wrong one is corrected.
- Whether you should be on this route at all. GST refund on exports: the two routes compares the with-payment route against the letter of undertaking route on cash cycle and document burden.
- The other document pair that stops money. Why your shipping bill is still showing as open in EDPMS covers the bank side of the same shipment.
- The document on the other side of the comparison. The shipping bill, field by field shows which of its values the return is being tested against.
- Why the field was wrong upstream. One invoice value, thirteen assertions traces the invoice number through every system that asks for it.
Purser holds the shipment record the invoice number, the shipping bill number and the port code are all projected from, and flags a divergence between the export invoice and the shipping bill data before the return goes anywhere. Purser never submits to a government portal and it never sends an outbound message without a recorded human approval event, so the return is still filed by whoever files it today and the shipping bill is still filed by your customs broker. What changes is that the two were compared against each other first. Purser Outbound is where that comparison lives.
Frequently asked questions
What does error SB005 mean on an export refund?
SB005 means invalid invoice number, per ICEGATE's published IGST refund frequently asked questions. It appears when the invoice number declared in Table 6A of FORM GSTR-1 is not the same string as the invoice number on the shipping bill. The GST portal's own refund guidance requires the two to be identical, and the mismatch is cleared by amending the export invoice in a subsequent return so that it matches the shipping bill.
What is the difference between SB002 and SB006?
SB002 means the export general manifest has not been filed, and SB006 means the gateway export general manifest is not available, which arises where a consignment moved through an inland container depot before reaching the gateway port. ICEGATE's guidance directs the exporter to contact the shipping line, airline or carrier in both cases, and for SB006 to follow up with the gateway port Customs, because the manifest is the carrier's filing rather than the exporter's.
My shipping bill shows SB000 but I have no refund. Why?
SB000 means the comparison passed, not that money is due. ICEGATE lists four reasons a validated shipping bill still does not pay: the export was made under a letter of undertaking or bond, so no integrated tax was paid; the refund amount is below Rs 1,000; the bank account is not validated with the Public Financial Management System; or the importer exporter code is under suspension.
Does an error code change the date my refund counts as filed?
Yes. The proviso to rule 96(1) of the CGST Rules provides that where there is a mismatch between the data furnished by the exporter in the Shipping Bill and those furnished in FORM GSTR-1, as amended in FORM GSTR-1A if any, the refund application is deemed to have been filed on the date on which the exporter rectifies the mismatch. The code therefore resets the filing date, not merely the payment date.
Can an export refund fail without showing any error code?
Yes, and it is the failure worth checking first. The GST portal cumulates integrated tax and cess from Tables 6A, 9A and 6B of FORM GSTR-1 or GSTR-1A against the tax paid under Table 3.1(b) of FORM GSTR-3B, and transmits invoices to ICEGATE only where the Table 3.1(b) amount is equal to or greater. On a negative export ledger balance the portal transmits nothing, so no shipping bill acquires a status at all.