DGFT
Shipping Bill Not Showing on DGFT: How to Re-Transmit from ICEGATE
The ICEGATE re-transmission facility that pushes a shipping bill back to DGFT, the six reasons the request gets refused, the 48-hour turnaround, and the one-request-per-day rule.
By Aaryan Kakani · · 12 min read
Why does a shipping bill fail to reach DGFT?
A shipping bill filed at a customs location does not travel straight to DGFT. It moves along a chain: ICEGATE hands the shipping bill to ICES, the customs processing system, and ICES is what transmits it onward to DGFT. That is the path the ICEGATE DGFT Re-Transmission User Manual V0.2 describes, and it is why a shipping bill can be perfectly visible on ICEGATE and still be invisible when you go to file a scrip application.
The commercial consequence lands on the exporter, not on the system. The export physically happened, the container sailed, the buyer has the goods. But the scrip application will not accept the shipping bill, the licence cannot be closed against it, and the scheme benefit sits unclaimed. Nothing about the export is wrong. Only the message is missing.
The first thing to get straight is that one shipping bill has to reach three different destinations, for three different reasons, and those three transmissions fail independently of each other. Fixing one does not fix the others.
| Destination | What it unlocks | Symptom when it fails | Remedy route |
|---|---|---|---|
| DGFT | Scheme benefits, scrip application, licence closure | SB not found when filing on the DGFT portal | DGFT Retransmission Facility (SB) on ICEGATE |
| GSTN | IGST refund on exports made with payment of tax | Refund not credited although the SB is cleared | GSTN / ICEGATE refund enquiry. A separate path, not this one |
| RBI EDPMS | Realisation tracking and closure of the export entry | SB shows the wrong status, or the bank and the portal disagree | Rectification of SB EDPMS Status under ICEGATE login |
The other thing worth internalising early: in most cases the message was never lost. It was never eligible to be sent. The Export General Manifest may not have been filed by the carrier, the shipping bill may still be provisionally assessed, or the shipping bill may simply not carry anything DGFT has a use for. Those are preconditions, not transmission faults, and hammering the submit button does not satisfy a precondition. That is exactly why the status enquiry (which tells you which precondition is unmet) matters far more than repeat requests.
How do you submit a DGFT re-transmission request on ICEGATE?
The facility lives inside the ICEGATE Enquiry Service and is available to any logged-in ICEGATE user. There is no fee, no document upload and no digital signature step. The path, as published in the DGFT Re-Transmission User Manual V0.2 (a twelve-page document on the ICEGATE guidelines library), is literal and unforgiving. Take it one click at a time.
The exact menu path
- :
The form itself is unusually small. Four fields, all of them things you already have on the shipping bill printout.
| Field | What to enter | Where to get it right |
|---|---|---|
| SB Date | The date of the shipping bill as filed | Take it from the SB copy, not from the invoice or the LEO stamp |
| SB Number | The shipping bill number | Copy digit for digit; do not strip or pad leading zeroes |
| Port Code | The customs location code where the SB was filed | The single most common source of a false "does not exist" result |
| IEC | Your Importer Exporter Code | Must be the IEC on the shipping bill, which may not be the logged-in user's own IEC in a CHA setup |
How long does DGFT re-transmission take?
The published figure is approximately 48 hours to complete the re-transmission process once the shipping bill details have been submitted. That is the number stated in the DGFT Re-Transmission User Manual V0.2 itself. It covers the whole chain, ICEGATE to ICES and ICES to DGFT, so you should not expect the shipping bill to appear on the DGFT side the same afternoon.
| Parameter | Position | What it means for you |
|---|---|---|
| Turnaround | Approximately 48 hours after submission | Plan the scrip application two clear days out, not the same day |
| Requests per SB per day | One. A second attempt the same day is refused | Resubmitting is wasted effort, not an escalation |
| Cost | No fee | Nothing to reconcile, nothing to expense |
| What to do while waiting | Use the DGFT Retransmission Status Enquiry | The status response usually names the blocker outright |
Two operational habits make the 48 hours manageable. First, submit early in a working week rather than on a Friday evening, so that if the response points at a carrier or a customs-side fix you have working days left to chase it. Second, write down the exact date and time of submission somewhere durable. Your SB tracker, not a chat message. A 48-hour window you cannot measure is a window you will keep re-starting.
How do you check the status of a re-transmission request?
The status enquiry sits directly alongside the request form. The path is Services widget → Enquiries → ICEGATE Enquiry Service → DGFT → DGFT Retransmission Status Enquiry. It asks for SB Number, 'SD Date', Port Code and IEC.
| Screen | Path | Fields |
|---|---|---|
| Submit the request | Services → Enquiries → ICEGATE Enquiry Service → DGFT → DGFT Retransmission Facility (SB) | SB Date, SB Number, Port Code, IEC |
| Check the status | Services → Enquiries → ICEGATE Enquiry Service → DGFT → DGFT Retransmission Status Enquiry | SB Number, 'SD Date', Port Code, IEC |
Run the status enquiry before you escalate anything. Five of the six responses the system can return are self-diagnosing. They name the blocker and, by implication, the party who has to clear it. Calling the helpdesk before you have that response wastes a call, because the first thing the helpdesk will ask is what the status enquiry said.
What do the six re-transmission failure responses mean?
The DGFT Re-Transmission User Manual V0.2 lists six responses the facility can return when a shipping bill cannot be re-transmitted. Read as a set, they are a decision tree: only one of them is actually about timing, and only one tells you the facility is the wrong tool entirely.
| Message | What it actually means | Who has to act | Next step |
|---|---|---|---|
| Invalid Shipping Bill No / Date | No shipping bill exists for that combination of IEC, port code, number and date | Exporter | Re-check the port code first, then the SB date format, against the shipping bill copy |
| EGM not filed | The shipping line or airline has not filed the Export General Manifest for the vessel or flight | Carrier / freight forwarder | Chase the carrier. No EGM means no transmission and no drawback either |
| Shipping Bill is provisionally assessed | The assessment is not final, so there is no settled value to transmit | Customs, on the exporter's follow-up | Get the provisional assessment finalised, then re-submit the request |
| EGM date must be less than today's date | The EGM carries a forward-dated entry, which the system will not accept | Carrier / port | Have the EGM date corrected at the carrier or port end before re-submitting |
| Shipping Bill already recorded for DGFT transmission today | You are inside the one-request-per-day queue for this SB | Nobody. It is a timing state | Wait. Allow the roughly 48 hours, then use the status enquiry |
| Shipping Bill does not contain LIC / DEPB / DFIA / ROSCTL, or DBK scroll not generated, or a ROSCTL claim is present | The shipping bill carries nothing DGFT needs, or the drawback scroll stage is not reached | Exporter. But as a re-think, not a re-file | Stop. Re-transmission is not the right remedy; work out which benefit you were actually expecting |
A note on the second and fourth messages, because they are the ones exporters most often mis-own. Both are carrier-side. The Export General Manifest is filed by the shipping line or airline, not by you, and until it is filed and dated correctly customs has no confirmation that the goods left India. That is also why a missing EGM blocks drawback at the same time as it blocks the DGFT transmission. The two symptoms have one cause, and chasing the carrier clears both.
When is the problem EDPMS rather than DGFT?
A large share of "my shipping bill is not showing" complaints are really realisation-side problems wearing a transmission-side costume. The tell is what you were trying to do when you noticed: if you were applying for a scheme benefit, it is a DGFT question; if your bank told you the shipping bill is still open, or shows as cancelled when it is not, it is an EDPMS question and this facility will not touch it.
The ICEGATE Advisory for SB EDPMS Enquiry sets out the access split cleanly: the SB EDPMS status itself is available publicly, while Rectification of SB EDPMS Status and FE Realization details are available only under ICEGATE login.
| What you want | Access | Path | Notes |
|---|---|---|---|
| See the SB EDPMS status | Public | Services → Quick Information → Public Enquiries → RBI-SB-EDPMS Enquiry | Returns the status plus a link to the error codes |
| See FE Realization details | Login required | Services widget → Public Enquiries → RBI-SB-EDPMS Enquiry | This option is pre-selected by default after login |
| Rectify the SB EDPMS status | Login required | Same screen, switched from 'FE Realization Details' to 'Rectification of SB EDPMS Status' | Easy to miss, because the other option is already selected |
The rectification form asks for Location, SB Number and SB Date, then a radio choice between two named defects ('Cancelled SB is shown as Active' and 'Active SB shown as Cancelled') and a free-text description. Those two radio options are the only status defects ICEGATE recognises structurally. Everything else you might want corrected has to be argued in the free-text box, which is worth knowing before you start writing: describe the defect in the plainest possible terms and give the bank-side reference that shows the contradiction. After submitting, the advisory asks you to check the status after 3 working days.
How do you stop transmission failures happening in the first place?
Most re-transmission requests trace back to something declared loosely at filing time. The clearest example is the nature of contract check, introduced from 6 October 2023 and described in ICEGATE Advisory v0.1 on the check introduced for nature of contract in shipping bill filing. From that date the same nature of contract must be declared at invoice level and at item level, with a strict one-to-one mapping into the shipping bill message format field.
| Nature of contract | SB message-format value | What the declared price includes |
|---|---|---|
| CIF | B | Goods plus insurance plus freight |
| CI | I | Goods plus insurance |
| CF | F | Goods plus freight |
| FOB | N | Goods only, at the port of loading |
The mapping matters because of what happens next arithmetically. On a CIF declaration the unit value is inclusive of freight and insurance, so the system derives item-level FOB by deducting the declared insurance and freight proportionately across the items of that invoice. FOB is not something you type in on a CIF shipping bill. It is computed. And FOB is the base for export incentives and for export duty. Declare the freight or insurance amount wrongly, or declare it in the wrong currency, and every downstream number inherits the error.
Worked example. How item-level FOB is derived on a CIF invoice
An invoice is declared CIF (mapped to B) for USD 20,000, carrying two items. Declared freight is USD 1,500 and declared insurance is USD 500.
- 1 Total the deductible elements 1,500 (freight) + 500 (insurance) = 2,000
- 2 Work out each item's share of the CIF value Item A CIF 12,000 ÷ 20,000 = 0.60 Item B CIF 8,000 ÷ 20,000 = 0.40
- 3 Apportion the 2,000 in that ratio Item A: 2,000 × 0.60 = 1,200 Item B: 2,000 × 0.40 = 800
- 4 Deduct to get item-level FOB Item A FOB: 12,000 − 1,200 = 10,800 Item B FOB: 8,000 − 800 = 7,200 Invoice FOB: 10,800 + 7,200 = 18,000
- 5 See what an error would have cost Suppose freight had been keyed as 15,000 instead of 1,500. The deductible total becomes 15,000 + 500 = 15,500 , Item A's share becomes 15,500 × 0.60 = 9,300 and its FOB collapses to 12,000 − 9,300 = 2,700 against a correct 10,800. Invoice FOB falls from 18,000 to 4,500. A 75% understatement of the base on which incentives are computed, produced by one misplaced digit.
DGFT re-transmission checklist
Before you submit
- Confirm the shipping bill actually carries a scheme flag DGFT needs. If it holds no LIC / DEPB / DFIA / ROSCTL, re-transmission is the wrong remedy
- Confirm the carrier has filed the EGM, and that its date is in the past rather than forward-dated
- Confirm the shipping bill is finally assessed, not provisionally assessed
- Confirm where the drawback scroll stands. A scroll not yet generated is one of the six refusal grounds
- Gather IEC, Port Code, SB Number and SB Date exactly as filed, from the shipping bill copy rather than from memory
Submitting and following up
- Submit one request, and only one per shipping bill per day
- Note the submission timestamp in your tracker and allow the approximately 48 hours to elapse
- Check the DGFT Retransmission Status Enquiry, entering your SB date in the 'SD Date' field
- If the response points at EGM or provisional assessment, fix that first. Do not resubmit against an unmet precondition
- Keep any EDPMS rectification as a separate item on a separate clock, allowing 3 working days before checking back
- Escalate to the ICEGATE Helpdesk on 1800-3010-1000 or icegatehelpdesk@icegate.gov.in only once the status enquiry is exhausted
Common questions about DGFT re-transmission?
How long does DGFT re-transmission of a shipping bill take?
The DGFT Re-Transmission User Manual V0.2 published on ICEGATE states that it takes approximately 48 hours to complete the re-transmission process once the shipping bill details are submitted. The data path is ICEGATE to ICES and ICES to DGFT, so the shipping bill appears at DGFT only after both hops complete. Record the date and time you submitted so the 48-hour window is measurable, and check the DGFT Retransmission Status Enquiry rather than filing the request again.
Can I submit a DGFT re-transmission request twice in one day?
No. A shipping bill that has already been recorded for DGFT transmission on a given day cannot be queued again the same day, and ICEGATE returns the response "Shipping Bill already recorded for DGFT transmission today". A duplicate attempt is wasted effort rather than a faster route. Wait out the 48-hour window, then check the status enquiry before submitting anything else.
What does 'EGM not filed' mean on the re-transmission status screen?
It means the shipping line or airline carrying your consignment has not filed the Export General Manifest for that vessel or flight. Until the EGM is filed and accepted, customs has no confirmation that the goods actually left India, so nothing transmits to DGFT and drawback does not process either. This is not something the exporter can fix on ICEGATE. Chase the carrier or your freight forwarder to file the EGM, then re-submit the re-transmission request.
What is the 'SD Date' field on the DGFT Retransmission Status Enquiry?
It is a label typo on the ICEGATE screen. The DGFT Retransmission Status Enquiry asks for SB Number, 'SD Date', Port Code and IEC, and the 'SD Date' field is the Shipping Bill date. The same date you entered when you submitted the re-transmission request. Enter your SB date there. Many exporters abandon the status check because the label looks like it wants some other document date.
Will re-transmitting to DGFT also fix my EDPMS or IGST refund problem?
No. A shipping bill has to reach three different destinations and they fail independently: DGFT for scheme benefits and licence closure, GSTN for the IGST refund, and RBI EDPMS for realisation closure. The DGFT Retransmission Facility (SB) on ICEGATE only pushes the shipping bill down the ICEGATE to ICES to DGFT path. An EDPMS status defect is corrected through the separate 'Rectification of SB EDPMS Status' route under ICEGATE login, where you are asked to check the status after 3 working days.
Official sources
Update history
- First published.