SCMTR & CSN filing FAQ

A CSN is the house-level cargo declaration under SCMTR. It references a Master Consignment (the bill of lading filed by the vessel operator) and adds the finer-grained detail underneath it: the individual shippers and consignees, goods descriptions, HS codes, and container/equipment details for each house bill.

Freight forwarders, NVOCCs (Non-Vessel Operating Common Carriers), and consolidators — the trade parties who combine cargo from individual shippers under a single master consignment. If you are a vessel operator filing the top-level manifest itself, that is a SAM or SDM, not a CSN.

It is an ordinary shape and it has its own code: set the house bill’s prior declaration to B. CBIC states it in a published clarification to the trade — give S when the house bill refers to one shipping bill, and B when several are getting consolidated under it. 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”, so “no prior declaration” — the right answer on a fresh import — is a combination customs rejects as error 118. What you refer to is a PCIN: in exports a PCIN corresponds to the cargo covered under a single shipping bill, so a house bill over four shipping bills sits over four PCINs. As for which PCIN goes in the previous-reference block, which holds a single identifier and does not repeat: none of them has to share it. File one line per shipping bill, each with its own PCIN; where a shipping bill has no house B/L of its own, its line takes the shipping bill number and date. That is the shape of the consolidated export customs accepted in September 2026, and it is the shape the guided export steps build.

Start from the Export filing — CSN Exit (SCX) card on CSN filing, and count your shipping bills. One shipping bill under one bill of lading is a straight bill: the master is consolidated S with prior declaration S and names that shipping bill’s PCIN. Several shipping bills under one B/L is a consolidation: the master is C with prior declaration N and names no PCIN — customs issues it an MCIN — and each shipping bill gets its own line, H with its own PCIN and its own containers ticked off the B/L, typing only its share. On both, cargo type is EX with movement TC, the destination and the port of receipt are the foreign port of discharge, the Indian port you load at is the first port of entry and the port of acceptance, and the itinerary ends with the sea leg from your port to the foreign one. The guided steps fill and lock what cannot be otherwise, check every rule customs has been seen to refuse an export for, and list them on the last screen as “What customs checks on an export”. The rules rest on a small base — three exports customs accepted on 19 September 2026 and the refusals filed beside them — and on 20 September customs’ own public record confirmed an export filed as a straight bill in exactly this shape as accepted, with a CSN issued.

On an export, a PCIN is the cargo identification number of one shipping bill — ICEGATE’s own words are that a PCIN corresponds to cargo covered under a single shipping bill. It is 20 characters: the year, PC, two letters and fourteen digits, like 26PCEG09010000000100 (an invented example). It is not the shipping bill number, and a bill of lading never carries one, which is why pasting a B/L here offers the shipping bill number it names and never a PCIN. It comes from the shipping bill, not from your CSN: CBIC’s clarifications say customs generates it at goods registration for every shipping bill, and its 2021 webinar says it goes to the custodian with the let-export order (LEO) — so it exists before you file, and the post-LEO copy of the shipping bill carries it, which is why shipping lines ask for that copy. You can also fetch it from ICEGATE after signing in, under PCIN Enquiry (Exports) → PCIN Excel Based Enquiry: a sheet of shipping-bill numbers and dates (ICEGATE’s manual says up to 500, for shipping bills after 1 January 2025) or a container number returns the CIN, its type, the ports, containers, packages, weights and rotation number. CBIC’s older training decks speak of an “18 digit” PCIN; every real one seen is 20. Do not guess one: a wrong PCIN is a refusal.

Previous declaration is where it goes — the guided steps and the full form both put it there, and so does every accepted export seen but one. That one, a Kolkata consolidation customs accepted on 22 September 2026, named every line’s PCIN under Supplementary declaration and left Previous declaration out, under a master filed referenced only (R); customs’ PCIN enquiry then tied each PCIN to its exact house bill, which it does only once an accepted filing has used it. So the checks here read a line’s PCIN from either block: named in either, it passes; named in neither, it is still 159; the same PCIN on two lines is still 383/384, whichever block each names it in. A filing in that shape opens in the full form, because the guided steps have no field for Supplementary declaration.

The CIN on the export CSN’s master row, as customs shows it. Measured on seven bills of a real 284-line departure manifest in September 2026, every line quoted exactly one of two numbers: the export CSN’s own CIN where it has one — 26PCSX… on a straight line, 26MCSX… on a consolidated master — or otherwise the shipping bill’s own 26PCEG… that the CSN referenced. The letters say where the number was issued: EG to the shipping bill itself, before any CSN, which is why ICEGATE’s PCIN enquiry answers a 26PCEG… with the shipping bill’s number and no rotation; SX to an export CSN, answered with the CSN number and the rotation; SE to an import CSN; SM on the manifest side. Look the bill up on customs’ record and quote what the master row shows. Check the lines that quote a CSN, in the SAM / SDM editor, does that comparison on an SDM, asking for SCX records rather than import ones, and shows a line quoting neither as a difference.

Only on a consolidation. A straight export bill, which quotes its shipping bill’s PCIN, is issued a CSN number and date and no new CIN — the cargo already has its PCIN. A consolidation’s master, filed as consolidated C with prior declaration N and no PCIN of its own, is issued an MCIN: 20 characters with MC after the year, shaped like 26MCEG09010000000100 (an invented example). Each line under it keeps the PCIN it quoted; nothing new is issued to a line. That is what customs’ own CIN table says, and it is what customs’ public record showed on 20 September 2026 for exports accepted the day before. One row of that table is not borne out: it has a line covering several shipping bills (prior declaration B) quote an MCIN, while every accepted line of that kind seen quotes a PCIN — so the platform accepts either there.

Customs says either may, and only one can. ICEGATE’s FAQ calls the CSN a facilitative measure: a forwarder, NVOCC or consolidator may file it, or may hand the details to the vessel operator to declare in the departure manifest — and once one party has furnished a bill of lading’s details, nobody else can. The shipping lines, in their own advisories, put the job on the forwarder: file the CSN with a valid customs VCN, then post the CSN number, its date and the PCINs against the master B/L on the line’s portal (ODeX, for most lines) 48 to 72 hours before the vessel; if you do not, the line files the master B/L itself from the shipping-bill details and passes any penalty to you. Those deadlines are the lines’ own, not customs’ — customs’ table says only that a CSN is due before departure from the last port of call, and nothing published times the SCX against the line’s departure manifest. The cut-off notice will not give you the VCN; look the ship up on VCN search or ICEGATE’s VCN enquiry.

The field means how full the container is — FCL full, LCL part-loaded, EMP empty — by the message guide’s own definition; when the shipping lines asked CBIC what to put, the whole answer was “It is FCL/LCL”. Customs’ public record shows exports with one container on several shipping-bill lines accepted both ways: FCL on the master with LCL on each line, and FCL on every row, each line with its own share of the weight. The check that bites is 237: the shipping line’s departure manifest declares the same box, and its load status must match yours. No customs document or carrier advisory says which is right, so the platform suggests LCL on a box two of your shipping bills share — the shape most files take — suggested, not locked. If you share a box on an export, ask the line what its manifest will carry for it and file the same.

Without. The CSN message guide labels the field as verified gross mass but defines it as the weight of the cargo with its packing, dunnage and bracing, and says there is no tare weight in it — so it is not the VGM figure you give the line, which includes the empty container. On a consolidation each line gives its share of each container’s cargo weight and the master’s figure for a box is the sum of the shares; on every accepted export consolidation seen the two agree exactly. Customs is not known to refuse a weight that disagrees: its published cross-checks against the line’s manifest (232 to 238) cover packages, the number of containers, and each container’s type, number, size, load status and shipper-owned flag, not weight. So on an export the platform warns about a box weight that does not add up and blocks only package counts that do not (221, 225).

None. A consolidation’s master is filed as consolidated C with prior declaration N and names no PCIN at all; customs issues that master its own MCIN when it accepts the filing. Every PCIN sits on its own line underneath, one per shipping bill. Putting one of the lines’ PCINs on the master as well is what draws 383 and 384. The platform warns about any PCIN on a consolidation’s master and blocks one that repeats a line’s.

One PCIN appears twice in the filing — on the master and on a line, or on two lines. The two codes arrive together: 383 is reported against the master consignment and 384 against the house line. Each PCIN goes on exactly one line, and a consolidation’s master names none, because customs issues it an MCIN. Neither code is in any published list; this reading comes from export refusals seen in September 2026 and customs’ own wording. The platform blocks a repeated PCIN before the filing is sent and says where the other copy is.

Because it is an Indian port. On an export the destination is the foreign port the bill of lading delivers the cargo to — the port of discharge, unless the bill shows on-carriage beyond it — and so is the port of receipt; a hub the vessel tranships at on the way is the next port of unlading; the Indian port you load at goes in the first port of entry and the port of acceptance. The message guide describes an export’s destination as the last port from which the goods leave India, which is what leads people here — but customs refused exactly that in September 2026, and the exports it accepted name the foreign port. Fix only the destination and leave the Indian port as the port of receipt, and the next refusal is 365.

That line’s own containers. On an export every line under the B/L lists the containers its cargo is in, with its share of the packages and weight, even though the master already carries the full list. 239 is a line with no equipment at all; 381 comes with it because containerised cargo needs at least one container of type CN on that line. In the guided steps, open the shipping bill’s line, tick its containers and type its share in each. 381 is in no published code list; this reading is from a refusal seen in September 2026.

The packages on the bill against the packages on its items — customs’ wording is “Total Pckg Mismatch in Transport Doc and Transport Item”. The usual cause is an item whose package count was left blank: a blank adds nothing, so the items come up short however right the total is. Give every item its count. The neighbouring codes are the same sum elsewhere — 221 is the bill against its containers, 225 a master against the lines under it. 709 is in no published code list; this reading is from a refusal seen in September 2026.

Not on what has been observed. None of the exports customs accepted in September 2026 carries a transhipper block, and no export refusal seen so far has asked for one — so the platform’s “no transhipper” warning does not fire on an export, and the guided export steps file none. That is an observation from a small number of filings, not a published rule: customs’ own object-mapping table lists a transhipper block for straight and consolidated export masters without saying whether it is required or merely allowed, the message guide marks it optional on an exit, and CBIC told the shipping lines in 2019 that the leg from an ICD or CFS to the gateway port is covered by the transhipper’s own inland messages rather than by the CSN. An export you built in the full form with a transhipper keeps it, and stays in the full form. If your export names a transhipment bond with no transhipper PAN beside it, the check says so: remove the bond, or give the PAN with it.

No. SCX is a reporting event of the Cargo Summary Notification (SACHM22): the export CSN a forwarder, NVOCC, consolidator or customs broker files for their own cargo leaving India, naming the shipping bills by their PCINs. SDM is the Sea Departure Manifest, a reporting event of the shipping line filing (SACHM23), filed by the shipping line or its agent for the whole vessel before it departs the Indian port, amended by SDA and closed by the SDN after departure. It is the export-side twin of the import pairing, where your SCE sits beside the line’s SAM. A forwarder files the SCX and never the SDM.

No. Asked exactly this, ICEGATE answered that under SCMTR’s design one shipping bill can be mapped to one BL or HBL only, and that trade may be asked to file a separate shipping bill for each BL or HBL. The relationship is one-way: several shipping bills may sit under one house bill, but one shipping bill may not span several. If a single shipping bill’s cargo genuinely moved out under two house bills, the correction is upstream in the shipping bill rather than in the CSN — there is no code for the one-to-many shape, because customs does not intend it to exist.

Yes, container by container. Type each box’s weight and packages as the master bill prints them on the master screen, and each house bill’s share on its own screen; wherever the shares do not add up to the master’s figure the app says so beside the cell, under the house bill’s container table, and on the review screen, where every box is listed with the master’s figure, each bill’s share, the sum, and a tick or a cross. A cross blocks filing, because the master’s row is the whole box and each house row is a bill’s share of it — customs re-adds the shares and compares them, and there is no honest filing in which they differ. It catches the case a bill-level total cannot: two containers with their weights interchanged between the master and the house, where every total still agrees. If you leave the master’s figures blank they are added up from the house bills instead.

In the guided steps, yes: every container whose agent code was the old PAN takes the corrected one, whether you correct it in the same sitting or after reopening the draft, and a container you had set to some other party is left alone. In the full form the field is plain and does not follow, so the checklist flags any container whose agent code is not the master’s consolidator PAN, naming both values, and the same check runs on any file you open in SCMTR JSON upload.

Give both house bills the same container number — identical numbers are the only thing in the message that records a shared box, and there is no separate "shared" field. Each bill then declares its own share of the box: its part of the weight and its own package count, not the whole container. The master consignment shows the sum. Because retyping an eleven-character number on a different screen is where this goes wrong, SCMTR.io asks for containers once, on the master bill; each house bill then ticks the boxes it is in and gives its share, so sharing a box is the same row ticked on two house bills, never a retype.

Because they describe different things and both are correct. The house bill’s load status describes that bill’s share — two shippers in one container means neither has a full container load, so each house bill says LCL. The master’s describes the box itself, which is full, so it says FCL. Real filings accepted by customs look exactly like this. SCMTR.io works both out from which house bills carry the box, so it is not a question you have to answer.

A master consignment is the top-level bill of lading a shipping line files, covering an entire container or shipment on a vessel. House consignments (house bills) sit nested underneath it — one per individual shipper whose cargo a forwarder or consolidator combined into that container. Each house bill carries its own consignor, consignee, goods, and equipment detail. A single master consignment can have any number of house bills under it.

Every CSN declares why it is being filed via a reporting event code: SCE (Entry — cargo arriving into India), SCX (Exit — cargo departing India), SCD (Domestic Movement), SCA (Amendment to a previously accepted CSN), SCU (CIN Updation Request), and SCC (Cargo Confirmation). Which fields are mandatory, optional, or not applicable changes depending on the reporting event.

Typically: master and house B/L numbers and dates; ports of loading, discharge, and any transhipment; consignor and consignee names and addresses for each house bill; HS codes and goods descriptions for each item; container numbers, types, seal numbers and load status for each piece of equipment; and your ICEGATE-registered filer identity including the authorized representative’s PAN.

The party’s PAN, with the code type set to PAN — not an IEC. Someone shipping their own used furniture and personal effects is exempt from holding an Importer Exporter Code under DGFT’s Handbook of Procedures, so there is usually no IEC to find, and none is expected. CBIC answered this directly in its published SCMTR clarifications: for unaccompanied baggage the filer gives the PAN of the party, or the passport number where the person has no PAN. The consignee code field on an import reads “IEC of the consignee; if IEC is not available, PAN should be mentioned”, and a household move is the ordinary case of “not available”. Set the item type to UB (Unaccompanied Baggage) on the same shipment — that is the flag telling customs these are personal effects rather than ordinary cargo.

DGFT publishes permanent IEC numbers for the categories exempt from holding one, and two cover a personal shipment: IABBR0145E for Indians returning from or going abroad claiming benefit under the Baggage Rules, and IIHIE0153E for persons, institutions or hospitals importing or exporting goods for personal use not connected with trade. Note these were re-issued in PAN format — much of the advice circulating in the trade still quotes the retired numeric versions (0100000045, 0100000053). Prefer the party’s own PAN wherever they have one: a permanent IEC identifies a category, not a person.

ZZZZZ in the UN dangerous-goods code and ZZZ in the IMDG hazard code — not blank. This catches people out because “no dangerous goods” feels like an empty field, but the MIG is explicit that ZZZ is declared when goods are not hazardous, and a real accepted filing carries exactly that. Both fields sit on the item, not the consignment, so a house bill with three commodities where only one is hazardous carries the UN number on that item alone and the sentinels on the other two.

Because every UN number has exactly one hazard class in the Dangerous Goods List, and customs checks the pair. UN1203 (petrol) is class 3; UN1830 (sulphuric acid) is class 8. Rejection codes 119 and 120 are the same disagreement read from each side, and 33 is an invalid IMDG code outright. The fix is not to adjust one field until the message goes away — check both against the dangerous goods declaration for the shipment. This platform fills the class from the UN number for you, and warns rather than blocks if you then change it, since the shipping document is the authority.

The IMDG Code, because it is the dangerous-goods regime for sea transport and therefore the one a CSN falls under. This matters because national lists cover the same UN numbers with different wording: UN1203 is “MOTOR SPIRIT or GASOLINE or PETROL” under IMDG, and “Gasoline includes gasoline mixed with ethyl alcohol” in the US 49 CFR table. Same substance, same number, different proper shipping name — and a safety data sheet prepared for a US shipment will show you the second one. Hazard class can differ in shape too: the US table writes explosives as 1.1D with the compatibility group, where the CSN field wants 1.1.

They are the two fields the CSN uses when cargo does not clear at the port it arrives at — when it moves inland by rail to an ICD, or into a container freight station to be de-stuffed. The transhipper code is the PAN of the company moving it, written bare with no “PAN:” prefix; the transhipper bond is that company’s ten-digit transhipment bond 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.

Because a transhipment bond is registered per customs station, not per company. CONCOR is one PAN across all of India and files under a different bond number at Nhava Sheva, at Mundra and at Chennai — and a Chennai CFS files one bond for cargo landed at Chennai and another for cargo landed at Kattupalli or Ennore and moved to it, so the platform looks the bond up for the port you report at. This is worth knowing because it makes a wrong filing look like a complete one: copy both fields from an earlier filing made at another port and you carry a PAN that is perfectly correct beside a bond that belongs somewhere else — every field populated, and rejected on arrival with code 147. Take the bond from the paperwork for the movement you are actually filing, or from a filing made at the same station. This platform fills both fields from one choice, scoped to the port you are filing at, so the pair cannot be mismatched by hand.

Not necessarily, and this is the one that costs an amendment rather than a re-file. An invalid bond or PAN is rejected outright, on a field you can see. But an expired bond that is still registered in customs’ records can be accepted: the number is still a valid number. Where an operator holds two bonds — one lapsed, one current — filing the lapsed one goes through and then disagrees with what the shipping line filed for the same movement, and bringing the two back into line takes an amendment. 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, not something customs publishes — but the platform has now measured it: in September 2026 a CFS re-registered its Chennai terminals under a new PAN and new bonds, and a filing nine days later still carrying the old PAN was accepted, then had to be amended once customs’ record showed the new one. The operator’s own arrival notice for this movement beats any list, ours included.

None — leave the transhipper block blank, with no PAN and no bond, at every gateway port and whether the onward leg goes by road or by rail. A move into an SEZ looks like an ICD move on the form, since both are cargo movement TI, but an ICD move by rail carries the train operator’s PAN and its bond at your gateway, and an SEZ move carries neither. Customs has accepted exactly that: five CSNs from Chennai carry twelve house bills by road into the Cochin SEZ, the Mannur FTWZ and NDR Infra SEZ with the block blank, and one house bill filed with 00 in both halves went through too. What is not on record is an accepted SEZ filing from another gateway, so if the zone’s customs officer tells you otherwise for your movement, follow them. On a consolidation the block to leave blank is each house bill’s. SCMTR.io does not ask for a transhipper when the destination is an SEZ.

On each house bill. Every accepted filing on record with house bills carries the transhipper on the houses and leaves the master consignment’s own block empty, so a blank transhipper on the master of a consolidation is the normal shape, not lost data. That matters most when you amend an accepted filing: typing a transhipper onto the master asks customs to add a block the CSN never carried, beside house bills that still name whoever they named. If the transhipper has changed, change it on every house bill that names the old one.

It depends on where the cargo goes after the port. Cargo moving to an ICD needs the transhipper’s TG bond on the house bill — the code is checked against the transhipper’s PAN. Cargo moving to an SEZ carries no transhipper and no bond, and so does cargo cleared at the port under direct port delivery; five accepted filings each show the SEZ shape. For a CFS it goes by port: some ports’ custodians file under their own bond, and accepted filings at several ports carry none. The knowledge base article on transhippers, CFSs and bonds lists what accepted filings carried port by port.

It is the container agent’s container bond — the CG bond — and it belongs to the box, not your cargo. A container arriving in India is itself a foreign good, so the shipping line or its Indian agency signs one bond with customs covering all its boxes; each box is debited to it on arrival through the carrier’s manifest and credited back when it is re-exported. CBIC’s clarifications describe one such bond per entity for all of India, unlike a transhipment bond, which changes at every port. No CSN field takes it. It explains 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 is the shipping line’s, not yours: the container agent PAN and the container ISO code 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. Still give the bond-holding agent on your CSN — the value has not changed; whether 82 is the check that moved is our reading, since the advisory names no codes — and note that no refusal on record here has ever carried 82, so this is customs’ published position rather than something seen from customs’ side.

Those two codes mean the combination is rejected, not any one field: 115 says a master consignment’s cargo type, cargo movement, consolidation indicator and prior-declaration flag do not go together, and 118 says the same of a house bill. The MIG publishes the list of combinations customs accepts — 108 rows, unchanged between its 2025 and 2026 revisions — so this is a lookup rather than a guess. The commonest cause by a distance is import cargo declared with a transhipment movement: IM goes with LC, DT or TI and never with TC, which belongs to TR and EX. Read all four values off the record the error names before changing any of them: cargo type and movement live in its location-customs block, the other two in its reference block. This platform checks the pair before you file and, when a rejection does come back, quotes the four values out of your own file and says which of them cannot stand.

Two fields, one value each: cargo type (typOfCrgo) is TR and cargo movement (crgoMvmt) is TC, and the destination is the foreign port the cargo is going to. TR is a cargo type and never a cargo movement — that field takes only LC, TI, TC, DT or FT — so reading “TR with TC” as an instruction to change the movement code moves the right value into the wrong field. “ITP” in the trade’s sense — and the custom house’s — is International Transhipment, the facility CBIC extended to LCL cargo in Circular 14/2007-Cus and JNCH implemented in Public Notice 16/2007; that notice defines TC in its own words as “international transhipment cargo”. Watch two things. Cargo type must be TR, not IM: the cargo arrived as an import, but customs wants the fact that it is passing through, and IM with TC is a combination listed nowhere. And the movement code belongs to each bill of lading rather than to the container — the same public notice has an ITP box’s cargo segregated per B/L into local, foreign-transhipment and ICD categories — so a consolidation can legitimately carry three different codes across its house bills, and putting one code on all of them is what produces a rejection naming exactly one. Two more things. The cargo-movement list on your CFS, delivery-order or IGM screen is the ICES IGM list, not this one: it carries codes a CSN has no equivalent for, and it labels the shared ones differently — one such screen calls TC “Transhipment Coastal” where the SCMTR guide calls it Foreign Transshipment. Read the code, not the vendor’s label, and take each field from the guide for the message you are actually filing. And separately, the ITP in NIC’s EDI documentation is a different message (Import Transshipment, filed by a CFS through a value-added network) and is not one you file.

No — and that is the assumption that costs several days. ICEGATE stops validating at the first record that fails, so the ones after it carry neither an error nor its “00 Successful” mark: they were never checked. Correct what failed and the next filing may come back with fresh errors on records that looked clean, which is the checks running for the first time rather than a new mistake. The same ACK is more useful than it looks in the other direction too: every block customs did check and accept carries that 00 mark, so it tells you what is already right — your transhipper and bond, say — as well as what is not. This platform reads both halves and shows them under the errors, which is why it can tell you the bond you were suspecting was never the problem.

Not in the way the CSN counts it. In working filers’ practice the cargo movement code for a CFS delivery is LC — local clearance — at every port, even when the CFS is registered under a different customs station, as Chennai’s CFSs are for cargo entering at Kattupalli or Ennore. TI, domestic transhipment, is for the genuine onward movement to an inland container depot. The transhipper code and bond fields are a separate question from the movement code: a CFS move can still carry them, with the bond belonging to the gateway the cargo actually entered at.

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 — so INMAA1SHC1 is a named CFS at INMAA1, Chennai. There is no central directory of them — ICEGATE does not issue one and its code-lookup application has been returning errors for some time — but the codes are published piecemeal: customs commissionerates assign them in per-port facility circulars, and filers otherwise keep their own lists built from filings that were accepted. In this platform you can search the destination port field by the CFS’s name rather than its code: facilities at your filing’s own port are offered first, and the rest stay reachable, since transhipment cargo is destined elsewhere by definition.

The master carries the box and the gateway port; each house bill names its own share of the box as LCL, the ICD as its destination, the movement code for transhipment and the transhipper with its TG bond. The CFS at the gateway does not appear on a house bill bound for an ICD — the box is stripped inland. The knowledge base article on what happens after the gateway port shows the accepted shape line by line.

Not for customs to accept it. Of 229 accepted bills whose destination is a CFS under the port the ship called at, 179 file the sea leg alone and 50 add a road leg from the gateway to the CFS, and customs accepted both shapes at Nhava Sheva, Kolkata, Cochin and Mundra. The route step files the sea leg alone and says so in a note; add the road leg if that is how you declare it. A CFS under a different station — a Chennai CFS for a ship calling at Kattupalli or Ennore — is the other case: every accepted bill carries the road leg there, and the route adds it for you.

Either, and they answer different questions. A plain six-character port code says the cargo is destined for the port. The ten-character port-plus-facility code says it is destined for a particular CFS or terminal inside that port. Both are correct filings; use whichever matches where the cargo is actually going. A real accepted filing carries the longer form, so the field is deliberately not restricted to the six-character list.

Once customs accepts a CSN, it assigns a reference number — the CSN number, also called the CIN (Cargo Identification Number). Later filings that amend (SCA), update (SCU), or confirm (SCC) that cargo reference this number instead of re-declaring everything from scratch.

Causes include filing the wrong combination of fields for the reporting event — the mandatory/optional rules differ between a fresh entry (SCE) and an amendment (SCA), for example — format errors (invalid port codes, malformed dates, unrecognized HS codes) and referencing details that do not match the master consignment. ICEGATE’s rejection response identifies the specific fields and reasons.

“Buyer” is customs’ word for the consignee, so error 44 is about the consignee’s country on the transport document the error is attached to — 43 is the shipper’s and 46 the notified party’s. The field takes a two-character ISO code, so US is correct, which means the rejection is almost always about something else in the same party block. Check four things in order. What the file actually carries, not what the form showed: the trade writes countries three letters long, and USA, IND or CHN cannot fit a two-character field. Which bill the error names, because the master consignment and every house bill under it carry their own consignee, and filling one in does not fill the other. Whether the country contradicts the party’s own identity code: on an arrival message the consignee is the Indian importer, and every code type customs accepts bar a passport (PPT) — IEC, PAN, GSN, GSD or GSG — is an Indian registration, so a foreign country against an Indian PAN or IEC reads as a contradiction. That last point is our reading of the code rather than a published rule, and it is the one worth checking when the country itself is plainly right; check too that the shipper and consignee have not been entered the export way round. And whether an Indian state subdivision code has been left beside a foreign country, which those codes are only ever for. A genuinely foreign consignee is allowed — it is simply rare enough to be worth confirming.

A rejected original never received a CSN number, so you correct the identified fields and resubmit it as a fresh filing. A rejected amendment is the opposite case: the original it referenced is still on record, so correct the amendment and send it again as an amendment — filing the cargo fresh collides with the original on the bill numbers (errors 122 and 123). Once a CSN has been accepted, every change goes through an amendment (SCA) that references the assigned CSN number and date.

Before the shipping line’s SAM, yes — on customs’ word since ICES Advisory 38/2026 (21 September 2026), which 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: the re-file after a deletion measured here, on 6 September 2026, was refused, and it predates the advisory; no re-file after a deletion has been seen accepted since. So amendment is still 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 is then the customs officer’s (ICES Advisory 37/2026). Errors 122 and 123 mean customs already holds a filing carrying that master or house bill, usually one of your own, and once the shipping line’s filing has closed the master to you the same code comes back for anything new against it. Look the bill up before re-entering it: on CBIC’s CSN / SAM / SDM tracking facility, or by dropping the file on SCMTR JSON upload, which asks the same record. 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. Measured in September 2026, all before the advisory: an accepted update amendment left the record blank for a while, and the filer’s fresh re-entry was taken as a second CSN; two other re-files on bills customs still held, one after a deletion and one after a vessel substitution, were rejected.

Find the one character that is not plain text, retype it, make the file again and re-file under a new control number. ICEGATE’s own FAQ (question 22) says a filing must be UTF-8 encoded and that the rejection email names the line and position of the problem. Nothing was filed, so no ACK is coming for that upload. The email does not say which character it is; the likely culprits — our reading, since in the one rejection on record the character was never seen — are values pasted from a PDF, Word or an email: a curly quote or apostrophe, a long dash, a non-breaking space or an accented letter, saved by the software that made the file in a Windows encoding. Every filing on record that customs accepted is plain text, and the one character outside ASCII customs has taken is a correctly encoded non-breaking space — the check is the encoding, not the alphabet. To find it, drop the file on SCMTR JSON upload, which lists every character outside plain text by line and column, with the field it sits in and what to type instead — match it to the email by the line, since the email’s position appears to count bytes rather than characters. Retype the value where the file was made rather than pasting it, create and sign the file again (editing a signed file breaks its signature), and send it under a fresh control number. A filing made here converts those characters to plain text as you type.

A value is longer than its field allows, and ICEGATE failed the whole file for it. The email says “your filing was failed due to some error”, then lists “Errors in file” as the offending value, a colon and the rule — for example “Consignee Street Address should be only characters and should not be more than length 70”. Despite the wording, count the characters first: in the one rejection of this kind on record the address held only letters, digits and spaces and was 74 characters long, so it was the length that failed. The list does not say which house bill the value is on, so search the filing for it — the same address is often on two parties, such as a notify party “same as consignee”, or on several house bills, and every copy has to be shortened. For an address, the city, state and PIN code have fields of their own, so a city repeated at the end of the street line can usually go. Nothing was filed, so re-file with a new control number. This platform now measures a value against its field’s limit however it arrived — typed, picked from the address book or brought in with an imported file — and shows an over-long one as a red issue before you sign.

One CSN belongs to one filing, and the platform will not hold it on two. The usual cause is a number typed onto the wrong job, or the right ACK dropped on the wrong one. An ACK granting a CSN another of your filings already carries is rejected and names that filing; when ICEGATE’s own answer grants it, the acceptance is recorded but the number is not, and the filing’s page says which job holds it, links there, and holds back amending, deleting and e-mailing until it is settled. If the other filing’s copy was recorded by a person, an organisation admin settles it from that notice: the page shows who recorded that copy, when and from which file, and the admin confirms the move in a sentence naming both jobs and the CSN. The number then sits on the filing customs granted it to, and the other filing goes back to waiting for its real outcome. If both copies came from ICEGATE’s own answers, nothing here can decide between them — take both ACKs to the ICEGATE helpdesk.

File an amendment (reporting event SCA) referencing the CSN number customs assigned on acceptance. The amendment re-sends the declaration with per-block amendment flags marking what is updated, deleted, or unchanged. You cannot simply re-file a fresh CSN for cargo customs has already accepted.

While you edit an amendment, every field that differs from the accepted filing is highlighted where it appears, with what the accepted filing said underneath. A Changes button in the toolbar counts them live and lists them all — old value, new value, grouped by section — so the last thing you read before signing is exactly what you are asking customs to alter. A count of zero is itself the warning: an amendment that changes nothing asks customs to update a CSN with itself.

Yes, once the filing exists here as one this platform can see was accepted — not merely as your word that it was. Drop the amendment on SCMTR JSON upload; if the CSN it references belongs to no filing in your organisation, you are offered a short wizard that asks for three documents in the order they check each other. The amendment first, because everything after it is checked against it. Then the original fresh filing that was accepted, which has to name the same master bill of lading. Then the ACK that accepted it, which has to be an acceptance and has to grant the exact CSN number and date your amendment references — a rejection granted no CSN to amend, and an acceptance for a different CSN means the amendment was built against a different filing. Nothing is transmitted: the filing is recorded as accepted under that CSN and your amendment opens against it, so the whole history stays under one job number. If you do not have the ACK file — ICEGATE emails it to the address registered against the licence, which is often not the person filing — you need not have it: drop the CSN you filed on SCMTR JSON upload and choose File an amendment or File a deletion, and the platform reads ICEGATE’s own record of your filing, matched on the PAN in the file and compared field by field, shows you the CSN number and date, and opens the change, its history noting that it was read from ICEGATE. An organisation admin can also type the CSN off the portal, and the audit trail records that it was somebody’s word rather than a customs document. A filing accepted on the portal can also simply be amended on the portal; recording it here is worth doing to keep the history in one place, not a precondition.

No. A CSN is sent under the sender ID it carries — ICEGATE reads who sent it from the file name, which is built from the CSN itself — so one you bring in on SCMTR JSON upload can be amended, deleted or filed straight away, and the form says which sender ID it will go under. Settings matters for new CSNs, which start from your organisation’s saved details; an organisation admin can save the uploaded CSN’s details as those defaults with one click, but nothing waits on it.

Because a file is dated when it is made and uploaded when you get to it — our own samples include a CSN made on the 5th and uploaded on the 9th whose ACK answers exactly the filing customs holds. The check shows both dates side by side and holds nothing against the gap. It only stops when the values customs publishes differ from your file, and then it lays the two side by side, value by value, so you can see which.

Because nothing here can confirm that a CSN you name was granted to your organisation, and an amendment rewrites what customs holds against whichever filing customs matches the reference to — a withdrawal removes it entirely. Supplying the original filing and its ACK is what turns the reference into something checkable: ICEGATE’s own document saying this cargo was granted this number on this date. It is also why an amendment can never be imported as a fresh filing here. Resetting it to msgTyp F and clearing its CSN turns “change CSN 1448812” into “file this cargo again”, which reaches customs as a duplicate of a consignment they already hold.

Almost certainly not. Two of the six SACHM23 events carry no cargo at all: an entry inward (SEI) and a departure notification (SDN) report the call rather than declaring what is aboard. The manifest guide’s field table excludes the master consignment block, the voyage details and the itinerary from both, and requires the arrival and departure details instead — so a departure notification of 481 containers is a page of counts and times, not a page of bills. Opened here, those two files show what they actually report: containers landed and loaded, persons on board, transport contracts, and the terminal’s own arrival and departure stamps, with no Lines or Containers tabs to sit empty. An arrival or departure manifest (SAM, SDM) is the one that carries the bills.

CSN messages are structured JSON documents conforming to the official MIG (message code SACHM22), submitted through ICEGATE. Historically filers hand-assembled these files against the spec; filing platforms like SCMTR generate the message from a guided form instead.

Yes — ICEGATE ties every filing back to a registered filer through a digital signature. Filings are signed with the filer’s DSC (Digital Signature Certificate) registered against their ICEGATE account before submission, whichever channel they are submitted through. On this platform that is Sign & upload: the scmtr DSC Signer on your own computer asks your token for the signature, and the private key never leaves it.

Customs checks the cargo movement against the port of receipt on the transport document. A receipt port that is a sea port (a code ending in 1, such as INMAA1) takes only LC, and anything else is error 365; an inland depot or SEZ (ending in 6) cannot take LC, and that is error 366. The rejection lands on the transport document, while the field to change is Cargo movement in Location & customs — which is why it reads as though it names nothing. A 365 has two possible fixes and only you know which: set the movement to LC, or, if the cargo really is going inland, correct the receipt port to the depot’s code. Every filing in this platform’s sample corpus obeys the rule; that the sixth character is what customs reads is an inference from that corpus, not a published statement.

Customs matched no CSN on the number and date your amendment referenced, together. 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. If the filing being amended was rejected, it never received a CSN and the cargo is filed fresh instead. 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.

Yes, where SCMTR has switched it on for your organisation and your admin has ticked May file by e-mail for you. Send the master bill and its house bills as PDFs, from the address you sign in with, to the bills address shown in Settings. The Sea Cargo Manifest Checklist drafted from them comes back by e-mail; what the bills leave out — which CFS, a consignee’s PAN — is asked on one page with no sign-in, and the checklist follows the moment you answer. Nothing is filed by e-mail: a person approves the checklist in SCMTR and the draft CSN opens, with the bills beside it, for the usual check, sign and send.

Yes. Since 17 September 2026 every file uploaded to SCMTR is kept — declarations, ACKs, shipping line filings and customs’ replies, on whichever screen you upload them, including the free check without signing in and files e-mailed to the checking address. A file is kept for two years after we last receive it, or for as long as a filing here still relies on it. We use kept files to help you when you ask about a rejection, to link a filing with its replies and amendments over time, and to improve how SCMTR reads and checks files; they are not sold, not used for advertising and not used to train AI models. A platform super administrator can open one, every opening is recorded, and you can ask for any file to be deleted. A shipping line filing is still read and edited in your browser, and is kept like any other upload. One thing worth a thought before uploading: a file somebody sent you names their consignor, consignee and cargo — upload only what you have the right to share. The screens you upload from say this, and the terms and privacy policy set it out in full.

Yes — short films on the SCMTR YouTube channel (youtube.com/@scmtrio), one job each and none longer than a few minutes: filing a first CSN, checking an ICEGATE file before customs refuses it, comparing a CSN with customs’ record, telling the shipping line your CSN details, amending or deleting an accepted CSN, checking files by e-mail, finding a ship’s VCN and tracking a BL; on the export side a straight bill, a consolidation and a refusal; and on the shipping line’s side building a SAM, the SAA that takes a bill off a SAM or puts one on, and the rejection whose ACK names nothing. Every help or reference page a film walks through links it under its heading, the full list is under Using the app, and the assistant hands out the same links. None of the films shows a customer’s data.

Yes, where checking by e-mail has been switched on. Your CSN filing page and Settings name a checking address; send the JSON to it as an attachment — up to five files in one message, from the address you sign in with — and the full report comes back as a reply: every problem, where it sits in the filing and how to fix it. Send the CSN together with the ACK ICEGATE sent for it and the two are read together, so each error names the value in your own file; the report also says which of your filings an ACK answers. Its button opens the screen for what comes next, once, within 24 hours, and never records anything by itself. The files are kept, like every file you upload. It has to come from the address on your account, because that is how the report knows whose it is — unless you use your own checking address (next question) — and a message from an address with no account here gets a short note about signing up rather than a report, no more than one a week. To have another file checked, send a new e-mail rather than replying to a report: a reply goes to a person, not to the checking address. Everything about it is in Checking files by e-mail in the help pages.

Yes. In Settings, under Checking by e-mail, get your own checking address and point a forwarding rule for ICEGATE’s mail at it. Everything that arrives there is checked, and the report comes back to you — never to whoever sent the message — which is why it works even though a forwarded message still carries ICEGATE’s name rather than yours. Gmail asks to confirm a new forwarding address before it forwards anything; that confirmation comes back to you as a report with Gmail’s own code in it. Microsoft 365 organisations often block forwarding outside the organisation unless an administrator allows it. Treat the address like a password: somebody who had it could send you files that look like ICEGATE’s, so a report of anything sent there says who sent it, and its button only ever opens the checker, never a filing ready to record. Getting a new address stops the old one at once, and the page asks before it does. ICEGATE’s rejections that come as a bare e-mail with no file can be forwarded the same way, and come back explained.

Most of it answers something you did: a sign-in link you asked for, an invitation to an organisation, a CSN alert a colleague chose to send, a reply to a file you e-mailed for checking, a reply from us to feedback you sent. Beyond those there are notices about a filing of yours when something outside SCMTR changes under it — another filer’s CSN or the shipping line’s manifest disagreeing with yours on the same master bill, or customs moving, adding or withdrawing your vessel’s call — which go to whoever created the filing. Exactly two are sent unasked and both can be switched off: a Monday summary of the files you checked that week, and one short note, once ever, if you checked a file and never came back. Each carries a one-click “Stop these e-mails” link in its footer, and there is a switch in Settings called “Weekly summary and occasional tips”. Nothing is e-mailed to everybody: when the privacy policy or the terms change materially, SCMTR shows you what changed the next time you open it and asks you to accept before you carry on — there is no announcement mail.

The invitation itself is unaffected — they are invited, and signing in with that address joins them to your organisation whether or not the e-mail arrived. What can be held back is the convenience e-mail. Check spam first, and check the address is the exact one they use. There are also daily limits, so this platform cannot be used to mail strangers: an organisation sends 20 invitation e-mails a day, 20 per person, and at most two to any one address in a day; an organisation that has not yet filed or checked anything sends five a day and one per address. If you have hit one, send them the sign-in page and the address you invited them under, or try again tomorrow.

Yes. When you open an SAA in Shipping line filing, SCMTR counts the manifest customs holds by itself, at the top of the page: it reads ICEGATE’s public record of your vessel call line by line — every line customs holds now and the containers on them — for a manifest ICEGATE names your own submitter on. Every count keeps everything customs’ public record shows for each line — the master bill and date, the CIN it quotes, cargo type and movement, every port, the transhipper, packages and weight, each house bill with its CIN and figures, and each container with its type, size, weight, status, agent and bond — so you can point at a line on the count’s map, read it whole and copy it to whoever holds the SAA; an agent counting the shipping line’s manifest under the line’s PAN included. Customs’ record names no party. When several agents work the same vessel call, a count one of them finished is handed to the next while customs still holds that version, so it is not counted twice. Your SAA is then checked against that count, as a pre-check: on an arrival manifest whose count customs’ current version confirms, a wrong line total, a container total below the count, a container your SAA adds that customs’ lines already name, a line added under a number already in use, and a container a removed line leaves on the vessel’s list with no line are errors — each is a refusal customs has made or is certain to make, or a change to the manifest you did not mean (some of these rest on SCMTR’s reading of customs’ record rather than a refusal on file); a container total above the count is a warning, since an empty can sit on the list with no line. A large manifest takes a few minutes; the count is kept, and reused while customs still holds that version.

Usually LCL on each line that names it and on the vessel’s container list — every arrival manifest on record files it so. Customs has also accepted a departure manifest that filed one FCL on both lines and on the list, each line matching its own export CSN. What matters is that each line matches the CSN it quotes and the list says what its lines say. A manifest built here does that, and the Checks tab notes lines that disagree, as a warning: no refusal for it has been seen.

The one public sign is the inward date on the line’s manifest record for your bill. When customs’ record shows it, your filing’s page says so. After entry inward an amendment needs the jurisdictional officer’s approval (ICES Advisory 37/2026), although the manifest guide also lists 373/374, “Entry Inward is Granted — Amendment Not Allowed”.

No. Sign in with Google, Microsoft or an e-mailed link and the account is created as you do — free, nothing to install. The first screen shows how SCMTR treats the files you bring; accept it and the page you asked for opens, a file you checked on scmtr.io/check included.

No. SCMTR has no passwords at all. You sign in with Google, with your Microsoft work account, or with a link sent to your email address — there is nothing to choose, store or reset, and nothing that can be reused against you if it leaks somewhere else.

Yes, and that is how it is designed to work. Ask for a link on your laptop, open the email on your phone, approve it there, and the laptop page continues on its own. You never have to forward the email to yourself or retype anything — the device where you started is the one that ends up signed in.

When you ask for a sign-in link, the page shows a short code and the email shows the same one. Approve only if they match. Because approving signs in the device that started the sign-in, this is what protects you if somebody else enters your address: you would receive a real email, but with no code on screen to match, so there is nothing to approve and nothing happens.

Links last ten minutes and work once. If yours expired, just ask for another — nothing is wrong with your account. If none arrive, check spam first: they come from support@scmtr.io. We deliberately do not say whether an address has an account, so a typo produces no error message. If it says we have sent as many sign-in emails as we can today, that is a platform-wide daily ceiling on outgoing mail, not something about your address — sign in with Google or Microsoft instead, which sends nothing, or ask again tomorrow.

It files every SCMTR message a vessel call needs from the trade: the CSN for consol agents, NVOCCs and forwarders, the shipping line’s SAM / SDM and its SAA amendments, and the export CSN (SCX) against shipping bills. Instead of hand-assembling JSON against ICEGATE’s message guide, you fill in guided steps built from it — with the rules for your kind of filing checked live, and the error codes ICEGATE rejects with caught before you send — then sign with your own DSC, upload to ICEGATE from here, and see customs’ answer on the filing. The free check, BL tracking and VCN search work without an account.

Consignors, consignees, notify parties, vessels, and item templates from every filing you send, download or have accepted are saved automatically and become searchable suggestions on future filings, ranked by recency. Repeat shipments stop meaning re-typing the same details, and one team member’s data entry becomes the whole organization’s autocomplete.

It is printed nowhere on the bill of lading, and there is no public register of carrier PANs. On a master with house bills under it the Consolidator PAN is the agent 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. A working filer’s table, for example, has Wan Hai filing under its own PAN from Chennai to Chennai and under an agent, OMEGA, from Chennai to Bangalore; that table is one filer’s practice and has not been checked with customs, while for fourteen lines — Maersk, MSC, ONE, OOCL, Evergreen, COSCO, HMM, Gold Star, Emirates, Wan Hai, Interasia, PIL, Hapag-Lloyd and Unifeeder — the PAN offered is the one on filings customs accepted, and the field says so. So on the master, pick the Shipping line on the bill — kept with your draft to choose the PAN, never sent to customs — and the PAN fills from a routing table for your port and destination, saying whose PAN it is; where the table names an agent whose PAN it does not hold, it asks you for it rather than offering the line’s own. The PAN field also searches by the line’s name: the PANs your own organisation has filed come first, then a reference list that says plainly it has not been checked with customs. Pick one and the containers’ agent codes follow it in the guided steps. If you are unsure, confirm with the line’s local office. On a master filed on its own, the field is your own PAN.

Yes. In the guided steps, a master with house bills has a Route for all house bills on the master step — port of loading, first port of entry, final destination, next port of unlading, inland transport (rail or road), transhipper and item type. Every house bill starts with it. Change one bill’s destination on its own page and only that bill changes, marked as changed for this bill only, with a Use button naming the route’s value to put it back; the bills after it keep the route, and the master step lists which bills have a destination of their own. A bill sent elsewhere is asked for its own transhipper, and one going into an SEZ for none; change the route’s own destination and its transhipper comes off with it, with one click to keep it. Change the route later and every bill you have not changed follows. The route itself is not sent to customs — it only fills in your house bills.

You can now. Customs files inland depots and SEZs under their full registered description, so the code INAIK6 is on record as “VILLAGE IBRAHIMBUR, POST KHURJA, BULANDSHAHR, UP” — which is why searching for “Khurja ICD” used to find nothing. Every port field now also answers to the short name your paperwork uses, and to operator names that appear on documents even where the site has since changed hands. What gets filed is still the official code and the official name; the extra names are search terms only and never reach your declaration, so if the name shown after you pick does not match the words you typed, nothing is wrong.

No. Drafts autosave continuously as you type, and a live checklist shows exactly which fields are still left to complete — useful because a real CSN is usually filled over several sittings as shipment information arrives. One thing worth knowing about the guided wizard: it creates the draft when you enter the bill of lading number rather than the moment you open it, so looking around never leaves a stray declaration behind or counts against your plan. From the moment a bill number is on screen it saves continuously, like the full form, and the footer says so. Before that — if you find the vessel first, say — what you have typed is kept in your own browser rather than on our side, and offered back when you come back to it. That copy stays on the machine you typed it on, expires after a day, and is cleared when you sign out, so a shared office workstation does not hand your work to the next person.

Yes — they are two views of the same draft, not two drafts. The wizard offers the full form from every step, the full form offers the guided steps back whenever the filing is a shape the wizard can show — where a bill holds several items it first shows you what combining them into one would change — and a draft always reopens in whichever view you last worked in, with the step rail showing what is still outstanding.

Two master consignments in your file carry the same master B/L and the same house bill — usually a line copied to start a second and then left as it was. Customs identifies a record by that pair, reads the two lines as one record filed twice, and reports both codes against the voyage rather than either line, which is why the acknowledgement seems to name nothing. Remove the duplicate line, or if the two really are different cargo on one master B/L, give each its own house bill. The platform blocks that pair before you file; the same master B/L with different house bills is declared split cargo and only warns. Neither code is in the CSN guide’s own error list — they are published in the vessel manifest’s shared list — so looking them up in the CSN MIG finds nothing.

Because the field is capped at the maximum length the MIG gives it. The one over-long value on record did not come back as an ACK at all: ICEGATE failed the whole file by email, naming the field and the limit — “Consignee Street Address … should not be more than length 70”, for a 74-character address — so stopping it as you type is far cheaper than a rejection hours later. A value that reaches the filing without being typed — picked from the address book, or brought in with an imported file — is measured too, and shown as a red issue naming the limit and how many characters to remove. The same lengths decide how wide a field is drawn, which is why a two-character state code no longer takes up the same box as a goods description.

Because the message wants a two-digit code from the MIG’s own 35-entry table, not the state’s name. Picking the country first is what tells the form whether that table applies — for an Indian party you choose the state by name and the code is written for you; for a foreign one the field takes free text. The consignee’s country starts as IN, and a party code is checked against the shape its code type promises — PAN, IEC, or one of the three GSTIN types the MIG allows — so an IEC is not measured against the PAN rule.

Yes, and everything else about its DSC that the file can show — free at scmtr.io/check with no account, or on SCMTR JSON upload when signed in. The signature is verified against the file’s exact bytes, the way customs verifies it, and when it fails the check says what changed where the file shows it: line endings changed by an editor, content added after the signature, or a general-purpose signing tool used instead of a JSON filing utility. The certificate is checked too: in date (amber from 30 days before expiry, since a renewal must be registered at ICEGATE first), not revoked by its authority, chained to CCA India, Class 3, and a signing rather than an encryption certificate. Signed in, it also says whether this DSC has signed a filing customs accepted from your organisation through Sign & upload — which is how an unregistered renewal shows up. Every check is listed, with the passes and anything that could not be checked, and none of it needs anything installed; a separate button compares the file with the DSC on your own computer through the scmtr DSC Signer. If you edit a signed draft in the platform, the stale signature is removed on the spot and the filing is signed again with Sign & upload.

Drop the signed file you sent on scmtr.io/check. Its Digital signature panel checks the causes a file can show and flags the likely one. The usual causes: the certificate is not the one registered on your ICEGATE ID — most often a renewed DSC that was never registered, because a renewal is a new certificate; the file was opened and re-saved after signing; or the certificate has expired or been revoked. Nothing in the cargo data needs to change: fix the cause, sign a fresh copy, and send it with a new control number, because the failed upload was received. This answer is informational only — confirm anything you are unsure of with ICEGATE.

Nothing is lost and nothing is filed twice. If an update ships while your filing is open, the page reloads itself onto the new version and puts your work back exactly where it was — the same values, the same step, the same bill you were editing — and tells you that is what happened. A submission interrupted this way never reached customs at all: the request is rejected before it is processed, so there is no partial filing and no duplicate to clean up. If it happens while you are part-way through signing, download and sign again after the reload.

No. Type the name as your bill of lading writes it and the platform looks for hulls that have carried it, showing each with its IMO number and, where customs holds one, a recent call at an Indian port with the port and date. Ships customs has seen at Indian ports come first, names other filers have confirmed next, and public ship registers last — which is what covers a vessel too new to appear anywhere else. Because several ships can carry one name, and ships are renamed on a change of owner, you pick the hull rather than the platform guessing: a name typed into the form is never turned into a vessel identity on its own. If the ship still cannot be found you can enter the IMO number directly, and the platform points you at where to look it up — searching by name is a convenience, and no filing depends on it. And if a register holds the ship but publishes no IMO number for it — common for barges and coastal craft — the search says exactly that, by name, and offers to file it as a non-IMO vessel in one click rather than telling you it was not found.

You can, and the platform will tell you what you are taking with you. Sign & upload refuses a filing with problems outstanding; Download JSON and Copy JSON used to hand the same file over in silence, and on 23 September 2026 a filer took a file the checklist was flagging, filed it on ICEGATE by hand and was refused for exactly those faults. Both doors now open a short dialog naming what customs would refuse, in the form’s own words, with Show me what to fix first and Download anyway second; a red “N problems to fix” pill sits beside them in the toolbar. Emailing a filing or a checked file works the same way: the composer shows a Not ready to file block above Send, and the message and the page its link opens carry the same block, so nobody receives the file believing it is filable. It never appears once customs has accepted the filing.

Press Sign & upload on a finished filing. The platform freezes your declaration to exact canonical bytes; the scmtr DSC Signer, a small code-signed utility installed once on your Windows computer, asks the DSC token plugged into it to sign those bytes, and your token asks for its PIN. The signature is verified against the frozen bytes before anything reaches customs, so a stray keystroke between freezing and signing cannot produce a filing you did not review, and a signature that does not verify is stopped here rather than by customs hours later. Your private key never leaves your token and never touches this platform. If your IT department will not allow the signer, the dialog that offers the download also offers the older route: the platform hands you the frozen file, you sign it on ICEGATE’s own portal with your registered DSC, and upload it back. Either way, before the file leaves it passes a gate that rejects the same filing twice, sends are paced, and a send that gets no answer is marked “Delivery unconfirmed” rather than treated as failed. The signed message then goes to ICEGATE, acceptance or rejection detail is shown against the filing field by field, and accepted filings are locked with their CSN number recorded.

Every filing is fingerprinted when it is frozen for signing — once on the exact bytes your signature covers, and once on the shipment with the control number, job number and date removed, which is what a regenerated file looks like. If an upload of the same filing has already gone and customs has not answered, or has accepted it, a second send is rejected before it leaves, with the earlier one named and one click to open it. A rejection by customs is never in the way, a 700 included. If you know better — ICEGATE confirmed by phone that the first one never arrived, say — type a reason of at least ten characters and send it anyway; the reason is kept with the filing. The same warning appears at the download step, before you sign.

An upload left and no answer came back — a timeout, or a connection dropped halfway — so ICEGATE may be holding the file or may never have received it, and nothing on this side can tell. The filing is locked and marked as sent, because that is the safer assumption, but no tracking number is claimed. Do not upload it again. The platform keeps reading customs’ public record for that master bill and clears the doubt itself when your filing appears there; dropping the emailed ACK on the filing settles it just the same. If nothing ever arrived, an organisation admin can return the filing to draft.

Two reasons, and the message says the same thing for both: nothing was sent and your signed file is unchanged. Sends are paced — thirty a minute across the platform, ten a minute for one organisation — and past that a send waits its turn. And if uploads stop completing, sending pauses for about five minutes rather than adding to a gateway that is already struggling. Try again in a few minutes.

Yes. Sign & upload asks the scmtr DSC Signer — a small utility installed once on your Windows computer, code-signed by TAGQA Pty Ltd — to sign the frozen filing with the DSC token plugged into your machine, and sends it. Your token asks for its PIN, the private key never leaves it, and the Signer never sees the declaration itself. The app offers the installer the first time it finds the Signer missing, and rejects a Signer too old to trust rather than letting it fail later. If your IT department will not allow the install, the same dialog offers the older route: download the frozen file, sign it on ICEGATE’s own portal, and upload it back.

ICEGATE takes the file, and what happens next depends on what customs decides. An acceptance reaches the filing on its own: since September 2026 customs’ public record publishes the CSN number and date of each accepted filing, and since 22 September 2026 the platform reads that record for every waiting filing about every fifteen minutes. When the record names your very transmission, yours is the only filing of your organisation on that master bill, and the record’s containers and packages agree with what was sent, the CSN number and date are recorded and the filing turns accepted — its history says the outcome was read from customs’ record, not from an acknowledgement. A rejection never appears on that record. Every decision is also e-mailed to your registered ICEGATE address as a file whose name ends in _ACK, and for a rejection that is the only way it reaches you: drop the file on the filing and every rejection reason is explained against the field it names. An amendment or a deletion is never settled from the record and waits for its ACK.

Yes — keep it and drop it on the filing when ICEGATE e-mails it. The ACK is customs’ own file: the one attached when the CSN is e-mailed, the only document that carries a rejection’s reasons, and the one a customs officer, a shipping line or an auditor will ask to see. An outcome read off customs’ record is a reading of a public page; the ACK is the answer addressed to your transmission. Dropped on a filing already accepted from the record, an ACK that agrees is kept and becomes the transmission’s own answer — the status does not change, the history now has the file behind it, and the CSN e-mail has a file to attach. One that disagrees — a different verdict, or a different CSN number — is refused and named, because two answers about one transmission need a person to settle, not an overwrite.

Nothing for filing — SCMTR is free to use, with no filing caps and no card required. If your organisation wants its own systems to check and send files to SCMTR and hear back by webhook, write to support@scmtr.io.

Yes. Each person is an Admin (manages the team and settings) or a Member (creates and files declarations); anyone somebody reports to is a manager, who sees and corrects their team’s work. Everyone shares the organisation’s address book and declaration library, and the audit history records who created, edited and submitted each filing — work done by a filing agent’s people is named by the agent.

Yes. The agency turns on Clients under its own Settings → Workspace and asks for your company by the PAN you file under; your admins are told who is asking and accept or decline. You choose what the agency may do — Files only, or Runs the account, whose ICEGATE ID the files carry — and an end date if you want one. Every filing stays yours, your admins stay yours, the agency’s people never become your members, and you can end the engagement or move to another agent whenever you like without losing a filing. Its people are named in your records by the agency’s name, never their own e-mail.

Yes. Turn on Only signers send under Settings → Workspace. Everyone can then prepare a filing and hand it on, but only admins and the members marked Signer on the Team page may press Sign & upload — and they are told before any DSC is asked for. A manifest is stopped at the send the same way. For an agency this covers its people in every client too.

Because you switched organisation in another tab. Each tab knows which organisation it was opened for, and a request from a tab that no longer matches is refused rather than followed, so nothing you do there lands in the wrong company — no suggestions from the wrong address book, no manifest sent as the wrong line. The tab offers Keep working here, which moves it back to the organisation it was opened for, or Reload, which brings it to the one you switched to.

Yes. Each organization’s declarations, address book, and filing history are fully isolated from every other organization — enforced at the database level with row-level security, not just in application code.

Yes — a declaration can be shared as a read-only link, useful for a shipper or customs broker who needs to check the details without an account. The link expires automatically, can be withdrawn at any time, and is excluded from search engines.

Amend as early as you can — before another party’s CSN against the same master bill of lading is accepted, the shipping line’s own or another forwarder’s. Customs’ error list has a refusal for changing a CSN linked to another (error 320). No refusal carrying it has been seen yet, so SCMTR warns rather than stopping you, but 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 time. That event does close the master to a brand-new CSN. The shipping line’s manifest (SAM) is a different event: since ICES Advisory 37/2026 (18 September 2026) you can still amend after it — file the amendment, then give the line the amended CSN and MCIN/PCIN so it can file a matching manifest amendment (SAA); once Sea Entry Inwards is granted, both need the jurisdictional customs officer’s approval — but a deletion becomes the officer’s to carry out, and a fresh CSN is no longer the route. (Until 19 September 2026 this answer said the manifest closed the window too; that was an inference no ICEGATE refusal ever confirmed, and the advisory replaces it.) Before the SAM a deletion is your own, and since ICES Advisory 38/2026 (21 September 2026) customs says it may be followed by a re-file of corrected particulars without a mismatch — amendment remains the lighter route, and no re-file after a deletion has yet been seen accepted from customs’ side. The platform watches for both on your behalf: every filing says what is still open to it, the wizard says so while you are still typing the bill number, an imported file says so before you build a draft on it, and a submission that customs would reject is stopped before it goes. The practical rule is to amend the day you notice something wrong rather than the week after.

No, it is how SCMTR is meant to work. Both of you file: you declare the house cargo, they declare the master, and customs cross-validates the two declarations against each other. Their filing is not a conflict with yours and does not invalidate anything you have sent. What it does do is end your ability to file a new CSN against that master, and put a later amendment of yours at risk (error 320, not yet seen refused) — so it is your deadline rather than your problem. It is also the reason the platform checks for it at every point where you might act.

Read it as information, not a refusal. It means another organisation using this platform has sent a CSN on the same master B/L at the same port of reporting — awaiting customs’ answer or already accepted — and the notice says how many and whether customs accepted theirs, never who; customs’ own public record names the filer, and the notice links to it. Nothing anyone is still drafting is counted. On most bills that other filer is the shipping line or the console agent on the other side of your consolidation, which is how SCMTR is meant to work. What it is telling you is to look at what customs already holds on the bill before you send: the two filings are compared on the bill date, the package count and each container, and where they disagree it is the later filing that customs refuses. If what you find is your own earlier CSN sent from another login, amend that one rather than filing a second.

No. The refusals at Sign & upload are the ones that stop a duplicate — the same signed file, or the same shipment regenerated — and those ask for a reason before anything leaves. These two are notes shown beside them, and they never block. “Control number already used” means a file with this control number already went on this job date — sent from here, brought in from the portal or recorded as made elsewhere — and ICEGATE processes one control number once per job date, so the send may come back refused as already processed: open the filing the note names and see what went under the number before you decide. “Customs already lists a CSN on this bill” means the public record already shows a CSN accepted under your PAN on that master B/L: a fresh CSN would be a second copy rather than an amendment, and a second accepted copy has to be settled with a customs officer, so if you mean to change that filing, amend it instead. If you know the number is free at customs, or the listed CSN is not yours to amend, you send as you are.

Yes, and the platform is careful to separate two things that sound like one question. Customs can tell you whether your bill of lading reached the carrier’s arrival manifest — that is about paperwork, and it is shown inline on the filing. Only the shipping line can tell you where the box physically is, so the filing also links straight into that carrier’s own tracking with your container or bill number already filled in. The carrier is identified from customs’ own record of who is running that VCN rather than guessed from the number’s prefix, which is more reliable — a container prefix names the box’s leasing owner as often as the line carrying it. Where a carrier’s site cannot accept the number in a link it is copied ready to paste instead, and where the carrier is not one we have mapped yet you still get a general tracking site that covers more of them.

An IGM amendment is the line’s SAA (an SDA for an export), and a forwarder cannot file it: customs takes one only from the carrier or its agent, so the line files it and bills whoever asked. Carriers’ own notices put their charge at up to ₹10,000 per amendment request on top of customs’ ₹1,000 fee, and the consignee’s Bill of Entry is refused with error 635 until the amendment goes through — the trade has reported ten to fifteen days for a short-landing amendment against customs’ own 24-hour target. Before the line files its SAM every correction to your CSN is free, and since ICES Advisory 38/2026 a CSN can even be deleted and filed again while no SAM refers to it. That is why the platform checks your CSN against the line’s filing before it goes, not after.

Yes, on Sign & upload, before your token is asked for. It asks customs’ own record what the line has filed for every master B/L on the CSN and compares the two field by field. The usual case is that the line has not filed yet, and nothing stops you — that is the free window. If the line’s SAM quotes your CSN and differs on a field customs has refused filings for (the B/L date is 164, total packages 232, the number of containers 233, the load status 399) you see the field, both values and the code, and sending anyway needs a reason of your own, kept with the filing. A difference on any other field pauses you and never stops you. If the line filed your master B/L as a straight bill, or its SAM quotes another CSN, the platform says so plainly rather than sending a fresh CSN on a bill the line already holds. A check that cannot reach ICEGATE never holds a send back, and the platform never decides which side is right — yours may be.

The deadline that matters is the line’s cut-off for CSNs, after which it files its manifest with what it has. If the line has shared its SAM on the platform it sets its own cut-off and you see it, on the Sign & upload check and in every reminder. If it has not, the platform shows the cut-off the line published for the call on the CSN cut-off board (scmtr.io/cutoffs) — indicative, so confirm it with the line. Where the board has none, it uses the rule your CSN’s own line publishes for India when that rule counts from the arrival (Maersk’s and CMA CGM’s, 72 hours before), worked out from the arrival customs lists for your VCN and marked estimated; and where the line publishes no such rule it counts 72 hours back from that arrival and says that this is a common cut-off, not your line’s word — your line may ask earlier. A CSN you have started and not sent is reminded to you a day before the cut-off and once more if it passes while the ship is still out; if a line named you on a B/L and customs holds no CSN of yours on it, you are reminded even if you have not started one. The e-mails and phone notifications switch off under Settings → Alerts.

One line: your own master B/L, never the whole manifest. A shared SAM holds every forwarder’s bill on the vessel, so a line of it opens for you only with a proof — customs’ record lists your CSN on that bill, the line names your PAN as the consolidator on it, your PAN is its consignee or notify party, or the line named you on the bill here or sent you its link. What you see is the master bill’s own details — date, packages, weight, containers, ports, what it quotes — the same things printed on the master B/L you already hold, compared with your CSN where you have one, filed or in draft. You are told per bill whether the line’s copy matches your CSN, differs, or does not quote it at all, which means the line is about to carry your bill straight. If you are not on the platform the line sends a link; drop your CSN JSON on it and it is compared and not kept. A shared draft is the line’s intention, not customs’ record, so it never stops your upload.

Yes, from a CSN customs accepted. Brokers still ask for the one-page cargo declaration of the old paper IGM, signed by the forwarder as agent and naming the IGM line and sub-line each bill sits on. On an accepted arrival notice press Form III for the consignee, tick the bills for that consignee only, and check the four details a CSN does not carry: the shipping line, vessel name, voyage and call sign, each filled in and each saying where its value came from. Everything else is read from the accepted CSN and cannot be changed. The IGM line and sub-line come from customs’ own record, never from your CSN’s numbering — until the line’s manifest is on record the form says Awaited, with the date the record was last read, and you send the copy again once the number appears. Print it, download the PDF, or e-mail it: the message carries the PDF and a covering note, never the CSN file or the acknowledgement.

Yes. An accepted filing can be amended (which pre-fills the SCA message with the assigned CSN number and per-block amendment flags) or used to file a deletion. Any filing can also be used as a template for a brand-new declaration for a similar shipment, with fresh identifiers generated automatically.

The ship’s name, with the transport means type set to 11 — non-IMO vessel. Barges and coastal or inland craft are commonly never assigned an IMO number, and the message allows for exactly that: on type 11 the identity field carries the name, up to 25 characters, instead of a number, and the check-digit rule that applies to an IMO number is not applied. The search tells you when you are in this case — if a ship register holds the hull under the name you typed but publishes no IMO for it, the result says so by name, with its flag and MMSI, and offers to file it as a non-IMO vessel in one click. Two cautions: a register publishing no number is not always proof the ship has none, so if your bill of lading or booking confirmation shows an IMO, that wins; and never invent one, because a wrong hull is a filing customs will reject. And one honest note: this is the shape ICEGATE’s guide specifies, but every filing this platform has seen accepted so far carried an IMO number, so a type-11 filing is not yet proven from here.

Sometimes — paste it into the same box you would type the ship’s name into. Customs publishes the mapping in one direction only: its enquiry answers “which calls does this ship have?” for an IMO number, and rejects “whose call is this?” for a VCN, so nothing can look a VCN up cold. What the platform can do is answer from the voyages it has already fetched — every ship anyone has looked up by name or IMO has its calls kept, this one included — which covers the common case of a vessel your organisation has filed against before. A VCN that comes back empty is not a wrong VCN; it means nobody here has looked that ship up yet, and searching by name brings its voyages back with it.

Both, whichever capacity you are registered in. The Cargo Summary Notification — ANC, ASA or ASC all file a CSN here, built, validated, signed, submitted and acknowledged. The shipping line filing an Authorised Sea Agent files for the ship itself (SACHM23) — since 12 September 2026, yes: open it on SCMTR JSON upload or under Shipping line filing, correct it, check it against customs’ own record, and press Sign & upload. The scmtr DSC Signer on this computer signs it with your DSC token — a copy signed elsewhere can be uploaded instead; it is verified, checked again and gated against a second send, then goes to ICEGATE under the sender ID in the file. Customs’ ACK to a SAM reaches your registered ICEGATE email — this platform tells you the file was taken, never that it was accepted.

No. The filing asks which ship is carrying the cargo and takes either its name or its IMO number in the same box — type the vessel the way your bill of lading writes it, voyage number and all (“MAERSK CAMEROUN/629W”), and it finds the ship, then pulls that vessel’s calls at Indian ports from customs. Because a ship’s name is not a unique identity — names are transferred between hulls when ships are sold, and several vessels can carry the same name at once — it shows every vessel known by that name alongside the port and arrival date customs holds for each, so you confirm which one is yours against the document in front of you. Nothing is filled in until you do. A vessel with no IMO number at all, such as a barge, is handled rather than left to you: when the registers hold the hull and publish no number for it, the search says so and one click sets the transport type to non-IMO and writes the name as its identifier. The same box also takes a VCN, if that is what you have.

All of it is on the public site. /reference covers the regulation and the message — the glossary, every field in a CSN, every coded value, the identifiers customs mints, rejection codes and their fixes, amendments and deletions, and how filing through the ICEGATE API actually works. /help covers using the platform, and troubleshooting written as symptoms rather than features. It is the same material the assistant answers from, which is why its answers name the documents behind them.

Partly, and it is worth knowing which part. Give it an IMO number and that vessel’s calls at Indian ports come back from ICEGATE’s public enquiry — VCN, rotation number, port, expected arrival, and the shipping line. Give it a master bill of lading and the manifest lines behind it come back too, and a three-step intake shows you what was returned, what it will write, and what it could not map, before anything in your draft changes. What it cannot do is fill the filing: customs holds the voyage, not your cargo. It reads the carrier’s arrival manifest, which is filed at or near arrival while your declaration is filed in advance — so on a new filing there is usually nothing there yet, and it carries none of your consignor, consignee, HS code or goods description, because no carrier ever sees the house bills underneath their master. For a new filing, pasting the bill of lading is the faster start; the customs fetch earns its place on amendments and as a check after filing.

There is a three-step wizard that follows the documents you hold rather than the MIG’s block structure — the carrier’s master bill with its containers, then your house bill with its parties, route, goods and the containers it picks from the master, then review. A line above every step shows the master, its containers and which house bill each is on. The step rail says what is still outstanding on each without blocking your way forward. It fills in whatever it can and says why, never asks for less than the message needs, and the full form is one click away from every step. Both edit the same filing, so you can move between them freely.

Yes. A shipping line’s arrival manifest opens in the browser — a real 1.4 MB file with one row per bill line — and is searchable by bill number, container, consignee, port or house bill. Any line can be edited with the same field-level editor a CSN gets, with self-consistency checks traceable to ICEGATE’s own error codes (279, 705, 156 with 153, 101 and 102), plus the shapes real rejections named — 370 with 118, and 707. Save it and it reopens where you left it, for your organisation, for ninety days after you last touched it; write it back and nothing changes in the file except what you changed.

Yes — since 21 September 2026 a SAM / SDM can be built here as well as opened. Under Shipping line filing, Start one from scratch asks for the ship’s IMO number and reads customs’ own record of the call, so the VCN, the rotation number and date, the port and the expected arrival are filled in rather than typed. You then choose which of the four filings it is — the arrival manifest (SAM), entry inward (SEI), the departure manifest (SDM) or the departure notification (SDN) — and answer plain questions; for a bulk or break-bulk arrival, ten questions per bill of lading write the whole cargo line, and the totals and the vessel’s equipment list are counted for you. Container lines, and a departure manifest’s export lines, are added in the editor from the CSNs already accepted for the call. Your own filing identity comes from the Shipping line filing card in Settings, which an Org Admin fills once. The wizard only builds the file: it hands over to the same editor that checks, signs with your DSC and sends every other manifest. One thing to know before relying on it — no manifest built here has yet been through customs, so check the first one line by line. It is written up at /help/starting-a-vessel-manifest.

It depends on how late you are, and the step that matters is the line’s, not yours. Before the line files its SAM: file your CSN and give the line its number and date — the SAM then quotes it and your house bills appear. After the SAM: ICES Advisory 37/2026 has the shipping line add the house bills by amending its own manifest (an SAA — “splitting of BLs”), against your CSN number and date; an officer’s approval is needed only once the vessel has been granted entry inwards. ICES Advisory 38/2026 (21 September 2026) then says what that amendment is: where you filed a CSN, the line first drops (deletes) the straight master bill line it filed, then re-adds the master bill as a consolidated one linking your CSN and house bill references; where no CSN was filed, the line puts the full house bill details into the SAA itself. The process CBIC’s SCMTR team has described to the trade — reported, not published in any notice — adds the three timing windows (before the SAM; after it but before the vessel berths, where no officer is needed; after entry inward, where the officer approves), and an SAA filed on top of an untouched SAM is the likeliest reason an amendment “goes in” and nothing changes. That process says only “delete SAM”, which alarms people; on our reading it means your bill’s own line dropped and re-added, not the manifest withdrawn — the procedure the advisory describes for this case, and the only thing SACHM23 could mean, since the message set has no message that withdraws a manifest. The advisory itself never uses the phrase. Phrase the request that way and it lands better. Only the person in charge of the vessel can amend a manifest, which is why this is a request to your line and not a filing of yours. On any accepted CSN here, Send CSN reference to the carrier produces the card the line needs. The whole sequence, what the line’s amendment may carry, and what it costs are at /reference/console-house-bills-onto-the-manifest.

370 is “redundant house details”: the manifest line says its cargo was declared before — it quotes a CSN or a CIN — and its house bills repeat detail that earlier declaration already holds. On the two refused amendments on record, the house bills carried the transport document (the parties and ports) and the item details; the 118 on each house bill is the same problem seen from the house bill’s side, not a second fault. There are two ways out. The first follows ICES Advisory 38/2026 (21 September 2026), which says only that the line re-adds the master bill “configured as consolidated, linking the reference details of the CSN and House BL”; what a house row then carries is customs’ own Trade Scenarios table’s shape and our reading, not the advisory’s words: its reference, its prior reference, its customs location and its containers, with the transport document and the item details excluded. Thinning the house bills to that is what the table asks for, though no filing on record here has yet been accepted in that shape. The second is to drop the house rows and let the line quote the forwarder’s CSN alone — the one shape that has been seen to pass customs’ checks, and what Add a line from a CSN builds. The Checks tab stops a send that carries either of the two refused blocks and offers to take exactly those off.

Because the amendment addressed a line or a container by a number customs does not hold it under. Customs finds what an SAA updates or removes by its line number, and a container by its line, sub-line and sequence number — not by the bill of lading or the container number beside them — and those numbers are the ones on the manifest customs holds now, every accepted amendment included. 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. 749 is in no published list; its published sibling 306 says the same of a line. Open the manifest as customs holds it and build again from that. Here, Build the amendment asks customs’ public record where it holds every line the amendment changes or removes, and will not sign one whose line or container numbers differ; a line declared as split cargo, a bill on nobody’s record and an enquiry that did not answer never block, and the panel says so. The Checks tab also compares your file’s numbering with customs’ and says when the two disagree. 748 is the same code for a cargo item, with a second cause worth checking first: a line that quotes an earlier declaration (previous declaration Y) carries no item details in customs’ Trade Scenarios table — the CSN it quotes holds the goods — so an SAA that updates an item there is refused even on the right line, as one was in September 2026. Take the item details off that line and correct the goods in the CSN; Build the amendment leaves them off such a line and says so. Detail at /help/amending-a-vessel-manifest.

The amendment added a box to the vessel’s container list under a sequence number the manifest customs holds already uses for another box. The code is in no published list; it was seen in September 2026 on an SAA adding a late bill with its ten containers, which gave them the places they would take in a list sorted from scratch — 10, 152, 458 and so on — on a manifest of 1,025 boxes. Every real SAM and SDM on file numbers its vessel list 1 to N, and the real amendments on file add at N + 1. So number every added box from N + 1 upwards, N being the declared total before this amendment with every accepted amendment since, and send it under a fresh job number; nothing else in the file refers to those numbers. Opened here, the Checks tab finds it before sending and Number the added boxes fixes it in one press. Once an accepted reply for the call is on file here, the added boxes are numbered past the list customs holds, not past the file’s own, and an added number inside that list stops the upload. Whether customs reuses a number freed by an earlier deletion is not yet known.

One line, not the manifest. The SACHM23 message set has no message that withdraws a manifest — its six events are SAM, SAA, SDM, SEI, SDA and SDN — so when a forwarder asks you to “delete the SAM” before filing an SAA for their console, what can actually be filed is an amendment (SAA) whose line for that bill carries amendment type D, telling customs to delete that line from the manifest it holds; the rest of the manifest is untouched and not re-sent. Since ICES Advisory 38/2026 (21 September 2026) that is customs’ published procedure, not only our reading of the message set: to put a forwarder’s house bills onto a master bill filed straight, the line first drops (deletes) the straight bill line it filed and then re-adds the master bill as consolidated, linking the CSN and house bill references — and the message set says the same from the other side, since no SACHM23 message withdraws a manifest. The advisory goes further: a line’s consolidation indicator (straight to consolidated or back), its consolidator PAN and its previous reference (a CSN, PCIN or MCIN) may not be changed in place at all — the system refuses the update — so any such change is the line dropped (D) and filed again (S). Here, open the manifest customs accepted on Shipping line filing and find the bill. To have it quote another CSN, press Quote another CSN on its row: a dialog asks customs’ public record for every CSN on the bill, you pick the one to quote, and when you add it the line comes off and the bill comes back under a new line number with the bill date, packages and boxes that CSN holds — Cancel leaves the line as it was. To take the bill off altogether, press Remove — the editor says that this is how you delete the SAM for one bill. Then build the amendment. A removed line’s number is not reused, so one SAA carries the D and the S; and the amendment builder refuses to build an in-place update of those three fields, asking you to remove the line and add it back instead. Customs has accepted the drop and the re-add in one SAA: a Kolkata amendment of October 2026, filed after entry inward, removed the straight line whole — its containers and route legs marked D — and re-added the bill consolidated. Before entry inward no officer is involved; after it, you file first and the jurisdictional officer approves afterwards, for a ₹1,000 fee, and the dialog says which window you are in — or “not checked” when customs has not been asked. Step by step at /help/amending-a-vessel-manifest.

Open the manifest and press Check with ICEGATE. It asks customs’ public record, bill by bill, which lines already carry an accepted CSN and how every field the two can be compared on agrees with your manifest — each difference marked Fix (customs has refused filings for it: bill date, packages, container count, load status), Check (should match) or OK to differ. The lookups are batched and paced so a large manifest never overloads ICEGATE’s public enquiry, you can stop them at any point, and the results are saved with the manifest. A bill with no CSN yet is reported as absent, which is the ordinary case for a manifest filed early — never as an error. A lookup that actually failed is reported as an error, and the two are never conflated.

Put the SAM beside the ACK. A SAM rejection names most rejected lines by number alone — the first real one rejected 114 lines and printed a bill number on two — so the ACK on its own cannot say which bill, container or CSN a rejection is about. Drop the SAM you sent (the file ending _DEC) together with customs’ ACK (_ACK) on Shipping line filing or SCMTR JSON upload, or open the SAM and add its ACK there. The two files are compared first: when they are the same send — sender, reporting event, port, job number and job date all agree — every rejection is shown on your line of that number, with its bill, what happened, what to do and customs’ codes underneath. An ACK to a different upload of the same VCN is shown only where it names the bill, and is marked as that upload’s; an ACK about another call puts nothing on your lines. Rejected lines your file does not hold are counted rather than guessed at. Both files are read in your browser.

Yes. Open the PDF, select all, and paste the whole thing once. It reads the container and its seal, the packages, the weight, the HS code, the goods description and the discharge port, then shows you every value it proposes — grouped by the step each belongs to — before anything is written. Nothing you have already typed is overwritten. It works on bills that lose their captions when copied, because it recognises values by shape: a container by its ISO 6346 pattern, a party by the GSTIN inside it.

Because a bill of lading does not carry what the message asks for. The CSN identifies a voyage by the ship’s seven-digit IMO number and by the VCN customs issued for that call at that port; a bill names the ship and numbers the voyage the carrier’s own way — “MAERSK CAMEROUN/629W”. Writing that voyage number into the conveyance reference would look filled in and correct while being the wrong identifier entirely, so the paste reports both values rather than writing either. It does not leave you to retype them: the ship’s name is handed to the finder and searched, and picking your hull out of the results is what writes the IMO.

Two things one document cannot give you. First, where the two bills disagree — listed plainly, and separating “the same value written differently” from “these are genuinely different values”. Neither is reconciled for you, because quietly normalising them hides a real data error as often as it fixes a typo. Second, who the consolidator is: the party that is the master’s consignee and the house’s agent at destination, which is what the container agent code follows from.

Yes. Drop the bill of lading as a PDF for reading and it opens in a panel beside the guided steps — docked to the side on a wide screen, a sheet that slides over the form on a narrower one — with Show the bill / Hide the bill at the top of the steps. It can be zoomed and rotated and its text copied. Every value read from the bill shows the page it came from, and that page mark is a button: press it and the panel jumps to that page, so a figure is checked against the document without a second window. The panel shows the PDFs you dropped in this sitting; after a reload, drop the bill again to see it.

The master shows a roster of the house consignees underneath it, so a bill that names nobody the master knows about is visible at a glance. Each house bill shows which of its parties still match the master and offers to copy the consignor down rather than have you retype it, and the container agent follows the master’s consolidator. The house B/L date is asked for on its own — it is not copied from the master, because the two documents are genuinely dated differently.

No. HS codes, UN dangerous-goods numbers and IMDG classes, package types, UN/LOCODE world ports, Indian customs locations, vessels by IMO, and carriers by SCAC or MLO code are all searchable inside the fields that need them. The lists answer locally where they can and fall through to DGFT and UNECE where they cannot, caching whatever comes back so the next filer gets it instantly.

A foreign principal never registers or files in its own name — the entity that registers with ICEGATE and files under SCMTR is always the Indian agency, so the customs identity on your filing belongs to that agency rather than to the overseas parent. For the shipping line code itself, CBIC published a directory of foreign lines covering most major container carriers, but it is a dropdown inside logged-in ICEGATE at registration time rather than a file you can download. When the line you chartered is not on it, the published answer is to enter the commercial code BLK, which was created for bulk cargo and which CBIC has confirmed publicly as the fallback for an unlisted line. Separately, if you go looking for ICEGATE’s public CODES directory of shipping line codes and get a server error, that is the service being down rather than anything wrong with your access — codes are allotted case by case by the Customs System Manager, not self-served.

There is no directory to search a company name in, and you rarely need one. Characters 3 to 12 of any GSTIN are that party’s PAN by construction, so a carrier invoice, delivery order or arrival notice showing a GSTIN is showing you the PAN exactly — and pasting a party block off the bill of lading pulls it out for you. To check a PAN you already hold, the GST portal’s Search Taxpayer by PAN and DGFT’s View Any IEC both return the registered name; neither works backwards from a name. The container agent code is a different question that is often mistaken for this one: it names whoever is responsible for that particular container for customs debit and credit — the consolidator on a consolidated bill, or the container’s owner when it is shipper-owned — not the shipping line operating the vessel. It comes off your paperwork and the commercial arrangement over the box, and no public register holds it. It is never mandatory in any reporting event, so leaving it blank is safe and far better than guessing a party who would then be recorded as responsible for the container.

Every field carries its own help text drawn from the MIG, and the SCMTR Assistant is available on every page — signed in or not — to answer questions about fields, codes, deadlines, and rejection reasons. It answers only from our SCMTR reference material; while it works it names the pages it is reading, and Sources under the answer lists the pages it drew on, so you can check it. It offers general information, never customs advice.

Yes. Any filing can produce a print-ready Sea Cargo Manifest Checklist with a tick box against every block — for checking line by line against the carrier’s paperwork, or stapling to the job file. It is also included when you share a declaration by read-only link.

Yes, and it needs no ICEGATE credential of your own. SCMTR JSON upload, at the top of your CSN filing page, takes any file from a customs filing — a SACHM22 declaration you downloaded here, one a partner sent, one assembled by hand, an ACK, or a whole SACHM23 shipping line filing. It works out which it is and opens the right view: a filing is laid out as a readable filing rather than raw JSON and checked against the reporting event’s own field rules, with every problem listed and the block it belongs to named; a manifest opens as an editable table of its lines. Nothing is submitted, and a CSN is never added to your filings unless you import it. A declaration or ACK you upload is kept for seven days so support can look at it if you ask about a rejection, then deleted automatically — only a platform super administrator can open it, every opening is recorded, and you can ask for it sooner; a manifest is read in your browser and never sent to us at all. It is the quickest way to find out whether a file is sound before it goes anywhere near customs.

Yes, on any CSN you open on SCMTR JSON upload — including one made in other software, which never met the voyage check this platform runs before signing. After the rest of the result is on screen, the VCN is compared with the calls customs currently lists for the ship, asking customs again unless it answered about that ship in the last fifteen minutes. It is amber where customs lists a different call of the ship at your port, has stopped listing the call, or lists it at another port — and where the call the file names had already arrived before the file was made while a later call at the same port is nearer the file’s date, which is how last voyage’s VCN looks on a ship that calls every week or two. That last rule is drawn from one live enquiry, and it can be amber harmlessly on a weekly feeder whose CSN was filed a few days after berthing, so compare the arrival notice before changing anything. A VCN customs has not listed yet is said neutrally, because it is often timing, and a file dated before the span customs’ answer covers is not judged at all. It is advice, never a rejection: only ICEGATE decides whether it accepts a VCN. If an amber line is right about an accepted CSN, an amendment will not fix it: ICES Advisory 37/2026 (18 September 2026) excludes the VCN and rotation number from a CSN amendment, so raise it with the shipping line and your jurisdictional customs officer as early as you can — before another party’s CSN against the master bill is accepted, which closes your CSN to any change (320), and before the line’s manifest and then Sea Entry Inwards narrow what is left.

Yes — that is the same drop target, and it needs no ICEGATE credential either. Drop the ACK (the file whose name ends in _ACK.json) on SCMTR JSON upload, at the top of your CSN filing page. If it answers one of your own filings, the outcome is recorded against that filing on the spot and explained against what was actually sent; if it answers a filing made somewhere else, it opens in the checker, which reads the verdict and what follows from it, then takes every error in turn: what ICEGATE’s code means in the MIG’s own words, where in your filing it sits, whether it rejects the whole filing or names one value, and numbered steps for fixing that particular code. Add the declaration it answers and each error is marked onto the block it names, with the offending value quoted back at you. The one rejection that names nothing — 700 Error-Refile, which appears nowhere in ICEGATE’s own code table — is answered with a four-step checklist run against your file rather than a shrug. If you are already on the filing, drop the ACK onto it instead — from its row’s menu or its Status card — and the outcome is recorded as it is explained.

Often, yes. Drop the CSN on SCMTR JSON upload and press Check with customs: it asks customs’ public record — the same enquiry the tracker uses — whether it holds a filing by your PAN on each master bill, and compares what it holds with the file. Green: customs holds this version, with the filing date and CIN, and every value the record carries agrees — ports, movement, transhipper, weights, packages and containers; it says nothing about parties or goods text, which the record does not publish. Amber: customs holds a different version — usually a draft that was corrected before it went, or a later amendment. Every answer lays your file beside customs’ record value by value, in plain field names, with both dates, differences first. Grey: the record is a copy made from a filing customs already holds, or holds nothing by your PAN, in which case the filing was rejected, never sent, or filed under another port or date. For a file checked here it reads a public page and decides nothing; only the ACK does (a filing sent from SCMTR is read off the same record under stricter conditions, and can turn accepted from it). Nothing is asked until you press the button, one check covers at most six master bills, and Check again opens two minutes later.

Usually you will not have to: since 22 September 2026 the platform reads ICEGATE’s public record for every waiting filing about every fifteen minutes, and a fresh filing customs accepted turns accepted here on its own, with the CSN number and date, once the record names your transmission and agrees with what was sent. To ask on the spot instead: once the filing’s page shows that customs holds it, a Get the CSN number button asks ICEGATE’s public record about the filing exactly as it was sent. Since September 2026 that record carries the CSN number itself (filings accepted before then may show none); where it does not, your organisation’s own ICEGATE portal login is asked, if an admin has saved one. If customs holds this very transmission, the CSN number and date are recorded and the filing turns accepted, marked in its history as read from ICEGATE’s own record. If customs names a different transmission, or cannot say, nothing changes, and the ACK file can still be recorded when it arrives. Only the filing’s creator or an organisation admin can press it. Emailing a CSN accepted this way still shows the cargo identification number customs gave, on the bill it belongs to.

No — on an export, change the port of receipt. An export moving on to a foreign port is TC, and EX with LC is a pair customs’ own trade-scenarios table does not list, so switching the movement draws 115 instead. The port of receipt on an export is where the cargo is received abroad: the same code as the destination port, not the Indian port it leaves from. The same filing was rejected 091 for an itinerary whose only leg ran from Kattupalli to Kattupalli — an export’s leg runs to the foreign port — and a sibling attempt drew 159, “Incorrect Cin Type in MC”, for saying it referred to a shipping bill without naming the CIN. The platform rejects all of these shapes before they are sent — and the other export refusals seen since, 286, 383/384, 239 with 381, and 709 — and names the code each time.

The one carrying the same control number. Customs answers an upload, not a consignment: a filing that was rejected, corrected and sent again is two uploads, — a refusal frees its control number, so a corrected file may go again under the same one, and often does; a send that was accepted or is still unanswered needs a new one — so two replies come back, both naming the same vessel, the same master bill of lading and often the same error. The CSN left in the folder is usually the first attempt, because the corrected file was sent and never saved. Compare the job-number segment of the file names, never the date one: ICEGATE stamps its reply with the day it answered, so a filing sent late on the 4th comes back named for the 5th and that proves nothing either way. SCMTR JSON upload checks this for you before it explains anything, and rejects a pair that is not the same filing rather than positioning every error on a document customs never saw. Where the two disagree only about which upload they are — same sender, same event, a master bill of lading in common — it says so and names both job numbers, so you know whether to go and find the other CSN or the other ACK.

From the filing itself — Email, on the filing’s page or in its row menu on the CSN filing page. It sends a submission alert carrying the declaration and the ACK as attachments, named exactly as ICEGATE names them so the recipient’s own systems file them correctly, over a table of every bill of lading on the filing with its date, destination, packages, weights and the consignment id customs assigned it. Paste addresses straight out of Outlook: display names, quotes, semicolons and line breaks are all understood, and a contact your mail client pasted without an address behind it is shown in red and blocks sending rather than being dropped — so the list you send to is the list you addressed. Replies come back to you rather than to us, you are always copied, and the addresses you use are remembered privately to you for next time. The message reports what the record actually says: an acceptance, a rejection, or a filing whose ACK has not arrived — never only the good news. It is offered on an arrival notification (SCE) that has been sent to customs — the event the outside world acts on — and on an amendment to one (SCA) once it has been sent, which when accepted carries its own CSN and supersedes what those same people were told. The amendment says so in its subject and states plainly that the details replace the ones sent earlier, so the two are not mistaken for duplicates. Your own housekeeping — a deletion, a departure, a CIN update — is not mailed.

It opens a page showing the same record the email carries, the ACK explained in plain English instead of raw JSON, and both files to download — no sign-in, which matters because the recipient has no account. It shows the consignment record, not your whole filing: the authorised person’s details, submitter codes and the full message are not on it, and search engines are told not to index it. The link is unguessable and expires after 30 days, and each message gets its own — so Withdraw link, in the Sent to section of the filing, closes that one message’s page without touching a link you sent someone else last week. It cannot recall the email; the attachments are already in their mailbox. The same section tells you how many times each link has been opened and when, which is a real answer to a question normally settled by telephone — though it counts opens of the link, not whether the message was read.

No. A CSN has no field for a transhipment permit anywhere — an ICD movement is declared entirely by cargo type IM with cargo 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 with its bond. The Sub-Manifest Transhipment Permit is the gateway port’s permit, and CBIC Circular 46/2005-Cus says where it comes from: it 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, so a counterparty asking you for one is asking the wrong party. Under SCMTR the inland leg is not a permit at all: the authorised transhipper files Customs Inland Manifest arrival and departure declarations per vehicle and links them by the cargo identification number. One trap — ICEGATE’s own abbreviation list expands SMTP as Simple Mail Transfer Protocol, its e-mail filing channel, so check whether the sentence is about cargo or about a file.

Every field label carries a small ? beside it. In the form it opens the same guidance shown under the label by default; in a filing you are reading — a locked filing, or a file opened with SCMTR JSON upload — it tells you what the field is, its key in the JSON (mstrBlNo, consolidatorPan…), whether the reporting event makes it mandatory, and the wire format where the screen has re-formatted the value, such as a date the file carries as YYYYMMDD. Hover it with a mouse, tab to it from the keyboard, or tap it on a phone, where it opens as a sheet from the bottom of the screen. Block headings, table columns, badges and an ACK’s terms — CSN, MCIN/PCIN, transmission id, error code — explain themselves the same way. If a tip does not answer the question, the assistant on this site does, from the same reference material.

Your software wrote the pre-SCMTR Sea IGM: a text file beginning with an HREC header record and carrying <consoligm> and <conscargo> section markers, which ICES took before SCMTR. It is not JSON and no SCMTR door reads it. Under SCMTR the same cargo is reported as a SACHM22 CSN by the forwarder or agent, or a SACHM23 SAM by the shipping line, both JSON files whose names begin F_SACHM22_ or F_SACHM23_. Export the filing in that format from your software, or build it here, and drop that file instead.

Read the line and column it names. A parser reports a character position; the checker turns that into the line, the column and the text around the fault, so you can search your own file for it. On a real file in September 2026 it was one missing comma between two fields, 49 KB into a 76 KB file. Fix it in the software that wrote the file rather than by hand, or the next file will carry the same fault, and drop the file again.

The number 20, found in the voyage details. A vessel-manifest reply can put a three-letter block prefix in front of an ordinary SCMTR code: VGD is the voyage details, VSL the vessel, MCR a master bill’s reference, MTE its containers, HTD a house bill’s transport document, and so on, as ICEGATE’s own filing FAQs list them. The prefix says where the fault sits; the number is the code to look up. The checker reads VGD020 as 20 and MTE749 as 749. The custodian and transhipper codes (CDB01, TMB03) are letters-then-digits too and are not this: those come from their own lists.

Chennai customs (Preventive Commissionerate, Chennai-III) set up an SCMTR help desk on 23 September 2026 by Public Notice 130/2026, and allocated officers by vessel: four pairs take named vessel calls and a fifth takes all other vessels and consolidation work. 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, sent straight away to your vessel’s officers — the tracking ID ICEGATE gave the transmission, printed as uniqueId in the acknowledgement’s header and shown here as Tracking id. A bill or job number does not let DG Systems find your message. The notice changes no filing rule, and other ports have published nothing like it that we hold. The officer table is at /reference/chennai-scmtr-help-desk.

The four-character ISO size/type code printed on the container’s door, or on the shipping line’s paperwork for that box — 2210, 4510 and so on — not booking shorthand like 40HC or 20GP, and not another line’s equivalent. Customs publishes no list for the field, so the app reads the code back under the field as one container terminal’s own list names it (4510 is 40 ft dry, 9 ft 6 in high; 4400 and 4410 are 9 ft high on that list, not high cubes), and turns amber on shorthand. Neither note stops you filing: no refusal on record names shorthand, but no accepted filing on record carries it either, and the shipping line’s manifest is compared with the code for the same box.

No published one, as of 24 September 2026. The manifest guide’s own list was replaced by the CSN’s in March 2025, with eight manifest-only codes (369 to 379) added that May, and a manifest reply writes a block prefix in front of the same number — VGD020 is 20 in the voyage details. The unpublished 7xx refusals (700, 705, 707, 748, 749, 753) exist only in real acknowledgements. ICEGATE’s advisories index, the 2026 port notices, the carriers’ advisories and the third-party code pages were all read again for the manifest family alone and none adds a code; the Reference section’s “Which error list does my code come from?” has every list.

That is the carrier’s own window, and it is the one you meet first. Maersk’s customer advisory of 2 September 2026 — the carrier’s words, not customs’ rule — takes an export amendment request from the SDM filing up to departure plus five days, and an import one from the SAM filing up to Sea Inward Entry and no later than eight hours before ETA. Its reasons for turning a request away are its own, not error codes: a mistyped PCIN, a scanned or unofficial shipping bill on ODeX, a split shipment without the revised shipping bill, identical house and master bill numbers on an import, and a shipper-owned container whose owner’s PAN is not on the customs bond. Where the carrier’s window is shorter than customs’, the carrier’s is the deadline; where it is longer, customs’ still applies.

They come from two different stages, and only one of them uses error codes. Structural validation runs first: a file malformed against the schema comes back as an _SFL.json carrying JSON-Schema vocabulary — maxLength, pattern, required — and no numbered code at all, which is why looking one up finds nothing. Business validation runs only on a file that passed structurally, and that is where every numbered error code comes from, in an _ACK.json. If you are hunting for a code and there is none, the file did not get far enough to be business-validated. Both are readable on the same screen, which tells you which one you have.

Yes, in one specific way. A transhipper’s allowed-for-shipment request carries the cargo identification number your accepted CSN earned — the PCIN or MCIN — and customs rejects their request when that number is missing (code CDB05) or does not resolve (CDB06). Both point at your filing, not theirs: either the CSN is not accepted yet, or they were given the wrong number. Their other codes are their own — an insufficient bond balance is the transhipper’s bond and nothing you file changes it. If instead someone asks you to file a transhipment request or a stuffing report yourself, that is a registration mistake at their end: a forwarder or consolidator is registered to file the CSN and nothing else.

A shipping line filing is SACHM23 — the line’s own filing, not yours — and every field it can carry is documented from ICEGATE’s published guide: the vessel’s registry, tonnage and nationality, the voyage and its itinerary, every master and house consignment block, persons on board, ship stores and crew effects. Open the file on SCMTR JSON upload and it becomes a searchable table you can correct line by line; the reference page lists each field with its JSON key and marks the ones the editor puts on screen. Note that a manifest and a CSN share many field names without always sharing the meaning, so read the reference for the message you actually hold.

Two messages produce the inland leg, and neither is yours to file. A transhipper files TRCHE01 — the allowed-for-shipment request before the cargo leaves the port of call, then an inland departure and an inland arrival for every vehicle carrying it. A custodian files CUCHE01 — stuffing, stuffing cancellation, stripping, and the yard’s arrival and departure timings. Drop the file on SCMTR JSON upload and it is read block by block — the message and its reporting event named in words (a stuffing report, an allowed-for-shipment request), every field labelled and explained from ICEGATE’s own guide, and anything neither guide describes shown with its raw key rather than dropped. Keep it and it is offered back next time. The same material is in the Reference section: 69 fields across ten blocks for the transhipper, 63 across nine for the custodian, each with its JSON key and what the guide says it holds. It is read-only, and deliberately so — each goes to customs under its own party’s registration and bond. Their consequences still reach you, most often as a rejection quoting the cargo identification number your CSN earned: CDB04, CDB05 and CDB06 on their ACK mean the PCIN your CSN earned is missing or does not resolve on their message, and those codes are explained here too.

Probably another system’s. ICEGATE is one gateway in front of several customs systems, and each answers from its own error list: the CSN and shipping line filing share one numbered table; the custodian and transhipper messages use alphanumeric codes such as TMB03 or LCB08; the legacy Sea IGM, Consol IGM, ICD IGM and the Bill of Entry each have a numbered list of their own, where the same number means something different. The message id in the reply says which — SACHM22 or SACHM23 is SCMTR, CACHI01 is a Bill of Entry, SACHI01 a Sea IGM. 994 itself is, as of September 2026, in none of the eighteen lists ICEGATE publishes; every list’s 99x band is a system-side error, and the one filer who reported it had it on a Bill of Entry. Keep the reply exactly as received and quote its control number to the ICEGATE helpdesk rather than editing anything on the strength of it. The Reference section’s “Which error list does my code come from?” has every list. A code in the SCMTR band that is in no list at all is a different case: customs writes those in the published codes’ words — 748 and 749 say “Not Exists For Update/Delete” like the published 306 — so read the words in your reply; the checker here does, and says when a reading came from the wording rather than a published description.

Both, and they mean different things. Every check the platform makes is reported in one of two tiers. Red — “issues”, “to fix” — is the message format itself broken: a mandatory field empty, a value outside its coded list, a total that contradicts the rows it counts. Customs rejects those, and Sign & upload will not send a filing carrying one. Amber — “to check” — is a filing that is well formed with something unusual in it, and for each of those either no ACK anyone has shown us mentions it, or the practice appears in filings whose outcome nobody has ever seen. Amber blocks nothing and never will on its own. So Valid means every rule the format enforces is satisfied; the amber list is what is worth a second look before you send. Each amber message says what the evidence for it actually is, because a warning presented as a verdict sends you to change a field that was fine — and on a filing of a hundred containers it buries the one line that matters.

No — clear the field rather than typing 0, if you take it off at all. Container weight is optional, and every weight in this message is positive by nature, so a 0 is rejected as a typo. But the more useful answer is that you probably should not change it: every empty-container filing anyone has shown us declares the box’s own tare weight, which is why this is amber rather than red. ICEGATE does publish error 128, “Weight > 0 for Empty Container”, and none of those filings has an ACK beside it to say whether customs minded — so the honest position is that nobody knows, and we say so instead of picking a side. The package count on an empty box is 0 everywhere it appears, and that is accepted; note that ICEGATE’s own list also carries 295, which says the opposite. If you ever receive an ACK for a filing of empties, accepted or rejected, we would very much like to see it.

For an acceptance it no longer matters much: since 22 September 2026 the platform reads customs’ public record for every waiting filing about every fifteen minutes, and a fresh filing sent from here turns accepted with its CSN number and date once the record names your transmission and agrees with what was sent — even one that came back without a tracking handle, which the record supplies. A rejection is the case to watch: it never appears on customs’ record and arrives only by email, to the address your ICEGATE registration is under — so a filing still submitted hours after its siblings were accepted is one to look for in that mailbox, and it is worth knowing which mailbox that is before you need it. When the email does come, drop the _ACK file it carries onto the filing — from its row’s menu or its Status card — and the outcome is recorded and every error explained, with where to fix it; with only the email’s words, any team member can record what it says. Statuses only move the way a real ACK would have moved them, so the record can never be walked backwards into saying something untrue.

Drop the attached file — the one whose name ends in _ACK.json — onto the filing itself: Upload ACK in the row’s menu on the CSN filing page, the Status card on the filing’s own page, or SCMTR JSON upload at the top of the CSN filing page, which finds the filing from the file. That records it for a filing sent from SCMTR with Sign & upload. Dropped on a filing, it is rejected if it answers a different job (and told which); dropped on the CSN filing page, one that answers none of your filings opens in the checker and is explained there, with nothing recorded. Otherwise the status, CSN and details are set from the file, it is kept on the upload it answers, and every error is explained against the payload that was actually sent — the value customs saw, the fix, where the field sits on the form — ending in one button, Refile, that opens a corrected copy going out as the next attempt under the same job — or, on an acceptance, a note of what is still owed. An acceptance granting a CSN another of your filings already holds is rejected, and names that filing. A draft kept here that you filed on ICEGATE yourself, or a filing made entirely elsewhere, is recorded through Record a filing made elsewhere on the CSN filing page instead, with the file you filed and its ACK: dropped on its own, the ACK is explained but not recorded, because the draft may have changed since it was downloaded and what goes on record has to be what customs received. If the outcome is already recorded, nothing changes and it says so.

Because a dropped manifest is looked up against your organisation’s saved ones first — by ICEGATE’s six-part file name, or by the voyage if the file was renamed. The same file, as it arrived or as you last saved it, reopens the saved copy with its corrections and customs answers rather than creating a duplicate. A newer file of the same manifest asks: replace the saved copy with it (corrections discarded, customs answers kept only for lines that are byte-for-byte unchanged) or open the saved copy instead.

Yes — and more than that. BL tracking asks ICEGATE’s public enquiries together: give it a master bill of lading number and a port and it shows every CSN customs has accepted against the bill (from the moment of acceptance, days before the vessel arrives), the carrier’s arrival manifest once it exists, and the vessel’s entry status — read as one shipment, with facts the filings agree on stated once and any genuine disagreement between filers flagged. A lookup that finds nothing shortly after filing means “nothing accepted yet”, not “wrong”. This is customs’ own record, not live GPS container tracking — for the box’s physical position the page links you to the carrier’s tracking with the number ready.

Yes. Customs’ public record — CBIC’s September 2026 CSN/SAM/SDM tracking facility — lists every accepted filing against a master bill: who filed it, when, and the container and package figures they declared. Signed in, Customs lookup (under ? in the header) answers it on its own page and also tells you whether the master is still open to you — because another party’s accepted CSN is exactly the event that closes your amendment window, and the line’s accepted manifest is what takes a deletion and a fresh CSN out of your hands (ICES Advisory 37/2026). Anyone without an account gets the same public record on BL tracking.

Because the other party on your master bill — usually the shipping line — filed their own CSN, customs accepted it, and on the fields customs cross-checks between the two filings their figures differ from yours. The platform watches customs’ public record for your filed bills and mails you once per disagreement, while the window to fix it is still open: the shipping line’s manifest is checked against both filings, and once their CSN stands against yours customs rejects any amendment of your CSN (error 320). Since ICES Advisory 38/2026 customs says the container ISO code is validated on the line’s manifest only; whether that is the size-code comparison between the two filings is our reading, the advisory names no codes, and nothing on record shows it either way — so keep the code right on your CSN regardless. The email lists the differing values side by side and links to your filing; if your figures are wrong, amend now — if theirs are, tell them, because their filing is the one that has to change.

Because customs’ list of calls for your ship now gives a different expected arrival day for the call your filing names than it did when you last worked on the ship and the call. The platform keeps the day a call moved from rather than overwriting it, so it emails you once per move — for a draft or a filing already sent — with both days, marks the row on your CSN filing list Arrival moved, and shows the filing’s ETA with the day it moved from. Nothing needs amending: the CSN carries no arrival date, and the call is still the same call. If the move is large, ask the carrier why, because a long slip can be the start of a roll or a substitution, and those do change your filing. Two honest notes. The day is the port’s record of the call, a day with no time, not the shipping line’s schedule. And as of September 2026 nobody has yet seen customs revise an expected arrival day at all — the email was built partly to find out whether it does — so an email is new evidence, and no email is no promise the ship is on time. The public BL tracking page shows the same expected arrival for the call a CSN on the bill names, which makes its link the one to send your customer.

Usually neither, yet. Customs’ public record shows a CSN only once customs has accepted it, and the shipping line files its SAM before the vessel arrives, often only days ahead — so an empty result early on is the ordinary state, not a verdict on your filing. What an empty result cannot tell you is whether the port and the bill you looked up are the ones you actually sent, and that is the question that matters most when nothing comes back. So the empty result carries the same drop target as a full one — Is this what you sent? Drop the CSN file the bill was filed in and it opens on SCMTR JSON upload, where Check with customs lays every bill in the file beside customs’ record, not only the one you looked up: the port and bill as the file names them, each value that differs, and whether customs holds a later version — or a plain statement that customs holds nothing yet against exactly what you sent. Signed out, you are asked to sign in first and the file is carried across with you. Before anything else, check the port code and the bill number character by character; a bill typed with a space, or a letter O for a zero, is the commonest reason a real filing looks absent.

Probably not — look at the house bills first. The older enquiry lists a consolidation by its house bills, each on the IGM line it was mapped onto, and a house bill declared as transhipment (cargo movement TC, onward to a foreign port) is not imported at this port and gets no IGM line. When every house bill under a master is transhipment, the older enquiry has nothing to list and answers “No details found”, although the shipping line’s SAM holds the master and customs has issued its MCIN. This was measured on one Nhava Sheva manifest in September 2026 — every locally cleared house bill had an IGM line and none of the eighteen transhipment ones did — and is not a statement from customs. Look the bill up on the New SAM/IGM enquiry, or in BL tracking here, which says so under the house bills: if they are all TC, nothing is missing. A house bill cleared locally (LC) with no IGM line once the rest of the vessel has one is the case to take to the line and to customs, with the MCIN and CSN numbers in hand.

Yes. Any BL tracking result carries a Share control — the link itself, a QR code, and your phone’s own share sheet where the browser offers one. The link encodes only the port and the bill number, nothing private and no sign-in, so it can go straight to a customer or a colleague’s phone and opens the same public lookup for them. The printed filing checklist carries the same QR, so whoever is holding the paper can scan straight to the live customs status.

Yes, for most lines. Put the master bill of lading into BL tracking and press Find the arrival (the port is optional), or open the CSN on this platform, and the Arrival card shows the day the ship is due at the Indian port and the route. For SITC, HMM, ONE, MSC, COSCO, Evergreen, Yang Ming, KMTC, Sinokor and Cordelia the date is read from the shipping line’s own tracking, and says whether it is an estimate and when it was last checked. For other lines, such as Maersk, Hapag-Lloyd, Wan Hai or OOCL, their sites cannot be read automatically: the card opens the line’s tracking and your team can add the ETA it shows, marked as entered by you. Customs’ day for the call is shown beside it when customs has it, but in the calls watched so far customs has not moved that day for a ship running late, so plan on the line’s date. A consolidator’s own master bill is not in any line’s tracker; search it with its port instead. A house bill is tracked by the master bill it sits under.

Yes. VCN search takes a ship’s name, its IMO number or a VCN, and shows the ship’s calls at Indian ports: each VCN with its port, rotation number and expected arrival, and when customs last listed it. Signed out, it now asks customs directly for you, the same as a signed-in search, so a ship nobody here has asked about before is usually still found — not only the ships already on record. Type the whole name as the bill of lading writes it: a voyage after a slash is ignored, but part of a name is not matched. A VCN is found only where its ship’s calls are already on record, because customs publishes calls by IMO number and cannot be asked which ship a VCN belongs to. When a VCN on record has since been dropped from its ship, the page says so, which is the strongest sign of a substitution. This is customs’ published list of calls, not a berthing schedule or the ship’s live position.

Only rarely: after your network has searched enough in the last ten minutes — about eight ship lookups from one address — that its free allowance to ask customs directly runs out, and even then only if what it falls back to has nothing still to come. Signing in is not what lets the search ask customs; it already does that signed out too. What signing in buys is a bigger allowance kept to your account instead of shared with everyone on your connection: either way, a search by IMO number or VCN asks customs about up to three ships and reuses any answer customs gave in the last fifteen minutes, and a search by name asks about every ship it finds, up to five, reusing an answer from the last twelve hours — a signed-in account gets about twenty such lookups in ten minutes rather than eight. If customs still lists no upcoming call once asked, that is normal for a ship some way off: a VCN is issued only days before arrival, so check again closer to the date. Everything shown carries the date customs last listed it, so you can judge how old it is.

Yes. A VCN exists only once the port registers the call, usually days before arrival rather than months, so a filing prepared early often has no number to pick or to type. On the ship step of the guided steps, once the ship is chosen and the reference is still blank, tick “The port has not issued a VCN for this call yet — continue without it”: Continue saves the draft and the house bills can be filled in. The VCN stays mandatory — the step rail and the review list it as outstanding, and the filing cannot be sent to customs until it is entered. For a ship with an IMO number the platform keeps reading customs’ list of calls for the ships on your drafts, and e-mails you when it lists a call for that ship at your port. A ship filed by name because it has no IMO number gets no such e-mail, since customs publishes calls by IMO number only.

Only when you ask it to. The notify party starts blank, and typing the consignee copies nothing across — a house bill’s notify party is often somebody else, and a box that filled itself was sending the consignee’s details out under the wrong heading. When the bill names the consignee as the notify party too, tick “Same as consignee” above the notify party: all nine fields fill from the consignee and keep following it as you type, and the guided steps fold them away while they do. Untick it to edit them yourself; what was copied stays as a starting point unless you choose to clear it. Ticking it when a different party is already typed there asks first — replace it with the consignee, or keep what you typed. A draft saved with the same party named in both places reopens with the box ticked.

Not to customs: JSON objects are unordered, and one vendor’s accepted filing on record carries its keys in what looks like hash order. It matters to the person reading two files side by side, which is why every block the platform writes — the header, the declaration reference, the authorised person, the vessel, the voyage, each consignment and each house bill — follows the order the accepted filings on record carry. Until 17 September 2026 a file made from a saved draft could come out with each block’s fields sorted shortest-first instead, an artefact of how the draft was stored rather than of anything typed; a download made since then is in the expected order, so if a file of yours reads that way, download it again.

Yes, and it is the main way the roadmap gets written. Use the Feedback button in the app header, Send feedback at the bottom of any public page, or the suggestion box on the roadmap itself — none of them needs an account. Suggestions asking for the same thing are grouped together, so fifteen people asking for spreadsheet import become one item with fifteen organizations behind it rather than fifteen competing entries. What is published is our wording, never yours: suggestions routinely mention a customer, a bill of lading, or a rate, and those stay private to our team.

The public roadmap lists what is being built, what is planned, what is under consideration, what has shipped, and what we have decided against — and anyone can vote on it. Votes are the strongest input but not the only one: some work is required by a change in the regulation, some unblocks several other items, and some is small enough to do immediately. Nothing on the roadmap carries a delivery date, because a date on work that has not started is a guess rather than a commitment.

Yes. A vote from a signed-in user is counted for their whole organization, and weighs roughly five times an anonymous one. Several colleagues voting for the same item still counts once — deliberately, so the largest team cannot set everyone’s priorities. Anonymous votes are counted too, and weighted lower because far less can be told about them: a whole office behind one connection can look like a single voter, and one person on a VPN can look like several. If you file with us, sign in before voting.

Yes. Inside the app the assistant is handed the form itself — the guided steps, their section headings, the full form’s sidebar and the label on every input — generated from the same model that renders it, so it answers “where do I put the destination port?” with the step, the section and the label as you see it, and “I can’t see the ports on the first step” with which step they are on. It starts from the screen you asked from, gives the JSON key alongside for matching an error message, says when a section is folded away or a field is filled in for you, and says whether the field is the master consignment’s or the house bill’s. The reference material still carries what the field means; the form map carries where it is.

It means we have published an item covering what you asked about and your question matched it. It does not mean the feature exists — check the status on the card, because only “Shipped” means you can use it today. If something is marked shipped and you cannot find it in the product, report that as a problem rather than as a suggestion.

A VCN (vessel call number) is the number a port issues for one ship arriving there on one voyage; the rotation number is a separate number, shown beside it. My VCNs, in the header, opens a page per VCN, appearing on its own the moment a filing or a kept file of yours first names it: every CSN of yours on the call, every upload of the shipping line’s SAM and customs’ ACK to each, the files either side has shown for it, and a timeline of what happened and when. Bills and containers, on the same page, reads each of your bills and containers against the shipping line’s manifest and customs’ record, worst status first, so you see what needs attention before a phone call tells you.

Explain this rejection does that reading for you. A SAM rejection names most lines by number alone — the first one seen here rejected 114 lines of a 795-line amendment and printed a bill number on only two of them — so the ACK by itself cannot say which bills are affected or whether anything on them is actually wrong. It resolves every rejected line to its bill on customs’ own public record, compares it against the CSN that bill quotes and, where the file you sent disagrees with what customs’ accepted manifest carries, says which is which — with a CSV of every line and an evidence pack ready to send the ICEGATE helpdesk.

It is a read-only page for whoever files the other side of your master bill — the carrier reconciling their manifest against your CSN, say — carrying only what the two filings are compared on: total packages, the number of containers, each container’s number, type, size, load status, SOC flag and seal, plus the bill of lading date — and nothing else of your filing. They need no account to open it, and can drop their own file back to you from the same link.

A case is for sorting out a problem on a VCN rather than for filing anything — a rejected manifest line, a CSN that disagrees with the carrier’s own filing. It gives the problem a read-only link for the other party, drafts messages from what customs’ record actually shows rather than from assumption, and keeps a timeline of what has been shared and when, so a disagreement is worked through in one place instead of over loose e-mails.

Yes. An Org Admin whose organisation has it switched on can mint an API key and register a webhook endpoint under Settings → API, so your own systems can check and send files to SCMTR and hear back by signed webhook when something changes. Write to support@scmtr.io to have it switched on.