Where the cargo goes after the gateway port

A CSN's hardest choices all hang off one fact: what happens to the cargo after the vessel discharges it at the Indian gateway port. That one fact decides the cargo movement code, how many legs the itinerary carries, which port fields hold which code, and whether the transhipper block is filled.

This page draws on two sources and says which is which: a working filer's day-to-day practice cross-checked against real filings, and CBIC's own published SCMTR clarifications — the question-and-answer document Indian Customs issued to the trade, which confirms several of these rules directly.

The four destinations, and the movement code each one files

The one that surprises people: a move to a CFS under the same customs station as the gateway is Local Clearance, not transhipment, however far the truck drives. Transhipment (TI) is the genuine onward movement to an inland depot or another station.

A CFS registered under a different station from the gateway — Kattupalli or Ennore to a Chennai-registered CFS, or the reverse — is the one shape where the record genuinely conflicts, and this page says so rather than picking for you. The regulation's own definition of transhipment is "any movement of customs cargo between two customs areas" (ICEGATE's SCMTR FAQ), which argues for TI. Customs' own validation now argues the other way. What is held:

An Ennore arrival delivered to a Chennai CFS (INMAA1TCF1), filed TI with two itinerary legs. Customs accepted it and issued a CSN number. The filer later deleted that filing for reasons the record does not show.A Kattupalli arrival delivered to a Chennai CFS (INMAA1AGL1), filed TI, accepted as CSN 1447385 on 2026-09-05 — and amended successfully on 2026-09-09, the corpus's only proven amendment. So TI on this shape is not merely accepted once; it survived a second pass.A filing of that same Kattupalli-to-Chennai shape refused on 2026-09-12 with error 365, "Cargo Movement Should be LC As Per Receipt Port" — customs naming LC itself, in writing, on the shape it had accepted as TI a week earlier.The working forwarder's latest scenario sheet files Chennai to a Kattupalli CFS as LC, also with two legs.

The reconciling fact is the port of receipt, not the gateway. On all three TI filings trnsprtDoc.prtOfReceiptCdd is INMAA1 — a sea port. Everywhere else in the corpus a sea-port receipt code goes with LC and an ICD receipt code (INDER6, INSBI6, …) goes with TI, without exception, and 365/366 are the pair of codes that enforce exactly that. These three records are the only ones that pair a sea-port receipt code with TI, and one of them has now been refused for it. See the 365/366 check.

So the position as of 2026-09-12: file the cross-station CFS move as LC — it is what customs asked for in writing, and it is what the rest of the corpus does with a sea-port receipt port. TI has been accepted on this shape and may still be; if you hold a recent acknowledgement either way, it is worth more than this paragraph. Either way, declare both legs and the transhipper block, which every one of these filings has in common, and keep prtOfReceiptCdd consistent with the code you choose: a sea port for LC, the inland code for TI.

The cargo type moves with it, and the MIG publishes the whole matrix. Foreign transshipment is the pair TR + TC — CBIC's clarifications confirm it in those words — and ordinary import cargo stays IM at every stage, whatever its movement: an import repositioned coastally files IM + DT at the intermediate port and IM + LC where it clears; an ICD shipment stays IM + TI. The form checks the pair against the MIG's own trade-scenarios table before you file, so a combination customs would refuse as error 115, 118 or 126 is caught here instead: IM and CG take LC, DT or TI; TR takes TC (and FT on a master); EX takes TI, FT or TC. The full table, and how to work a rejection back through it, is in cargo type, movement and the combination customs checks. DT and FT are the codes a CSN filer almost never meets — they belong to cargo that stays with the vessel, which is the vessel operator's story, and that is exactly why they appear in no forwarder filing we hold.

One consequence worth carrying: the movement code belongs to the bill of lading, not to the container. Customs says so itself — JNCH Public Notice 16/2007 has the LCL cargo in an international-transhipment container "segregated as per Bill of Lading … Local Cargo (LC), Transhipment Cargo (TC) and ICD Transhipment cargo (TI) … separately stored". So a consolidation legitimately carries three different codes across its house bills, and setting one code across all of them is what produces a rejection naming exactly one.

For an SEZ movement the destination fields carry the SEZ's own code (Mundra SEZ is INAJM6), the transhipper block stays empty, and the movement code is TI — that is a working filer's direct answer (2026-09-03), though they add they have never actually filed the scenario themselves, so treat it as practitioner guidance rather than a filed-and-accepted shape. A real filing now backs it: the shipping line's own CSN at Visakhapatnam files its consignments into the Visakhapatnam SEZ (INVTZ6) as IM + TI, with a road leg and an empty transhipper block. On the same filing, the TI consignments going by rail to an ICD name the operator's PAN and bond. A steamer agent's arrival manifest at Nhava Sheva does the same with its five consignments into the JNPT SEZ (INPJN6), even though that leg is filed as rail. And customs has accepted it: five CSNs from Chennai take twelve house bills into the Cochin SEZ (INCOK6), the Mannur FTWZ (INCJJ6) and NDR Infra SEZ (INNPK6), all IM + TI by road, and not one names a transhipper. So an SEZ move has no transhipper PAN or bond to find, whichever SEZ and whichever gateway: see my cargo is going to an SEZ.

The itinerary follows the cargo's stages — usually two legs

However the box actually travelled, the filed itinerary carries two sequences: the sea leg to the gateway, and the onward leg to the final destination. The exception is cargo cleared at the gateway itself: direct port delivery has one leg, and so do most accepted filings for a CFS at the gateway — see a CFS at the gateway.

Take a real example: cargo from Ningbo that physically sails Ningbo → Nhava Sheva → Mundra, is discharged at Mundra, and then moves by rail to ICD Sonepat. The filing shows:

prtOfCallSeqNmbr: 1, modeOfTrnsprt: "1" (sea) — Ningbo to MundraprtOfCallSeqNmbr: 2, modeOfTrnsprt: "2" (rail) — Mundra to ICD Sonepat

The Nhava Sheva call never appears. In the filer's own words: "we do not capture every intermediate operational movement — the filing is based on the transport documents, where we report only the Indian gateway port and the final destination." The sequence number is a plain serial (1, 2, …), and the second leg's mode is 2 for rail or 3 for road, whichever the cargo actually uses — an ICD is usually rail, but road happens and is filed as road.

Transhipment onward by sea to another Indian port does not appear in any filing we hold or any scenario the filer uses; if you have one, treat it as unmapped territory and check with your CHA before filing.

Two refinements from CBIC's own clarifications, for the routes that genuinely have stages: a shipment loaded at Brisbane and transhipped at Singapore files both hops (Brisbane → Singapore, Singapore → Nhava Sheva) — "the itinerary is from where the consignment was loaded to where the consignment is cleared" — and an SEZ shipment moving via a CFS carries three legs: origin → gateway, gateway → CFS, CFS → SEZ. CBIC confirmed that three-leg shape in writing. So the two-leg pattern above is the shape of the common movements, not a ceiling.

Which port field carries which code, per destination

firstPrtOfEntry stays with the ship in every case — see which port goes where for the full port-field story.

LCL cargo for an ICD — a consol box landing at the gateway port

Filers ask this as "how do we file LCL for an ICD", for example to ICD Patparganj (INPPG6) via Nhava Sheva. The shipping line's master B/L lands at the gateway port, the forwarder's CSN is a consolidation, and the house bills are for an inland depot. Being LCL changes none of the codes. What decides each house bill is where its cargo is cleared, and the box can reach the ICD in one of two ways.

1. The box goes on to the ICD unopened. Every house bill for the ICD carries:

The master carries the containers and the house bills. Its own transhipper block stays empty. Some filings on file from Nhava Sheva put the gateway (INNSA1) in the next port of unlading instead. No acknowledgement we hold shows customs preferring one over the other, so the ICD code, as in the table above, remains the shape to follow.

2. The box is de-stuffed at a gateway CFS and the cargo goes on to the ICD. Here the CFS moves the cargo, and it files the CFCHI51 message with its SMTP segment (see the SMTP section). What the house bill's CSN should carry in this case, and whether its transhipper is the CFS or the rail operator, is unknown: we hold no CSN we can tell is of this shape. Ask the CFS before filing.

The box can also carry house bills with different movements. Customs segregates an LCL box's cargo by bill of lading into LC, TC and TI (JNCH Public Notice 16/2007). So a house bill cleared at a gateway CFS is LC, with the CFS code as its destination and no transhipper, while the ICD house bills in the same box are TI.

Whether a TG bond is needed at all, destination by destination, is answered in Is a TG bond mandatory for a CSN filing?

A CFS at the gateway: one leg or two

A terminal code and a CFS code look identical: six characters of port, four of facility. CBIC's clarifications allow either as the destination of local cargo: "For any LC cargo, the destination location can either be the terminal code (in case of DPD/DPD) or the custodian code of the CFS."

A terminal code (INVTZ1VCT2, the Visakha Container Terminal inside Vizag port) names where the cargo is delivered directly — direct port delivery with a precise address. One itinerary leg: a real accepted filing has destination INVTZ1VCT2, movement LC, the sea leg alone, and a PCIN from customs.A CFS code (INNSA1AGL1, INCCU1BLC1…) names an off-port facility the box moves to under bond. Whether the itinerary shows that move is not something customs has insisted on. Across the import CSNs customs accepted that we hold (measured September 2026), 179 of 229 bills whose destination was a CFS under the port the ship called at carry the sea leg alone, ending at the gateway; the other 50 add a second leg, gateway → CFS, every one by road (3). Both shapes were accepted at Nhava Sheva, Kolkata, Cochin and Mundra, and some CFS codes appear in both. So one leg is the common shape, and the road leg is optional.A CFS under another station — a Chennai CFS (INMAA1…) for a ship that called at Kattupalli or Ennore, below — is different: all 27 such bills carry a second leg, by road.

This page used to say that a CFS destination must carry the onward leg and that a filing without it is rejected. That was a filer's rule of thumb; the accepted filings do not bear it out, and no acknowledgement we hold refuses a CSN for it. The app derives the sea leg alone for a CFS or terminal at the gateway, and the second road leg for a CFS under another station; add the road leg yourself if your practice is to show the move into the CFS.

Kattupalli, Ennore and the Chennai CFSs

Chennai's CFSs are registered under the Chennai station code (INMAA1), and they serve Kattupalli and Ennore too — the ports are structurally integrated, and when Chennai is congested, Chennai-bound cargo is routinely diverted to berth at Kattupalli and still delivers into a Chennai CFS. That is why a filing can legitimately read firstPrtOfEntry: INKAT1 with an INMAA1… CFS in the destination: the ship called Kattupalli, the cargo's CFS is Chennai's.

The bond side follows the gateway, not the CFS's registration: the same CFS code carries a different bond for a Chennai arrival, a Kattupalli arrival and an Ennore arrival. The app's CFS picker knows the multi-bond cases and asks which station the cargo entered at rather than guessing.

Kattupalli also has CFSs of its own, and their codes come from customs itself — Chennai Customs' Facility Circular 20/2018 assigns INKAT1AWC1 (Apollo World Connect Ltd) and INKAT1LNT1 (L&T Ship Building Ltd) in ICES under Kattupalli Port. That circular is also the answer to "where do CFS codes come from": customs commissionerates publish them in per-port facility circulars as facilities are approved. There is still no central directory — but the codes are published, one circular at a time.

And the integration runs both ways: a working filer's scenario sheet (2026-09-03) carries Chennai as the gateway with a Kattupalli CFS as the destination — firstPrtOfEntry: INMAA1, destPrt: INKAT1AWC1, nxtPrtOfUnlading: INKAT1, two itinerary legs. So the destination CFS's station code does not have to match the gateway in either direction; what has to be right is the pair of facts — where the ship called, and which facility takes the box. The movement code on that cross-station shape is the split described at the top of this page: the sheet says LC, the one accepted filing we hold says TI.

The corner that is still unconfirmed

At Mundra, Pipavav, Hazira and Marmagao, the filer's practice for CFS-bound cargo is to file the plain port code with no CFS code and no onward leg at all — the filing looks exactly like direct port delivery. CBIC's clarifications do sanction a plain-gateway or terminal-code destination for DPD cargo, so the shape itself is legal; what is unconfirmed is using it for cargo that actually moves on to a CFS. The filer themselves marked it "doubtful", their reference list carries no CFS codes for those four ports, and we have not seen an acceptance that proves the practice. If you file one of these, keep the acknowledgement — it is the evidence this page is waiting for.

At Mundra the other shape is now on record. One accepted import CSN filed at Mundra in September 2026 names the CFS itself as the destination — INMUN1AGL1, with cargo movement LC, first port and next port both INMUN1, and no transhipper — and customs accepted every line of it. That is a single filing, so it shows the CFS-coded shape can be accepted at Mundra, not that the plain-port shape is refused; but where you know the CFS, it is the shape with an acceptance behind it. The destination search at Mundra and Nhava Sheva now offers the CFS codes seen on accepted filings (at Nhava Sheva: INNSA1ELP1, INNSA1MSA1, INNSA1ILP1 and eight more), each marked as having no operator name or bond on record yet.

"Do we have to mention the SMTP for an ICD movement?"

No — and there is nowhere to put one. The CSN has no SMTP field. The whole SACHM22 guide (v1.6) carries no transhipment permit number anywhere, and nothing in the ICD shape above asks for one. What declares an inland movement is what this page has already covered: cargo type IM with movement TI, the ICD's code in destPrt and nxtPrtOfUnlading, a second itinerary leg at mode 2 or 3, and the transhipper block.

SMTP is the Sub-Manifest Transhipment Permit, and it is raised from the carrier's manifest, not from your CSN. CBIC Circular 46/2005-Cus — the one that automated container movement from the gateway ports to the inland stations — states that the "Sub manifest Transshipment Permit (SMTP) portion of the IGM itself will be treated as a request for transshipment". So nobody files an SMTP as a document: customs' own system raises the permit from the manifest and passes it to the destination station. That is why the ICD's local IGM is keyed to four things together — the gateway IGM's rotation number and date, the gateway port, and the SMTP number and date — which the ICD IGM message (SACHI41) rejects a filing for missing at codes 104 to 114, refuses as a duplicate at 115, and will not let anyone amend afterwards (112, 207).

Three messages ask for the number, and a forwarder files none of them:

So when a counterparty asks you for "the SMTP", they are asking for something that comes from the line's manifest and the gateway custom house, not from anything you filed. What you can give them is the CSN number and the MCIN or PCIN — the references that identify your consignment in every one of those messages.

Under SCMTR proper there is no permit in this shape at all. The authorised transhipper files Customs Inland Manifest arrival and departure declarations for each vehicle leg and links them to the earlier legs by the cargo identification number — ICEGATE's SCMTR FAQ 2.0, Q41 and Q43 — with no fresh bond per movement (Q44). The SMTP belongs to the older ICES 1.5 machinery still running beside it.

A different SMTP, same three letters. ICEGATE's own abbreviation list expands SMTP as Simple Mail Transfer Protocol: e-mailing the signed JSON is one of the channels it offers for filing (SCMTR FAQ 2.0, abbreviation 27 and Q16). That SMTP has nothing to do with where the cargo goes — it is how a file reaches customs, and this platform uploads the signed file to ICEGATE directly instead. See Filing through ICEGATE's Open API.

Cargo going on to Nepal or Bhutan — how is a Nepal shipment filed?

Cargo landed at an Indian port and moved on to Nepal or Bhutan is not an import into India. It is transit: it enters at the gateway port — Kolkata, Haldia or Visakhapatnam are the ports the trade's question to CBIC names — and leaves again by rail or road for a station across the border; that question names NPKTM, NPBRG (ICD Birgunj) and BTTHI. Three sources say something about it, and they carry very different weight.

What customs has said. CBIC's published SCMTR clarifications take the question directly, as the trade put it: these shipments are usually tagged with the TC movement, the consignee and notify party are foreign and hold no PAN, and the leg from the Indian port to Nepal or Bhutan can be merchant haulage, so no transhipper is known at filing. CBIC's answer covers only the transhipper: the carrier or authorised transhipper is an Indian entity whose PAN can be given, and the onward movement is done either by that carrier or by a transhipper such as CONCOR — registered with a PAN under SCMTR either way. It does not say what goes in the consignee code for a party with no PAN.

What one real filing carries. A shipping line's own CSN at Visakhapatnam holds two consignments for a Kathmandu consignee, one with a house bill under it, and every one of them carries the same shape:

No acknowledgement for that filing is held, so this is a shape a shipping line sent, not one customs is known to have accepted — and it is the line's filing, not a forwarder's.

What a whole shipping line's SAM carries. A line's arrival manifest for one Kolkata call, from September 2026, carries 228 lines of transit cargo out of 559. That is far more than the one filing above, and every one of them is filed the same way:

Customs accepted it. Asked on 23 September 2026, customs' public record held that manifest. Every value it shows for ten lines checked, including one each to Kathmandu, Birgunj and Thimphu, matched the file: cargo type TR, movement TC, the station as port of receipt and destination, and the transhipper on the Birgunj rail line and on no road line. That makes this the first transit shape on record that customs is known to have accepted. The public record does not show the consignee fields, but they were part of the file customs accepted. It agrees with the Visakhapatnam CSN on the destinations, the port of receipt, the rail leg to Birgunj and the missing consignee code. It adds two things. The transhipper appears only where a rail operator moves the box, which reads as the merchant-haulage case below: a road leg names no transhipper. And the code type is sent as PAN with the code itself left empty. The bond flag is not a country rule, though: other lines' SAAs write N on boxes bound for India as well.

What customs' combination table allows. Cargo type and movement are checked as a pair (errors 115/118/126). On a master consignment of cargo type TR the table permits TC on every row, and FT only on a straight consignment (S); import cargo (IM) never takes TC. So filed as an ordinary import with an ICD movement, a Nepal consignment is the wrong pair — see the combinations customs accepts.

Still unknown, and worth asking the line or your customs broker before you file:

The consignee code. The line's filing above left it out. The message guide's field table lists the consignee code as optional, while a note in the same guide says a consignee code is mandatory on an arrival filing. Nothing held here shows which of the two customs enforces for a consignee with no PAN.The transhipper, when the onward leg is merchant haulage. CBIC's answer assumes a registered carrier or transhipper moves it; what to file when the consignee's own truck does is not answered. The line's SAM above leaves it empty on every road leg and fills it only on the rail leg, and customs accepted that manifest. That is a shipping line's filing, though; a forwarder's CSN for the same cargo has not been seen.

If you file one, keep the acknowledgement — accepted or refused, it is the evidence this section is waiting for.

A refusal by e-mail reading "Header validation failed" is not about any of this. That wording is about the job and control number the file was sent under, whatever the cargo — see Reading an acknowledgement.

Related

Which port goes where — the four port fields themselvesTranshippers, CFSs and bonds — the code and bond pair, and why bonds are per port