What accepted filings actually carry

The Message Implementation Guide (MIG) tells you which CSN fields are mandatory. It does not always tell you which values customs actually takes — and on a few fields the published guidance and production behaviour differ. The notes below were read off real SCMTR filings and the acknowledgements ICEGATE returned for them, so they describe what worked rather than what a document says should work.

Where a point rests on a filing whose acknowledgement came back Accepted, that is said explicitly. Everything else is a pattern observed across real filings whose outcome is not separately proven, which is weaker evidence — useful as a default, not as a rule to rely on blindly.

The consolidation indicator: what real filings actually use

Every consignment in a CSN carries a consolidation indicator saying what kind of bill it is. The MIG's own code list names straight (S), consolidated (C) and house (H), which reads as though a forwarder's filing should be C on the master and H on the house.

Real forwarder filings do something different, consistently:

H on the house bill — the bill you issued to your shipper.R (ICEGATE's "B/L being referenced only") on the master above it — not C.M (Master) on a master bill filed on its own, with no house bill under it.

This holds across every forwarder filing examined, including ones ICEGATE returned an Accepted acknowledgement for, and across four different consolidator PANs — so it is not one company's house style.

C and S do appear in the wild, but in a carrier's filing covering many master bills at once, which is a different kind of filing from a forwarder's. If you are a forwarder or NVOCC filing your own house bill, R/H is the pairing to expect.

This matters because the indicator is a legal characterisation of the bill that you sign. A wrong value here is worse than a blank one.

A master bill with no house bill is normal

It is easy to assume every CSN has a house bill under it. Not so — a master consignment with no house consignment beneath it is both common and, for some reporting events, the only legal shape.

The master B/L number is mandatory in all six reporting events. There is no CSN without one; it is the spine of the message.The house B/L number is mandatory for SCE, SCX, SCD and SCA — and not applicable at all for SCU and SCC. The whole house consignment block is excluded for those two events.

So the reverse case — a house bill with no master — never happens, while a master on its own happens routinely. Two situations produce it:

A straight bill, where the carrier issued the transport document directly to the shipper. There is no forwarder in the middle and so no house bill to declare.A forwarder filing a carrier's master on its own, without adding a house bill beneath it.

If you are filing a master alone, expect the consolidation indicator M rather than a house-style code.

Consolidator PAN: yours on the house, the carrier's on the master

Both the master and the house consignment carry a field called "Consolidator PAN", and it is tempting to put your own PAN in both. They name different parties.

On the house bill, the consolidator is you — the forwarder or NVOCC who issued that bill to your shipper. Your own PAN goes here.On the master bill, the consolidator is the party who consolidated at the carrier's level, which is normally not you. In every forwarder filing examined this was a different PAN from the filer's, and a different one in each filing.

The one exception is a master filed on its own with no house bill under it: there the master is the bill you are filing, so your PAN belongs on it.

Where do I get the shipping line's PAN? It is printed nowhere on the bill of lading. It is the Indian PAN of the carrier (or its Indian agent) whose master bill you hold — the same on every filing with that line. The master's Consolidator PAN searches by the line's name: the PANs your own filings have used come first, then the PAN accepted filings carry for the line (fourteen lines, marked confirmed; for six of them — Wan Hai, ONE, Evergreen, Gold Star, Emirates and RCL at Kattupalli — the line's own declaration is on customs' public record under that PAN, and the note says as customs records it), then a reference list of about thirty lines that has not been checked with customs — so confirm with the line's local office if unsure. The wizard writes the same PAN onto every container on the master as its agent, which is how every accepted forwarder filing on record carries it.

Getting this backwards names the wrong party on a customs document, and because both fields carry the same label it is an easy mistake to make and a hard one to spot on review. Check which section of the filing the field sits in, not just its name.

How do I check a CSN JSON file field by field?

Use the JSON inspector. It checks a filing against the actual message schema and against the mandatory/optional rules for its own reporting event — a real validation, not a reading.

Sign in and open CSN filing. SCMTR JSON upload is the drop target at the top of the page.Drag your .json file onto it, or click it to choose the file. It is read-only — nothing is filed, and the file cannot be edited there. The file is kept for two years, like every file uploaded to SCMTR, so support can look at it if you ask about a rejection and a filing can be linked to its replies; a platform super administrator can open it, every opening is recorded, and you can ask for it to be deleted at any time. The screen says so as you upload.It reads the reporting event off the file and reports either "No validation issues" or a count of them.Each issue names the JSON path it sits at and what is wrong. Selecting one jumps to that field in the rendered filing, so you can see it in context rather than counting braces.

There is a toggle for showing empty fields, which is worth turning on when you are checking that something optional was actually populated rather than silently dropped.

It takes any of the three files a filing produces, and works out which it was given — you do not have to say. A declaration is validated and rendered as above. An acknowledgement (…_ACK.json) is read into plain words instead: the verdict and what follows from it, then every error with the MIG's description, where in the filing it sits, whether it refuses the whole filing or names one value, and numbered steps for fixing that particular code. A structural-failure response (…_SFL.json) is explained as the different thing it is — schema validation, which runs before any business rule and therefore carries no numbered error code at all.

Two things follow from having both files rather than one:

Upload the declaration alongside an acknowledgement and each error is anchored onto the block it names in the rendered filing, with the offending value quoted back at you. Where the refusal is 700, which names nothing, the four-step checklist is run against the file itself rather than merely listed.Where the acknowledgement answers a filing you made here, the inspector says which one and why it thinks so, and offers to record the outcome against it. That is the page's only write, it needs your confirmation, and the result is marked as an outcome you uploaded rather than one ICEGATE gave us directly.

An amendment or deletion is never imported as a fresh filing. Resetting msgTyp: "A" to F and dropping its CSN would turn "change CSN 1431790" into "file this cargo again from scratch" — a different declaration to customs, and a duplicate of one they already hold. If the CSN it references belongs to an accepted filing of yours, the inspector opens the amendment against that filing instead, keeping its job number and history. If it does not, it says so and points you at recording the original filing first.

The assistant on this site cannot do that. It answers from written reference material, so a field-by-field verdict from it would be an impression of a filing rather than a check of one, and this is not a document to get an impression of.

What the rest of this page is for is the part a validator cannot tell you: the conventions real accepted filings follow, where the published guidance and production behaviour differ, and the traps that make a technically valid filing wrong. Those are worth reading before you file, and worth asking about afterwards — the blocks are named here by both their plain name and their JSON key (headerField, decRef, authPrsn, vesselDtls, voyageDtls, MCRef, HCRef) so you can match them to what you see in the file.

The traps a JSON review actually turns on:

Which PAN fields carry the PAN: prefix, and which are bare?

This is the single most common false alarm when reading a CSN, because the message is not consistent and the app's own field help is written for someone typing into a form, not for someone reading a file. In a form you type the ten characters and the prefix is added for you. In the JSON, these are the two forms, confirmed across every examined accepted filing:

So "consolidatorPan": "PAN:AAACE0001A" is correct as written and must not be "corrected" to the bare ten characters — that is the one place the prefix belongs. Everywhere else, a PAN: prefix is wrong and will fail the field's own format.

What goes in the transhipper field?

There is no field called "transhipper PAN" — the two fields are Transhipper code (trnshprCd) and Transhipper bond (trnshprBond), which is why searching for the PAN by name finds nothing. But the code is a PAN in practice: every examined filing that fills it carries the ten-character PAN of the authorised carrier responsible for the onward movement, bare and unprefixed. The bond is that carrier's transhipment bond number.

Both are only for cargo that tranships onward rather than clearing at the port of entry. Where the cargo clears locally, the block is left out entirely rather than filled with blanks — and that is a matrix rule, not a habit: the block is optional in every reporting event, but inside it both fields are marked mandatory, so the two failure modes are the block missing when the movement needs it (420/430, "Mandatory Object MC/HC_Transshipper is Missing") and the block present when it does not (460/470, "…is Redundent"). The MIG's own definition of the party is the authorised carrier "responsible for operating the conveyance" on the onward leg, and ICEGATE's FAQ adds that there is one authorised transhipper for the whole inland movement, whatever the modes of transport, and that party executes the bond. On a CFS move the two fields carry the CFS's own PAN and bond; on an ICD move, the rail or road operator's — see After the gateway port.

headerField — what a live filing carries

messageID is always SACHM22.versionNo is the reporting event followed by 1102 — SCE1102 for a fresh entry. It is not a version you choose.indicator is P — production — on every filing this app makes. The code list also has T, for test, but customs does not refuse a filing for carrying it: two filings flagged T came back accepted, each with a CSN issued, and nothing on record has been refused for the flag. A T in a file made elsewhere is not a problem to fix.date is YYYYMMDD and time is T then HH:MM — 20260828, T15:02.senderID is your ICEGATE ID: alphanumeric, at most 25 characters, no spaces or punctuation.receiverID is the customs port code of the port you are reporting to, and it is normally repeated as decRef.prtofRptng. So is the date: decRef.jobDt normally equals headerField.date.

authPrsn — who is filing

Three fields, all mandatory in every reporting event, and none of them asked for per filing — they come from the organisation's saved profile.

sbmtrTyp is ANC, ASA or ASC — notified carrier, sea agent, sea carrier.sbmtrCd is the submitter's registered code, bare. It is PAN-based in every accepted filing examined, though the MIG allows fifteen alphanumeric characters.authReprsntvCd is the authorised person's PAN, bare and exactly ten characters. It is normally the same value as sbmtrCd, but it does not have to be: a filing where the two differ is perfectly ordinary when the authorised person is not the entity that registered.

vesselDtls and voyageDtls — which ship, which call

modeOfTrnsprt is 1 for sea.typOfTrnsprtMeans is 10 when the ship has an IMO number and 11 when it does not.trnsprtMeansId is the seven-digit IMO number when the type is 10 — not the ship's name. It carries a check digit: multiply the first six digits by 7, 6, 5, 4, 3, 2, add them up, and the last digit of that sum is the seventh digit. 9969924 gives 214, so 4 is right. A number that fails this is a transcription error, not a ship.cnvnceRefNmbr is the VCN customs issued for that ship's call at that port — NSA12026081299, not the carrier's own voyage number off the bill of lading. The two are different identifiers and a bill of lading carries only the second — and neither is the rotation or IGM number, which is a third thing again (which is which). Why customs asks for it when it already has the IMO number: the IMO says which hull, the VCN says which of that hull's arrivals. A ship calls at your port many times a year, and customs files your CSN under one arrival — its own error list carries 327 and 328, "VCN of CSN Does Not Match with VCN of CSN/SAM/SDM", for a call that disagrees with the call on another accepted filing for the same cargo, and CBIC's published clarifications describe the vessel operator being given an enquiry "about the CSNs manifested for its vessel (VCN)". An IMO number alone would name the ship and not the voyage.Type the VCN exactly as it is given to you — one unbroken run of capitals and digits, no spaces and no dashes. Nothing reformats it on the way out: the message allows up to 35 characters and says nothing about their shape, so what is in the box is what customs receives, trailing space and all. A number read out over the phone or copied out of a PDF is where a stray character gets in, and it is a plausible way to earn 20 Invalid Voyage Call Number-VCN on a number that is otherwise right — plausible rather than measured; no acknowledgement we hold has been traced to one. Paste it, then look at what you pasted. The on-screen check is no help here: it ignores capitals and spaces at either end when it compares your number against customs' list, so a clean-looking check is not proof of a clean field.totalNoOfTrnsprtEqmtMnfsted counts distinct containers and totalNmbrOfLines counts consignment lines. Both are totals of what is in the file, so they should agree with it.

Is the conveyance reference mandatory? And on an export?

Mandatory on the three events that declare a cargo movement — arrival (SCE), departure (SCX) and domestic movement (SCD) — and on a cargo confirmation (SCC). Optional on an amendment (SCA) and a CIN update (SCU), where the voyage was settled by the filing you are changing; on those two the voyage block may be left out altogether, and a blank conveyance reference is not treated here as something missing.

That is the MIG's own field table, and the form follows it. On an event where the field is mandatory you cannot get past it: the review will not release a filing with it empty, and the same rules are checked again on the server before anything is sent. So "can I leave it blank and file the rest" answers as no on an arrival — not because customs is lenient about it, but because it never reaches customs. Customs' own list has 404 Mandatory Object Voyage Details is Missing for a file that arrives without the block at all.

An export needs one too. Almost everything written about finding a VCN is in import language — arrival notice, ETA, arrival — but the field itself does not change on a departure filing: it is still the port's number for that ship's call at the port your filing reports to, reaching you the same ways, off the calls customs lists for the ship or off the line's own paperwork. Only the document it is printed on is different. See Finding the ship you are filing for.

The requiredness above is the MIG's field table, which is published. The rest of the export paragraph follows from what a VCN is rather than from a filing: every filing examined here is an arrival or an amendment, so no accepted export filing has been measured on this.

Does each master bill need its own VCN?

No. The ship and the call are stated once, above all the master consignments — vesselDtls and voyageDtls sit at the top of the message and the master consignments sit under them. Three master bills on one filing share that one VCN, and so does every house bill beneath them, which is why the voyage block does not repeat the way the consignment blocks do. There is nowhere to put a second one.

The consequence is the one worth remembering: cargo arriving on two different ships cannot share a filing. Two master bills on different vessels — or on different calls of the same vessel — are two CSNs, and that is a decision to make before you file rather than after. An accepted filing cannot be split by amendment; deleting it and re-filing is a route customs says is open before the line's manifest since ICES Advisory 38/2026 (21 September 2026) — that the re-file may be two filings rather than one is our extrapolation, the advisory says only "corrected particulars" — though the one re-file after a deletion on record here — before the advisory — came back 122/123. See Deleting does not free the bill of lading.

MCRef — the master bill's own reference

lineNo numbers the master consignment within the filing, from 1.mstrBlNo and mstrBlDt are the carrier's bill number and its date, YYYYMMDD.consolidatedIndctr is R when house bills sit under this master and M when the master is the only bill.prevDec is N on a fresh filing — it says whether a prior declaration exists, not whether this one has been filed before.

The container agent is usually the master bill's consolidator

The container agent code identifies the party responsible for a piece of equipment. It is optional in every reporting event, so a blank costs you nothing.

Where filings do carry it, the value is the master bill's consolidator PAN — not the filer's own, and not the house bill's consolidator. This held in every examined filing that had a house bill under a master. A master-only filing examined carried a third party again, different from both, so there is no reliable default there.

The practical rule: if you are filling this in, it is the party who consolidated at the carrier's level — the same PAN that appears as the master bill's consolidator — unless you know otherwise for this particular box.

The app fills it in from the master's consolidator PAN on every container. In the guided steps a corrected consolidator PAN carries the agent code with it — every container that was following the old PAN takes the new one, on a reopened draft as much as in the same sitting. In the full form the field is plain and does not follow; instead any container whose agent code differs from the master's consolidator PAN is marked worth a look with both values named, on the checklist and on any file opened in SCMTR JSON upload, so a stale PAN is caught before it is filed as the party responsible for the box.

It is not the main line operator's code, however much it looks like one. The MLO code is a PAN, it arrives with the vessel, and on any single filing you check it may well match — so it is an easy wrong conclusion to reach twice. Across eleven examined filings it matched on five and differed on six, and the five are coincidence rather than meaning: they are the filings where the consolidator happens also to be the main line operator, so one PAN reaches both fields by unrelated routes. The container agent code occurs in exactly one other place in the whole message — the master consignment's consolidator PAN — in ten of those eleven. The eleventh is a master-only filing whose agent appears nowhere in the message at all. Nor is there a single line PAN per ship to fall back on: one IMO returns two different MLO codes across its own calls.

Containers are declared at both levels

Where a filing has a house bill, the same containers are declared twice: once on the master consignment and once on the house consignment beneath it. The two lists are normally identical, box for box.

The levels are not equally required:

Master-level equipment is mandatory for a fresh entry (SCE, SCX, SCD). This is the authoritative list.House-level equipment is optional — it exists so a house bill can name its own boxes when they differ from the master's.

A consolidation where several house bills sit under one master should show the master carrying every box across all of them, with each house naming only its own.

The common failure here is declaring containers only against the house bill, leaving the mandatory master-level list empty. Since each house is legitimate on its own, nothing about the house bill looks wrong — the gap is at the level above it.

The house B/L date usually matches the master's

Where a filing carries both a master and a house bill, the two issue dates were the same in every case examined — forwarder and carrier filings alike.

That follows from how the pair comes into being: the forwarder issues the house bill for cargo travelling on the carrier's master, at the same point of loading, so both documents are dated that day.

It is a strong default rather than a rule. A house bill dated differently from its master is perfectly possible, and if your paperwork says so, file what the paperwork says. Treat a pre-filled matching date as a starting point to check against the bill in front of you, not as a value that has been decided for you.

Package type codes: the published list is shorter than what is accepted

Every published SCMTR guide carries the same five-code package list — PKG, KGS, MTS, LTR, USG. Filings ICEGATE has Accepted demonstrably carry codes beyond it, including BGS (bags), RLS (rolls), CAS (cases — the code two accepted filings used for wooden boxes) and CRT (crates).

So the published list is a partial extract, not a closed set, and the field is best understood as up to three uppercase letters or digits with customs as the final authority on the value.

Two practical consequences:

Do not force a code from the published five if it misdescribes the cargo. Bags filed as PKG are less accurate than bags filed as BGS, and BGS is accepted.Do not invent a code by guesswork either. Codes like BAG or BAL look plausible but production writes bags and bales as BGS and BLS. Copy the code from your own shipping documents or a previous accepted filing rather than inferring it.

Note also that the package type appears at two levels — against the individual cargo item, and as a summary on the transport document. On a master summarising house bills, the document-level code is often the generic PKG even where the item names something specific.

A previous-declaration block carrying only splitIndctr: "N" is not a reference

Real filings write "prevRef": {"splitIndctr": "N"} — "this consignment is not a split" — with no CIN type and no prior CSN, and customs accepts them; an accepted filing pair carries exactly that shape. So the split indicator alone does not make the block a previous-declaration reference, and the form does not demand the reference fields (CIN type and the rest) because of it. The moment the block carries an actual reference — a CSN number, a CIN type — the rest of the block's required fields apply as normal. Set the indicator to "Y" only when the consignment genuinely is a split of a previously declared one, in which case the prior filing must be referenced.

When prevDec is Y: what a real previous-declaration reference carries

The block above is the empty case. The filled case is what a filer building on someone else's declaration sends — a line referring to a forwarder's CSN, a consolidator referring to a co-loader's — and the MIG defines it field by field: CIN type (cinTyp, 4 characters: MCIN or PCIN), the CIN itself (mcinPcin, 20 characters, as customs issued it), who filed the referenced CSN and as what (csnSbmtdBy, csnSbmtdTyp), its reporting event (csnRptngTyp), the customs location it was filed at (csnSiteId, 6 characters), and the CSN number (csnNmbr, 7 digits) with its date (csnDt). Once the block is opened, the M/O/X matrix makes only cinTyp mandatory; every other field in it is optional.

What live filings actually write is smaller than the definition. On a real arrival manifest, 62 master consignments referred to earlier CSNs, and every one carried exactly the same four reference fields — cinTyp: "PCIN", the 20-character mcinPcin, csnNmbr and csnDt — and none of the submitter, event or site fields. (A manifest's block also carries the package count and unit of the referenced declaration, nmbrOfPkgs and typOfPackage, which the CSN's block does not have.) So the working minimum is: the CIN type, the CIN, the CSN number and the CSN date of the filing you are building on, all taken from their acknowledgement, and prevDec set to Y on the same consignment. Whatever you reference must be the filing for this bill — a CSN number for a different master bill, or the right CSN with the bill number or bill date written differently from the CSN's, is rejected with 164, and its totals then fail 232/233 as well; see Error codes, "Reading several codes at once".

Transhipper code: marked mandatory, accepted blank

The MIG marks the transhipper code as mandatory within the transhipper block. In practice ICEGATE has Accepted a filing that left it blank while carrying a real transhipper bond number, with every error code returned as successful and a PCIN issued for the house bill in question.

This is worth knowing because it is easy to conclude a filing is broken when it is not. If you are checking a rejection, the transhipper code is unlikely to be the cause.

The wider lesson generalises: the MIG's "mandatory" means mandatory within this block if the block is present at all. A block you never opened does not have its mandatory fields demanded of you. What trips people up is that filling in one field of an otherwise-empty block switches on every other mandatory field inside it — so a single stray value can produce a cluster of errors that look unrelated to what you just typed.

Reading an acknowledgement: absent values arrive as the text "null"

When ICEGATE returns an acknowledgement, fields with no value are not empty and are not JSON null. They arrive as the four-character string "null".

This has been confirmed against real acknowledgement files. It matters whenever you read an ACK programmatically or eyeball one: a field reading null has no value, and code that only checks for an empty string or a real null will treat that text as a genuine answer and carry the word "null" forward into whatever it builds next.

If you are comparing an acknowledgement against your filing by hand, read "null" as "customs returned nothing here", not as a value.

Indian customs location codes: how to read one

Locations in a filing use UN/LOCODE-style codes, and Indian customs codes carry an extra trailing character the plain international format does not:

IN + three letters identifying the place + one character for the kind of location.

That final character tells you what sort of facility it is:

1 — a seaport (for example INNSA1, Nhava Sheva)4 — an airport6 — an inland location, such as an ICD or CFSB — a land customs station

Foreign ports carry no such suffix and are the plain five-character form — CNSHA for Shanghai, for instance.

This is useful as a sanity check on a code you have typed or been given. A code ending in 4 where you expected a seaport, or a five-character Indian code where a six-character one belongs, is worth a second look before filing.

Does the order of the fields in the file matter?

Not to customs. JSON objects are unordered by specification, and one vendor's accepted filing on record carries its consignment keys in what looks like hash order — nothing about acceptance turns on it. It matters to a person reading two files side by side, which is what a filer does when comparing a download against another vendor's file.

Every block the platform writes follows the order the accepted filings on record carry: the header, then decRef, authPrsn, vesselDtls, voyageDtls and mastrCnsgmtDec; within a consignment MCRef, trnsprtDocMsr, trnsprtEqmt, houseCargoDec; within a house bill HCRef, locCstm, trnshpr, trnsprtDoc, trnsprtDocMsr, itemDtls, trnsprtEqmt, itnry; and each block's fields in the order the accepted filings write them — measured, not chosen, which is why the party blocks carry the country sub-division before the country although the form asks for the country first.

Until 17 September 2026 a file made from a saved draft could come out with each block's fields sorted shortest-first — jobDt, jobNo, msgTyp, prtofRptng, rptngEvent instead of msgTyp, prtofRptng, jobNo, jobDt, rptngEvent — an artefact of how drafts are stored, not of anything typed. A download made since then is in the expected order; if a file of yours reads that way, download it again. Checked against every accepted CSN held here (106 files), the platform's order agrees with them on every block, with one exception worth knowing: three house bills end their HCRef with prevDec, consolidatorPan where the other 192 end consolidatorPan, prevDec, and the platform writes the latter.

These notes describe behaviour observed in real filings and acknowledgements, not official guidance. ICEGATE's published Message Implementation Guide remains the authority on what is required, and customs remains the authority on what is accepted — confirm anything load-bearing before you rely on it, or consult a licensed customs broker.