Cargo type, movement and consolidation

Four small coded fields decide whether customs will look at your filing at all. They are checked together, as one combination, against a table the MIG publishes — and because the rejection names all four at once, it reads as though nothing in particular is wrong.

The two codes that check all four are:

115 — Invalid MC CargoType+CargoMvmt+Consolidated+PrevDecl Combination (master consignment)118 — Invalid HC Comibination of CargoMvmt+CargoType+Consolidated+Previous (house bill)

and 126 — Invalid Cargo Type and Cargo Movement Combination — is the first two on their own.

The rule is a published table, not a judgement call

The MIG's §8 Trade Scenarios Mapping Table enumerates every combination customs accepts, row by row, together with the blocks each one then requires. The platform reads that table directly: it is what the form checks before you file, and what the acknowledgement inspector works a 115 or 118 back through.

It is the same table in MIG v1.5 (March 2025) and v1.6 (August 2026), which is as close to settled as anything in SCMTR gets.

What each movement code means

Customs stated these in its own words long before SCMTR. JNCH Public Notice 16/2007, which implements CBIC Circular 14/2007-Cus for international transhipment at Nhava Sheva, defines the manifest's cargo movement field like this:

LC Local Cargo: … the port code where cargo is delivered. It is the same as the port of arrival.TC – Transhipment Cargo: … international transhipment cargo and the port of destination shall be port code where transhipment cargo is destined to be delivered.TI – Transhipment to ICD: … local cargo meant for transhipment to hinterland port i.e. ICD. The port of destination is the Port Code of ICD.

The SCMTR list adds DT (domestic transit) and FT (foreign transit) for cargo that stays aboard the ship. See where the cargo goes after the gateway port for choosing between them.

On foreign transshipment the MIG contradicts itself and the mapping table settles it. Its house-consignment attribute table spells the code FI; its master-consignment table, and every one of the mapping table's nine house-level rows, spell it TC. Public Notice 16/2007 spells it TC too. So TC is the code, at both levels, and FI is a typo in the guide.

The combinations customs accepts

Read the row for what your record is; the last column is what its cargo movement may be.

On a master consignment

On a house bill

And eleven the table calls impossible

These triples exist in no shape at all, whatever the movement: IM+S+C, IM+H+C, EX+S+N, EX+S+C, EX+H+N, EX+H+C, EX+C+S, TR+S+C, TR+H+C, CG+S+C, CG+H+C.

Read as four short rules

Import cargo stays IM, whatever it does next — LC when it clears at the port or moves to a CFS, TI when it moves inland to an ICD, DT when it stays aboard for another Indian port. It never takes TC. Coastal goods (CG) behave identically.TC belongs to TR and EX. Cargo landed only to be carried on to a foreign port is transhipment cargo, type TR; export cargo may also take it.TR on a house bill takes TC and nothing else. FT is a master-level shape only.A prior declaration of Y means this cargo already has a CSN, and the record's previous reference block has to name it. A fresh consignment is N.

The commonest fault: import cargo with a transhipment movement

IM with TC appears in the table nowhere, at either level, and it is the fault behind most 118 rejections on transhipment work. It happens because both halves are individually reasonable: the cargo did arrive as an import, and it is going onward as transhipment cargo. Customs wants the second fact — so locCstm.typOfCrgo becomes TR and locCstm.crgoMvmt stays TC.

TR is a cargo type. It is never a cargo movement. The two fields sit next to each other and the codes look interchangeable, so this is worth stating flatly: the movement field takes LC, TI, TC, DT or FT and nothing else. A filer who reads "TR with TC" and changes the movement from TC to TR has moved the right value into the wrong field and broken a filing that was one edit from correct. Change the type.

How do I file transhipment (TC) cargo?

To customs, "TC cargo" is one thing: cargo landed at an Indian port only to be carried on to a port outside India — the "international transhipment cargo" of Public Notice 16/2007, the ITP work of the trade. It is not cargo moving on to a CFS (LC) or to an ICD (TI), which the trade also calls transhipment; those codes are chosen on where the cargo goes after the gateway port. Which filing you are making decides the rest:

Import-side transhipment, in a CSN Entry (SCE) — the cargo arrives on this vessel and leaves on another for a foreign port. Cargo type TR, cargo movement TC. The rest of this section is about this case.Cargo going on to Nepal or Bhutan — the same pair, TR + TC, with the station across the border as its destination. That shape has its own section, with the accepted manifest behind it.An export, in a CSN Exit (SCX) — every export leaving for a foreign port is cargo type EX, movement TC. That is the ordinary export shape, not a special case: see exports: filing an SCX.

Field by field, on each bill of lading that is transhipment cargo — each house bill in a consolidation, or a straight master bill on its own. The pair belongs to the bill, not to the box, so a container shared with local cargo changes nothing.

Everything else on the bill stays as it would on an import: the table's row for a TR + TC house bill reported for the first time lists its transport document, transhipper, item details, customs location, containers, itinerary and measures — an import house bill's blocks plus the transhipper. The one edit that turns an import house bill into transhipment cargo is the type: TR where it said IM, and TC in the movement. Never TR in the movement field — see the section above.

How much of this customs has confirmed, and what it has not. TR + TC is accepted on a shipping line's arrival manifest — 228 transit lines of one Kolkata call, held on customs' record on 23 September 2026 — and EX + TC on export filings customs accepted in September 2026. IM + TC was refused as 118 on 5 September 2026. What no acknowledgement on record shows is a forwarder's import CSN with TR + TC house bills: three such filings are on file from September 2026 — from Nhava Sheva and Kattupalli, on to Jebel Ali, Mombasa, Hamad and beyond — each with TR and TC on the house bill, a foreign port of receipt and a consignee with no code, and none has a reply on file. So the two codes and the destination and receipt ports above are customs' own rule; the next port of unlading, the itinerary, the transhipper and the consignee shape are what filers send. If you file one, keep the acknowledgement — accepted or refused, it is the evidence this section is waiting for.

Where the two fields are in the guided steps. On step 2, Your house bill, both sit under the folded line Customs route and codes filled in for you, below Where it is cleared — Type of cargo and Cargo movement, beside the first port of entry and the next port of unlading. Open the line and set the type to TR and the movement to TC. On a master filed with no house bill the same folded line is on its What is on the bill page; on an export the pair is typed once, on the master bill. The form checks the pair against the table before you file, so IM + TC is caught here rather than by customs.

A second check, on one field alone: 365 and 366

115, 118 and 126 check the four coded fields against each other. Two more codes check the cargo movement against a port, and they are the ones that arrive when the combination itself is perfectly legal:

365 — Cargo Movement Should be LC As Per Receipt Port366 — Cargo Movement Can Not Be LC As Per Receipt Port

They read together as one rule: customs decides from the port of receipt what the movement code is allowed to be, and refuses the record if the two disagree.

The field they name is trnsprtDoc.prtOfReceiptCdd — the Indian port where the goods are received into the movement being declared, not the foreign load port (that is prtOfAcptCdd). The two are confused constantly; which port goes where is the page for that. The rejection arrives on the transport document block, because that is where the receipt port sits — while the field you actually change, crgoMvmt, is one block away in Location & customs. That split is why the code reads as though it is pointing at nothing.

What decides it is the kind of place the receipt port is

The sixth character of an Indian customs location code says what kind of facility it is — 1 a sea port, 2 a rail terminal, 4 an air cargo complex, 6 an ICD or SEZ, B a land customs station. Cargo received at a sea port is local; cargo received at an inland depot has been transhipped inland to get there. So:

Every filing in this repo's sample corpus obeys it. Across the accepted, refused and third-party CSNs held here: 96 consignment records in 17 files pair a sea-port receipt code with LC; 15 records in 7 files pair an ICD receipt code with TI; four pair a foreign receipt code with TC; and not one record anywhere pairs an ICD receipt port with LC. Three records break the pattern, all of them the same cross-station shape, and they are the subject of the next section.

That the sixth character is what customs reads is inference — the error text says "as per receipt port" and does not say how the port is classified. The correlation is what is observed; the mechanism is the most economical reading of it.

What to do with a 365

Set locCstm.crgoMvmt to LC on the record the error names. Leave everything else alone — both itinerary legs, the destination port, the transhipper block and the cargo type all stay as they are; IM + LC is a legal pair at both levels, so the combination check will not then fail.

Before refiling, check the other half: if the cargo is genuinely going to an ICD, it is the receipt port that is wrong, not the movement code, and it should carry the ICD's code rather than the gateway's. A 365 is equally consistent with either mistake, and the platform cannot tell them apart — only you know where the cargo is going.

A 366 is the mirror image. The receipt port is an inland location, so the movement is TI and the destination port should be that same inland code. If the cargo really is clearing at the sea port, the receipt port is the field to fix.

Cargo movement is a property of the bill of lading, not of the container

This is the part that catches people filing ITP work, and customs says so itself. Public Notice 16/2007, on the LCL container arriving for international transhipment:

The LCL cargo will be segregated as per Bill of Lading (BL) and each category of cargo i.e. Local Cargo (LC), Transhipment Cargo (TC) and ICD Transhipment cargo (TI) will be identified and separately stored …

So one container legitimately holds house bills with three different movement codes, and each house bill carries its own type-and-movement pair. Setting one code across all the houses in a consolidation is what produces a rejection naming exactly one of them.

"ITP" means two different things

To the trade and to customs at JNCH, ITP is International Transhipment — the Circular 14/2007-Cus facility for moving imported cargo, FCL or LCL, on to a port outside India. That is what a filer means by "an ITP shipment". In a CSN it is cargo type (locCstm.typOfCrgo) TR, cargo movement (locCstm.crgoMvmt) TC — two fields, one value each, and never TR in the movement field.To NIC's EDI documentation, ITP is the name of the older Import Transshipment message (CFCHI51) that a CFS files through a value-added network. That message is not yours to file — see who else files against your cargo.

Both are about transhipment; only the first is a thing you declare on a CSN.

Your CFS or IGM system's code list is not this one

Worth knowing before you copy a code between screens. The cargo-movement list on a CFS, delivery-order or IGM system is the ICES IGM list, not SCMTR's, and it differs in ways that look like the same field:

It offers codes SCMTR has no equivalent for. A TP on such a screen has no counterpart in a CSN — crgoMvmt takes LC, TI, TC, DT or FT and nothing else.It glosses the shared codes differently. One such screen labels TC "Transhipment Coastal", where the SCMTR guide calls it Foreign Transshipment and Public Notice 16/2007 calls it international transhipment cargo. Read the code, not the label — the label is the software vendor's, the code is customs'.

So a value that is right on the IGM screen is not automatically right in the CSN, and the reverse. Take each field from the guide for the message you are actually filing.

The same table says which blocks the record must then carry

The mapping table's last column lists the blocks each combination requires. Read forwards it is the rule behind the 4xx "Mandatory Object … is Missing" codes — 401 to 438, one per block — and read backwards the 4xx "Object … is Redundent" codes. Two things are worth knowing.

A house bill has to carry its containers. On 23 September 2026 customs refused an import house bill filed with no transport-equipment block as 433, "Mandatory Object HC_Transport Equipment is Missing" — and every one of the 383 house bills in accepted filings we hold lists its boxes. So the platform stops a house bill whose combination is fully stated (cargo type, movement, consolidation and prior declaration all present) and whose equipment block is empty, before you file. An equipment block that is present but empty counts as missing: the file drops an empty block before it goes out, and customs sees the same gap. For every other block the row lists, the platform says the table expects it and lets you file — the same table lists a block on the R master that 205 accepted master consignments omit, so the column over-claims, and only the one object with a refusal behind it blocks. An export is judged by its own rules instead (the export page has them), because break-bulk export cargo legitimately carries no container.

The transhipper block is the second one worth knowing:

The table lists the transhipper block — the code and the bond — as required exactly when a consignment is being reported for the first time and moves onward under bond. That is TI for any cargo type, and TC or FT for EX and TR. It is listed for no LC or DT row, and for none where the prior-declaration flag is Y, because the earlier filing already named the transhipper.

Read that as where it is expected, not as a rule customs enforces both ways. Accepted filings we hold populate the block on LC consignments, where this table does not ask for it, and no filing has ever been refused for omitting it — trnshpr is optional as a block for SCE in the MIG's own field table. So the platform says when the table expects it and does not stop you filing without it. If you know the movement is bonded, fill it in; the table is the best answer anyone has to "when does this block apply", and it is the MIG's own.

Which bond goes in it is a separate question with its own page: transhippers, CFSs and bond numbers. The short answer for a transhipment movement is the custodian's bond — Public Notice 16/2007 has the containers moved from the port terminal "under custodian-cum-carrier bond filed by the custodian", and JNCH Public Notice 76/2018 has that bond registered in ICES as the Transhipment (TP) bond at that customs station.

One caution about the consolidation column

The mapping table writes consolidation as S, C or H for its ordinary rows — the three values the MIG's prose LOV names. Real accepted filings mostly do not. Every forwarder filing we hold, including the ones customs accepted, carries R on a master with house bills under it, M on a master with none, and H on each house. Both are true at once: the field's full domain has eleven values, and production uses them.

R is in the table, though — twice, as RN / R / N and EX / R / N, each with cargo movement NA and no cargo type of its own. That row describes exactly what accepted filings do: a master marked R is the bill of lading referenced only. It declares no cargo type and no movement, and the cargo is classified on its house bills. (An earlier version of this page said the table never names R; it does, and the correction matters for what follows.)

When does the platform refuse a combination, then?

Only when a record states all four values and the table has no row for them. An R master that also declares a cargo type and a movement is making a complete claim the table does not list, and customs checks it: on 23 September 2026 an import master carrying IM + LC with R and N was refused as 115. The platform now stops that shape before you file, and says what to do — either drop the cargo type and movement from the master and leave the classification to its house bills, or make it a real consolidation (C / N on the master, H on each house). The ordinary accepted R master, with no locCstm block, states nothing to judge and is untouched.

An R master is prior declaration N, quoting nothing. On 3 October 2026 a forwarder's CSN amendment (SCA) whose R master declared prior declaration Y, with a PCIN of another CSN in its prior reference, was refused as 115 on the master — though the same CSN's previous SCA, with the identical master, had been accepted four days earlier. Every R master on an accepted fresh CSN on record is N with no prior reference, and the same CSN's next SCA, setting its master back to N and dropping the prior reference, was accepted the same day. The platform stops R with anything but N on a fresh CSN, warns on an amendment, and explains a 115 on such a master in those terms.

M stays outside this check on purpose: accepted filings use it, none of them declares a cargo type beside it, and no acknowledgement has ever named it. Refusing it would refuse a shape nobody has tested. So the platform enforces the cargo-type-against-movement half of this table for every record, the whole four-way combination only for a record that spells all four out, and explains the rest — and if 115 or 118 comes back on a record this platform passed, read the table's rows as shapes (a consolidated master with houses under it; a house under it; a straight bill on its own) rather than matching the letters.

Related

Where the cargo goes after the gateway port — choosing the movement code for a real destinationTranshippers, CFSs and bond numbers — the two fields the movement code turns onWhy customs rejected this filing — the other error familiesEvery coded value — the code lists themselves