Customs & Clearance
IGCR Clearance SVB Registration ICEGATE Registration AD Code Registration MOOWR Scheme Importer of Record (IOR)Codes, DSC & Setup
IEC Registration IEC Renewal DGFT Digital Signature Class 3 DSC Export Promotion Bank A/c Foreign Company SetupEPR (CPCB)
EPR Plastic Waste EPR E-Waste EPR Battery WasteCertifications & Licenses
BIS Certification WPC Certificate FSSAI Export License Certificate of Origin View all services →
IGST refund status is the stage your export refund has reached inside the Indian Customs EDI System, from validation of the shipping bill against your GST return through to the scroll that releases money to your bank. If you exported on payment of IGST and nothing has landed, two enquiry screens tell you exactly where it stopped, and most guides send you to the wrong one.
Nobody at Customs sanctions your claim by hand. Under Rule 96 of the CGST Rules, the shipping bill is itself the refund application, and the system validates it automatically. That is why a clean claim pays in days and a claim with one field out of step sits silently for months.
Everything on this page is checked against the ICEGATE IGST Refund FAQs published by the Directorate General of Systems, the CBIC circulars named in each section, and the judgments cited. Where the widely circulated version of a fact is wrong, this page says so and shows the official position.
This page covers the refund of IGST paid on export of goods, where the shipping bill is the claim. It does not cover the LUT or bond route, where refund of unutilised input tax credit is claimed separately in Form GST RFD-01.
You will get value from this page if you are:
For goods exported on payment of tax there is no separate refund application. Under Rule 96 of the CGST Rules, the shipping bill is deemed to be the refund application. The system validates it against your GST return, and IGST refund status is simply the point that automated process has reached.
The system does not write to you when it rejects a record. It sets a code and moves on. You have to go and look, which is what the rest of this page is about.
| Term | Meaning |
| ICES | Indian Customs EDI System, the customs system that validates the claim and generates the scroll |
| ICEGATE | The national trade portal where you check IGST refund status. Now ICEGATE 2.0 |
| EGM | Export General Manifest, filed by the carrier to confirm the goods left India |
| Gateway EGM | The EGM filed at the gateway port for cargo that started at an ICD |
| Temporary scroll | The first scroll. The shipping bill is eligible and queued, but not yet payable |
| Permanent scroll | The final scroll. This is the one that goes to PFMS and pays |
| PFMS | Public Financial Management System, which validates your bank account before payment |
| SB000 to SB006 | The response codes ICES returns against each shipping bill |
| Table 6A | The export invoice table in GSTR-1 that ICES matches against your shipping bill |
| EDPMS | Export Data Processing and Monitoring System, where your export proceeds are tracked |
An IGST refund flows only when four records agree. Your IGST refund status is really a report on which of the four is out of step.
If you have not linked the account yet, Export Promotion Bank Account registration and AD Code registration are the two filings that make the refund possible in the first place.
Two different enquiries do two different jobs here. Confusing them is the single most common reason exporters believe the portal is broken, and most published guides name only one of the two.
The refund enquiries sit behind login. If you do not have credentials, ICEGATE registration comes first, and it needs a valid IEC. The legacy portal is retired, so a bookmark to an old enquiry page will not work. Everything runs through ICEGATE 2.0.
From the dashboard go to Services, then Enquiries, then the ICEGATE Enquiry Service. Both refund enquiries live inside it.
This is the screen that returns the SB000 to SB006 response code against each shipping bill. The full path is Login 2.0, then dashboard, then Services, then Enquiries, then ICEGATE Enquiry Service, then IGST Validation Enquiry. It is set out at question 18 of the ICEGATE IGST Refund FAQs, which ICEGATE updated in April 2026.
Same menu, different enquiry, and it is question 19 of the same FAQ. Enter the location code and the shipping bill details and search. A scroll number here means Customs has cleared the claim for payment. Validation and scroll are two separate stages. The scroll screen does not carry the response code, so an exporter who only checks it will never learn why a claim failed.
SB000 means validated. Anything else is a blocker with a specific cause, set out below. A shipping bill sitting at SB000 with no scroll number against it is a different problem entirely, and it has its own section further down.
If the cargo moved from an ICD, check the gateway EGM. Gateway EGM pendency is one of the most common reasons an otherwise clean shipping bill sits unpaid. Where it is pending, the shipping line has to file a supplementary EGM at the gateway port.
Once you know the code, the correction happens where the data originated. An invoice mismatch is fixed through the customs officer interface at the port. A GSTIN or port code error is fixed on the GST side. Refreshing the ICEGATE screen changes nothing.
Half of all IGST refund failures never reach Customs at all, because the invoice data was never transmitted from GSTN. ICEGATE cannot show you a shipping bill it has not received, so a blank customs enquiry is not proof that Customs is at fault.
On the GST portal, log in and go to Services, then Refunds, then Track status of invoice data to be shared with ICEGATE. Select the financial year and month, and quarterly filers pick the last month of the quarter, then search. This screen reports the transmission status and any validation error raised on the GSTN side before the record left for Customs.
Read the two together. A record that is not transmitted is a GST side fix. A record that is transmitted and carries a customs response code is a customs side fix. A complete IGST refund status check covers both screens, and working the wrong side is how months get lost.
This table is the practical core of any IGST refund status check. The first seven codes are the official ICES validation codes as published by the Directorate General of Systems, and SBV00 is official too. SB009 and SB104 are not in the published ICES code table; both are marked accordingly below. Verified 29-08-2026 against the ICEGATE IGST Refund FAQ of April 2026, the Delhi Customs export FAQ and the DG Systems step by step guide v3.0.
| Code | Official meaning | What it takes to clear |
| SB000 | Successfully validated | Nothing. If no money follows, the block is downstream. See the sections below |
| SB001 | Invalid shipping bill details | Correct the shipping bill number, date or port code reported in GSTR-1 |
| SB002 | EGM not filed | The carrier files the EGM. For ICD cargo, the gateway EGM must be filed in ICES at the gateway port |
| SB003 | GSTIN mismatch between the shipping bill and the GST return | Correct the GSTIN at source so the two agree. Where the shipping bill cannot be amended, the port of export is approached on the merits |
| SB004 | Record already received, a duplicate transmission from GSTN | Usually no action if the earlier record already validated at SB000. Confirm which record scrolled |
| SB005 | Invalid invoice number | The most common code by far. Permanently rectifiable through the customs officer interface at the port of export |
| SB006 | Gateway EGM not available | Supplementary EGM at the gateway port, filed electronically by the line |
| SBV00 | Shipping bill was already validated successfully | No action. Confirm the scroll position instead |
| SB104 | Port code is not valid | A GST side correction, raised with the GSTN helpdesk. Not part of the official ICES code table but returned in practice |
This matters because acting on the wrong definition sends you to the wrong desk. A widely repeated version of this table, which currently feeds several of the top search results and the AI summaries built on them, swaps the meanings of SB001, SB003 and SB005. The official ICEGATE FAQ is unambiguous.
| Code | Commonly published, and wrong | Official ICEGATE definition |
| SB001 | Invalid invoice details | Invalid shipping bill details. The shipping bill number, date or port code reported in GSTR-1 does not match |
| SB003 | Rarely listed at all | GSTIN mismatch between the shipping bill and the GST return |
| SB005 | GSTIN mismatch | Invalid invoice number. The invoice number on the shipping bill does not match the one reported in GSTR-1 |
If you have been chasing a GSTIN correction because someone told you SB005 means a GSTIN mismatch, that is why nothing moved. SB005 is an invoice number problem and it is fixed at the port of export, not with the GSTN helpdesk. fixed at the port of export, not with the GSTN helpdesk.
SB005 is an invoice number mismatch between the shipping bill and GSTR-1, and it is the only code with a permanent statutory fix. Circular No. 05/2021-Customs dated 17 February 2021 made the customs officer interface available for all past shipping bills, irrespective of filing date, on payment of Rs. 1,000 per shipping bill. The document set is not in Circular 05/2021 itself: it comes from Circulars 05/2018-Customs and 08/2018-Customs, which that circular carries forward. The officer needs a self certified copy of GSTR-1 or Table 6A, the corresponding GSTR-3B, and a concordance table tying each shipping bill invoice to the invoice reported in the GST return. The facility is for SB005 alone; it does not extend to any other code.
SB003 is different, and it is worth being precise about it. The officer interface route for GSTIN mismatches came from para 2 of Circular No. 15/2018-Customs, extended by Circular No. 22/2018-Customs dated 18 July 2018 to cases where PAN was quoted in place of GSTIN. Both were date limited. Circular 15/2018-Customs dated 6 June 2018 covered shipping bills filed up to 30 April 2018, and Circular 22/2018-Customs extended that to 30 June 2018. Neither limit has since been lifted. Circular 05/2021 made the interface permanent for SB005 alone. An SB003 case today is corrected at source and taken to the port on the merits.
Two scrolls exist, and confusing them is why exporters believe a refund has been sanctioned when it has not.
A shipping bill that appears in the temporary scroll but never in the permanent one almost always has a bank account that has not cleared PFMS validation. Fixing the account registration releases it.
There is one further stage most exporters never hear about. Where PFMS rejects the account after the scroll has been generated, the shipping bill is marked PC, permanently cancelled, in the system and pushed to the SCROLL_PC menu on the dashboard of the customs port officer for re scrolling.
The status remains visible on ICEGATE after login. Correcting the bank registration is what allows the re scroll to happen. Nothing re scrolls on its own, and this is the single most common reason a refund appears to have been sanctioned and then vanishes.
pushed to the SCROLL_PC menu on the dashboard of the customs port officer for re scrolling. The status remains visible on ICEGATE after login. Correcting the bank registration is what allows the re scroll to happen. Nothing re scrolls on its own, and this is the single most common reason a refund appears to have been sanctioned and then vanishes.
PFMS is where a technically perfect claim goes to die, and it is the part exporters have the most direct control over. It is also the reason an IGST refund status can read as sanctioned while the bank shows nothing.
The account registered for refunds and incentives against your IEC on ICEGATE must clear PFMS validation before any scroll can pay. Validation fails for ordinary reasons: the account name does not match the IEC holder exactly, the IFSC changed after a bank merger, the account was closed or converted, or the account was never registered as an export incentive account in the first place.
Three checks worth running before you escalate anything:
Where validation has failed, re-register the account on ICEGATE, confirm PFMS validation has cleared, and then ask the port officer to re-scroll the affected shipping bills from the SCROLL_PC menu. enu.
SB000 with no payment is the most frustrating IGST refund status of all. There are a limited number of causes.
In the first four cases the scroll amount goes to zero automatically and the shipping bill drops out of the scroll. Nothing on the portal tells you which one applies, which is why the shipping bill, the drawback claim and the GST return have to be read together rather than one at a time. to zero automatically and the shipping bill drops out of the scroll.
Nothing on the portal tells you which one applies, which is why the shipping bill, the drawback claim and the GST return have to be read together rather than one at a time.
A different problem from a blocked claim, and one exporters routinely write off. Where the IGST credited is less than the IGST actually paid, the route depends on why the shortfall arose.
Where the price of the exported goods was revised upward after export and additional IGST was paid on a supplementary invoice or debit note, the refund of that additional tax is claimed in Form GST RFD-01 with your jurisdictional GST officer. Circular No. 226/20/2024-GST dated 11 July 2024 sets out the mechanism.
Until a dedicated category is live on the portal, which was still the position when this was re-checked on 29 August 2026, the claim is filed under “Any other”, with a remark identifying it as a refund of additional IGST paid on upward price revision. It must be filed within two years of the relevant date under clause (a) of Explanation 2 to Section 54.
The claim needs the shipping bill, the original invoices, the contract or document evidencing the revision, the debit note or supplementary invoice, proof of payment of the additional IGST with interest, the FIRC for the additional remittance, a chartered accountant certificate linking the remittance to the revision, and Statements 9A and 9B.
Where the shortfall came instead from a declaration or processing error on the shipping bill itself, note that the Revised Refund Request route under Circular No. 40/2018-Customs dated 24 October 2018 closed for shipping bills filed after 15 November 2018 and has not been reopened.
Circular 26/2019-Customs and Circular 05/2021-Customs extended only the SB005 officer interface, not the Revised Refund Request. Older cases still sitting on a short scroll are pursued with the IGST Refund Cell at the custom house on the merits. A short credit is not the end of the claim.
Not every stalled IGST refund status is a data mismatch. Where the Risk Management Centre for Customs or DGARM flags an exporter as risky, an alert is inserted in the system and the refund scroll is kept in abeyance pending verification. The status screen will not say so in plain language, and in practice exporters find out only when the money never arrives.
Two circulars set the timeframes. Circular No. 16/2019-Customs dated 17 June 2019 requires verification in red flagged cases to be completed within 30 days, with a further 5 working days for the Chief Commissioner to forward the reports to the Risk Management Centre for Customs.
Circular No. 131/1/2020-GST dated 23 January 2020 tightened the process on the GST side: verification is to be completed within 14 working days of the exporter furnishing the prescribed information, and where it is not, the exporter may escalate to the jurisdictional Chief Commissioner, who is to have it completed within a further 7 working days.
Two points matter commercially. First, the alert is not a finding against you, and it is lifted once the No Objection is received. Second, and more useful, being red flagged does not remove your entitlement to interest for the period of the delay.
A Rule 96(10) notice is one of the few things that can hold up an IGST refund status even when every code reads clean. The rule restricted the IGST refund route for exporters who had imported inputs under concessional notifications. It was omitted with effect from 8 October 2024 by Notification No. 20/2024-Central Tax, along with Rules 89(4A) and 89(4B), and the omission carried no saving clause.
In M/s Goodluck India Limited v. Union of India, 2026 INSC 821, SLP (C) No. 24550 of 2025, decided on 6 August 2026, the Supreme Court held that the omission applies to proceedings that were still pending, precisely because no saving clause was provided. The Court recorded that the legislature brought in no saving clause and no sunset clause when sub-rule (10) of Rule 96 was omitted. Open notices and unadjudicated demands under the omitted rule are affected.
There is also a route CBIC itself provided a month before the omission. Where the exposure arose because inputs were imported under Notification 78/2017-Customs or 79/2017-Customs without paying IGST and compensation cess, Circular No. 233/27/2024-GST dated 10 September 2024 allows the position to be regularised: if the IGST and compensation cess are subsequently paid with interest and the bill of entry is reassessed by the customs authorities, the benefit of those notifications is treated as not having been availed, and the IGST refund on the export is not hit.
This is the part most exporters do not know, and it changes how you should read a late IGST refund status: it is worth money.
Because the shipping bill is deemed to be the refund application, the sixty day period runs from the shipping bill itself. Section 56 of the CGST Act then provides interest where the refund is not made within sixty days of the application. The section itself says at a rate not exceeding six percent as may be notified; six percent is the notified rate, under Notification No. 13/2017-Central Tax. Nine percent applies where the refund arises from an order in appeal or from a court.
In Anita Agarwal v. Union of India, Writ Petition No. 1474 of 2023, decided on 14 November 2024, the Bombay High Court held that interest under Section 56 runs from the expiry of sixty days from the date of the shipping bill until the date the refund is granted, and that the exporter having been red flagged in the meantime did not defeat that entitlement.
The Court reasoned that the department had used the exporter’s money throughout and that Section 56 contains no exclusion for periods of investigation. It allowed a deduction only for the thirty day verification window that the 17 June 2019 circular itself permits.
The practical consequence: if your refund sat on a departmental blocker rather than your own error, and the money came late, interest is arguable, and it is statutory rather than discretionary. Keep dated screenshots of the status screen, because the computation depends on establishing when the delay started and who caused it.
A refund that has been paid can still come back to bite you, and reading your IGST refund status as final the day the money lands is a mistake, since this is the half exporters forget.
Export proceeds have to be realised within the FEMA timeline and reported against the correct RBI purpose code, and the inward remittance is tracked in EDPMS against the shipping bill. Where the shipping bill stays open in EDPMS because the remittance was never closed against it, or was closed under the wrong purpose code, the export can be treated as unrealised. Rule 96B of the CGST Rules then allows recovery of a refund already granted where the proceeds are not realised within the period allowed under FEMA.
Keep the FIRC or the bank realisation certificate against each shipping bill, and reconcile EDPMS at the same time as you reconcile the refund. A refund file that is clean on the customs side and open on the realisation side is not finished.
How long an IGST refund status should take to move has a statutory answer and a practical one, and they are different.
The statutory answer: because the shipping bill is the refund application, the sixty day period in Section 54 runs from the date of the shipping bill, and interest under Section 56 accrues from day sixty one.
The practical answer: a clean claim, with the EGM filed and the GST return data transmitted and matched, commonly scrolls within one to three weeks of the EGM. Anything materially beyond that is not slowness, it is a blocker you have not found yet. The right response to a late refund is to pull the IGST refund status and read the code, not to wait another month.
Escalation only works when it is aimed at the right desk, and the desk depends on where the record actually is. Read your IGST refund status first, then pick the row below that matches it.
| Where the record is stuck | Who owns it | How to escalate |
| Not transmitted from GSTN | GSTN | Raise a ticket with the GSTN helpdesk quoting the return period and the transmission error |
| SB002 or SB006 | The shipping line or carrier | Written request to the line for the EGM or supplementary EGM, copied to the gateway port |
| SB005 or SB003 | The port of export | Officer interface submission to the Assistant or Deputy Commissioner, with the concordance set |
| Bank or PFMS | ICEGATE and your bank | Update the refund and incentive account on ICEGATE, then ask the port officer to re-scroll |
| Risky exporter verification | Jurisdictional CGST formation | Escalate to the Chief Commissioner once the 14 working day window in Circular 131/1/2020-GST has passed |
| No response from anyone | The grievance system | ICEGATE helpdesk ticket first, then a CPGRAMS grievance, and a written representation to the IGST Refund Cell at the custom house |
Put every escalation in writing and keep the acknowledgement. If the claim later goes to interest under Section 56, the correspondence is what establishes that the delay was not yours.
| Problem | Why it happens | What to do |
| Status stuck at SB005 for months | Invoice number on the shipping bill does not match GSTR-1 | Officer interface at the port of export under Circular 05/2021-Customs, with the invoice concordance set |
| Told SB005 means a GSTIN mismatch | A widely republished error in the code table | Treat it as an invoice number problem and go to the port, not the GSTN helpdesk |
| Nothing at all on the ICEGATE enquiry | The record was never transmitted from GSTN | Check Services, Refunds, Track status of invoice data to be shared with ICEGATE on the GST portal |
| SB002 or SB006 on ICD cargo | Gateway EGM not filed in ICES, or filed manually | Ask the shipping line for a supplementary EGM at the gateway port |
| Scroll generated, no credit | Bank account not validated by PFMS, or account changed after registration | Re-register the account and IFSC on ICEGATE and confirm PFMS validation |
| Scroll generated, then reversed | PFMS rejected the account after scrolling; shipping bill marked PC | Correct the bank registration and have the port officer re-scroll from the SCROLL_PC menu |
| SB000 but no scroll number | Ineligible export, partial invoice validation, legacy drawback conflict, claim under Rs. 1,000, or an alert on the IEC | Read the shipping bill, the drawback claim and the GST return together to identify which applies |
| Refunds stopped after a bank merger | The pre merger IFSC is still mapped against the IEC | Update the IFSC on ICEGATE and re-confirm the AD Code mapping at the port |
| Refund credited but short of the IGST paid | Upward price revision after export, or a declaration error on the shipping bill | File RFD-01 under Circular 226/20/2024-GST for a price revision. For older declaration errors, take it to the IGST Refund Cell |
| Rule 96(10) notice still open | Proceedings begun before the rule was omitted | Raise the omission and the Goodluck India judgment, and check whether Circular 233/27/2024-GST regularises the position |
| Nothing wrong on the data, still no money | Risky exporter alert holding the scroll in abeyance | Pursue verification against the timelines in Circular 16/2019-Customs and Circular 131/1/2020-GST |
| Refund finally received, months late | Departmental delay rather than exporter error | Compute interest under Section 56 from the 61st day after the shipping bill and claim it |
| Refund received, then a recovery notice | Export proceeds not realised or not closed in EDPMS | Close the shipping bill in EDPMS against the FIRC and the correct purpose code |
Reading an IGST refund status correctly is only the first step; JPARKS INDIA has handled EXIM compliance since 2019, backed by S.K. Agency, AEO-LO accredited customs brokers operating since 1990. That combination matters on a refund file, because the fix almost always sits at the port rather than on the portal.
We take the claim set whole. Your IEC and port list produce a shipping bill level status register covering both the GST side and the customs side. Each blocked record gets a written cause and a fix. Where the fix is an officer interface submission we prepare the concordance and file it at the port of export. Where it is a gateway EGM we chase the line. Where it is a bank mapping we correct the registration and get the shipping bill re-scrolled. Where the delay was the department’s, we compute the interest and claim it.
Learn more about our EXIM compliance services, or speak to an Import Export Consultant in India.
IGST refund status is the stage your export refund has reached inside the customs system, from validation of the shipping bill against your GST return through to the scroll that releases payment. For goods exported on payment of tax the shipping bill is the refund application, so the status is generated automatically rather than against a claim you file.
After logging in with your IEC credentials, go to Services, then Enquiries, then the ICEGATE Enquiry Service. IGST Validation Enquiry gives you the response code. IGST Scroll Sanctioned Status gives you the scroll position. Both paths are set out in the ICEGATE IGST Refund FAQs at questions 18 and 19.
Validation and payment are two separate stages. IGST Validation Enquiry tells you whether the shipping bill matched your GST return and returns the SB000 to SB006 code. IGST Scroll Sanctioned Status tells you whether Customs has generated a scroll to pay it. A claim can pass the first and stall at the second, and the scroll screen never shows you the response code.
Log in to the GST portal and go to Services, then Refunds, then Track status of invoice data to be shared with ICEGATE. Select the financial year and month, and quarterly filers choose the last month of the quarter. This shows whether your invoice data was transmitted to Customs at all, and any error raised before it left GSTN.
SB005 means the invoice number on the shipping bill does not match the invoice number reported in GSTR-1. It does not mean a GSTIN mismatch, which is SB003, although that error is widely republished. SB005 is corrected through the customs officer interface at the port of export under Circular No. 05/2021-Customs, which made the facility permanent for all past shipping bills on payment of Rs. 1,000 per shipping bill.
SB000 means validated, not paid. The usual causes are an export made under LUT or bond, partial validation where a shipping bill covers several invoices, a legacy higher or composite drawback claim on the same shipping bill, an IGST claim below Rs. 1,000, a bank account that has not cleared PFMS validation, or an alert or suspension running against your IEC.
Yes. Where goods are exported on payment of integrated tax, the exporter is entitled to a refund of that tax, and under Rule 96 the shipping bill is deemed to be the refund application. Exports made under a LUT or bond are a different route: no IGST is paid, and the refund claimed is of unutilised input tax credit in Form GST RFD-01.
Not for goods exported on payment of IGST, because the shipping bill is deemed to be the refund application. RFD-01 applies to the LUT or bond route, and to a refund of additional IGST paid on an upward price revision after export under Circular No. 226/20/2024-GST.
The statutory period is sixty days, running from the date of the shipping bill because that is the refund application, after which interest accrues under Section 56. In practice a clean claim scrolls within one to three weeks of the EGM being filed and the GST data matching. If yours is materially beyond that, the cause is a blocker rather than a queue, so check the response code.
PFMS is the government system that validates your bank account before a scroll can pay. Validation fails when the account name does not match the IEC holder, the IFSC changed after a bank merger, the account was closed, or the account was never registered for refunds and incentives on ICEGATE. Until it clears, a shipping bill can sit in the temporary scroll and never reach the permanent one.
Free consultation
Talk to an EXIM expert
Tell us what you are stuck with. We usually reply the same business day.
Prefer WhatsApp? Chat with us instead
5.0 ★ rating · 126 Google reviews · EXIM specialists since 1990 · Your details stay private
