Party codes and PANs

Several fields on a CSN want a party identified by a code, and filers reasonably go looking for a directory to search. There is no such directory — and mostly you do not need one, because the value is already printed on a document you are holding.

The reliable route: a GSTIN already contains the PAN

Characters 3 to 12 of any GSTIN are that party's PAN, by construction. A GSTIN is built as state code, PAN, entity number, the letter Z, then a checksum:

07AAAPX0003A1Z5
││└────┬────┘│││
││     │     ││└─ checksum
││     │     │└── Z
││     │     └─── entity number
││     └───────── PAN: AAAPX0003A
└┴─────────────── state code 07 = Delhi

So a carrier invoice, delivery order or arrival notice showing a GSTIN is showing you the PAN exactly, with no lookup and no guessing. It is the most reliable source there is, and it is the one to reach for first.

The same token gives you two more fields for free: the first two digits are the state code in the MIG's own numbering, and that resolves the country subdivision without any name matching. Pasting a party block into the app extracts all of this for you.

Andhra Pradesh is 37. The MIG's state list leaves Andhra Pradesh out altogether, but ICEGATE's own list of common errors says code 37 was added for it, every Andhra Pradesh GSTIN starts with 37, and customs has accepted CSNs carrying 37 for an Andhra Pradesh consignee. Do not use 28, the state's code before 2014: the MIG does not list it either. Pick Andhra Pradesh in the state list and 37 is filled in for you.

Daman & Diu is 26 now. Daman & Diu merged into Dadra & Nagar Haveli on 26 January 2020, and a Daman business's GSTIN starts with 26. The state list shows 26 as "Dadra & Nagar Haveli and Daman Diu"; the MIG's older 25 for Daman & Diu is still offered, and filings carry both.

Ladakh is 38 — its GST state code, the same numbering customs followed for Andhra Pradesh. We have not yet seen a filing carrying it, so it is offered on that reasoning rather than on proof.

Confirming a PAN you already have

Two official services will confirm a PAN, and neither will search for one (a checklist drafted from e-mailed bills asks you for a consignee's PAN or GSTIN the same way, since no bill carries it — Bills by e-mail):

GST portal → Search Taxpayer by PAN returns the legal name registered under a PAN, plus every GSTIN under it.DGFT → View Any IEC does much the same, since an Indian entity's IEC is its PAN.

Both take a PAN and give back an entity. Neither works backwards — you cannot search by company name to find a PAN. Both sit behind a captcha, so they are a minute of a person's time rather than something any system can do for you. Worth spending when a value looks wrong.

What code do I file when the consignee is a government department?

The same code types as anyone else — the guide's five, IEC, PAN, GSN, GSD, GSG, and PPT for a passport number — and the same rule. On an import the MIG asks for the consignee's IEC, and if there is no IEC, the PAN; the code goes in cnsgnesCd and its type beside it in typOfCd (the notify party's in panOfNotfdParty and typOfNotfdPartyCd). A government buyer changes which value you have to hand, not the fields.

In order of preference:

The PAN first, for the same reason as any other consignee: it names the department itself, and it is what nearly every filing on record carries for a consignee of any kind. No filing on record has a government department as its consignee, though, so which of these three customs accepts for one has not been seen on a filing yet — the order above is our inference, not a pattern from filings.

The permanent IEC is the answer to "the department has no IEC". Ministries and departments of the central and state governments are exempt from taking an IEC, and DGFT gives each exempt category one permanent IEC to use instead (Handbook of Procedures, para 2.07). They are in PAN format. The numeric permanent IECs still quoted in the trade press are the old baggage and personal-use rows of the same table, which DGFT's handbook now gives in PAN format as well — they are not codes for a government department.

DGFT says non-commercial PSUs use these too. A permanent IEC names a category, not the department, so it tells customs nothing about who is receiving the goods — prefer the department's PAN whenever it has one. The household-goods page has the other rows of the same table.

GSG is allowed, but nothing on record shows it used. The MIG lists it ("GSTIN given for Govt. Entities"), yet no filing we hold carries GSG, GSN or GSD. Use it only with a GSTIN that is really the department's. One kind to avoid: a department registered under GST only to deduct GST TDS may hold a GSTIN built on its TAN rather than a PAN (the fourteenth character is D). This app checks that a GSTIN has a PAN inside it and will stop at one like that — file the PAN or the permanent IEC instead.

Two things that sound like government cargo:

Item type GC is the MIG's "Govt. Cargo". It is a separate question from the code type — it says which body of customs rules applies to the goods. The MIG gives it no more definition than those two words, and no accepted filing on record carries it; OT (other cargo) is what almost every filing uses. Ask the importer whether the goods are government cargo in customs' sense before choosing it.CG is not government. Where the MIG says "In case of CG, GSTIN/PAN code should be mentioned", CG is the cargo type Coastal Goods. It has nothing to do with a government consignee.

On an import the shipper (cnsgnrsCd) is abroad and its code is not required: the MIG makes the consignor code mandatory only for export (EX) and coastal (CG) cargo.

The container agent code is not the shipping line's PAN

This is the most common mix-up, and it is understandable: both are PANs and both sit near the vessel on the form.

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.

There is no register to look it up in, and CBIC says so. The published SCMTR clarifications treat the container-level code purely as an auto debit/credit question and point the filer at their jurisdictional nodal officer rather than at any directory. The value depends on the commercial arrangement over that particular box, which no public register models.

It is never mandatory in any reporting event. Leaving it blank is safe, and far better than guessing a party who would then be recorded as responsible for the container. Since ICES Advisory 38/2026 (21 September 2026) customs says the container agent PAN is validated on the shipping line's manifest only, not on your CSN; no acknowledgement on record shows that either way, so keep the value right here regardless.

If you corrected the consolidator PAN after adding containers, check the agent codes: in the guided steps they follow the correction on their own; in the full form they do not, and the app flags each container whose agent code is not the master's consolidator PAN so you can retype it under Equipment.

What the MLO code is instead

The MLO code is the shipping line's customs identity, in PAN form, returned per vessel call by ICEGATE's public VCN enquiry. That one is reliably available, and the app reads it for you when you pick a ship.

Two properties worth knowing:

It is recorded per call, not per hull. The same vessel can report different lines on different voyages — chartered out, sold, or run by a different agency — and both answers are correct for their call.It identifies the line, which is not the same question as who is responsible for the box. See above.

Why is the master filed under an agent's PAN, not the shipping line's?

Because on some routes the line on the bill does not file for itself. The master's Consolidator PAN is the PAN the line files under on this route, and a line can use a different agent depending on the port and the final destination. These examples are one working filer's table, sent in September 2026, and no published customs document sets the rule out. The three agent rows in it have not been checked with customs — no filing on those routes exists to check them against — while the same filer's other routes have been: on 43 of his bills the line's own declaration is on customs' public record, filed under exactly the PAN he used, and on every one of them that PAN was the line itself. So where this table names an agent, it is his word; where it names the line, customs agrees.

So the app does not pick the PAN from the line's name alone. On the master, Shipping line on the bill takes the line printed on the bill. That choice is kept with your draft only, to pick the PAN — the line itself is never sent to customs; the filing carries the PAN and nothing else. The PAN is then filled from our routing table for this filing's port and destination — the destination in "Route for all house bills", or the one every house bill shares. What it does:

It says whose PAN it is — for example "Files under OMEGA — Wan Hai Lines on INMAA1 → INWFD6" — and where the row came from. Rows from the filer's table say they have not been checked with customs. The filer wrote "Bangalore"; INWFD6 — the station their own port list calls Bangalore ICD — is our reading of that, still to be confirmed, so on a Chennai master to another Bangalore station the table has no row and the PAN is left for you.Where the table holds the agent's PAN, it fills in. Wan Hai Lines, Chennai → Chennai, fills Wan Hai Lines' own PAN (AAACW4257A — the one on twelve of the filer's accepted filings and, at Mundra, the one customs' record shows Wan Hai's own declaration under). OMEGA's and AISSA Maritime's PANs are on file too, from the same filer's table, and fill on the routes above.Every other route a listed line sails, the line itself. Fourteen lines carry a row with no port and no destination — the PAN their own accepted filings carry — so a Wan Hai box to a Mundra ICD or a Chennai CFS fills Wan Hai's PAN without a row for that route. RCL is the exception: two PANs, by port (Kattupalli, Nhava Sheva); anywhere else it asks and offers both.When the route changes, the PAN follows, as long as it still holds the table's earlier answer — and that includes clearing it when the new route's agent has no PAN on file, or the route has no row, rather than leaving the wrong party's PAN standing. A PAN you typed yourself is never replaced; the note offers the table's instead.When the table names the agent but not its PAN, it says so and asks you to type the PAN from the line's arrival notice, rather than offering the line's own.When the table has no row for the route, the PAN is left for you to type. The line's own PAN is offered in one click, but never filled in by itself — on an inland route it is often the wrong party.

Ports are matched by customs station, so a CFS counts as the port it sits under. The table is kept by us; if your route is missing or wrong, tell us through Feedback.

Can I pick a shipping line's PAN by typing the line's name?

Yes, on the master's Consolidator PAN when a house bill sits under the master. Besides picking the line on the bill (above), the PAN field itself searches by the line's name as well as by PAN:

Your own filings come first — every shipping-line PAN your organisation has filed as a master's consolidator, with how many filings used it.Then the line's own PAN as accepted filings carry it. 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 consolidator PAN on filings customs accepted (thirty bill-prefix → PAN pairs, none contradicting another), and the note under the field says Confirmed on a filing customs accepted. Customs' own public record goes one step further for six of them — Wan Hai, ONE, Evergreen, Gold Star, Emirates and RCL at Kattupalli: on bills carrying those lines' prefixes, the line's own declaration is on record under exactly that PAN, so the note reads as customs records it. RCL's two PANs split by port — AAJCR4245A is the PAN RCL's own declaration went in under at Kattupalli; AAHCR9728E is the one a filing customs accepted at Nhava Sheva carries — so they are offered by port and say so. A route the line files through an agent (Wan Hai via OMEGA to Bangalore and at Cochin, Interasia via AISSA Maritime at Cochin) still wins over the line's own PAN.Then a reference list of about thirty lines, from a working filer's own sheet, for the lines no accepted filing covers. Those have not been checked with customs, and the note under the field says so. Confirm with the line if unsure.Where a line uses a different agent at a different port, the agency at your filing's port is listed first — Yang Ming and Regional at Cochin, Swen at Tuticorin.

Pick one and the PAN fills in; in the guided steps the container agent codes follow it. You can still type any PAN yourself. On a master filed on its own the field is your own PAN, so no list of shipping lines is offered there.

There is no national directory behind this — there is no public register of carrier PANs to look one up in, which is the same wall this page describes for party codes. Your own filings are the best source you have, which is why they come first.

The MLO code is the other half of the answer, and it does arrive by itself. Pick the ship on the master bill step and the shipping line's MLO code comes back from customs with the voyage, along with the line's name where we can resolve it. That code is the line's customs identity in PAN form — but it is the code customs returns for that call, not something you should retype into a PAN field on the strength of the two looking alike. See What the MLO code is instead for where each one belongs.

Foreign shipping lines have no PAN

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 the overseas parent.

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

Why you cannot find the public code directory

Because it is currently broken, not because you are looking in the wrong place.

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 from both a plain request and an ordinary browser. The older old.icegate.gov.in copy no longer exists at all.

Shipping line codes are in any case allotted case by case by the Customs System Manager against submitted documents. There is no self-service directory to register yourself in, by design.

Related

Which reference is minted by whom: Every reference number, who issues it, and whenWhat the container agent code means on the form: CSN field conventionsWhen the party is a person with no IEC at all: Household goods and personal effectsThe code types (the guide's five and PPT) and the item type, as code lists: Coded valuesPasting a party off a bill of lading: Using SCMTR