IGST Scroll Sanctioned Status: How to Check It and Fix a Stuck Refund

When your IGST refund scroll status shows "sanctioned", it means Customs has validated your export data and authorised your bank to release the refund. A scroll is the payment instruction Customs generates once your shipping bill, the carrier's export manifest and your GST return all agree. If the status reads pending or failed instead, the data has not lined up yet, and the refund waits until you fix the mismatch. You can check the status yourself on ICEGATE, so you do not have to guess where the money is.

This guide is for Indian exporters who ship goods on payment of IGST and claim the tax back as a refund. If you are still deciding between the two export routes, our note on LUT vs IGST refund covers that choice. Here we focus on what happens after you have shipped: reading your scroll status, decoding the response code, and unsticking a refund that has stalled. Getting your export money into India is a separate step, and a receiving accounts setup handles that side while Customs handles the tax refund.

Exports are zero-rated under GST. When you export goods and pay IGST on them, that tax is refundable. You do not file a separate refund application for it. Your shipping bill itself is treated as the refund claim, and the system cross-checks it against your GST return.

A refund scroll is the document Customs generates to authorise that refund. Once the checks pass, the officer generates a scroll, the port approves it, and it moves to the Public Financial Management System (PFMS) for the money to be credited to your bank account. The scroll is the green light, not the payment itself.

There are two scrolls in the process, and knowing which one you are looking at saves confusion:

A shipping bill can appear in the temporary scroll but drop out of the final one, usually because bank account details need correcting. If that happens, you furnish correct bank details to the proper officer so the record updates in ICES.

The status you see maps to where your claim sits in that flow. In brief:

• Sanctioned / scroll generated: Customs validated your data and authorised the refund. Credit follows once PFMS clears your bank account.
• Pending: the claim is still being validated, or an upstream document (the manifest, or your GST return) has not been matched yet.
• Failed / not generated: validation did not pass because of a data mismatch or a transmission gap. You need to trace the response code and correct the source record.
• Scroll generated, credit failed: the refund was approved but the bank leg failed, most often because the account is not validated in PFMS or the IFSC changed.

The refund only flows when four things line up: the shipping bill, the Export General Manifest (EGM) filed by the carrier, your export invoices in GSTR-1 Table 6A, and a bank account validated through PFMS. If any one is off, the status stalls. Treat those four as your checklist before you chase anyone.

ICEGATE is the customs portal, and it shows the response code for each shipping bill once data has been received from GSTN. To check your scroll status:

• Log in to ICEGATE with your IEC-linked credentials.
• Go to Services → Enquiries → ICEGATE Enquiry Service.
• Open IGST Scroll Sanctioned Status.
• Enter your IEC, the shipping bill number, the port or location code, and a date range (the window is capped, so keep it short).
• Select Search to see the status and the sanctioned amount for each shipping bill.

Here is what a decoded enquiry line tells you, read left to right:

That single line is the whole story: three invoices are sanctioned and will be paid, two are stuck on an SB005 code, and your scroll is therefore partial. You do not wait for the two bad invoices to fix the three good ones; the cleared amount moves on its own.

Checking on the GST portal

The GST portal shows the same journey from the returns side. Log in, then go to Services → Refunds → Track status of invoice data to be shared with ICEGATE. This tells you whether your Table 6A invoice data was transmitted to Customs and whether it was accepted or rejected, which is the first place a mismatch shows up.

The response code tells you exactly why a shipping bill is or is not in the scroll. This is where many summaries online get it wrong, so the definitions below follow the CBIC customs guidance rather than a paraphrase.

A quick note on the two codes people mix up: SB003 is the GSTIN mismatch, SB005 is the invoice-number mismatch. Some widely-shared tables swap them, which sends exporters to fix the wrong record. Read the code, not the summary.

If the status is stuck, the cause is almost always one of these, roughly in order of how often exporters hit them:

• An SBxxx code on the shipping bill. A mismatch between GSTR-1 and the shipping bill (invoice number, GSTIN, or SB number) blocks that invoice. Fix the source record as per the table above.
• EGM not filed or not linked. No manifest, no validation. The carrier controls this, so chase the shipping line, not Customs.
• Bank account not validated in PFMS. The scroll can generate and the credit still fail. This is common when a public-sector bank merges and your IFSC changes. Ask your Customs House Agent (CHA) to have the port update your PFMS bank record.
• A "risky exporter" hold. The Directorate General of Analytics and Risk Management (DGARM) can flag an exporter for manual verification, which parks the refund until the check clears. If nothing else explains the delay, this is worth ruling out with your jurisdictional officer.

The IGST refund gives you your tax back. It does not put your buyer's payment in your account, and it does not close your FEMA obligations. Those run in parallel, and a refund can be questioned later if the export proceeds are never realised.

When your customer pays, that money has to reach India within the FEMA timeline for realisation of export proceeds, and your bank issues a bank realisation certificate once it does. The inward payment is reported under the right RBI code, typically the P0102 purpose code for realisation of export bills for goods, and it is tracked in EDPMS until the entry is closed. For the GST refund itself, the FIRC for GST refund is the document that evidences the foreign inward remittance.

This is where a cross-border collection setup earns its place. It does not touch your Customs scroll, but it gets the money in on the next business day, reports it under the correct purpose code, and issues an eFIRA automatically, so the realisation half of your paperwork is clean while you deal with the tax half. Whether it is a goods or services export, the inward remittance has to be documented either way, and if you also file SOFTEX rather than a shipping bill, our note on softex vs shipping bill explains which applies to you.

Once your data is clean, the scroll is usually generated within a couple of weeks of the return and manifest being matched, and the credit follows shortly after PFMS validates your bank account. The variable is not the scroll run, which is regular; it is how long the mismatch on your side takes to clear. A bill sitting on SB005 can wait for months, while a clean SB000 bill moves in the next scroll cycle.

So the practical timeline is set by you. Check the status early, act on the code the day you see it, and the refund tends to arrive on schedule rather than becoming a quarter-end scramble.

Your IGST scroll status is a status you can read yourself, and it almost always points to a fix within your reach: a code to reconcile, a manifest to file, or a bank record to validate. Check it early on ICEGATE, act on the response code the same day, and keep your realisation paperwork clean in parallel so nothing about the export raises a question later.