Which SCMTR message do I file?

SCMTR is not one message. It is a family of them, filed by different parties about the same voyage, and they are easy to mistake for versions of each other because their codes differ by a single character. This page is about telling them apart.

If you are a freight forwarder, NVOCC, consolidator or customs broker, the short answer is: you file the Cargo Summary Notification, message SACHM22. That is what this platform files. The rest of this page is context for the messages you will hear about but not send.

What this platform does with each SCMTR message

One table, because "do you support X?" is the question underneath most of the ones below. Every SCMTR message — the CSN, the manifest, the transhipper's and the custodian's — can at least be read here, and exactly one can be filed. The Bill of Entry is another system's message: its error codes are explained, the file itself is not opened.

Everything readable comes through one door: CSN filing → SCMTR JSON upload, which works out which of them you have handed it. See SCMTR JSON upload.

Someone sent me a file called F_SACHM23_SAM_… — should I be filing that?

No — not if you are a forwarder or consolidator. That is an Arrival Manifest, and it is filed by the Authorized Sea Carrier or Authorized Sea Agent: the shipping line, or the steamer agent acting for the vessel.

You can still open it here: drop it on SCMTR JSON upload and it opens as an editable table of its lines rather than as a filing.

The two messages describe different things about the same voyage:

The manifest's six events are worth knowing by name, because a carrier will quote one at you and only two of them are the manifest itself. CBIC's own expansions:

SAA is the one that most often gets reported as "the line has filed": it is an amendment, it can need an officer's approval depending on how late it was filed, and until it is approved the manifest line it asks for does not exist downstream. See When the Bill of Entry cannot find the manifest.

When each manifest event is due, per ICEGATE's SCMTR FAQ

Two more things the same FAQ states about the manifest: empty containers are declared too, as equipment with status Empty; and Regulation 13 provides a penalty of up to ₹50,000 for contravening any provision of the regulations, which is the answer to "what happens if a declaration is late".

Does a manifest carry house bill details?

It can, and it does not have to. The manifest's master consignment has the same house-bill array a CSN has, with the same blocks underneath — reference, ports, parties, measures, items, containers, itinerary. On a real arrival manifest of 238 master bills, 16 carried house bills under them, 17 house bills in all, each declared in full. The other route is the one the FAQ describes: the line refers to a CSN already filed for the bill instead of re-declaring it — on the same manifest, 62 of the 238 lines carried a previous-declaration reference pointing at an earlier CSN's PCIN. So a house bill reaches customs either inside the manifest or through your CSN; the manifest does not have to repeat what your CSN said.

One difference you will notice if you ever read a manifest beside a forwarder's CSN: the consolidation indicator uses the published codes there — S straight on 222 of those 238 masters, C consolidated on the 16 with house bills, H on every house — where a forwarder's CSN carries R on the master and H on the house. Customs validates the two sets separately, which is why the error table has 249/250 "Invalid MC/HC Consolidated Flag For SAM/SDM" next to 56 "Invalid MC Consolidated Flag For CSN". Copy a manifest's indicator into a CSN, or the other way round, and you land on one of them.

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 — see Two companies, one master bill of lading for how that pairing works and why their filing is also your deadline.

Is SACHM22 out of date? I heard there is a SACHM23 now.

No. The higher number is a different message, not a newer one. Both are current, both are maintained by ICEGATE side by side, and each has its own implementation guide published on the same page of the ICEGATE site. Customs' own error list carries separate codes for an invalid reporting event under SACHM22 and under SACHM23 — they coexist by design.

The confusion is understandable, and it costs real time: a SACHM22 filing rejected for an unrelated reason has been misdiagnosed as "we are on the old message version" more than once. If your filing is being refused, the message code is almost never the cause — check why customs rejects a filing instead.

How do I tell what a file is, just from its name?

Every SCMTR declaration follows one naming pattern:

F_SACHM22_SCE_YOURICEGATEID_100032_20260827_DEC.json
│ │        │   │             │      │        └── what it is: DEC, ACK or SFL
│ │        │   │             │      └── the date
│ │        │   │             └── your job number
│ │        │   └── the ICEGATE ID that filed it
│ │        └── the reporting event
│ └── the message code
└── F for a fresh filing, A for an amendment

So F_SACHM23_SAM_… reads as "a fresh Arrival Manifest", and A_SACHM22_SCA_… as "an amendment to a Cargo Summary Notification". The second and third segments tell you almost everything: the message, and what it is reporting.

Which reporting event do I use?

That is a question about your own filing, not about which message. The six CSN events are covered in the CSN filing guide — briefly, SCE for cargo arriving, SCX for cargo leaving, SCD for domestic movement, SCA to amend an accepted filing, SCU to update a cargo identification number, and SCC to confirm.

An event cannot be changed once a declaration exists; start a new one instead.

Is SCX the same as the departure manifest (SDM)?

No. They are two different messages, filed by two different parties, about the same sailing.

So if you are a forwarder with cargo leaving India, SCX is yours and SDM is not — it is the export-side twin of the import pairing, where your SCE sits beside the line's SAM. A file named F_SACHM22_SCX_… is an export CSN; one named F_SACHM23_SDM_… is the carrier's departure manifest, and it opens on SCMTR JSON upload as a table of its lines rather than as a filing.

Only one of you can declare a given bill of lading. ICEGATE's FAQ calls the CSN facilitative: the forwarder may file it, or hand the details to the vessel operator to declare in the departure manifest, and once one party has furnished a bill's details nobody else can. The shipping lines expect the forwarder to file — see exports: who files, when, and what the shipping line wants.

How to file the SCX itself — a straight bill with its PCIN, or a consolidation with one line per shipping bill — is in exports: filing an SCX, shipping bills and PCINs, and the guided steps start it from the Export filing — CSN Exit (SCX) card.

Which version of the message does this platform file?

The current Cargo Summary Notification guide is version 1.6, published 14 August 2026, and that is the revision this platform files against — including the amendment rules it tightened, where certain blocks accept only "updation" rather than the full set of amendment codes. See coded values for which blocks those are.

One thing worth knowing if you check for yourself: ICEGATE's published document lists its own version as 1.6 on the download page, while the revision history inside the file still reads 1.5. The content is the newer one; the changelog inside it was not updated. If you are comparing revisions, compare the documents, not their internal version tables.

What about the other SCMTR messages?

You will see these named in ICEGATE's guidance. None of them is filed by a forwarder or consolidator:

All of these can be read here — drop one on SCMTR JSON upload and every field is named from ICEGATE's own guide (Reading a transhipper or custodian file). None of them can be filed here, and none of them should be: each goes to customs under its own party's registration.

CIM (custodian), message CUCHE01 — filed by the custodian of a customs area, reporting cargo received and released.Transhipper messages, message TRCHE01 — filed by an authorised transhipper (registration category ATP) moving cargo between customs areas. ICEGATE's FAQ names them: the Allowed for Shipment Request (ASR), filed before departure from the port of call, and the Customs Inland Manifest, filed on arrival (CIM-AR) and departure (CIM-DP) for every vehicle — truck or train — carrying the cargo up to and between inland customs areas.Stuffing and stripping reports — filed by custodians and terminal operators wherever cargo is segregated or stuffed into different containers.

What the FAQ says about transhipment itself, since forwarders whose cargo moves inland ask:

Transhipment under Regulation 7 is any movement of customs cargo between two customs areas.There is one authorised transhipper for the whole movement, whatever the modes of transport, and that party executes the transhipment bond.Each stage is declared before departure and on arrival, but the data is not re-typed: the later declarations link to the earlier ones by the cargo identification number (CIN) — which is why the PCIN or MCIN your CSN earned matters after the gateway port.No fresh bond per movement; the party responsible may execute a National Transhipment Bond, managed by the customs system.

Which guides does ICEGATE actually publish?

Six, on its Message Implementation Guide page, as of September 2026. Knowing which is which saves reading the wrong one:

The manifest guide's error list has shared the CSN's numbered codes since March 2025, plus a few of its own (369–379). ICEGATE's own filing FAQ shows a manifest code carrying a three-letter prefix naming the block it was found in — VGD020 is error 20, "Invalid Voyage Call Number", on the voyage details — but the one refused manifest reply seen from 2026 carried bare numbers (164, 232, 233) in the current shared list's wording. Several numbers changed meaning when the manifest guide switched lists, and one reply cannot settle every one of them. So a manifest's reply is read on its own screen, under Shipping line filing, and each error is shown in customs' own words — see Customs' reply to a manifest. The transhipper and custodian messages are answered from a different list, with alphanumeric codes such as TMB03 or LCB08: every one of them is transcribed in Which error list does my code come from?.

If a line or CFS asks you for an "ITP JSON", they are asking a transhipper for a transhipper's filing, not you for a CSN. Note the acronym does double duty: the trade's ITP is International Transhipment — cargo carried on to a foreign port, which you do file, as an ordinary CSN with cargo type TR and movement TC (see cargo type, movement and the combination customs checks) — while the ITP in the table above is NIC's ICES Import Transshipment message, which you do not.

If you have been asked for one of these, it is a sign that the party asking has you registered under the wrong entity type. Party codes and PANs covers what each registration type means and who should hold which.

What is container domestication, and does SCMTR file it?

"Domestication" is the trade's word for turning a foreign line's container into a duty-paid box that may stay in India. A marine container comes in duty-free under Notification 104/94-Customs (16 March 1994) on the shipping line's continuity bond, to be re-exported within six months; domesticating it means an importer clears the box itself for home consumption and pays the duty, after which it can be used for coastal, rail or road moves or storage. JNCH Public Notice 79/2008 (24 October 2008) sets the procedure for a box landed on a one-way lease: the importer files a Bill of Entry for Home Consumption on the container, and the line must have manifested the box as cargo, with a bill of lading and an invoice; a box that was not manifested needs a manifest additional-entry application backed by the lease or the bill. Domesticating a box that was already cleared on the line's bond is, in that notice's words, "not permitted in the normal course".

SCMTR does not file domestication. It is a Bill of Entry, not a CSN or a SAM / SDM, and there is no reporting event, cargo-movement code or JSON message for it in either SACHM22 or SACHM23. "TCI" is not a code in the message guide either — if it means TCI Seaways, a domesticated box in its coastal service is ordinary equipment under coastal cargo.

Where SCMTR does touch it, and this is our reading of the notice rather than customs' statement: the box has to reach customs' record as goods on a bill — on the arrival side that is the line's SAM and any CSN filed against it — not only as a container in the equipment list; and the SAM's container bond flag and shipping-line bond number are where the 104/94 bond is declared, which is the record customs reads to see whether a box was re-exported in time. Customs said in July 2026 that it monitors un-re-exported containers from ICEGATE's own reports rather than from manual bond debits (reported as Circular 32/2026-Customs).

Customs publishes no domestication letter or format. JNCH Facility Notice 102/2016 (12 July 2016) lists only what a request to the port's Container Cell must carry — the container number and size, vessel and voyage, IGM or rotation number, the continuity bond number and the location — and that is for movement permission and bond extensions, not domestication. A "format" you are asked for is the line's, the CHA's or the custom house's own local letter: ask the line's container desk or the Container Cell at the port, and file the Bill of Entry through your CHA.