Reference numbers and tracking

SCMTR filing involves a lot of numbers that look alike. This is who mints each one, at what moment, and what it is good for.

The ones you provide

The one ICEGATE gives you the instant you submit

Unique ID (called a tracking ID on the portal path) — the handle that identifies your transmission to ICEGATE. It is not the customs decision; it only confirms the file was received and queued. Since September 2026 customs' public record of accepted filings names it too, which is how the platform tells that a CSN number on that record belongs to this transmission and not to another filing on the same bill: for a fresh filing sent from here, the CSN number and date are read off that record and the filing turns accepted on its own. A rejection never appears there and arrives only in the emailed acknowledgement.

It can be missing even on a successful upload. That is not a failure — it means the filing went through without a handle. Where customs later lists the filing on its record, the handle is recovered from there; otherwise the outcome is read off the emailed acknowledgement or the portal and recorded by hand.

The ones customs mints when it accepts

The CIN goes to the level carrying the cargo detail. In a consolidated filing the house bill receives a PCIN, and on almost every import acknowledgement seen the master receives nothing at all. (Customs' own table, below, provides for an MCIN on a consolidated master, and a few acknowledgements do carry one — read yours rather than expecting either.) Anything reconciling filings against customs records has to key on the house bill, not on the filing as a whole.

An export consolidation is the exception (added 2026-09-20). There the master is filed as consolidated C with previous declaration N and names no PCIN of its own, and customs issues that master an MCIN when it accepts — the Export, consolidated, previous N row of the table below, and what customs did on the consolidated exports it accepted in September 2026 (a small number of filings). The lines under it are issued nothing new: each quotes the PCIN its shipping bill already has. See exports: filing an SCX, shipping bills and PCINs.

An export's PCIN is not minted by any CSN at all. Customs attaches it to the shipping bill — CBIC's clarifications say at goods registration, its 2021 webinar says it travels to the custodian with the let-export order — so it exists before the forwarder files anything, is printed on the post-LEO shipping bill, and can be fetched from ICEGATE's PCIN Enquiry (Exports). A straight export CSN that quotes it is issued a CSN number and no new CIN.

Which lines get a CIN is set by ICEGATE's own table, keyed on cargo type, consolidated indicator and previous declaration (the CIN generation mapping in ICEGATE's SCMTR Object Mapping workbook, reproduced in the message guides):

Transhipment (TR) and coastal (CG) cargo follow the import pattern. The first customs reply to a SAM / SDM seen here did exactly what the consolidated-C-C row says: six consolidated lines filed with previous declaration C, and an MCIN for each.

A CIN reads as year, CIN type, issuing message, date, then a running serial. Three layouts have been seen, all twenty characters:

An MCIN has the same twenty-character shape with MC after the year — that is how the MCIN customs issues to an export consolidation's master reads too: every one seen on customs' public record in September 2026 reads …MCSX00…, like the example above. And foreign cargo transhipped out on an export CSN (cargo type TR, movement FT) quotes a PCIN in the …PCSE00… shape of the first row — the shape of a number issued on an accepted CSN, most likely the cargo's own entry CSN. CBIC's 2019–2020 training decks describe an "18 digit" PCIN, with a template that has 00 where real numbers carry the two issuing-message letters. No real PCIN or MCIN seen is 18 long; the message guide's field is 20, and 20 is what the checks here expect. If someone quotes the 18-digit format at you, it is from those decks and appears to predate go-live.

The two letters after the CIN type name the message that issued it, not your reporting event — a manifest amendment (SAA) issued SM. The serial is a single counter customs runs nationally across CSNs, manifests and shipping bills alike: a shipping bill's PCIN and a CSN's issued on the same day in August 2026 sat within a few thousand of each other, which is why the numbers are large and why two filings made on the same day are nowhere near each other.

The practical use of this is that a PCIN tells you the day the filing was accepted without looking anything up, which is worth knowing when you are handed a bare CIN and asked which filing it belongs to.

The CSN cannot be worked out from the PCIN, or the other way round. They are two separate counters kept at different speeds: the CSN counts filings, the PCIN's serial counts consignments, and a single consolidated filing takes one CSN while issuing many CINs. Both climb steadily over time, so either number will date a filing — but there is no arithmetic that turns one into the other, and anyone who offers you a conversion is guessing.

Because the CSN only ever climbs, a CSN quoted with a date that does not fit the sequence is a transcription error worth querying before you file an amendment against it.

A CSN belongs to one filing, not to you and not to the voyage. This is the mistake worth guarding against: if you filed twice on the same vessel — two master bills, two consignments — you hold two CSNs granted the same day, minutes apart, with numbers a handful apart. They look interchangeable and are not. Quoting the wrong one produces a perfectly well-formed reference to the wrong shipment, and nothing in the message will reject it.

The reliable way to pair them is through the PCIN, which is issued per consignment: look the CSN up by the PCIN of the consignment you mean, rather than by your own name or the vessel. An enquiry keyed on the voyage will return every CSN you have against it, in no order that tells you which is which.

This decomposition is read off real acknowledgements and filings — a handful of CSN and manifest replies, and 318 shipping-bill PCINs on one departure manifest — rather than published by customs, so treat it as a dependable hint and not a rule.

The ones the carrier and the port mint

You can read these; you never write them.

A VCN and an IMO number cannot be converted into each other. They identify different things — one call of one ship at one port, against the hull's permanent identity — and there is no rule connecting them. Customs' public enquiry maps them in one direction only: give it an IMO and it lists that ship's calls; it will not tell you whose call a given VCN is. The platform can still often answer it, because every call it has ever fetched is kept: paste a VCN into the vessel box and if the ship has been looked up here before, it comes back. A miss means nobody here has looked that ship up, not that the VCN is wrong — see Finding the ship you are filing for.

(IGM number, line number, sub-line number) is the carrier's unique address for one consignment — a house bill at sub-line 1 upward, a direct master bill at sub-line 0. It is also, not coincidentally, the shape amendments are matched on, and the address a Bill of Entry quotes.

Is the VCN the same as the IGM number, or the rotation number?

No. One call of one ship carries all three, they appear at different moments, and none of them stands in for another.

That one call has both a VCN and a rotation number is what customs' own vessel-call enquiry shows: ask it about a hull and every call comes back with the two side by side, plus the date the rotation was registered. Some calls come back with a VCN and no rotation number beside it, which reads as the VCN being the earlier of the two — that is a reading of the enquiry's own answers rather than anything published. On the calls looked at here the rotation was registered between two and nineteen days before the expected arrival: a handful of calls, not a statistic.

That the IGM number and the rotation number are the same value is measured, against real bills on the live enquiries — see When the Bill of Entry cannot find the manifest.

The timing is the practical difference. Your CSN goes in before the ship arrives, when the VCN exists and a usable IGM does not; the IGM is what the manifest becomes at or near arrival, and it is what a Bill of Entry is checked against. That is why a CSN quotes a VCN and a Bill of Entry quotes an IGM number — not because SCMTR renamed the IGM.

They do not even look alike. A VCN is fourteen characters beginning with a port code — NSA12026081299. The rotation and IGM numbers customs returns are plain runs of digits, seven of them on the calls seen here, with no port code in them.

Two things invite the mix-up. ICEGATE's error 24 is titled Invalid Rotation/Voyage Call Number, naming both in one row. And carrier staff say "rotation" and "IGM" interchangeably, which is correct — they are the same number — but neither of them is your VCN. Never type a rotation or IGM number into the conveyance reference, and never the carrier's own voyage number off the bill of lading either.

What are the parts of a VCN, and can the same one come round twice?

A four-character port code, the year, then six digits. NSA12026081299 is fourteen characters: NSA1 is Nhava Sheva — the same port whose full customs code is INNSA1, with the IN dropped — then 2026, then 081299. Every VCN on an accepted filing seen here reads that way.

ICEGATE's own advisory confirms that shape. Its 2021 SCMTR advisory for authorised transhipment operators defines the VCN as fourteen characters — port code (4) + year (4) + month (2) + running serial (4), e.g. BOM12021038888 — and says the port code is used without the IN prefix; ICEGATE's 2024 rotation-number user manual repeats it. A real 2026 departure manifest at Mumbai carries BOM12026083240: BOM1, 2026, month 08, serial 3240.

Two older published examples are written differently, and both are fourteen characters. CBIC's specification for the message a port sends customs defines the field as "Location Code (6 chars) + Year (4 digits) + 4 digits running serial no.", with the example INBOM120190001, and ICEGATE's published resolution for error 20 quotes the same shape for 2021 — INNSA12021XXXX. Real numbers follow the advisory instead. Do not reformat a VCN to match either example, and do not "correct" one customs' own enquiry lists: file the number the port issued, exactly as given.

The six trailing digits are not a plain counter: the first two are the month the port registered the call and the four after them a running serial — the advisory's own definition, and what every call seen here shows. Nothing practical follows from it except the two things worth repeating: there is no arithmetic that produces a VCN, and there is nothing inside one for you to fix.

So a date inside the number that disagrees with your ETA is not, on its face, wrong. Those digits look like the moment the port registered the call rather than the day the ship arrives — one call recorded here was registered on the last day of July, for an arrival in the first week of August, and carries July. A December number for a January arrival is the same case one year-end further on. No call spanning a year end has been seen here, so that last step is reasoning from the shape rather than something measured: file what customs' list or the arrival notice gives you, and do not edit the year because it disagrees with the ETA.

The four letters name the port that registered the call — which is not always the customs site you file at. Customs lists Haldia's calls (HAL1…) under the Kolkata site INCCU1, and CSNs filed at INCCU1 with a HAL1 number are accepted. So "the first letters differ from my port" is not, on its face, an error. What is worth a second look is a VCN that customs' own list places at another site altogether — a Chennai port number (MAA1…, listed at INMAA1) on a filing reported at Kattupalli (INKAT1), whose calls have their own KAT1… numbers. That is usually the same ship's call at the neighbouring port, or its last voyage, copied from an older file. When you check a file here, the voyage line asks customs where the VCN is listed and says so if it is not your port; judge it by that answer, not by the letters.

Can the same VCN come round twice? Nothing recorded here shows one doing so — across the calls held here no VCN appears under more than one hull — but that is a small window on a national numbering scheme rather than a guarantee, and the year inside the number is what would keep serials apart if a port began its own again each January. Inference from the format, not a published rule. So if you keep your own record of VCNs against bookings, key it on the number and the ship, never on the number alone.

Where a party's PAN comes from

Three of the message's fields want a party's PAN, and filers reasonably ask whether there is a directory to look one up in. There is not — but there are two dependable ways to get one right.

From a document you already hold. 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, with no lookup involved. This is the most reliable route, and the one to reach for first.

Confirming a PAN you already have. The GST portal's Search Taxpayer by PAN returns the legal name registered under a PAN, and DGFT's View Any IEC does much the same, since an Indian entity's IEC is its PAN. Both are worth a minute when a value looks wrong. Neither works backwards: you cannot search by company name to find a PAN.

The container agent code is not the shipping line's PAN. This trips people up because both are PANs and both sit near the vessel. The container agent code 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. On real accepted filings it is the master consignment's consolidator, and it differs from the line operating the vessel. It comes off your paperwork and the commercial arrangement over the box, not from any register. It is never mandatory in any reporting event, so leaving it blank is safe and is much better than guessing a party who would then be recorded as responsible for the container.

What if the shipping line is foreign and has no PAN?

Then it has no PAN to give, and that is expected rather than a problem to solve. 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 you meet on a filing belongs to, for example, MSC Agency (India), not to MSC's foreign parent.

For the shipping line code itself, CBIC published a directory of foreign shipping lines covering most major container carriers. It is a dropdown inside logged-in ICEGATE at SCMTR registration time, not a file you can download, and when the line you chartered is not on it the published answer is to enter the commercial code BLK. That fallback was created for bulk cargo and CBIC has confirmed it publicly as the general answer for a line that is not listed.

How do I get a shipping line code, and why does the CODES directory not work?

A shipping line code is allotted case by case. CBIC's advisory on the procedure has the Customs System Manager issue it against submitted documents — there is no self-service directory you can register yourself in, by design.

The public CODES enquiry is currently broken, and it is not you. ICEGATE's CODES application still lists a Shipping line Code enquiry among about thirty others, and its index page loads normally, but every enquiry behind it returns a server error — checked directly on 2026-08-29, including from an ordinary browser. The older old.icegate.gov.in copy no longer exists at all. If you go looking for that directory and get an error page, nothing is wrong with your access.

Why does the same ship show a different line on different voyages?

Because the line is recorded per vessel call, not per hull. Customs answers "who is running this particular call", and a ship chartered out, sold, or operated under a different agency between calls will legitimately answer differently. One vessel in our own checks returns two different line identities across its own calls, both correct.

This is why the app looks the line up from the voyage you selected rather than from a table of ships, and why a line name that surprises you is worth checking against the call date rather than assumed to be wrong.

Timing — the thing that catches people out

The IGM number does not exist when you file.

It is minted at or near the vessel's arrival at the Indian port, while the CSN is filed in advance of arrival. So for the whole period between filing and arrival there is no IGM to look up, and a manifest enquiry returning nothing is the expected state rather than a fault.

That gap has an answer since September 2026: customs' record of accepted CSNs lists a filing from the moment it is accepted, so the period between filing and arrival is no longer silent — see What customs already holds. "Not found" on a tracking lookup shortly after filing still means not yet, not wrong.

The same record also shows whether an IGM line exists yet. Each house line on it carries the IGM line and sub-line it has been mapped onto, empty until the mapping happens; the master row stays empty regardless, so read the house lines, and for a bill with no house bill read the older manifest enquiry instead. That is the fact worth reading when something downstream of the manifest — a Bill of Entry, most often — refuses on the IGM while the SCMTR filings are plainly on record: see When the Bill of Entry cannot find the manifest.

Tracking a shipment

ICEGATE publishes two public enquiries for a master bill, and the app's BL tracking page uses both. Give it a master bill of lading number and a port, and it reads the accepted CSNs on customs' record (available from acceptance, days before arrival) alongside what the carrier's manifest says — whether the consignment is on it, against which IGM and line, and the vessel and container detail behind it — consolidated into one shipment view.

Two uses:

Before filing — pull the vessel, voyage and container details the carrier has already declared, rather than retyping them. The form's Fetch from ICEGATE button does exactly this.After filing — confirm your consignment actually landed on the carrier's manifest. A CSN customs accepted and a manifest that does not mention your bill is a mismatch worth catching early.

The manifest status shown against a declaration is cached when fresh and looked up live otherwise, so opening a filing does not re-query ICEGATE every time.

Reading an acknowledgement

Two things routinely surprise people:

Absent values arrive as the literal text "null", not as an empty JSON value. A rejected filing's CSN number is the four characters null, and reading it as a number gives nonsense.Error codes appear under more than one spelling in the response. A filing that shows no errors under one name may still carry them under another.

Both are handled for you inside the app; they matter if you are reading a raw acknowledgement file yourself.

Filename convention

Real filings are named for their own contents:

{msgTyp}_{messageID}_{reportingEvent}_{senderID}_{jobNo}_{date}_DEC.json

So F_SACHM22_SCE_ACMEEDI_1856_20260825_DEC.json is a fresh SCE filing, job 1856, sent on 25 August 2026. An amendment starts A_ and carries SCA. The app's Download button produces the same shape, which makes a downloaded file recognisable next to files from anywhere else.

This is a rule, not a habit. ICEGATE reads those seven parts out of the name itself and refuses the file if they are not all there:

Invalid SCMTR File Name format, The File Name format should be messageType_msgID_reportingEvent_SenderID_jobID_date_declaration

A signed file carries _DECSigned in the last position instead of _DEC, and that is still one part, so it is accepted.

So never rename a filing file — not to tidy it, not to tell two of them apart, not to add a date you can read. Anything extra becomes an eighth part and the upload is rejected before customs ever sees it. The trap that catches people is passive: download the same file twice and your browser saves the second as … (1).json, which is no longer a valid name. If that happens, download it again to a clean folder rather than renaming the copy.