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, carrier manifest and GST return align.
This guide covers how to read your scroll status on ICEGATE, what each status means, how to decode the SB response codes, and how to fix a refund that is stuck, whether you export under a LUT or an IGST refund claim.
What is an IGST refund scroll?
Exports are zero-rated under GST. When exporters pay IGST on goods, that tax becomes refundable through the shipping bill itself, which is treated automatically as the refund claim. A refund scroll is the Customs document that authorises that refund.
Once the checks pass, it moves to the Public Financial Management System (PFMS) for credit to your bank account.
Two scrolls exist in this process:
| Scroll type | Who generates it | Meaning |
|---|---|---|
| Temporary scroll | Officer in the CLK role in ICES | Shipping bills picked for a refund run; amounts provisional, not yet paid |
| Final (permanent) scroll | Officer in the AC_DBK role in ICES | Refund confirmed and sent to PFMS for credit to a validated bank account |
A shipping bill can appear in the temporary scroll but drop from the final one if the bank account details need correction.
The amount on each bill traces back to the export invoice you filed, so a mismatch there is where most holds begin.
Who actually gets an IGST refund scroll?
Not every exporter sees a scroll. Exporters of goods who pay IGST on the shipment claim it back through the shipping bill, and that is what generates a scroll.
Exporters who ship under a Letter of Undertaking (LUT) pay no IGST, so there is no scroll to track; they claim unutilised input tax credit instead.
Service exporters usually fall in this second group and follow the export of services under GST route rather than a scroll.
So if you paid IGST on an export of goods and see no scroll after your returns are filed, that is a problem to trace. If you shipped under an LUT, a missing scroll is simply expected.
What each scroll status means
Read your status against this quick reference, then act on the row you land in:
| Status | What it means | Your next step |
|---|---|---|
| <strong>Sanctioned / scroll generated</strong> | Customs validated your data and authorised the refund | Wait for PFMS to clear your bank account; credit follows |
| <strong>Pending</strong> | Claim still validating, or the manifest or GST return has not matched yet | Check the response code and the EGM; fix the source record |
| <strong>Failed / not generated</strong> | Validation failed on a data mismatch or transmission gap | Trace the SB response code and correct the source record |
| <strong>Scroll generated, credit failed</strong> | Refund approved but the bank leg failed | Validate your account in PFMS, usually a changed IFSC |
Four elements must align before a scroll generates: the shipping bill, the Export General Manifest (EGM), your export invoices in GSTR-1 Table 6A, and a bank account validated through PFMS.
The documents that must align
Before you chase Customs, confirm each of these is clean, because the scroll runs only when all four agree:
- Shipping bill filed with the correct IEC, GSTIN and invoice numbers.
- EGM filed by your carrier and linked to the shipping bill.
- GSTR-1 Table 6A carrying the same invoice numbers as the shipping bill.
- Bank account validated in PFMS, with the IFSC currently in use.
From shipping bill to bank credit: the stages
A refund moves through a fixed sequence, and knowing which stage you are at tells you who to chase:
- Shipping bill filed with IGST paid, marked as the refund claim.
- EGM filed by the carrier and linked to the bill.
- GSTR-1 Table 6A transmitted and matched against Customs records.
- Temporary scroll picks up the validated bills.
- Final scroll confirms the refund and sends it to PFMS.
- PFMS credit lands in your validated bank account.
A hold at stage 3 is a data fix on your side; a hold at stage 6 is a bank-validation fix.
The money only closes out once the export bill is realised too, which runs through your export bill collection in parallel.
How to check IGST scroll status on ICEGATE
Follow these steps to verify your scroll status:
- Log in to ICEGATE using your IEC-linked credentials.
- Navigate to Services → Enquiries → ICEGATE Enquiry Service.
- Open IGST Scroll Sanctioned Status.
- Enter your IEC, shipping bill number, port or location code and a short date range.
- Select Search to view the status and sanctioned amount for each bill.
A decoded enquiry line reads: SB No. 4512367 | Port INNSA1 | Invoices 5 | Validated (SB000) 3 | SB005 2 | Scroll: partial.
This shows three invoices cleared and in the scroll, and two held on an invoice-number mismatch. The three good invoices proceed independently, so a partial scroll still releases the clean part of your refund.
Checking on the GST portal
Log in to the GST portal, then open Services → Refunds → Track status of invoice data to be shared with ICEGATE.
This shows whether your Table 6A invoice data was transmitted to Customs and whether it was accepted or rejected. This is where a mismatch first surfaces, often days before it shows on ICEGATE.
IGST refund response codes, decoded correctly
| Code | Official meaning | Action required |
|---|---|---|
| <strong>SB000</strong> | Successfully validated. GSTIN, shipping bill number and invoice numbers match between GSTN and Customs. | Nothing. This code signals readiness for the refund scroll. |
| <strong>SB001</strong> | Invalid shipping bill number. The SB number in the GST return does not match Customs records. | Correct the shipping bill number in your GSTR-1 through an amendment. |
| <strong>SB002</strong> | EGM not filed. The carrier has not filed the Export General Manifest. | Ask the shipping line or carrier to file the EGM. |
| <strong>SB003</strong> | GSTIN mismatch. The GSTIN on the shipping bill differs from the GSTIN filing the GST return. | Amend GSTR-1 (Form 9A route) or use the CBIC correction facility with an undertaking. |
| <strong>SB004</strong> | Record already received. Invoice already processed, often a duplicate transmission. | Usually no action; verify the earlier record was paid. |
| <strong>SB005</strong> | Invalid invoice number. The invoice number in GSTR-1 does not match the one on the shipping bill. The most common hold. | Reconcile the numbers, then amend GSTR-1 or seek a shipping bill amendment through Customs. |
| <strong>SB006</strong> | Gateway EGM unavailable or filed with an error at the gateway port. | The shipping line files or revalidates the gateway EGM, approved by the gateway port officer. |
A distinction that trips up many exporters: SB003 is the GSTIN mismatch, SB005 is the invoice-number mismatch. Many shared tables swap these, which sends exporters to fix the wrong record.
Fixing the most common hold: SB005, step by step
SB005 is the invoice-number mismatch, and it stalls more refunds than any other code. The fix is a reconciliation, not an escalation:
- Pull the invoice number exactly as it appears on the shipping bill.
- Compare it with the invoice number reported in GSTR-1 Table 6A for the same export.
- If they differ, amend the GSTR-1 record through Table 9A in a later return so the numbers match.
- Where the shipping bill itself carries the error, file a shipping bill amendment with Customs instead.
- Wait for the next scroll run; the corrected bill is picked up automatically once the numbers agree.
Most SB005 holds come down to a stray prefix, a missing zero or a manual typo, so the correction is small even when the delay has felt long.
To stop it recurring, use the same invoice-numbering format in your billing system and your GSTR-1 filing, and reconcile the two before each return rather than after a refund stalls.
A single shared numbering rule across the shipping bill, the tax invoice and Table 6A removes the most common cause of a stuck scroll before it ever reaches Customs.
Why your scroll is not sanctioned yet
A stuck refund usually traces to one of these causes:
- An SBxxx code on the shipping bill. A mismatch between GSTR-1 and the shipping bill on the invoice number, GSTIN or SB number. Fix the source record against the response-code table above.
- EGM not filed or not linked. Without a manifest, validation cannot happen. Chase the shipping line, not Customs.
- Bank account not validated in PFMS. The scroll can generate while the credit still fails, common when a public-sector bank merges and the 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 exporters for manual verification, parking the refund until the check clears.
The scroll is Customs' job, but the data is yours. Customs generates the scroll automatically once records agree.
It cannot fix a wrong invoice number or an unvalidated bank account, so nearly every stuck refund traces to a source record you or your carrier control.
When no code explains the delay
If ICEGATE shows no SB code and both the EGM and your bank details are clean, the hold is usually a manual one.
A "risky exporter" flag from DGARM parks the refund for verification, and only your jurisdictional GST officer can release it.
Track your inward realisation in edpms vs idpms meanwhile, because an open realisation entry is a common reason a refund is held for a second look.
Raise a written grievance on the ICEGATE or CPGRAMS portal if the officer does not respond within a reasonable window.
How long an IGST refund scroll takes
Once your data is clean, the scroll typically generates within a couple of weeks of the return and manifest being matched. Credit follows shortly after PFMS validates your bank account.
The variable is not the scroll run, which is regular, but how long the mismatches on your side take to clear. A bill stuck on SB005 can wait months, while a clean SB000 bill moves in the next scroll cycle.
Check the status early, act on the code the same day, and the refund tends to arrive on schedule rather than becoming a quarter-end scramble.
The realisation trail that sits alongside your refund
The IGST refund returns your tax, but it does not deposit your buyer's payment into your account, and it does not close your FEMA obligations.
These run in parallel, and a refund can be questioned later if the export proceeds are never realised.
When your customer pays, that money must reach India within the FEMA timeline for the realisation of export proceeds. The inward payment is reported under the right RBI purpose code, typically P0102 for the realisation of export bills for goods.
Customs and your bank then track that entry in EDPMS until it is closed. For the GST refund itself, a FIRC for GST refund evidences the foreign inward remittance.
Keeping that realisation half clean matters as much as the scroll. A foreign inward remittance certificate that arrives late, or a receipt logged under the wrong code, can reopen a refund you have already banked.
This is the same evidence trail that decides how FIRC works once your export bill is collected.
A cross-border collection setup does not touch your Customs scroll, but it gets the money in on the next business day, reports it under the correct code, and issues an eFIRA automatically.
Routing receipts through dedicated receiving accounts keeps the realisation half of your paperwork clean while you handle the tax half. Getting that inward flow right is also how you sidestep the mistakes exporters make receiving international payments.
Get your export proceeds in cleanly, on the next business day
RBI PA-CB authorised
Auto eFIRA & FIRC
Correct purpose code
Frequently asked questions
It means Customs has validated your export data and created the refund instruction. The amount then moves to PFMS for credit to your bank account, so payment usually follows soon after.
Most often a response code (SB003, SB005 and similar), an unfiled EGM, or a bank account not validated in PFMS. Check the code on ICEGATE and fix the source record.
SB003 is a GSTIN mismatch between the shipping bill and your GST return. SB005 is an invalid invoice number, where the invoice in GSTR-1 does not match the shipping bill.
The bank leg likely failed in PFMS. Ask your CHA to have the port update your PFMS bank record, especially if your IFSC changed after a bank merger, then request scroll regeneration.
Yes. Log in to ICEGATE, go to Services, then Enquiries, then IGST Scroll Sanctioned Status, and enter your IEC, shipping bill number and port code to see each bill's status.
They are separate but linked. The refund runs through Customs, while your buyer's payment must be realised into India under FEMA and evidenced by a FIRC, or the refund can be questioned later.
DGARM can flag an exporter for manual verification, which pauses the refund until the check clears. If no code explains your delay, raise it with your jurisdictional officer.
