Working with a shipping line filing (SAM / SDM)

A SAM / SDM — the SACHM23 Arrival or Departure Manifest — is the shipping line's or steamer agent's declaration of everything on one ship for one call: every master bill, every container, every port on the itinerary. It is a different message from the Cargo Summary Notification a forwarder files, and it is far larger — a real arrival manifest runs to hundreds of bills and hundreds of containers, and over a megabyte of JSON. This page is about opening one in the platform, finding the lines that need correcting, and filing it.

It opens, checks, signs and files manifests. Since 12 September 2026 the last step is here too: sign the manifest with the scmtr DSC Signer on your computer and it goes to ICEGATE from this screen. What it will not do is forward a manifest its own checks say customs will refuse, and it will not send the same file twice by accident: every manifest filed here is fingerprinted, and a second send of one already in customs' hands is refused with what the first one was.

Two things it still does not claim. Sent is not accepted — customs' answer to a SAM / SDM arrives at your registered ICEGATE e-mail, and nothing here says a manifest was accepted until you drop that reply on the Shipping line filing page (see "Customs' reply to a manifest" below). And a manifest customs has already accepted is not corrected by sending a fresh one at all: that is an amendment message, SAA on an arrival manifest and SDA on a departure.

What is a SAM / SDM, and how is it different from a CSN?

The CSN (SACHM22) is one forwarder's own consignments. The manifest (SACHM23) is the whole ship: filed by the Authorized Sea Carrier or Authorized Sea Agent, one line per master bill of lading, with the vessel's complete equipment list beside it. Customs cross-checks the two against each other on the bill's date and a few physical facts about each container — see Checking a manifest against ICEGATE and What must match — so a line that quotes a CSN and disagrees with it is rejected, and so is a CSN that disagrees with a manifest line quoting it.

About 85% of the two messages' fields are the same blocks. The manifest adds the vessel-side blocks the CSN does not carry: the rotation number, the vessel-wide equipment list, the persons on board, the terminal operator. Which SCMTR message am I supposed to file? sets the two side by side.

Since 12 September 2026 a manifest can be filed from here too. This platform files the CSN; with a manifest it opens, checks, corrects, saves, writes back — and, with Sign & upload, signs and sends it to customs through the same gate a CSN passes. See Can I file the manifest from here? below.

How do I open a manifest?

Drop the file on SCMTR JSON upload on your declarations page, or open Shipping line filing in the header and drop it there. The platform works out what it is: a CSN opens in the declaration form, an acknowledgement is read out error by error, and a SACHM23 manifest opens as a table of its lines. You do not have to know which screen a file belongs to.

The file is read and edited in your browser, which is what lets a file well over the 3 MB a CSN is checked up to be opened at all. Like every file uploaded to SCMTR, it is also kept (for two years) — sent in the background, so nothing on the page waits for it.

A manifest you opened before opens again without the file. Every SAM / SDM / SAA opened, sent or recorded here is listed under SAM / SDM files kept here on the same page, newest first, with its event, port, rotation and job number; press one and it opens in the editor as if you had dropped it. A vessel call's page offers the same as Open in the editor beside its manifest. That is how a line's desk checks yesterday's SAM against the CSNs the forwarders filed overnight.

You no longer need a file at all. Since 21 September 2026 a manifest can also be started from nothing — for a bulk, tanker, break-bulk or tramp call, where no liner system produces one. Take Start one from scratch on the same page: find the ship by its IMO number and the call fills itself in from customs' record, then answer what only you know. It hands the finished manifest to this editor, which checks, signs and files it as it does any other. See Filing a SAM or SDM when you have no software for it.

What do I see once it is open?

One row per manifest line — the master bill, the consignee, how many boxes and packages, the gross weight, the port of discharge and the cargo movement — with the vessel, voyage, rotation number, port and ETA above the table, and four tabs:

Lines — every master bill on the manifest.Containers — the vessel-wide equipment list, with which line each box belongs to.Voyage & vessel — the ship, the voyage, the rotation, the itinerary and the persons on board.Checks — what the manifest contradicts about itself, explained (below).

Everything the file holds is on screen. The Containers tab always shows the container number, type, size, load status, packages, weight and seal, and then every other column the file fills: on a manifest that fills them, the seal type, shipper-owned, the container agent, the bond flag and the final destination of each box. A value the file carries under a name the SACHM23 guide does not use is not dropped either. It is listed under the block it sits in, as Also in the file, read-only and sent back unchanged. One real departure manifest writes a house bill's supporting documents as supDoc where ICEGATE's schema says crgoSuprtDocs. The same file names the vessel list's package count totalNmbrOfPkgs.

Opening a tab does not change the file. An itinerary stop with no port name keeps no name. The name of the port is shown under its code, and it is written into the file only if you change that port's code. A line's own SAM can leave every stop unnamed, and it used to come back from the Voyage tab with names this app had filled in. For an Indian customs port that name is the customs house's address. The voyage was then marked edited, and the change went into the amendment.

Guidance: Full | Compact, beside the tabs, is the same switch as on the CSN form, and it remembers the same choice. Full shows the explanation under every field and above every table. Compact puts it behind the ⓘ beside the field or heading and packs the fields closer. It hides no value, and warnings and errors always show.

An entry inward (SEI) or a departure notification (SDN) opens differently, and is meant to. Those two events carry no cargo at all: the manifest guide's field table excludes the master consignment block, the voyage details and the itinerary from them, and requires the arrival and departure details instead. So there are no Lines and Containers tabs — there is nothing that would go in them — and the file opens straight onto The whole message, with the containers landed and loaded, the persons on board and the transport contracts reported in the strip above. A departure notification of 481 containers is a page of numbers, not a page of bills. See Which SCMTR message am I supposed to file? for when each of the six events is due.

Search finds a line by bill number, container number, consignee, port or house bill number. The filters beside it narrow the table to the lines you have edited, the lines with problems, the consolidated ones, the transhipments, the ones with a prior declaration — or, once you have asked customs, the lines where a filed CSN differs or where no CSN is on record yet.

I opened a SACHM23 file and there are no bills, no containers and nothing to correct — is it broken?

Almost certainly not, and the reason is not that a SACHM23 has no bills. An arrival or departure manifest (SAM, SDM) very much does: a real one runs to 238 lines, one per bill of lading, with 812 containers under them. If you are looking at a manifest and the line table is empty, something is wrong.

But two of SACHM23's six events are not manifests in that sense at all. An entry inward (SEI) and a departure notification (SDN) report the vessel's call rather than declaring what is aboard, and they carry no cargo whatsoever — 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 covering 481 containers is a page of counts and times: containers landed and loaded, persons on board, transport contracts, and the terminal's own arrival and departure stamps. Not one bill of lading appears in it, and none should.

Opened here, those two files show what they actually report. There are no Lines or Containers tabs — there would be nothing to put in them — the file opens straight onto The whole message, and the strip above it carries the counts. So:

Empty tabs on a SAM or SDM — that is a problem worth looking at.No cargo tabs at all, on a file whose reporting event is SEI or SDN — that is the file being read correctly. The event is shown at the top of the screen; check it before concluding anything is missing.

The commonest cause of the confusion is simply picking up the wrong file: an entry inward and the arrival manifest for the same call are two different documents, and only one of them has the cargo in it.

How do I correct a line?

Open the row. The line expands into the same field-level editor a CSN gets — the port pickers, the HS code lookup, the PAN handling, the house bills and containers underneath it — and closes again when you are done. Only the line you have open is being edited; the other few hundred are left exactly as they arrived.

Every line you touch is marked Edited, measured against the file as you opened it rather than against your last save, so a manifest with three corrections in it always says so.

A problem is marked on the field it is about, on every manifest type. A line's problems are listed at the top of the open line, and since 24 September 2026 the field each one names carries the same red border and message the CSN form's own checks give — a port name in a port-code field, an over-long address, a placeholder PAN — and the block holding it shows a count and opens by itself. Click the problem (Go to the field) and the editor opens the block, and the container or item row if it sits in one, and puts the field in view with the keyboard on it. From the Checks tab, Open the line at the field does the same from across the manifest. The colour on the field is the finding's own: red for what customs refuses, amber for what the guide asks and no refusal has shown — never a red box under an amber message.

NULL in a field is what the file says, not something the app put there. Some lines' software writes the word NULL where it has no value — a 284-line departure manifest sent it as four consignees' street address. The field shows it because the file holds it, and a mandatory field that holds only NULL is reported as holds the text "NULL", not a value, never as empty: customs receives the four letters, and no accepted filing on record sends a literal null anywhere. Fix it in the software that writes the file. Only a problem about the line as a whole (a count that does not add up) has no field to land on. Until then a filer got the field's path in prose — master.mastrCnsgmtDec[272].locCstm.firstPrtOfEntry — and a form with nothing red on it.

What does the platform check on a manifest?

First, what the file contradicts about itself — each check traceable to a published ICEGATE error code, or to a rule the manifest guide states outright; then, for an amendment and (by three of its bills) a fresh SAM / SDM, what customs' public record holds (see amending a manifest). The editor does mark the fields the manifest guide makes mandatory (see the next section), but it does not list missing ones as problems the way the CSN form's checklist does. What it checks is the message's own internal agreements:

The declared line count and container count match what is actually on the manifest — ICEGATE error 279.Every container on a line is on the vessel's equipment list — 279 — and every box on the vessel is on some line, bar an empty being repositioned (said once, as such). On an amendment the vessel list carries only what changes: a box a removed line held, or a box changed on an updated line, missing from it is a note, never 279; a box the amendment adds still has to be on it.A container is not listed twice on the vessel — 156, with 153 on the vessel details, which is what customs returns for it.A container is described the same way everywhere it appears — the same size and the same load status on the line and on the vessel list — 705.The current stop in the itinerary (stop 0) is the port the manifest is filed at — 102 for an Indian inward call, 101 for a foreign inward one.

Every value is also held to the guide's own field table — length, pattern and plain text — and, since 24 September 2026, two more things a real 284-line departure manifest showed a line's software writing:

A port's name where its code goes. "NHAVA SHEVA SEA" on eight lines, "BANGALORE ICD" on one, in the first-port-of-entry field. The six-character field refuses it by length (red — an over-long value is a refusal by e-mail with no acknowledgement, already seen on a CSN); the finding now says the field takes a code, and names the code the name stands for (INNSA1; for "BANGALORE ICD" the port list's best match, INWFD6, one of Bangalore's ICDs — a guess the filer confirms). In a port field long enough to hold the name — the destination, a port of call — the same value is amber: customs' code list holds codes only, but no manifest refused for a name there is on record. A custodian's code in the destination (INCCU1HDC1, as an accepted Kolkata SAM sends) is a code and is left alone.

A field the guide does not name. The same file carried the shipping bill's number and date (sbNo, sbDt) under the previous-declaration block on 243 lines — in neither the guide's field table nor ICEGATE's schema. Each such value is shown on its line under Also in the file, kept exactly and sent unchanged; the Checks tab lists each such key once, amber, with how many places carry it, rather than once per line. Whether customs reads or refuses a field it did not define, only the acknowledgement will say. Checked 24 September 2026: sbNo/sbDt appear in no revision of the manifest guide (v1.3 to the current v1.6), in neither CSN guide, and in none of ICEGATE's JSON schemas for the message — whose prevRef has seven fields and which do not forbid extra ones. The only files carrying them come from one shipping line's software. The shipping bill is referenced the guide's way through its PCIN in mcinPcin — and ICEGATE's own signed-in screens for a CSN or a manifest line show that PCIN, never a shipping bill number.

A placeholder PAN, and the word "null" inside a value. A Kolkata amendment of the same day carried XXXXX0000X as the consignee's code and the notify party's PAN, and NILnullnull as the consignor's street address — the writing software's stand-ins, the shape of a PAN and the number of nobody, and empty fields joined as the text "null". Both are amber: customs' register cannot match the one and reads the other as text, but no refusal for either is on record. Only a value that is "null" in all but name is flagged — a real address with a stray null on its end is left alone, since a 238-line manifest a line really sent carries 83 of those. (A value that is exactly null is how ICEGATE itself writes an absent one, and is read as empty.)

On a departure manifest (SDM, SDA) the line table's port column is headed Destination rather than Discharge — it is where the cargo is going.

Seven more were added in September 2026. The first two are shapes customs rejected outright, so the platform stops them before the file is sent; the rest are the file contradicting itself (red) or looking copied from somewhere else (amber):

A line that quotes an earlier declaration does not repeat what that declaration already holds. If a line says its cargo was declared before — previous declaration Y, with a CIN — and its house bills also carry the transport document or the item details, customs rejects it with 370 ("redundant house details") on the line and 118 on every house bill. The parties, ports and goods are already in the CSN.

The house bills themselves are not what customs named. Customs' own Trade Scenarios table requires a house bill on such a line to carry its own reference, its prior reference, its customs location and its containers; what it excludes is the transport document and the item details. So 370 means "not these parts", not "not these bills". Two ways out, and only one has been seen to pass: thin the house bills to what the table asks for (the table's word — no filing on record has been accepted in that shape), or drop the house rows and let the line quote the CSN alone, which is what Add a line from a CSN builds and the only shape on record that has passed customs' checks. Where the house rows carry either of those two, the Checks tab offers Take the transport document and the item details off line N's house bills, which removes exactly those blocks and leaves the bills, the master line, its reference, its containers and its route as they were.

Three tiers, because only part of this is proven:

Red for the transport document and the item details — objects 43 and 45, the two a real refusal named.Amber for anything else the table happens to exclude — the itinerary, supporting documents, an additional declaration and the rest. The table lists what is required, not what is allowed, accepted filings carry blocks beyond their row, and no refusal on record names these. Blocking a send over one would cost a filing window for a rule nobody has seen enforced.Amber again where the house bills are already thin: that is the right shape on paper, but every manifest and accepted CSN on record puts house bills only under a line that declares nothing earlier, so it is worth confirming with your line before sending.

A block that is present but empty does not count — the file strips it before it goes out, so being refused for it would be being refused for something the file does not carry.

A container has one load status. A container that one house bill names, given a different load status on the master line, is 707 ("multiple load status"); a status that differs from the CSN the line quotes is 399. A container shared by several house bills is legitimately FCL on the master and LCL on each of them, and is left alone. A box two or more master lines name is usually LCL on each line and on the vessel's list; customs has also accepted a departure manifest that filed one FCL on both lines and the list, each line matching its own export CSN. Lines that disagree about such a box, or a list that says what none of its lines do, get an amber note (no refusal seen).

"Declared before" names what was declared. Previous declaration Y, S or B with no CIN beside it, or C with no CSN number and date, is amber: every real line that carries the flag carries its reference, and the flag means nothing without it, but no rejection for leaving it out has been seen.

The file says what it is, once. The header's reporting event and the declaration's must agree (red). The header's version repeats the event — SAA1102 on an amendment — and one that names a different event is amber: it is the mark of a file made by copying another.

An amendment action on a filing that amends nothing (amber). The amdType field tells customs what to do to a line it already holds — S add, U change, D delete — so it belongs on an SAA or an SDA. The guide marks it not-applicable on every full filing, and D in particular says "delete the line customs holds under this number", which on a SAM or SDM names nothing, because customs holds nothing yet. It is usually the mark of an amendment made by editing a copy of the full manifest. Clear it, or build the change as an amendment against the manifest customs accepted. (Until 21 September 2026 a stray D also silenced this screen's other checks on that line.)

A manifest is a fresh filing or an amendment, not both (red). The message type (master.decRef.msgTyp) is F for a filing in full and A for an amendment, and it has to agree with the reporting event: F with SAM or SDM, A with SAA or SDA. A file saying A on a SAM, or F on an SAA, cannot go out — ICEGATE builds the file's own name out of both, so the name would contradict the contents. It is the usual mark of an amendment made by editing a copy of the full manifest. Set the message type, or build the amendment from the accepted manifest instead.

The IMO number checks out against itself (red). An IMO number's last digit is derived from the first six, so a transposed pair fails the check. The vessel is what customs matches the whole manifest — and every CSN filed against it — to, so a wrong number here is not a small error. The check binds only where the file says the identifier is an IMO (transport means type 10): a barge or country craft legitimately has none and declares type 11. A real IMO number sitting under type 11 is flagged the other way, since that relaxation is exactly what would hide it.

One rejection the file alone cannot show: an amendment that adds a container the vessel's list already holds (156, 153). It is the usual case when a line is added late, for cargo whose CSN came after the manifest — the containers were on the vessel's list from the start, and only the line is new. Building the amendment here avoids it: open the full SAM customs accepted, add the line, and Build amendment adds a container to the vessel's list only when that SAM lacks it.

On an entry inward (SEI) or a departure notification (SDN) those container checks do not apply — there is no cargo tree to check — and others take their place:

The arrival and departure details are present. The guide marks that block mandatory on both events, and on an SDN it is essentially the whole message. A notification without one is flagged red (customs' code 213, "Arrival Detail is Missing").No cargo lines are present, since the guide excludes them from both events. Amber, not red: it usually means the wrong file was picked up.The persons-on-board total equals the crew and passenger counts added together, which is how the guide defines it (217), and crew and persons are above zero (274, 275).Every e-Sanchit IRN reads as one: sixteen digits beginning with the upload date as YYYYMMDD, as every IRN on the real manifests we have seen is — and not the same IRN for two documents (336/337/338 are customs' codes for a wrong IRN). An IRN dated a day after the job is fine: a SAM customs holds does exactly that.No serial number is used twice in the crew effects (195) or the ship's stores (200).An SEI carries a persons-on-board entry and the ship's stores. The guide's field table leaves both out of an entry inward, but every real one we have seen — four, from two lines at two ports — carries both, as e-Sanchit references or listed by name, and ICEGATE's own SEI schema lists both blocks as required. An entry inward with neither is told so; no refusal for leaving them out is on record, so it is a word, not a verdict.A named person's codes are the guide's. Person type FM (crew), FL (passenger) or DEE (stowaway); gender 0, 1, 2 or 9; a rank from the guide's list (MASTER, CHIEFOFF, COOK…); a document type from its list (039, a passport); a crew-effect or stores article code from its goods-on-board list (099, miscellaneous, on every real row). Customs publishes 177, 178, 179, 196 and 201 for a wrong one; none has been seen firing.On an SEI, the counts agree with the SAM of the same call: the transport contracts equal the SAM's lines, and the equipment reported equals the SAM's vessel equipment list, from the same submitter (291). The Checks tab compares against the SAM you have saved here for that port and rotation, and says which copy it read — if the SAM has been amended since, customs holds a different one. On both pairs we have — a four-line call and a nil call — the counts matched, and customs granted the first call entry inward the next day. A nil SAM given the placeholder row still agrees with an entry inward reporting zero equipment: the row is not a box.On an SDN, the same two counts against the SDM of the same call (292 if the submitter differs): the transport contracts equal the SDM's lines, the equipment its vessel list. On the one departure pair we hold with customs' replies — a Kolkata call of 36 lines and 73 boxes, both accepted on 1 October 2026 — they matched. That SDN also left out the containers-loaded and containers-landed counts, which the guide and ICEGATE's schema both mark mandatory, and customs accepted it; so leaving them out is not flagged, and the guided builder does not insist on them.

All of these except the first are amber: customs publishes the codes, but no refusal under them has been seen here.

After an SDN, customs may answer shipping bill by shipping bill. On the one departure we have seen (Kolkata, 1 October 2026), ICEGATE mailed the line an EGM file (SACHE18A_….out) marking every shipping bill on the vessel with a letter — S on the EGM, Q for one customs' record still showed at stuffing, or another letter from customs' table. It is not a check of your file: drop it on the file check and it is read and summarised, and what the letters mean is in Exports: who files the CSN, and when.

Three more are advice rather than refusals, because a real manifest can legitimately carry them or customs has accepted one that did: a master bill that appears on two lines (not counted when the same amendment deletes one of them — that is the drop-and-re-add), a load status the platform cannot reconcile, and container weights that read as tonnes — a line whose boxes add up to a thousandth of its gross weight. The guide puts container weight in kilograms (cargo and packages, no tare); an accepted SAM of September 2026 carried a box at 8.15 on a line of 8,154.34 kg, and customs' public record repeats the figure, so it is not refused, but it is what the terminal and the CFS read.

Every value is also held to the length and pattern the manifest guide prints, and a value over its limit blocks sending — except where a real filing shows the guide is wrong. The ICEGATE user ID on a supporting document is one: the guide allows 15 characters, but an ICEGATE ID is 16 (a PAN, three letters and three digits, such as AAAAA0000ACSA001), and a real departure manifest carries one on every house bill. The platform takes 16.

A sound manifest passes all of these silently. The real manifest the editor was built against — 238 lines, 812 containers — raises nothing, and so do both of the real departure notifications and both real entry inwards tested against it, which is the point: a check that greets a correct file with a screenful of warnings is one filers learn to click through.

Why are some manifest fields marked with an amber asterisk?

Because the manifest guide makes them mandatory for your file's reporting event. ICEGATE's SACHM23 guide has its own field table, separate from the CSN's, saying for each of the six manifest events — SAM, SAA, SDM, SDA, SEI, SDN — which fields are mandatory, which are optional and which do not apply. Once a manifest is open, the editor reads that table for the event the file names and marks each mandatory field with an asterisk.

Amber, not red, on purpose. On a CSN a red asterisk means customs refuses the filing without the field: those rules were checked against real accepted CSNs, and a wrong one would be corrected by the next rejection. The one reply to a manifest read here so far is an acceptance, and no customs refusal of a manifest has ever been read here to confirm these rules for us — and the guide is not perfect. In six places it marks a field mandatory inside a block it says does not apply to that event, and one field it makes mandatory on an entry inward (prsnGivenName, a person on board's given name) is blank on a real arrival manifest. So the asterisk says "the guide asks for this", not "customs will refuse this", and nothing is blocked because of it. A line above the editor says the same thing in words.

A block or field the guide leaves out of the event is not offered — unless your file fills it. An entry inward or departure notification, for instance, has no voyage or ports of call to fill, because the guide rules them out for both. But a real file sometimes carries a value the guide excludes: a real entry inward on record carries a containers-landed count and a persons-on-board list, both of which the guide leaves out of SEI. Those stay on screen, each with an amber note saying the guide does not use it for this event, because hiding them would hide something the file still contains and still writes out when you download it. Keep it or clear it; nothing is blocked either way.

Where is the containers-landed count on an entry inward?

On the The whole message tab, in the Arrival & departure details block, beside the other counts the notification reports — crew, passengers, containers loaded. An entry inward has no Lines tab and no sidebar of sections; everything it carries is on that one tab, block by block. The strip across the top of the screen shows the same number as Landed. The Persons on board list, when an entry inward carries one, is further down the same tab. Both show an amber note, because the guide leaves them out of SEI.

If the editor says the guide's field rules could not be loaded, nothing is marked and nothing is hidden — the whole file is shown as it is. Closing the manifest and opening the file again tries once more.

What are ship stores, persons on board and crew effects?

Three blocks of a manifest that have nothing to do with cargo, and surprise people opening one for the first time. None of them ever appears in a CSN, and none is a forwarder's to declare — they belong to the vessel.

Ship stores are what the ship carries for its own use rather than as cargo: fuel, provisions, spare parts, bonded stores. Each is declared with the quantity on board and where on the ship it is kept.Persons on board are the crew and passengers — name, nationality, rank or rating, the identity document each is travelling on, where they joined the ship and where they leave it, and a visa where one is required.Crew effects are goods belonging to a crew member personally. They are declared apart from both the cargo and the ship's stores, because customs treats them as a third thing.

You will see all three in a manifest a line sends you, and the editor shows them as it shows everything else in the file. Correcting them is the line's business, not yours. Every field in each block is described in Every field in a shipping line filing.

Can the crew list, crew effects and ship stores go in as a PDF?

Yes — through e-Sanchit, with the reference number it gives back. ICES Advisory 30/2023 lets a line upload each of the three as a PDF under a fixed document code; e-Sanchit returns an Image Reference Number (IRN), and the manifest carries that number in place of the details:

Real manifests do this: an arrival manifest's only person on board, and a departure manifest's only ship-stores row, are a sixteen-digit IRN. Such a row has no given name because there is no person, which is why the editor does not demand one.

Some lines also write the e-Sanchit document code into a nearby field, although the advisory asks for it only in e-Sanchit: 745000 as the person's identity-document number on a SAM, 744000 as the crew effects' sequence number and 799000 as the stores' location on board on an entry inward. The editor keeps those as filed. On the one call where we could check, customs granted entry inward the day after such an SEI. The three IRNs of one call are usually consecutive numbers — the crew list, crew effects and stores uploaded together — with the crew list's quoted on the SAM and the other two on the SEI.

Another line does it differently, and the editor reads both. On two entry inwards a Nhava Sheva line filed in September 2026, the crew list's IRN is the first person entry (type IRN), the crew-effects IRN sits under that same entry as its one crew-effects row with sequence 1, and there is no stores IRN at all: the stores are listed by name — mutton, beef, chicken, juice — with the room they are kept in and the quantity in KGS or PCS. Beside the IRN entry the line names three of its twenty-five crew one by one — the master, the chief officer and the cook — as person type FM (a crew member; FL is a passenger and DEE a stowaway), with rank codes MASTER, CHIEFOFF and COOK, gender 1, a passport (039) and one crew effect each, coded 099 (miscellaneous) and described in words. The persons list is not the crew count: four entries stand beside a crew of twenty-five, and no check compares the two.

A 559-line Kolkata SAM of September 2026 does the same as the first: one person on board, type IRN, a sixteen-digit number as the family name. Its crew manifested is 1, which counts the one IRN row rather than the people on the crew list. Nothing on record shows whether customs reads that count against the list.

What has ICEGATE clarified about filing a manifest?

Points ICEGATE and customs have published since SCMTR began, which a line's software has to get right. Dates and rules for your port are in SCMTR at your port.

A bill split across more than one record uses the split indicator. When one master or house bill is split — part by one mode of transport, part by another — the second SAM or SDM used to be refused with error 122, MC-MBL details already exists. ICES Advisory 03/2026, as Nhava Sheva's Public Notice 15/2026 describes it, added a split indicator:

ICES Advisory 09/2024 relaxed several checks:

On a consolidated bill customs generates an MCIN, and a SAM may now quote that MCIN in a later declaration without repeating the packages, weights and invoice value, which customs already holds.For the personal effects of foreign nationals and diplomats, a passport number may stand in for the consignee code (formerly refused with error 42).On an export SDM, the consignee code (the foreign buyer) is optional.On a SAM, the expected departure time is optional.A vessel shuttling between one Indian and one foreign port — so its last port of call and Indian port of call repeat — is no longer refused.No bond is required for domestic transhipment of cargo by sea.

How do I file a nil SAM — a call that lands no cargo?

A nil manifest still declares one piece of equipment. The only published model is Chennai Customs' Facility Notice 01/2021, on error-free manifest filing. For a nil SAM, totalNmbrOfLines is 0 and totalNoOfTrnsprtEqmtMnfsted is 1. The notice's model nil-cargo file has no cargo lines and one placeholder row on the vessel's equipment list:

The bond flag on that row is N, the only value customs takes on a non-container row (350). ICEGATE's own SAM schema also lists the vessel's equipment list as required. The same notice asks that the expected arrival and departure times be exactly those declared in the Port Community System (PCS).

What the platform checks. A SAM with no lines and nothing on the vessel list is flagged amber. One press, Add the placeholder row and set the totals, writes the row above and the totals 0 and 1. The platform also asks customs' public VCN enquiry for the ship's calls, sending only the IMO number, and flags in amber a SAM whose expected arrival is on a different day from the one customs holds for its VCN.

How sure this is. The notice is Chennai's, from 2021. No nil SAM from any port, with its outcome, is on record here, so the placeholder row is the published model, not a proven requirement at every port. The same notice's model nil departure manifest is different and does not read cleanly, so nothing is said of a nil SDM.

A nil SAM was sent and no acknowledgement came. One such question, from Nhava Sheva in September 2026: a nil SAM declared 0 equipment with no equipment list, and gave an arrival twelve days after the one on customs' record of its VCN. Which of the two held it up is not known. Check, in order:

The equipment list and totals above.The expected arrival and departure against PCS, and against the call on VCN search: if the port re-scheduled the call, the port updates it.The mailbox of your ICEGATE-registered e-mail ID. Some refusals come by e-mail, never as an _ACK (Reading an acknowledgement).If you re-file, use a fresh job number. The notice asks for one per file.

Every manifest hangs off the port's call number. Customs generates the rotation number automatically from the port's vessel call number (VCN) message, and the same rotation number is used for the SAM, the SDM and the EGM (ICES Advisory 27/2020). CBIC's 2021 webinar is blunt about the order: without the VCN, manifest filing under SCMTR is not possible. The VCN's format is in Every reference number.

What a real departure manifest looks like

A real SDM seen here — a steamer agent's export call at Mumbai, September 2026 — filed 19 consolidated master bills (consolidated C, previous declaration N) over 318 break-bulk house bills of steel coil (house H, previous declaration S), each house quoting the PCIN of its shipping bill. Under ICEGATE's CIN table that combination issues an MCIN for each master and nothing for the houses, so the acceptance of such a manifest should carry nineteen MCINs. In break-bulk the "container" rows are the coils themselves, each numbered with the coil's own number, with equipment type BB.

It also left three fields empty that the guide marks mandatory on a departure manifest — the expected arrival time (the ship is already in port) and the transhipper code on the masters and houses (its transhipper blocks carry only a zero bond) — so on an SDM the editor offers those fields rather than marking them.

Can I let the forwarders check their CSNs against my SAM before I file it?

Yes — press Share with CSN holders on the SAM or SDM. SCMTR asks customs who holds a CSN on each BL, compares every CSN with your line, and tells the holders on SCMTR whether it matches; a board shows you each line, each holder and the answer, and a link lets you send the rest a way to check on their own. Each forwarder sees only its own BL, never the manifest. Every mismatch found this way is one fixed before filing instead of an SAA afterwards. The details, including who can see a line, are in Check your CSN against the line's SAM.

Can I save a manifest and come back to it?

Yes. A manifest is an afternoon's work, and half its corrections wait on somebody else's answer. Press Save to come back to and it is kept for your organisation, with the file as it arrived beside your corrections — so reopening it still reports what you changed — and with every answer you have already had from ICEGATE. After the first save it saves itself whenever something changes, on a long interval rather than every keystroke, because each save is the whole manifest.

Saved manifests are listed on the Shipping line filing page. Anyone in your organisation can open one; only the person who saved it, or an organisation admin, can change or delete it. A saved manifest is kept for ninety days after it was last touched and then removed, and an organisation may keep up to fifty at a time.

I dropped a manifest I had already saved — why did it open my saved copy?

Because that is the one you were working on. A dropped file is first looked up against your organisation's saved manifests — by ICEGATE's six-part file name, or, for a file renamed on its way through an inbox, by the voyage: same event, vessel, voyage, rotation and port, with a manifest never mistaken for its own amendment. If a saved copy matches and the file is the same one — as it arrived, or as you last saved it, which is what a re-dropped download is — the saved copy opens with its corrections and every ICEGATE answer it holds, and there is no Save button because there is nothing to create. Before this, a second drop quietly made a duplicate row.

If the file is a newer version of the same manifest — your own system has produced it again — you are asked. Replace the saved copy with this file makes the new file both the manifest and the thing "unchanged" is measured against: the corrections on the saved copy are discarded (and that is recorded in the audit log), and ICEGATE answers survive only for lines the new file carries byte-for-byte with the same bill. Open the saved copy instead leaves the new file alone.

Either way, the dialog lists what changed, value by value: the line and its bill, the container, the field, what it was and what it is now. The job number, control number and time are left out, because they change on every send. A line that re-sends its whole manifest to correct three container size codes is told exactly that, and not only "differs on 1 line". The same list appears when the file you drop is a different upload of a VCN you have saved, such as a second job number for the same call. If the saved list cannot be read at that moment, the file simply opens fresh — the lookup never stands between you and your file.

How do I get the corrected manifest back out?

Download manifest. The file is written back through the same transform an accepted filing goes through — numbers as numbers, line numbers as the manifest carried them, empty blocks dropped — and a manifest you open and write back without editing, in the same sitting, comes out identical to the one you opened. Nothing changes but what you changed. One thing to know about a manifest you saved and reopened later: every value is exactly as it was, but the order of the fields inside each block may differ from the file you first opened — the platform keeps a saved manifest in a form that does not remember field order, and the shipping lines' own files do not agree with each other on one. Customs reads the values, not their order, so nothing about acceptance turns on it; a comparison tool that diffs the two files line by line will show it.

If the manifest you opened was signed, an edited copy is written back without the signature: a digital signature covers the exact bytes it was made over, and a manifest that left here still carrying one would be refused for a tampering the filer knows nothing about. It has to be signed again — which you can now do here.

Can I file the manifest from here?

Yes, since 12 September 2026. Press Sign & upload. The dialog signs with the scmtr DSC Signer on your computer: pick your certificate, press Sign and file, and the manifest is signed with your DSC token and sent in one step. Only a 32-byte digest of the manifest goes to the signer, which is why a ten-megabyte file signs as fast as a small one. If the signer is not installed, the dialog offers Install the signer and a Check again button that picks it up without closing anything.

If you sign on a different computer, or already hold a signed copy, open Signing on another computer, or already hold a signed file? at the bottom of the dialog: download the manifest, sign it there, and upload the signed file back.

Either way the bytes are identical, and either way the file goes to ICEGATE over the same channel a CSN filed here goes over.

What happens before it is sent

Three things, all of them on our side:

The signature is verified. A file whose signature does not match its contents never leaves.The manifest is checked again, on the server, against the file that is actually about to be sent rather than against what your browser said about it. If the checks find an error, it is not sent — the list comes back so you can fix it in the system that produced the file. A warning is your judgement to make, and does not stop anything.It goes through the gate. If this organisation has already sent this manifest — the same file, or the same voyage regenerated under a new job number — the send is refused and you are told when the first one went and what became of it. Getting past that needs a reason, which is recorded.

That third one is the point of the feature. ICEGATE's own engineers have described a single 10 MB manifest arriving eighteen times in three months, thirty minutes of validation each, with every acknowledgement in the trade queued behind it. Nobody does that deliberately — they do it because nothing came back and there was no way to see what had already gone.

What "sent" means, and what it does not

It means ICEGATE took the file. It does not mean customs accepted it. Customs' answer reaches you at your registered ICEGATE e-mail as a separate file, and until you hand it over this platform will never tell you a manifest was accepted, approved or cleared.

Customs' reply to a manifest

The reply is the file whose name starts A_SACHM23 or F_SACHM23 and ends in _ACK — for example A_SACHM23_SAA_MSCINBOM01_14_20260903_ACK.json. Drop it on Shipping line filing (or on Check an ICEGATE file, which reads it the same way and offers to keep it) and you see:

Accepted or refused, and for a refusal every problem customs named, in its own words and placed on the line and block it names. The refused manifest replies seen so far carried the CSN's own numbered codes (164, 232, 233); ICEGATE's guide also shows codes with a block prefix, such as VGD020 (error 20 in the voyage details). Because the manifest guide's numbers changed meaning in 2025, each is shown as customs wrote it rather than looked up.Every CIN in it. On a consolidated line (consolidated indicator C, previous declaration C) customs issues an MCIN, and the reply lists it beside the line number and bill of lading, with a copy button.Which of your sends it answers. It is matched by ICEGATE's tracking id first, then by sender, reporting event, job number and job date, and kept with that send. The list of manifests you sent then shows customs' verdict beside each one.Kept on the wrong send? A send gets one answer. If a reply was recorded on the wrong one of two sends of the same manifest — the same file sent twice from different logins, say — an organisation admin can press Remove ACK on that send in the list: the row reads as awaiting customs again and the reply can be dropped on the send it answers. The file itself stays in your files; only where it was placed changes.

What happened, and what to do. Above customs' own list, the platform reads the whole reply and says it in a paragraph — what went wrong, what to do next, and how sure that reading is. The same reading appears in the editor, under the rejection, when the ACK is opened with the file it answers (drop both together, or press Fix it in the editor): where the file's own checks can repair what customs refused, the button is right there — 394's Number the added boxes from N + 1, for instance — with Show it in Checks beside it, and once the copy no longer has the fault the card says so and that it is ready to sign and upload under a fresh job number. It knows these:

It also says how to read the size of the reply, which is what alarms people first. A reply to an amendment lists the whole manifest customs holds, not the file you sent: a two-line SAA comes back as 1,706 rows. The rows that echo a bill number are the lines you sent. Rows with a code and no bill number are lines customs already held and found wrong again. The rest — bill null, no code — are the manifest echoed back empty, and say nothing about those lines either way. They are not lines customs accepted, and not lines it lost.

What changes once it is kept: a refused manifest no longer blocks a corrected one — customs holds nothing from it, so no override reason is needed. An accepted one keeps blocking a second copy, now saying customs accepted it.

Two things that look wrong and are not. Nearly every value in an accepted reply is the word null: ICEGATE repeats your manifest's outline and fills in only what it has something to say about — on an amendment, the lines the amendment touched. And an acceptance stamps a handful of blocks as checked and names no consignment one by one: it says the manifest was taken, not that every line was read and found right.

Occasionally ICEGATE takes the file and returns no tracking number. That is recorded honestly as what it is: the file is at customs and neither you nor we can follow it up here.

An amendment is checked against the whole manifest, not only the lines it changes. On 17 September 2026 a shipping line amended one line of a 794-line arrival manifest. That line passed every check — bill, bill date, the CSN it quoted, packages and container — and the amendment was still refused: customs raised error 233 on 114 other lines, the same lines that had refused the line's previous amendment the day before. So a refusal of your amendment can be about lines you did not touch, and until those are resolved every amendment on that vessel call is refused the same way. Read which lines the errors are on before changing anything on your own; if they are all other lines, the fix is theirs, and the reply's line numbers are what to hand the people who can make it.

Seeing a refusal on your own lines

A refusal names most lines by line number only. The first real one refused 114 lines of a 795-line amendment and printed a bill number on two of them, so from the reply alone you cannot tell which bills customs means. Put the manifest beside it and you can:

Drop both files together on Shipping line filing or SCMTR JSON upload — the manifest (_DEC) and the reply (_ACK), as they usually arrive on one e-mail. Or drop the reply first and add the manifest where the screen asks for it; it spells out the file name to look for. Or open the manifest and press Customs' reply in its header. The manifest is read in your browser either way.First it says whether the two belong together. Sender, reporting event, port, job number and job date must all agree for the reply to be this file's answer, and then every refusal is shown on your line of that number. A reply to a different send of the same vessel call (same port and rotation, another job number — a line's earlier or later amendment) is said to be one, and only the refusals it names by bill — under the same bill date, where it gives one — are shown on your lines, marked as the other send's: a line number alone is not trusted across two sends. A reply about another call puts nothing on your lines at all.Each refused line is then one card: its bill and date, one sentence on what happened, what to do in order, the line's own packages, containers and the CSN it quotes, and customs' codes underneath. A refusal of a house bill names the house bill and the CSN it quotes. Codes that belong together are read together — 164 with 232 and 233 on one line is read as one fault, not three: on the one refusal of that kind seen so far, customs could not tie the bill to the CSN it quotes and the counts failed beside it — see ICEGATE error codes.Refused lines the file does not have are counted, not guessed at — "customs refused 113 more lines that are not in this file" — so an extract of a manifest is noticed. A refusal stamped on a container or cargo-item row is listed on its own, never on a line: a reply files those rows under other lines than their own.In the editor the refused lines are marked refused and have a filter of their own, and Ask ICEGATE about their bills checks exactly those bills against what customs holds.

This is the quicker first look — the reply laid over the lines in your own file. For a line-by-line reading against customs' record itself (which bill each refused line is, whether it still agrees with the CSN it quotes, and an evidence pack to hand the ICEGATE helpdesk) — including when you do not have the manifest the reply answers — see Customs refused my manifest — which bills, and why?

A bill date that disagrees with the CSN is now caught by that check. The lookup is keyed by bill number and date, so a line whose date was wrong used to find nothing and read "no CSN on record" — the ordinary, harmless answer. When a line quotes an earlier CSN and nothing is found under its own date, the check now asks which dates customs holds the bill under, and says "Master B/L date — this manifest 25-JUL-26, their CSN 27-JUL-26". That is what line 795 of the first refused manifest showed: a CSN on record for its bill, under a date two days from the manifest's. Which of the two dates is right is for the bill of lading to say.

The five things a send can come back as

Sent, with a tracking number. ICEGATE took the file; customs' decision follows by e-mail.Sent, no tracking number. ICEGATE took the file and gave nothing to follow it by.ICEGATE refused this manifest. The reason ICEGATE gave is shown. Nothing of yours is at customs, so a corrected file is not held back by this one.Delivery unconfirmed. The upload left and no answer came back — a timeout, a dropped connection. ICEGATE may hold the file or may never have received it. Do not send it again on a guess: the gate refuses the same file while that send is unresolved, and the sent list shows what is known.Held. Nothing was sent and your signed file is unchanged. Either sends are being paced — thirty a minute across the platform, ten a minute for one organisation — or uploads have stopped completing and sending is paused for about five minutes. Try again shortly.

If the outcome could not be recorded on this side after ICEGATE took the file, the dialog says exactly that rather than "nothing was filed": check the filing on ICEGATE before sending again.

Can I re-send a manifest customs has already accepted?

Correcting an accepted manifest is a different message, not a fresh one: an amendment — SAA on an arrival manifest, SDA on a departure — and filed inside the hours before arrival it needs the proper officer's approval, given online. See which message do I file for the amendment events and their windows. Editing your copy of a filed manifest and sending it again as a fresh one is not a correction and is not how customs takes one — which is part of why the gate refuses the second send.

When you open a SAM or SDM, SCMTR asks customs' public record about three of its bills: the first, the middle and the last. If customs holds every one of them on another rotation, from your submitter, the page says the file looks like an earlier manifest with its rotation changed. One such SAM was uploaded in October 2026: its bills and line numbers still belonged to the August call it was copied from. It is a warning, because a bill rolled over from an earlier call can sit on two calls. A SAM built here is not asked about, and a failed answer never holds back the verdict.

What is the largest manifest it can open?

Thirty-two megabytes to open and save — well beyond a laden 4,000-line call. A real 238-line arrival manifest is about 1.4 MB. Sending has its own ceiling of 24 MB for the signed file, which still covers the ten-megabyte manifests ICEGATE's own engineers describe; a server carries three sends at once and asks a fourth to wait a moment.

Can I export what the checks found?

Yes. The Checks tab exports its findings as CSV or JSON, for the system that produced the file or for whoever has to fix it. When a send is refused for errors, the dialog shows up to twenty-five of them and says how many there are in total; the export carries them all.