Guide

SCMTR & CSN filing guide

A plain-language walk through India's Sea Cargo Manifest and Transhipment Regulations — what changed, who files what, and how a Cargo Summary Notification actually moves through ICEGATE.

What is SCMTR?

Sea Cargo Manifest and Transhipment Regulations, 2018 — rules issued by India's Central Board of Indirect Taxes and Customs (CBIC) under the Customs Act, 1962. SCMTR replaces the older Import/Export General Manifest (IGM/EGM) process with structured, machine-readable electronic messages filed through the ICEGATE portal.

What is a CSN?

A Cargo Summary Notification is the house-level cargo declaration filed by freight forwarders, NVOCCs, and consolidators. It references a master consignment — the bill of lading filed by the vessel operator — and adds the finer-grained detail underneath: individual shippers, consignees, goods descriptions, and equipment.

It replaces the pre-SCMTR Sea IGM file format: a text file beginning with an HREC header record and carrying <consoligm> and <conscargo> section markers, which ICES took until the rollout. Software that still writes that format is writing a message no SCMTR door reads — the same cargo now goes as a SACHM22 CSN from the forwarder or agent, or a SACHM23 SAM from the shipping line, both JSON files whose names begin F_SACHM22_ or F_SACHM23_.

Is SCMTR mandatory at my port yet, and what does it cost?

Yes, in stages. The arrival manifest (SAM) and entry inward (SEI) went live across India on 16 January 2025 and the departure manifest (SDM) on 26 August 2025. Supplementary IGMs and EGMs stopped being accepted on 12 August 2026 — a manifest now changes only through SAA or SDA. CBIC Circular 38/2026 then makes every SCMTR message operational port by port: Goa and Mumbai on 1 September 2026, Mundra on 5 October, Chennai on 9 October, and Nhava Sheva with every remaining port on 15 October 2026, with no penal action during that implementation phase.

How late an arrival manifest can be amended without an officer's approval depends on the voyage from the last port of call: until 6 hours before arrival for under 48 hours at sea, 24 hours for 48 to 96, and 48 hours for longer (Circular 43/2020). After entry inward, an amendment needs the jurisdictional officer's approval (Advisory 37/2026) — though the message guide's errors 373 and 374 read as a flat refusal, and customs has not said which the system does. An IGM amendment has carried a flat ₹1,000 fee since Circular 14/2017, and Regulation 13 sets a penalty of up to ₹50,000 for an authorised carrier who contravenes the regulations. Ports issue their own instructions, so confirm the position at yours with the customs house. Every date, window and source, port by port.

Since ICES Advisory 37/2026 (18 September 2026), a CSN amendment carries the same officer-approval split once entry inward is granted, and one field is never amendable at all: the conveyance reference (VCN) and rotation number cannot travel in a CSN amendment, before entry inward or after. What that means for a CSN amendment.

Who has to file one?

Freight forwarders, NVOCCs, and consolidators — anyone who has combined cargo from multiple shippers under a single master bill and issued their own house bills for it. The vessel operator files the arrival or departure manifest above you; the CSN is the layer you are responsible for. Each stakeholder registers on ICEGATE in their own role. Strictly, filing one is not an obligation in law: ICEGATE's own FAQ calls the CSN a facilitative measure, and a forwarder may instead hand the cargo details to the line for its manifest. What filing it buys you is that your shippers' and consignees' details reach customs from you, and the line's manifest refers to your filing rather than re-declaring the bill.

The role you already hold on ICEGATE decides the SCMTR entity type you register under, and it is the code that then appears on every filing you make:

If you file CSNs you are almost certainly an ANC — forwarders, NVOCCs, consol agents and customs brokers all register under that one code. Registration is applied for through the SCMTR widget on your ICEGATE dashboard and approved by Customs, and three things can never be changed afterwards: the entity type, the entity PAN, and the port. You register at a single port but may file at any Indian port.

Which message are you filing?

SCMTR is a family of messages, not one document, and two of them are easy to confuse because their codes differ by a single character. A higher number does not mean a newer version.

Both are current and ICEGATE publishes an implementation guide for each. Seeing a SACHM23 file is normal — your CSN is cross-validated against the carrier's manifest, so the two exist side by side for every voyage. The other messages in the family (custodian, transhipper, import transhipment) are filed by neither of you.

The filename says which is which. A declaration is named F_SACHM22_SCE_ICEGATEID_jobno_date_DEC.json — the leading letter is F for a fresh filing or A for an amendment, and the second and third segments are the message code and the reporting event.

The CSN guide is at version 1.6, published 14 August 2026. One quirk if you check for yourself: ICEGATE's download page lists it as 1.6 while the revision history inside the document still reads 1.5. The content is the newer one — compare the documents, not their internal version tables.

Both messages are filed from this platform. You file the CSN here; a shipping line's SAM / SDM (SACHM23) can be opened, searched and edited here too — one row per bill line — checked against customs' record to see which of its bills already carry an accepted CSN, and signed and filed from here, through the same gate that stops a file going to customs twice. Since 21 September 2026 a manifest can also be built here from scratch — for a bulk, tanker or tramp call with no liner system behind it — though none built here has yet been filed. An SAA amendment is built from the manifest customs accepted, addressed by the line, container and item numbers customs holds. Customs' answer to a manifest still reaches the line at its registered ICEGATE address; dropped on the Shipping line filing page, it is read as one story — which lines were refused and why — and kept with the send it answers.

Reporting events

Every SCMTR message declares why it is being filed via a reporting event code. Which fields are mandatory, optional, or not applicable depends entirely on which event it is — the same form asks for different things under each.

The basic filing flow

1. A vessel operator's master consignment already exists or is being filed in parallel.
2. A fresh CSN (SCE for import entry, SCX for export exit) declares the master consignment reference, vessel and voyage detail, filer identity, and one or more house-bill-level declarations underneath it.
3. Customs validates the filing and returns either an acceptance with a CSN number, or a structured rejection — unless ICEGATE cannot take the file in at all, in which case the rejection arrives as an email and no ACK ever does. Since September 2026 an accepted CSN's number and date also appear on ICEGATE's public enquiry, which is how this platform marks a filing accepted without waiting for the e-mail.
4. Later changes go through an amendment or update filing referencing the original CSN number.
5. A cargo confirmation filing closes out the reference once the cargo movement is fully accounted for.

Every filing must be digitally signed

Customs accepts nothing unsigned. A CSN is submitted as a signed message, and the signature is what ties the declaration back to a registered filer rather than to anyone who happens to know an ICEGATE ID. The requirement is on the filing itself, not on the channel — it applies whether the message is submitted through the ICEGATE portal or over the Open API.

The signature must come from a Class 3 Digital Signature Certificate issued by a CCA-India-licensed Certifying Authority — eMudhra, (n)Code, Capricorn, Sify and others — and, critically, it must be the certificate registered against the filing organisation's ICEGATE account. A signature from a DSC that is perfectly valid but not the registered one is a rejection, and it is a rejection that arrives hours later rather than at the moment of filing.

The private key lives on a USB token and never leaves it: the token performs the signature itself, given only a short fingerprint of the declaration. That is why signing always involves something running on the filer's own machine — on ICEGATE's own portal, or through a utility the filer installs — and why no service can legitimately offer to sign on a filer's behalf. Filing through this platform means preparing and freezing the declaration here and signing it with the token on the filer's own computer — through the platform's desktop signer, or on ICEGATE's portal for anyone who cannot install one. Because the signature covers the exact bytes of the declaration, any edit after signing invalidates it — which is the mechanism that makes a signed filing evidence of what was actually declared.

A signature that customs cannot validate produces no ACK at all. ICEGATE e-mails the registered address instead — “DSC validation failed for control no. … Please use a valid DSC” — and its own FAQ gives the causes: a certificate that is invalid, expired or not the one registered for the ICEGATE ID; a file changed after it was signed; or a signature block out of place. A renewed DSC is a new certificate, so it has to be registered on the ICEGATE ID before it can file; until then it fails exactly like an expired one. The failed upload still counts as received, so the corrected file goes with a new control number.

The declaration names who files it in two fields. The submitter code is the registered organisation, and the authorised representative is what the message guide calls the PAN of the authorised person. Customs has accepted filings that name the organisation's own PAN there and filings that name the person who files; it need not be the holder of the DSC that signs.

Master vs. house-level detail

A single CSN filing can declare cargo at two levels: master consignment level (the top-line reference tying back to the vessel operator's manifest) and house consignment level (one entry per house bill a consolidator has issued to a shipper, each with its own consignor, consignee, and goods detail).

The distinction matters beyond structure. When customs accepts a consolidated filing, the Cargo Identification Number is issued per consignment, and it goes to the level carrying the cargo detail — the house bill receives a PCIN and the master receives nothing at all. Anything reconciling your filings against customs records has to key on the house bill, not on the filing as a whole.

An export consolidation is the exception. Its master is filed as consolidated C with previous declaration N and names no PCIN of its own, and customs issues that master an MCIN on acceptance — ICEGATE's own CIN-generation table says so, and it is what customs did on the consolidated exports it accepted in September 2026. The lines under it are issued nothing new: each quotes the PCIN its shipping bill already has.

One master-level field is easy to fill with the wrong company. On a master with house bills under it, the Consolidator PAN names the party the shipping line files under on that route— the line itself on some routes, an agent on others — and it can differ by destination from the same port. In a working filer's route table, one line files under its own PAN from Chennai to a Chennai destination and under an agent from Chennai to Bangalore. That is one filer's practice, sent to us in September 2026, not a rule customs publishes and not one checked with customs; where the paperwork or the line's own office says otherwise, follow them. Nothing on the bill of lading prints the PAN, and no public register lists carrier PANs. Party codes and PANs has the filer's table.

Exports: one shipping bill, or several under one B/L

An export CSN (SCX, CSN Exit) takes one of two shapes, and which one is decided by counting shipping bills. Both were among the exports customs accepted in September 2026 — a small number of filings, but they agree with the published sources below.

On both, cargo type is EX with movement TC; the destination and the port of receipt are the foreign port of discharge, while the Indian port the cargo is loaded at is the first port of entry and the port of acceptance; and where a shipping bill has no house B/L of its own, its line carries the shipping bill number and date. So no PCIN ever has to share a slot with another: each shipping bill gets its own line.

Which number each export bill quotes, and which customs issues, is set out in ICEGATE's own CIN-generation table — the workbook CBIC's clarifications point filers to. An export's PCIN is never issued by the CSN: customs attaches it to the shipping bill at goods registration, and it is printed on the let-export (LEO) copy.

CBIC's own training material glosses the letters by who issued the bill: S is a straight B/L, issued by the vessel-operating carrier to the actual buyer or seller; C a consolidated B/L, issued by a consolidator and not naming them; H a house B/L; R a B/L being referenced only. For the prior declaration: N none, Y a CIN generated earlier is being referenced, C a CSN quoting a previous CSN, B shipping bill to be referenced — with S, in the message guide's table, for a bill that refers to exactly one. The same decks describe an “18 digit” PCIN; every real PCIN and MCIN seen is 20 characters.

On the import side a house bill and its paperwork line up one to one. On the export side they do not, and the field that absorbs the difference is the small coded one nobody reads twice: prior declaration. A house bill covering several shipping bills is an ordinary shape, and it has its own code. CBIC said so directly, in a published clarification to the trade:

In the previous reference of HC, please give S when referring to one SB. If multiple SBs are getting consolidated, give B.

The MIG's own trade-scenarios table carries both as export house-bill rows, and it marks EX + H + N and EX + H + C “Not Possible”. An export house bill always refers to something, so “no prior declaration” — the right answer on a fresh import — is a combination customs rejects as error 118. What you are referring to is a PCIN: in exports, ICEGATE states that a PCIN corresponds to the cargo covered under a single shipping bill, so a house bill over four shipping bills sits over four PCINs.

The rule runs one way only, and the reverse shape is barred outright. Asked whether one shipping bill could be mapped to several bills of lading, ICEGATE answered that SCMTR's design allows a shipping bill to map to one BL or HBL only, and that trade may be asked to file a separate shipping bill for each. If a single shipping bill's cargo really moved out under two house bills, the correction is upstream in the shipping bill — nothing you can put in the CSN will make it pass. The full explanation, with both shapes, the ports, the totals and how to file it in the guided steps.

What an export is refused for, and what each code means

One Kattupalli-to-Colombo export was filed several ways in September 2026; four attempts were rejected for the four reasons below, and a later one was rejected only on its package count — so its shape is what customs wants. Together they settle what the published documents do not spell out. 365 “Cargo Movement Should be LC As Per Receipt Port” on an export means the port of receipt is wrong, not the movement: it named the Indian port the cargo leaves from, and it should carry the foreign destination's code, where the cargo is received — taking the code at its word and switching to LC draws 115 instead, because EX with LC is a pair the trade-scenarios table does not list. 159 “Incorrect Cin Type in MC” is an export saying it refers to a shipping bill or an earlier CSN (prior declaration S, B or Y) without a previous-CSN reference naming the CIN — though a Kolkata consolidation customs accepted on 22 September 2026 named every line's PCIN under Supplementary declaration instead, under a master filed referenced only (R), so a PCIN named in either block is a PCIN named. And 091 “Port of Call Can Not Be Same as Next Port of Call” was an itinerary whose only leg ran from Kattupalli to Kattupalli: an export's leg is the one to the foreign port. An import's terminal leg may repeat the arrival port, and customs holds an accepted filing that does.

Other exports refused the same month add four more. 286 “Invalid Destination Port Code” was an Indian port as the destination: the message guide describes an export's destination as the last port from which the goods leave India, but customs refused exactly that, and the exports it accepted name the foreign port of discharge. 383 and 384 — a CIN “Referred Multiple Times” in the master and in the house — arrive together when one PCIN is used twice in a filing, on a master and a line or on two lines: each PCIN goes on exactly one line, and a consolidation's master names none. 239 with 381 is a line that lists none of the B/L's containers: on an export every line carries its own, with its share, and containerised cargo needs one of type CN. And 709 “Total Pckg Mismatch in Transport Doc and Transport Item” is the items falling short of the bill's packages, usually because one item's count was left blank; 221 is the same sum against the containers and 225 a master against its lines. 381, 383, 384 and 709 are in no published code list — neither the message guide's table nor the official error list — so their meanings here are read from customs' own wording and the filings that drew them.

All of this rests on a small base: three exports customs accepted on 19 September 2026 and the refusals filed beside them. It is what customs has refused, not a list of everything it would. This platform checks every one of these shapes before an export is sent, naming the code each time.

How are the consignor and consignee identified?

Each party on a transport document carries a code and a code type, and the type is the half that gets filings rejected. The guide names five types: IEC for an Importer Exporter Code, PAN for a PAN issued by the Income Tax Department, and GSN, GSD and GSG for the GSTIN of a normal taxpayer, a diplomat and a government entity — and customs has also accepted PPT for a passport number, though no guide lists it (a passport typed PSP was refused). Customs validates the type against the direction of the cargo — there are distinct rejection codes for the wrong consignee code type on an import and on coastal goods, and the same pair again for the consignor on an export.

On an import the rule reads: give the consignee's IEC, and if no IEC is available, give the PAN. That fallback is not a loophole — it is the ordinary answer for a large class of shipments, because plenty of consignees are not required to hold an IEC at all.

The clearest case is a household move. Someone shipping their own used furniture and personal effects is exempt from holding an IEC under the Handbook of Procedures, so there is no code to go looking for. CBIC answered this directly in its published SCMTR clarifications: for unaccompanied baggage the filer gives the PAN of the party, or the passport number. The same shipment also needs its item type set to UB — unaccompanied baggage — which is the flag that tells customs these are personal effects rather than ordinary cargo.

What to file for used household goods and personal effects covers it in full, including the permanent IEC numbers DGFT publishes for the exempt categories and why the ones widely quoted in the trade are the retired, pre-PAN-format versions.

The reference numbers, and who mints which

SCMTR filing involves a lot of numbers that look alike. The order they appear in is the thing to hold on to: you supply some, ICEGATE returns one the moment it receives the file, and customs mints the rest only if it accepts.

Job number — you choose it

Your own reference for this filing. ICEGATE echoes it back in the ACK, which makes it the surest way to recognise which response belongs to which filing.

Sequence / control number — you choose it, and customs answers under it

The number this message goes out under. ICEGATE builds the file name it requires from the job number in decRef, and of 250 declarations on record here — several filers’ — 244 carry that same number in the header too, which is what makes a reply recognisable: customs names its acknowledgement after the control number, and one accepted amendment filed as job 100114 came back named …_65717_…_ACK.json. A file where the two differ is still accepted, so it is nothing to re-send over. The one thing ICEGATE does refuse is a control number it has already processed for that job date, and it says so by e-mail rather than with an ACK. An amendment is not that: one was accepted under its job number on the same day its CSN was granted under that number, so the app keeps the job number on amendments and deletions too, and gives a number of its own only to a second amendment of one job on one day. A refusal does not use a number up: one filing on record was refused and accepted under its original number the same day.

Master B/L number — the carrier issues it

The join key to the carrier’s manifest: the single field that lets your filing and theirs be matched up. Your own house B/L numbers sit underneath it.

Unique ID — ICEGATE returns it on submission

The handle the ACK is later fetched with. It is not the customs decision — it only confirms the file was received and queued. It can be absent even on a successful upload, and then there is nothing to fetch against and nothing to look the filing up by: the outcome arrives only as an email to your registered ICEGATE address, to be recorded against the filing by hand.

CSN number and date — customs mint them on acceptance

Seven digits, and the date it was granted. The pair is the reference, not the number alone, and every later amendment or deletion quotes it — the pair, not the upload that carried the filing: the accepted amendment on record here names the CSN number and date and no transmission id at all, so which copy of your file you start from does not change what it references. Customs mint one per accepted upload, so a CSN belongs to exactly one accepted filing — the same number appearing against two of your consignments is a mistake in your own records, not something customs did, and the amendment you build on it would reference the wrong cargo.

MCIN / PCIN — the Cargo Identification Number

Issued per consignment rather than per filing, at the level carrying the cargo detail. In a consolidated filing the house bill gets a PCIN and the master gets nothing — except on an export consolidation (master C, previous declaration N), where customs issues the master an MCIN and each line quotes the PCIN its shipping bill already has. It is what the CFS, the transporter and any later filing that refers to this cargo quote, so copy it out of the acceptance. An accepted amendment does not re-issue it — the ACK returns the PCIN as “null” and the one already issued stands — but a fresh re-entry of the same cargo that customs takes is a new CSN and a new PCIN, and everyone quoting the old one has to be told. The two letters after PC or MC say where the number was issued — measured on customs’ record in September 2026, not published: EG to the shipping bill itself, before any CSN; SX to an export CSN (PCSX to a straight line, MCSX to a consolidated master); SE to an import CSN; SM on the manifest side. A shipping line’s SDM line quotes whichever the export CSN’s master row shows — its own SX number where it has one, else the EG number it referenced.

IMO number — the hull, permanently

Seven digits assigned once when a ship is built and never reused, even after scrapping. It survives renaming, reflagging and resale, which is why customs identifies a vessel by it. A vessel name does not do this job: several ships can carry one name at the same time, and ships are routinely renamed on a change of owner or charter — so a name off a bill of lading narrows the field, and the IMO number is what settles it. Not every vessel has one: barges and coastal or inland craft are commonly never assigned an IMO number, and the message allows for exactly that — transport means type 10 is a vessel with an IMO number, type 11 a vessel without, and on type 11 the identity field carries the vessel’s name (up to 25 characters) in place of a number. Do not invent one: a made-up or borrowed IMO number is a filing customs will reject, where type 11 with a name is the shape the message guide specifies. One caveat, stated because it matters: every filing this platform has seen accepted so far carried an IMO number, so a type-11 filing has not yet been proven against customs from here.

IGM number — minted at arrival, by the port

Does not exist at filing time. See the note below on why a tracking lookup that finds nothing shortly after filing is expected rather than broken.

The one that catches people out is the IGM number: it does not exist when you file. It is minted at or near the vessel's arrival, while the CSN goes in ahead of arrival — so for the whole window between the two, the manifest enquiry has nothing to show, and its returning nothing is the expected state rather than a fault. Since September 2026 that gap has a second answer: CBIC's CSN / SAM / SDM tracking facility (Public Enquiries 2.0 on ICEGATE) lists every accepted SCMTR filing against a master bill from the moment customs accepts it — who filed, when, and the container and package figures they declared. It is public: a bill number and a port are enough, with no ICEGATE login. Presence there is confirmation of acceptance; absence means nothing accepted yet, never rejected, because rejected filings do not appear at all — as of September 2026; the submission-status enquiry customs announced in ICES Advisory 38/2026 (21 September 2026) is under implementation, not live. Two qualifications, each measured once in September 2026: a CSN whose deletion was acknowledged was still listed three weeks later, dated the deletion day — so present does not mean open to amendment; and one bill went blank for a while after an accepted update amendment, and the filer's fresh re-entry was then accepted as a second CSN with a new PCIN — so absent does not always mean never filed. Where a filer has sent, amended and re-entered a bill, the record shows the latest accepted version, not the history.

One date is conspicuously not among them: the ship's expected arrival. Customs' public list of a ship's calls gives each call — each VCN — an expected arrival day, but the CSN itself carries no arrival date: its voyage block names the ship and the call, and its itinerary names ports, not days. So a slipped ETA changes nothing in a CSN and needs no amendment. What does change it is a different call or a different ship — a roll or a substitution — because that changes the VCN, and a different ship changes the IMO number too.

What goes in the container fields

Containers are declared at both master and house level, and the equipment block asks for the box number, what kind of equipment it is, whether it is full or empty, and a size-type code — the four digits that say how big the box is and what sort it is.

That last one is worth knowing about before you meet it, because it is the field where filers most often disagree with each other. It is optional in every reporting event, and the MIG publishes no list of valid values — so what reaches customs is simply whatever the line's own equipment record said. ISO 6346 has used alphanumeric codes like 22G1 since 1995 and general shipping advice will point you at them, but no filing we can read carries one: every observed declaration uses the older four-digit numeric form — 2210 for a 20-foot box, 4400 for a 40-foot.

Since ICES Advisory 38/2026 (21 September 2026) customs says it is no longer the forwarder's to be refused for: the container ISO code and the container agent PAN used to be validated at both the CSN and the SAM, the double check was refusing forwarders' filings for equipment the line controls, and both are now validated at the SAM alone. Keep taking the code from the box all the same: the advisory names no error codes, so whether the seven-field cross-check with the line's filing, later on this page, is what moved is not settled, and no acknowledgement on record shows the change either way.

The folklore that different lines send different codes for the same size turns out to be true. One carrier's single filing of 86 containers declares its 20-foot boxes three different ways, because it passes each box's own code through rather than normalising them. The practical rule: take the code from the container door or from the liner, never from commercial shorthand like 40HC, which is a booking label rather than a code.

An empty container: what the rules ask for, and where they contradict themselves

Repositioning empty boxes is an ordinary movement and it is declared like any other cargo: load status EMP, the goods described as empty containers under HS code 86090000, package type CON. What the message wants for the numbers on such a box is genuinely unsettled, and it is worth knowing that before you file rather than after.

ICEGATE's published error list carries three codes about empty containers, and two of them point in opposite directions. 127 rejects a package count above zero on an empty box; 295 says the count on an empty box “should be mentioned as one”. Both are in the same section of the same list. Beside them, 128 rejects a weight above zero on an empty box — while every empty-container filing anyone has shown us declares the box's own tare weight, and none of those filings has an ACK beside it to say whether customs minded.

So there is no rule here to follow, only a practice: zero packages, the tare as the weight, and the document's gross weight carrying the tares added up. That is what real filings do. It is not what the error list unambiguously asks for, and we say so rather than presenting a guess as a rule — which is also why this platform marks a tare weight as worth a second look and blocks nothing over it.

One box, two house bills — and why the load status disagrees with itself

A consolidation routinely puts several shippers' cargo in one container, and the message has no field that says so. The only thing recording it is that the house bills carry an identical container number — there is no “shared” flag and nothing linking one bill to another. A single mistyped character is therefore not a typo but a second container, and the equipment count and the summed weights go wrong with it.

Each house bill declares its own share of a shared box — its portion of the weight and its own package count, never the whole container. The master consignment carries the totals. In one filing customs accepted, container TIDU5226928 appears on two house bills at 1,157.47 kg / 99 packages and 3,018.87 kg / 252 packages, and once on the master at 4,176.34 kg / 351 packages.

The same relationship holds for a box with one house bill in it: the master's row is the whole box, the house row is that bill's share, and with one bill the two are equal. Customs re-adds the shares and compares them with the master, so a master bill and a house bill that disagree about a container — two boxes with their weights interchanged between the two documents, say, where every total still agrees — is a rejection waiting to happen, and worth settling with whoever issued the wrong document before filing. SCMTR.io makes the comparison container by container and will not file while the two disagree.

That same filing shows the part that looks like a contradiction and is not: the load status differs between the two levels on purpose. A house bill's status describes that bill's share, so two shippers sharing a box means neither has a full container load and each says LCL. The master's status describes the box, which is full, so it says FCL. Both are right, and accepted filings look exactly like that.

The corollary is that the load status is not really a free choice. One house bill on a container has the whole box and is FCL; two or more sharing it are LCL. The one case that genuinely is a judgement call is a lone house bill on a part-full box — rare, but real, and the only situation in which a filer should be overriding it. On the line's manifest, a box two master lines share is LCL on each line and on the vessel's list in every manifest on record.

Moving cargo onward under bond

Cargo that does not clear at the port it arrives at — it goes inland by rail to an ICD, or into a container freight station to be de-stuffed — moves under a customs bond. The CSN has to say who is moving it and under which bond, in two fields: the transhipper code, which is that company's PAN written bare, and the transhipper bond, a ten-digit number.

Either a rail operator or a CFS can be the transhipper, and the message does not distinguish them. If your cargo clears where it lands and moves nowhere under bond, the block does not apply to you at all.

Which movement code, and what it commits the rest of the filing to

Customs stated these in its own words long before SCMTR, in JNCH Public Notice 16/2007 — the notice implementing CBIC Circular 14/2007-Cus for international transhipment at Nhava Sheva. LC is local cargo, delivered at the port it arrived at. TC is transhipment cargo, carried on to a port outside India, and the destination is that foreign port. TI is cargo moving to a hinterland port, an ICD, and the destination is the ICD's code. SCMTR adds DT and FT for cargo that never leaves the ship.

The code is not a free choice, and this is where transhipment filings most often fail. Cargo movement is validated together with the cargo type, the consolidation indicator and the prior-declaration flag, as one combination, against a table the MIG publishes in full — and the rejection names all four at once: 115 on a master consignment, 118 on a house bill. Import cargo stays IM whatever it does next and takes LC, DT or TI; it never takes TC, which belongs to transhipment (TR) and export (EX) cargo. A house bill of transhipment cargo takes TC and nothing else.

The consolidation indicator is part of that combination, and one shape catches import filers: a master marked R is the bill of lading referenced only. The table gives it one row, with cargo movement NA and no cargo type, and every accepted filing on record follows it — theR master declares no cargo type or movement of its own and the cargo is classified on its house bills. An R master that also declares IM and LC is a combination the table has no row for, and customs refused one as 115 on 23 September 2026. The same table's last column lists the blocks each combination must carry, and a house bill filed without its containers was refused the same day as 433, “Mandatory Object HC_Transport Equipment is Missing”.

Two consequences worth carrying. First, the movement code belongs to the bill of lading, not to the container: Public Notice 16/2007 has the cargo in an international-transhipment LCL box “segregated as per Bill of Lading” into local, foreign-transhipment and ICD categories, so one 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. Second, the same table says where the transhipper block below is expected: it is listed on every consignment reported for the first time that moves onward under bond — TI for any cargo type, TC or FT for export and transhipment cargo — and on none that clears where it lands. That is where the block belongs rather than a rule enforced both ways: the block itself is optional in the MIG's field table, and accepted filings do carry it on LCconsignments the table does not ask for it on.

One more piece of vocabulary, because it is asked in both meanings. To the trade and to the custom house, an ITP shipment is International Transhipment — cargo landed in India and carried on to a foreign port. In a CSN that is two fields, one value each: cargo type (typOfCrgo) becomes TR, and cargo movement (crgoMvmt) stays TC. TR is never a cargo movement — that field takes only LC, TI, TC, DT or FT, so putting TR there moves the right value into the wrong field. And note that the cargo-movement list on a CFS, delivery-order or IGM screen is the ICES IGM list rather than this one: it carries codes a CSN has no equivalent for, and labels the shared ones differently. Read the code, not the software's label. The ITP in NIC's EDI documentation is a different thing entirely: the older Import Transshipment message a CFS files through a value-added network, which is not a message you file. The full table of accepted combinations is published in the reference.

The PAN never changes; the bond changes at every port

This is the part that catches people, because it makes a wrong filing look like a complete one. A transhipment bond is registered per customs station, not per company — JNCH Public Notice 76/2018 describes the bond and bank guarantee as being registered in ICES at that custom house, by the carrier or custodian, who it then calls the transhipper. CONCOR is one PAN across all of India and files under a different bond at Nhava Sheva, at Mundra and at Chennai. The bond follows the station the cargo landed at, not only the facility: on every accepted filing that lands a box at Kattupalli or Ennore for a Chennai CFS, the CFS files a different bond from the one it files for cargo landed at Chennai — five CFSs, fourteen filings, no exceptions. Copy both fields from an earlier filing made elsewhere and you carry a PAN that is perfectly correct beside a bond that belongs to another port — every field populated, and rejected on arrival. Take the bond from paperwork for the movement you are actually filing, or from a filing made at the same station.

The bond also changes over time, and customs does not say so — three cases measured on filings customs accepted in September 2026. A CFS re-registered its Chennai terminals under a new company PAN and new bonds from 1 September, and a filing on the 9th still carrying the old PAN wasaccepted, then had to be amended once customs' record showed the new one: the old number was not rejected, it was silently wrong. A CFS's bond for cargo landed at Ennore was one number on 25 August and another from 7 September. And one operator filed two different Mundra bonds on the same day, both accepted. So the bond is decided by the operator and the port the box landed at, at the time you file — the operator's or CFS's own arrival notice for this movement beats any list.

Rejection code 147 (“Invalid Transhipper Bond Number”) is where this usually surfaces. If the PAN checks out, compare the bond against a filing at this port before looking anywhere else.

An accepted filing is not proof the bond was right

There are two failure modes here, and only the first announces itself. An invalid bond or PAN is rejected outright, on a field you can see, and you correct it and re-file. But an expired bond that is still registered can be accepted — the number remains valid in customs' records, so nothing rejects it. Where an operator holds two bonds, one lapsed and one current, filing the lapsed one goes through and then disagrees with what the shipping line filed for the same movement. Bringing the two back into line takes an amendment, not a re-file.

So check the bond against the paperwork for this movement rather than trusting that it went through, and where the shipping line's filing names a different bond, align with theirs. This is a working filer's account of the behaviour rather than something published by customs, which is precisely why it is worth writing down.

On a consolidation, the transhipper is on each house bill

Where a master bill of lading has house bills under it, the transhipper block belongs to the house bills, and the master consignment's own block is empty. Every accepted filing on record with house bills is shaped that way: the master carries its reference, its packages and measures, its container list and the house bills themselves, and nothing else. An empty transhipper on the master of a consolidation is the normal shape, not missing data — which matters most when an accepted filing is opened to be amended. Typing a transhipper onto the master there does not correct anything; it asks customs to add a block the CSN never carried, beside house bills that still name whoever they named. If the transhipper has changed, the change goes on every house bill that names the old one.

Cargo going into an SEZ names no transhipper

A move into a special economic zone looks exactly like an ICD move on the form — cargo movement TI, onward from the gateway to another Indian station — and the combination table cannot tell the two apart. But where an ICD move by rail carries the train operator's PAN and its bond at the gateway, an SEZ move carries neither: the transhipper block is left blank, at every gateway, whether the onward leg goes by road or by rail. Customs has accepted it: five CSNs from Chennai take twelve house bills by road into three zones — the Cochin SEZ, the Mannur FTWZ and NDR Infra SEZ — with the block blank on every one, while every accepted filing to an ICD names its rail or road operator. One of those house bills carried 00 in both halves and was accepted too, so customs is not checking the block against a party there. A working filer's scenario sheet says the same, and so do a shipping line's own CSN at Visakhapatnam and a steamer agent's arrival manifest at Nhava Sheva. What is not held: an accepted SEZ filing from a gateway other than Chennai, or customs text that says “leave it blank” in those words — so if your zone's customs officer tells you otherwise for your movement, follow them. SEZ cargo routed through a CFS first is not settled by any of it.

The other bond: the BOND NO on ICEGATE's tracking page

Look a master bill up in ICEGATE's New SAM/IGM enquiry and each container row ends with an Agent Code and a BOND NO. That bond is not a transhipment bond. It is the container agent's container (CG) bond: a container arriving in India is itself a foreign good, so the line or its Indian agency signs one bond with customs covering all its boxes, each box debited to it on arrival through the carrier's manifest and credited back when it is re-exported. It is the opposite of a transhipment bond in the way that catches people — CBIC's own SCMTR clarifications answer “one entity, one bond for pan India ops”, where the transhipment bond changes at every port. No field on a CSN takes it. It explains one rejection, 82 (“Container Bond Not Found For the Agent”): the PAN in a container's agent code has no container bond registered, so the agent code must name whoever actually holds the bond for that box. Since ICES Advisory 38/2026 (21 September 2026) customs says that check falls on the line's SAM rather than the CSN — the container agent PAN and the container ISO code are now validated at the SAM alone, the double check having refused forwarders' CSNs for the line's own equipment — so the value to give is unchanged; whether 82 is the check that moved is our reading, the advisory naming no codes, and no refusal on record here has carried 82. Transhippers, CFSs and bond numbers carries the sources for all three of these.

A bill the older SAM/IGM enquiry cannot find while the rest of the vessel shows

ICEGATE's older SAM/IGM enquiry lists a consolidation by its house bills, each on the IGM line it was mapped onto. A house bill declared as transhipment (cargo movement TC, onward to a foreign port) is not imported at that port, so it is never mapped onto an IGM line — and when every house bill under a master is transhipment, the enquiry has nothing to list and answers “No details found” for a bill the line's SAM holds and customs has already given an MCIN. That was measured on one Nhava Sheva manifest in September 2026 — across five consolidated lines every locally cleared (LC) house bill had an IGM line and none of the eighteen TC ones did — and it is a measurement, not a statement from customs. The New SAM/IGM enquiry, or BL tracking here, shows the master on its SAM line with its MCIN and each house bill's cargo movement; only an LC house bill still without an IGM line once the rest of the vessel has one is worth taking to the line and to customs.

CFS codes, and where the destination goes

A container freight station is identified by a ten-character code: the six-character customs port, then a four-character suffix naming the facility inside it — INMAA1SHC1 is a named CFS at INMAA1, Chennai. The length is ICEGATE's own: its ICES 1.5 custodian message specification says that where cargo is discharged through a CFS, a 10-character CFS code is what must be given. The destination port field takes either form. A plain six-character port says the cargo is destined for the port; the ten-character code says it is destined for a particular facility within it. Both are correct, and they answer different questions.

There is no central directory of either, though the codes are not unpublished: customs commissionerates assign them in per-port facility circulars — Chennai Customs' circular 20/2018, for instance, assigns the Kattupalli CFS codes — so a code can be verified one circular at a time. ICEGATE itself documents only the format: its own location service returns 586 customs stations, every one of them the short six-character kind. Bond numbers are further out of reach by their nature — a transhipment bond is a financial instrument between one company and one custom house, which is why customs asks the filer to supply the number rather than look it up. So filers keep their own lists, built from filings that were accepted. Where one operator runs facilities at several stations under a single code, that code alone cannot tell you the bond — each station has its own.

A CFS move is not a transhipment — the movement code says so

The cargo movement field draws a line that surprises people: in working filers' practice, cargo delivered into a CFS files as LC — local clearance — even when the CFS is registered under a different customs station, while TI is reserved for the genuine onward movement to an inland container depot. The filed itinerary follows the same discipline: two legs only — the sea leg to the gateway, then the onward leg to the final destination — however many ports the box actually touched in between. Where the cargo goes after the gateway port walks all four destinations — port pickup, CFS, ICD, SEZ — and what each one makes the filing look like.

“Do we have to mention the SMTP?” — no, and here is why

A counterparty asking a forwarder for “the SMTP” on an ICD movement is asking the wrong party. The Sub-Manifest Transhipment Permit is the gateway port's permit for moving manifested cargo inland, and a CSN has no field for it anywhere — the SACHM22 guide mentions a permit only as a crew document code. CBIC Circular 46/2005-Cus explains why: the permit is raised from the carrier's IGM, whose “Sub manifest Transshipment Permit (SMTP) portion … will be treated as a request for transshipment”. It is then quoted in the inland station's own ICES messages — the ICD's local IGM, the ICD custodian's container arrival, and a CFS's Import Transshipment — and none of those three is a forwarder's to file.

For an ICD movement your filing says it in the fields above and nowhere else: cargo type IM with movement TI, the ICD's code as the destination and next port of unlading, a second itinerary leg by rail or road, and the transhipper block. Under SCMTR the inland leg stops being a permit at all — the authorised transhipper files Customs Inland Manifest arrival and departure declarations for each vehicle and links them to earlier legs by the cargo identification number.

One trap for the abbreviation itself: ICEGATE's own list expands SMTP as Simple Mail Transfer Protocol, the e-mail channel for sending a signed filing in. Whether a sentence means a permit or a protocol is usually settled by whether it is talking about cargo or about a file.

Cargo going on to Nepal or Bhutan is transit, not import. The one shape customs is known to have accepted is a shipping line's September 2026 Kolkata manifest, with 228 such lines: cargo type TR with movement TC, the station across the border (Kathmandu, Birgunj or Thimphu) as destination, next port of unlading and port of receipt, a second itinerary leg by rail or road, and the transhipper block filled only on the rail leg to Birgunj — none on any road leg. The consignee is foreign with code type PAN and the code left empty. Customs' combination table never allows TC on import cargo, so a Nepal consignment filed as an ordinary import with an ICD movement is the wrong pair. What a forwarder's CSN for the same cargo should carry has not been seen accepted, and the consignee-code question is open; the detail and the open points are at after the gateway port.

Why do filings get rejected?

Three different things are all called a rejection, and they look nothing alike. A structurally invalid file was not a valid SCMTR message at all — it comes back carrying JSON-Schema vocabulary and no error code, meaning something was malformed rather than merely wrong. A business validation failure means the file parsed fine and customs disagrees with its contents; that one arrives as field-level error codes you can act on.

The third never becomes an ACK at all. Some files are rejected by email, to the address the ICEGATE registration is under, before any ACK exists: a control number already processed for that job date, a signature from a DSC that is not the registered one, a file that is not UTF-8 encoded, a value longer than its field allows. These carry no error code, arrive in prose, and mean nothing was filed — no CSN, and no ACK coming for that upload, so waiting for one is waiting for nothing. ICEGATE's own FAQ documents several of these emails; the over-length one is known here from a single real rejection in September 2026, whose wording is in no ICEGATE document we hold. The emails, what each means and what to do.

The cheapest family to prevent is arithmetic, because your own file settles every one of them. Customs adds up what you declared and checks it against itself: the declared container total against the containers actually in the message, the declared line count against the consignments present, the document package count against the sum of the item counts and the container counts, the master's package count against the sum of its house bills', and each master container's weight and packages against the house rows carrying that box. A container mentioned on a house bill has to exist on its master, and at voyage level above that.

A close cousin is the duplicate identity: customs tells records apart by their numbering — every master consignment by its line number, every house bill by the line and sub-line pair. Two house bills under one master both numbered 1 are, to customs, one record filed twice, and the filing is rejected. Files assembled by hand are where this happens. The bills themselves are an identity too: two master consignments carrying the same master B/L and the same house bill come back as 375 and 376, “Duplicate Record in MC Ref / MC Transport – MBL+HBL”, reported against the voyage rather than either line — usually a line copied to start a second and left as it was. The same master B/L with different house bills is declared split cargo and is not a duplicate.

The fix is nearly always the same: count again, and make every level agree. It is also the family most worth preventing rather than curing, which is why totals in this platform are derived rather than typed, row numbering is automatic, and an uploaded file is checked for both before it is filed.

A third family is about the characters themselves. ICEGATE names them by field: 354 and 355 reject a special character in the master and house bill-of-lading numbers, and 356 does the same for a container number — so those three carry letters and digits and nothing else, whatever the carrier's paperwork prints between them. For party names, addresses and goods descriptions the MIG publishes no per-field character rule, and real accepted filings carry a narrow set beyond the alphabet: the full stop, comma, ampersand, slash, hyphen, brackets, colon and equals sign. Case is not a published rule either, and is no less real for it — every value in every accepted filing on record is upper case.

Beneath all of that sits the one character rule ICEGATE does publish, and it covers the whole file: the file must be UTF-8 encoded. ICEGATE's SCMTR FAQ (question 22) says a file that is not is rejected by email naming the line and position of the fault, and that is what happened to a real filing in September 2026, made in other software — what the offending character was is not known, because it was never seen. In practice the bar is close to plain ASCII: every filing on record that customs accepted is plain text throughout, with no curly quote, long dash or accented letter in any of them — and the one character outside ASCII customs has taken, on seven accepted filings, is a correctly encoded non-breaking space. So the check is the encoding, as the FAQ says, not the alphabet; the safe practice is still plain text. None of this is worth memorising: this platform converts case, turns pasted characters into their plain equivalents and drops what cannot be filed as you type, in the fields each rule applies to.

Length is the other limit, and it is published: every field in the MIG has a maximum length — 70 characters for a party's street address, 256 for a cargo item description, eight for an HS code. Treat it as a hard limit. The one over-length rejection on record, in September 2026, did not come back as an ACK naming a field: ICEGATE failed the whole file by email, quoting a 74-character consignee street address and the words “should not be more than length 70”. The one exception worth knowing runs the other way: an accepted filing on record carries a ten-digit HS code where the guide prints eight.

The published error table runs to 452 codes, and the one filers find hardest to act on is not in it. 700 Error-Refile is a rejection with no field, no family and no detail beyond the number — look it up in the official table and you will find nothing, because it is not there. It is the catch-all, and ICEGATE has published nothing about its causes, so it is worked by elimination, cheapest check first: the arithmetic above; a re-sent filing reusing its old control number — send a fresh one, though ICEGATE answers a re-used number by email rather than with a 700; a consolidation shape that disagrees with the bills actually in the file; and a conveyance reference that is the carrier's voyage number rather than the VCN customs issued for that call — or a VCN customs has since replaced because the vessel changed, which the filing page can now say, since it records what customs listed for the ship when you filed. That order is a way of working, not a ranking: no 700 on record has been traced to any of them. ICEGATE's own account points elsewhere for large files: on 12 September 2026 its engineers told the trade that a 700 on a large manifest file was the system picking the file up and refusing it under database contention at peak time, the same file going through later. ICES Advisory 38/2026 (21 September 2026) says the processing of large manifest files has since been re-engineered with dedicated schedulers and indexing — an answer about acknowledgement delays that does not mention 700; that the two describe one path is our link. So a 700 on a small, correct file is still worth the checklist, and a 700 that clears on a re-send of an identical file was likely load. Filers also name a timeout, a port code customs does not know and a wrongly entered PAN, GSTIN or IE code; customs has numbered errors for the last two, so those would normally come back named. Sometimes there is not even a 700: one refusal on record came back stamped Rejected with every consignment marked 00 Successful and no code at all. Work it the same way — a missing code is not a different, worse kind of failure.

The ACK is named after the file it answers: the same type, message, event, sender and job number, with _ACK where the filing had _DEC. The date is the exception — ICEGATE stamps its reply with the day it answered, so a filing sent late on the 4th and answered on the morning of the 5th comes back named for the 5th. Pair a reply with its filing on the job number and on what the two files carry, not on the whole name — and expect a file renamed on its way through a mailbox to be harder to place, because a rejection's body does not repeat the job number the name carried.

A reply to a SAM / SDM (SACHM23) is not a copy of the file it answers, though it looks like one: on every reply, accepted or refused, the header's versionNo reads ICES1_5, decRef.msgTyp reads F and every record's amdType is dropped whatever was sent, and each line's prevRef reads "null" on a refusal, filled only on an acceptance with the CIN customs issued. So never infer what was sent from what came back — open the file you sent.

Which is why a corrected shipment leaves you holding more files than filings. Customs answers an upload, not a consignment. A rejection, a correction and a second send is two uploads with two control numbers, so two ACKs come back — both naming the same vessel, the same master bill of lading and often the same error — while the CSN still in the folder is usually only the first attempt, the one nobody thought to keep a copy of because it had failed. Only the pair sharing a control number belongs together, and reading a reply against the other file positions every error on a document customs never saw. Keep the exact file you sent for every upload, named by its job number, including the ones you expect to be rejected. How to tell two ACKs apart.

Some codes name a field under a name the message never uses. “Buyer” is the consignee — 44 Invalid Buyer Country Code is about the consignee's country on the transport document it is attached to, where 43 is the shipper's and 46 the notified party's. All three take a two-character ISO code, which is why the rejection that puzzles filers most is the one on a country code that is already correct: US is right for the United States, so the cause is usually elsewhere in the same party block. Three things to check before re-typing the code: the three-letter form the trade writes (USA, IND) sitting in a two-character field; the error naming a different bill than the one you corrected, since the master and every house bill carry their own consignee; and a foreign country declared against an Indian PAN or IEC, which on an arrival message reads as a contradiction — every party code type customs accepts bar a passport (PPT) is an Indian registration. That last one is our reading of the code rather than a rule ICEGATE publishes, and it is the one worth checking when the country itself is plainly right.

One reading detail, because it costs a search otherwise: a code can arrive zero-padded. A real ACK writes "044" where the published table writes 44, and not uniformly — the success markers in the same file stay 00. Strip the leading zeros before looking a code up.

A code is only meaningful with the message it answered. ICEGATE is one gateway in front of several customs systems, and each replies from its own list: the CSN and the shipping line filing share one numbered table; the custodian and transhipper messages use alphanumeric codes such as TMB03; the legacy Sea IGM, Consol IGM, ICD IGM and the Bill of Entry each have a numbered list where the same number means something else — 999 is “reserved” on a CSN and “check the duty parameters” on a Bill of Entry. The reply's message id says which list to read: SACHM22 or SACHM23 is SCMTR, CACHI01 a Bill of Entry, SACHI01 a Sea IGM.

One more distinction is worth carrying, because the two need opposite responses and the ACK does not label which you have. A field-level rejection names one value that is missing, outside its coded list or the wrong shape — the fix is local and nothing else changes. A filing-level one rejects the declaration as a whole: nothing in it is malformed, but what it claims disagrees with something customs already holds. Sending that one again with a fresh control number and no other change gets the same answer. The reference to another party's CSN is the commonest case: customs matches the bill you name against that CSN on its number and its date, and a bill written with the right number and a date two days off draws 164and then fails its totals against the CSN as well (232, 233) although they are identical — seen on a real rejected manifest amendment in September 2026, where the neighbouring line that matched its CSN exactly passed. Compare the number and the date against the CSN's ACK before touching a package count.

Your CSN is one message among several

SCMTR does not ask one party for one filing. The shipping line or its agent files the SAM (SACHM23 — arrival, departure, entry inward, departure notification); an authorised transhipper files the inland movement (TRCHE01 — allowed-for-shipment request, departure, arrival); a custodian files what happened in the yard (CUCHE01 — stuffing, stripping, arrival and departure times); and the port operator has messages of its own. A forwarder, NVOCC or consolidator files the CSN and nothing else. Who prepares and uploads the file is a separate question from whose filing it is: a customs broker or filing agency may prepare a client's CSN and upload it under its own ICEGATE user ID or the client's, and the filing remains the client's.

The filings are separate but the cargo is not, and each stage links to the last by the cargo identification number rather than re-declaring it — which is why the MCIN or PCIN a CSN earns still matters an inland leg later. Three consequences reach a filer who never touches those messages: the line's accepted manifest takes a CSN deletion out of the forwarder's hands and turns an amendment into two filings (the CSN amendment, then the line's matching SAA); a transhipper's request is rejected when the PCIN it quotes is not accepted yet; and a CFS occasionally asks a forwarder for a filing only a transhipper may make, which is a registration mistake at their end, not a missing file at yours.

When one of those files lands on your desk anyway — and it does, usually with a question attached — every field either message can carry is set out from ICEGATE's own guides: every field a transhipper or custodian files covers the transhipper's 69 fields across ten blocks and the custodian's 63 across nine, with what each guide says about them. And the file itself can be opened: drop it on SCMTR JSON upload and it is read block by block with those same descriptions attached, its reporting event spelled out, and anything neither guide describes listed rather than dropped. Neither message is a forwarder's to file; both are worth being able to read.

Two of SACHM23's six events declare no cargo at all, and reading one as a manifest is a wasted afternoon. An arrival or departure manifest (SAM, SDM) declares what is aboard, bill by bill. An entry inward (SEI) and a departure notification (SDN) instead report the call itself, after the fact — the manifest guide's own field table marks the master consignment block, the voyage details and the ship itinerary X on both, and marks the arrival-and-departure block mandatory on exactly those two and not-applicable on the other four. So a departure notification of 481 containers is a page of counts and times — containers landed and loaded, persons on board, transport contracts, the terminal's own arrival and departure stamps — and carries not one bill of lading. A file that looks empty in a manifest reader is usually not a broken manifest; it is one of these two, opened as the wrong thing. Both open here for what they are.

Two companies file against one master bill of lading

A consolidated shipment produces two separate cargo declarations against the same master bill of lading. The freight forwarder, console agent or NVOCC declares the house cargo — the individual shippers and consignees whose goods were combined into the container. The shipping line declares the master, at vessel level. Customs then cross-validates the two against each other. Neither files instead of the other, and the line filing against your master B/L does not invalidate anything you sent.

The cross-check is narrower than people expect. Error codes 232–238 name seven physical facts about the container and nothing else: the total packages, the total equipment, and per container its type, ID, size, load status and SOC flag. Everything a filer would call commercially sensitive — your shippers, your consignees, your rates — sits outside that list entirely. Two declarations are compared on what is physically true about the steel box, not on commercial relationships.

Of those, the ones customs has actually been seen refusing are the bill's date (164), the packages (232), the number of containers (233) and a box's load status (399) — and only where the line quotes the CSN; a line carrying the bill with its own house bills is not compared with it. This platform compares every field the two can be compared on and sorts each difference as Fix (customs has refused filings for it), Check(should match) or OK to differ, measured over both sides of nearly a thousand accepted bills (what must match). From a manifest you can ask customs, bill by bill, which lines already have an accepted CSN against them and how they compare — before either side is refused on it. A bill with no CSN yet is reported as absent rather than as a problem: the forwarder files on their own schedule. Measured across real shipments the forwarder's CSN comes first and the line's manifest lands up to five days after it, one to three days before the vessel is granted entry inward — so an early manifest with absent lines is a manifest filed unusually early, not one that is wrong.

The line has to quote your CSN, and nothing sends it to them. A manifest line that covers a forwarder's consignment carries a prior reference block naming the CSN it stands on — the CSN number and the date customs granted it, or the MCIN/PCIN customs issued, with the submitter, the reporting event and the customs site beside them. Customs then compares the line against that CSN: the bill of lading number and its date under 164, and the seven physical facts above under 232–238. None of it reaches the line automatically. In practice the carriers collect it themselves — Maersk, CMA CGM, Hapag-Lloyd and ONE all publish advisories telling customers to post the CSN number and date, and the PCIN, into a portal before arrival, several of them adding that otherwise the line files the master bill on its own and the customer carries the charges. Those are the carriers' own notices rather than anything CBIC has published, so treat the deadlines in them as each line's commercial terms, not as regulation — but the thing they are collecting is real, and a bill date re-typed into a portal is exactly where 164 comes from.

Whoever files second receives any rejection, because customs has the first filing to compare against. That does not mean the second filer is the one who is wrong — a mismatch is usually mechanical, like a container type written 2200 on one filing and 2210 on the other.

How long do you have to amend? Aim for before another party’s CSN

This is the most expensive thing to learn late, and almost nothing announces it. Amend or delete your CSN before another party's CSN for that master bill of lading is accepted if you can — the shipping line's own, or another forwarder's. After that the CSN is linked to theirs: customs' error list has 320 for an amendment or deletion of it, and a fresh master- or house-level filing against the same bill meets 122 and 123. No refusal carrying 320 has been seen yet, so since 29 September 2026 SCMTR warns of it rather than stopping the amendment; if customs does answer 320, the correction goes to the shipping line and your jurisdictional customs officer. There is no notice, because the other filing is not a date. It is somebody else's action, and it can happen at any moment.

The shipping line's manifest (SAM) is a different event, and since ICES Advisory 37/2026 (18 September 2026) it does not close the window. After the SAM and before entry inward, the forwarder still files the CSN amendment (SCA) directly, then gives the line the amended CSN and MCIN/PCIN so it can file a matching manifest amendment (SAA); once entry inward is granted, both need the jurisdictional customs officer's approval. The one public sign that entry inward was granted is the inward date on the line's manifest record. What the SAM does take away is the deletion — from then on the officer carries it out — and a fresh CSN: the advisory has the CSN filed before the manifest, and the line add any missing house bills by amending its own (SAA). The VCN and rotation number cannot be amended either way. Before the SAM the deletion is the forwarder's own, and since ICES Advisory 38/2026 (21 September 2026) customs says it may be followed by a re-file of corrected particulars — what that changes, and what it does not, is under amendments below.

Until 19 September 2026 this page said the line's manifest closed the window just as another party's CSN does. That was an inference from 320, which names a linked CSN; no ICEGATE refusal ever showed a manifest closing a CSN to amendment. The advisory is customs' own published process and replaces it — though no filing on record here has yet been seen amended after a manifest, so this is what the advisory says rather than something observed.

One step is in no notice at all. The process CBIC's SCMTR team has set out for the trade — reported, and published in no circular, advisory or public notice — has three windows rather than two: before the SAM; after the SAM but before the vessel berths, where no officer is needed but the line must act; and after the vessel is inward, where the officer approves. In both of the later windows that process has the line first delete what it already filed, and only then file the SAA; an SAA laid over an untouched SAM is the likeliest explanation we have for an amendment that “goes in” and changes nothing. What “delete” covers, that process left unsaid; for the console case ICES Advisory 38/2026 (21 September 2026) describes the procedure, with the drop inside the SAA itself: where the forwarder filed a CSN, the line first drops (deletes) the straight master bill line it filed and then re-adds the master bill as consolidated, linking the CSN and house bill references — the bill's own line, not the manifest withdrawn, which is our reading of the reported phrase and also all the message set allows, since SACHM23 has no message that withdraws a manifest. Where no CSN was filed at all, the same advisory has the line put the full house bill details into the SAA's own house cargo block instead. And the drop-and-re-add is the rule for any change to a line's consolidation indicator, consolidator PAN or previous reference (CSN, PCIN or MCIN): the advisory says an in-place update of those is refused by the system, so the line goes out as a D and comes back as an S — whether customs takes both in one SAA is not yet proven by an acknowledgement on record. For any other CSN amendment after the SAM — figures, a party — the line's matching SAA updates the line (U, “modification of allowable fields”); the advisory has nothing deleted for that. The same sequence is how a consolidation's house bills reach a manifest that was filed without them: the console split, step by step. That is not the split indicator, which is for one bill genuinely filed in parts: JNCH Public Notice 15/2026 gives it three values — N for an ordinary bill, Y on every part, and F on the last part, which is what closes the set — and a part filed without them collides with the first as 122.

Customs finds what an amendment changes by its numbers, not by the bill. An SAA updates or removes a line by its line number, and a container by its line, sub-line and sequence number; the bill of lading and the container number written beside them are not what customs looks up. Those numbers are the ones on the version customs holds now, amendments included, so an amendment built from the file the line sent weeks ago can address the wrong line. In September 2026 a line's SAA removed a bill as line 256 with its four containers numbered 1 to 4; customs held that bill on line 295, and line 256 held a different bill with one container. It came back as 749 (“Line_No+Sline_No+EqmtSrNo Not Exists For Update/Delete in TrnsprtEqmt”), a code in no published list; its published sibling 306 says the same of a line. The remedy is to open the manifest as customs holds it, every accepted amendment included, and build from that. A second code from the same month, 753 (“Amd-MC-MBL Details Already Exists”, the amendment's twin of 122), refused an SAA line that declared a bill afresh when an accepted CSN on the same rotation already held it: a bill customs already holds is quoted, not declared again, and if the CSN describes the cargo wrongly it is the CSN's filer who changes it. Numbers bind additions too: every real SAM and SDM on file numbers the vessel's container list 1 to N, the real amendments add at N + 1, and an SAA that gave its added boxes the places a re-sorted list would — inside the 1,025 the manifest held — was refused as 394 (“Line_No+Sline_No+EqSrno Already Exists in Equipment”, published nowhere). A deleted line leaves its number unused, so a manifest's line total is a count, never its highest number: an SAA declaring the highest number came back 90 (89 for the containers), and a refused reply to an amendment, which lists the manifest customs holds with the lines the amendment sent, gives the count once the lines the amendment deletes are taken out. Here an SAA is checked before it is sent against the manifest customs holds — counted line by line from ICEGATE's public record, or read from the newest accepted reply on file — for its totals, added numbers and the lines it addresses. A third, 748 (“Line_No+Sline_No+Srno Not Exists For Update/Delete in TrnsprtItems”), is 749 for a cargo item, and on the refusal seen the line number was right: the line was a straight bill quoting an earlier declaration, which customs' Trade Scenarios table gives no item details at all — the CSN it quotes holds the goods — so the item the SAA updated had never been held there. Item details come off such a line; the goods are corrected in the CSN it quotes.

Three things about the codes themselves. The vessel manifest guide prints eight codes of its own that the CSN's list does not — 369, 371–374 and 377–379: an invalid consignor PAN, a missing passport number, the two “Entry Inward is Granted — Amendment Not Allowed” codes, a cargo description code that should say freight container, and a cargo movement customs does not allow for export or transit cargo. A manifest reply may also write a code with a three-letter block prefix — VGD020 is 20 found in the voyage details, MTE749 is 749 on a master bill's container — where the prefix says where the fault sits and the number is the code. And an unpublished code arrives in the published codes' own words: 748 and 749 say “Not Exists For Update/Delete” exactly as the published 306 does, so a code in no list is read by its wording first, and quoted to the helpdesk second.

At Chennai, a refused amendment has somewhere to go. Public Notice 130/2026 (23 September 2026) set up an SCMTR help desk at the Preventive Commissionerate, with officers allocated by vessel, for problems “particularly with respect to amendments”, taken up with DG Systems. Its one firm ask, repeated in the Commissioner's letter of 24 September to the lines and the consolidators' associations, is the Unique ID of every refused SAA or SCA — the tracking ID ICEGATE gave the transmission, the acknowledgement's uniqueId — sent straight away to the vessel's officers. It changes no filing rule, and no other port has published anything like it that we hold.

Both events are visible before they cost anything. CBIC's CSN / SAM / SDM tracking facility (above) shows them from the moment of acceptance: look up the master B/L and the port, and another filer's CSN on the record means the window has shut; the line's manifest under the SAM event means you can still amend, with the line's SAA to follow, but no longer delete; only your own filing means everything is open. This platform reads the same record for every filing and says on the filing's page which case applies — withdrawing File a deletion once the manifest covers the bill, and both actions once another party's CSN does. The practical rule is unchanged: amend the day something looks wrong rather than the week after — once the window has closed, a wrong declaration has to be settled with the shipping line and the jurisdictional customs officer rather than through any portal.

Filing the CSN in the first place has no cutoff counted in days. CBIC's table of who files what puts the CSN “before departure from the last port of call” — the same point it sets for the carrier's arrival manifest — and nothing published turns that into hours or days before arrival. The five-day figures that circulate are practice, not a rule, and the 6, 24 and 48-hour windows are the carrier's manifest amendments, above. What actually closes a forwarder's window is another party's CSN being accepted, which is why it is worth watching the record rather than a calendar — and why a VCN the port has not issued yet is a reason to keep the rest of the filing ready, not to guess at one. Is there a deadline for the CSN itself?

The other clock is the shipping line's SAM. Before the line files it, every correction to your CSN is free — the line simply picks up the amended CSN, and since ICES Advisory 38/2026 a CSN can even be deleted and filed again while no SAM refers to it. After it, the same correction is the line's SAA: a request carriers' own notices charge up to ₹10,000 for on top of customs' ₹1,000 fee, with the consignee's Bill of Entry refused under error 635 until it goes through. So the deadline to work to is the line's cut-off for CSNs, after which it files with what it has — one large carrier asks for the CSN by 72 hours before arrival. The platform checks a CSN against what the line has filed for every master B/L before the token is asked for, and reminds you of the cut-off a day before it, using the line's own where the line has set one here and otherwise 72 hours before the arrival customs lists, said as a default rather than the line's word. Check your CSN against the line's SAM before you send it

Why does customs refuse a cargo movement “as per receipt port”?

Beyond the combination checks on cargo type and movement (115, 118, 126), customs checks the movement against one field on the transport document: the port of receipt. A receipt port that is a sea port — a customs location code ending in 1, such as INMAA1 — takes only LC, and anything else is rejected as 365, “Cargo Movement Should be LC As Per Receipt Port”. An inland container depot or SEZ — a code ending in 6 — cannot take LC, and that is 366. The rejection arrives on the transport document, while the field to change sits in the location and customs block, which is why it reads as though it names nothing.

A 365 has two opposite fixes and only the filer knows which: set the movement to LC, or, if the cargo really is bound for an inland depot, correct the receipt port to the depot's code and keep TI. Every filing in this platform's sample corpus obeys the rule; that the sixth character of the code is what customs reads is an inference from that corpus rather than a published statement, and one cross-station shape has been accepted as TI a week before being rejected as 365.

How do you amend or withdraw an accepted filing?

One rule decides everything else: an amendment references a CSN. The granted number and its date are both mandatory on an amendment, and they are what make it an amendment rather than a second declaration. Reference the wrong CSN and you have amended somebody else's filing.

A withdrawal surprises people: a deletion is not its own message type. To withdraw a filing you send an amendment whose amendment type is delete — there is no standalone delete message on the wire. A deletion also carries almost nothing: header, declaration reference, authorised person, vessel, and no cargo tree at all, which stands to reason when you are withdrawing the whole CSN. A real deletion message runs under 600 bytes against a 3,500-byte original.

An update is the opposite: the accepted filing re-sent in full — every master consignment, house bill, container, item, and itinerary leg — with the CSN reference added and the changed values corrected in place. Nothing is removed and nothing is restructured.

Not every block accepts every amendment code. Version 1.6 of the MIG narrowed this: the message itself takes update or delete — a filing is corrected or withdrawn, never “supplemented” — while the authorised person, vessel and voyage blocks take update only, there being no vessel to delete or second voyage to add. Everywhere else the full set of update, delete and supplementary applies. The form offers only what the block allows, so this is not something you have to remember.

The rejection that catches most amendments is 316, “CSN No/Date Not Exists For Amendment Request”: customs matched no CSN on the number and the date together, and the date is the half that is usually wrong. Take both from the positive ACK of the filing being amended — not the filing date, not the ACK's own header date, not today. And whatever the cause, a rejected amendment leaves the original standing: correct the amendment and send it again as an amendment, never as a fresh filing, which collides with the original on the bill numbers (122, 123).

That pair comes back whenever customs already holds the bill from you. Whether a filing you have since deleted still holds it has changed on paper: the re-file after a deletion measured here, on 6 September 2026, was refused, but ICES Advisory 38/2026 (21 September 2026) says a forwarder may now delete a CSN and promptly re-file corrected particulars without a mismatch, provided no SAM has yet been filed against it. That is customs' stated position, not yet something seen from customs' side — no re-file after a deletion has been seen accepted since — so amendment stays the lighter route while the CSN is yours to amend, and once the line's SAM covers the bill it is the only self-service one, a deletion being the officer's from then on (ICES Advisory 37/2026). Look the bill up on the tracking facility before re-entering it: a listed bill draws the code and wants an amendment of the filing that holds it; a blank one takes a fresh filing, but as a new CSN with a new PCIN, which the CFS and the transporter quoting the old one must then be told. One filer's accepted update amendment left the record blank for a while and their fresh re-entry was taken as a second CSN; two re-files on bills customs still held — one after a deletion, one after a vessel substitution — were rejected, both before the advisory.