How to file a CSN

This guide walks through how a CSN filing works under India's SCMTR framework — useful background whether or not you're using this platform to file.

Who files a CSN

A CSN is filed by 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're a vessel operator filing the top-level manifest itself, that's a different message type (the Sea Arrival/Departure Manifest), not a CSN.

Is filing one mandatory? Not in law. ICEGATE's SCMTR FAQ describes the CSN as a facilitative measure: it lets the party that actually holds the cargo details declare them to customs directly, without handing them to the shipping line. A forwarder is free not to file one and to give the details to the line for its manifest instead. What filing it buys you is that your shippers' and consignees' details go to customs from you, and the line's manifest is meant to refer to your filing rather than re-declare the bill — see Two companies, one master bill of lading for how the pair fits together and the deadline it creates.

The basic filing flow

A vessel operator's Master Consignment already exists or is being filed in parallel. A CSN always references a master consignment — it can't stand alone.You file a fresh CSN (reporting event SCE for an import entry, or SCX for an export exit), declaring the master consignment reference, vessel and voyage details, the authorized filer's identity, and one or more house-bill-level declarations underneath it — each with its own consignor, consignee, goods description, item detail, and container/equipment detail.Customs (via ICEGATE) validates the filing against the published Message Implementation Guide (MIG) for the message and returns either an acceptance (with a CSN number/CIN assigned) or a structured rejection listing exactly which fields failed validation and why.Once accepted, later changes go through amendment or update filings (reporting events SCA/SCU) that reference the original CSN number rather than re-filing from scratch.A cargo confirmation filing (SCC) closes out the reference once the cargo movement is fully accounted for.

What varies by reporting event

The same overall CSN structure is reused across all six reporting events (SCE, SCX, SCD, SCA, SCU, SCC), but which fields are required, optional, or not applicable shifts depending on which one you're filing:

Fresh filings (SCE/SCX/SCD) need full vessel, voyage, and cargo detail since nothing about this shipment has been declared before.Amendments and updates (SCA/SCU) need the original CSN reference plus only the fields that changed — vessel/voyage detail is typically optional here since it was already established.Cargo confirmation (SCC) is a lighter-weight filing that closes out a reference rather than introducing new cargo detail.

Filing the wrong combination of fields for a given reporting event gets a filing rejected — always check the mandatory/optional rules for the specific reporting event you're filing, not just the overall CSN structure.

Master vs. house-level detail

A single CSN filing can declare cargo at two levels:

Master consignment level — the top-line reference tying back to the vessel operator's manifest, plus any cargo detail that applies to the whole consignment.House consignment level — nested underneath, one entry per individual house bill a consolidator has issued to a shipper. Each house-level entry carries its own consignor/consignee, goods description, item-level HS codes, and container/equipment detail, independent of the other house bills sharing the same master consignment.

A single master consignment can have any number of house consignments nested under it — this is exactly the "many house bills consolidated into one container/booking" scenario a freight forwarder or NVOCC handles routinely. Neither the MIG nor the message schema puts a cap on that count, and it is not six or any other small number — we hold accepted filings with well over a dozen house bills under one master. If a tool or portal refuses more than a handful, that is the tool's own limitation, not an ICEGATE rule ("Is there a limit on how many house bills I can file under one master?" has the detail).

It can also have none. A master consignment with no house consignment under it is normal — that is what a straight bill looks like, where the carrier issued the transport document directly to the shipper with no forwarder in between. The master B/L number is mandatory in every reporting event; the house bill is mandatory only for SCE, SCX, SCD and SCA, and is excluded entirely for SCU and SCC. So a master without a house is routine, while a house without a master never happens.

Because each house carries its own parties, a house consignor or consignee that differs from the master's is normal rather than a mistake — on a consolidation it is the expected result. "Using SCMTR" covers where those fields sit in the form and how the "Same as consignee" tick behaves.

For the field-level conventions real accepted filings follow — which consolidation indicator to use, whose PAN goes where, and which package codes customs actually takes — see "What accepted CSN filings actually carry".

Common fields you'll need on hand

Master and house B/L numbers and datesPort of loading, port of discharge, and any transhipment portsConsignor and consignee name and address for each house billHS codes and goods descriptions for each cargo itemContainer numbers, types, and seal numbers for each piece of equipmentYour ICEGATE-registered filer code and the authorized representative's PAN

What does a CSN look like as a file?

Asked often enough to be worth answering directly. Below is a complete SCE filing — one master bill with one house bill under it, one container, one item — with every party invented. It carries the shape and the conventions of filings customs has accepted, so it is a reliable model of what belongs where, but the values are fictional and it is not a filing you can send.

{
  "headerField": {
    "senderID": "ACMEFORWARD",
    "receiverID": "INNSA1",
    "versionNo": "SCE1102",
    "indicator": "P",
    "messageID": "SACHM22",
    "sequenceOrControlNumber": 4821,
    "date": "20260829",
    "time": "T11:04",
    "reportingEvent": "SCE"
  },
  "master": {
    "decRef": {
      "msgTyp": "F",
      "prtofRptng": "INNSA1",
      "jobNo": 4821,
      "jobDt": "20260829",
      "rptngEvent": "SCE"
    },
    "authPrsn": {
      "sbmtrTyp": "ANC",
      "sbmtrCd": "AAAAA0000A",
      "authReprsntvCd": "AAAAA0000A"
    },
    "vesselDtls": {
      "modeOfTrnsprt": "1",
      "typOfTrnsprtMeans": "10",
      "trnsprtMeansId": "9169926"
    },
    "voyageDtls": {
      "cnvnceRefNmbr": "NSA12026081299",
      "totalNoOfTrnsprtEqmtMnfsted": 1,
      "totalNmbrOfLines": 1
    },
    "mastrCnsgmtDec": [
      {
        "MCRef": {
          "lineNo": 1,
          "mstrBlNo": "ACME2607639",
          "mstrBlDt": "20260811",
          "consolidatedIndctr": "R",
          "consolidatorPan": "PAN:BBBBB1111B",
          "prevDec": "N"
        },
        "trnsprtDocMsr": {
          "nmbrOfPkgs": 343,
          "typsOfPkgs": "PKG",
          "marksNoOnPkgs": "N/M",
          "grossWeight": 13260.0,
          "unitOfWeight": "KGS"
        },
        "trnsprtEqmt": [
          {
            "eqmtSeqNo": 1,
            "eqmtId": "ESDU1401993",
            "eqmtTyp": "CN",
            "eqmtSize": "2210",
            "eqmtLoadStatus": "FCL",
            "eqmtSealTyp": "BTSL",
            "eqmtSealNmbr": "D2712521",
            "socFlag": "N",
            "cntrAgntCd": "BBBBB1111B",
            "cntrWeight": 13260.0,
            "totalNmbrOfPkgs": 343
          }
        ],
        "houseCargoDec": [
          {
            "HCRef": {
              "subLineNo": "1",
              "blNo": "HSE2607639",
              "blDt": "20260811",
              "consolidatedIndctr": "H",
              "consolidatorPan": "PAN:AAAAA0000A",
              "prevDec": "N"
            },
            "locCstm": {
              "firstPrtOfEntry": "INNSA1",
              "destPrt": "INDER6",
              "nxtPrtOfUnlading": "INDER6",
              "typOfCrgo": "IM",
              "itemTyp": "OT",
              "crgoMvmt": "TI",
              "natrOfCrgo": "C"
            },
            "trnshpr": {
              "trnshprCd": "DDDDD3333D",
              "trnshprBond": "9900112233"
            },
            "trnsprtDoc": {
              "prtOfAcptCdd": "CNNSA",
              "prtOfAcptName": "NANSHA CHINA",
              "prtOfReceiptCdd": "CNNSA",
              "prtOfReceiptName": "NANSHA CHINA",
              "cnsgnrsName": "EXAMPLE TRADING CO., LIMITED",
              "cnsgnrStreetAddress": "12 EXAMPLE ROAD",
              "cnsgnrCity": "NANSHA",
              "cnsgnrCntryCd": "CN",
              "cnsgnesName": "EXAMPLE IMPORTS PRIVATE LIMITED",
              "cnsgnesCd": "CCCCC2222C",
              "typOfCd": "PAN",
              "cnsgneStreetAddress": "44 EXAMPLE STREET",
              "cnsgneCity": "NEW DELHI",
              "cnsgneCntrySubDiv": "07",
              "cnsgneCntrySubDivName": "DELHI",
              "cnsgneCntryCd": "IN",
              "nameOfAnyOtherNotfdParty": "EXAMPLE IMPORTS PRIVATE LIMITED",
              "panOfNotfdParty": "CCCCC2222C",
              "typOfNotfdPartyCd": "PAN",
              "notfdPartyStreetAddress": "44 EXAMPLE STREET",
              "notfdPartyCity": "NEW DELHI",
              "notfdPartyCntrySubDiv": "07",
              "notfdPartyCntrySubDivName": "DELHI",
              "notfdPartyCntryCd": "IN",
              "goodsDescAsPerBl": "BACK LIGHT UNIT"
            },
            "trnsprtDocMsr": {
              "nmbrOfPkgs": 343,
              "typsOfPkgs": "PKG",
              "marksNoOnPkgs": "N/M",
              "grossWeight": 13260.0,
              "unitOfWeight": "KGS"
            },
            "itemDtls": [
              {
                "crgoItemSeqNmbr": 1,
                "hsCd": "85299090",
                "crgoItemDesc": "BACK LIGHT UNIT",
                "unoCd": "ZZZZZ",
                "imdgCd": "ZZZ",
                "nmbrOfPkgs": 343,
                "typOfPkgs": "PKG"
              }
            ],
            "trnsprtEqmt": [
              {
                "eqmtSeqNo": 1,
                "eqmtId": "ESDU1401993",
                "eqmtTyp": "CN",
                "eqmtSize": "2210",
                "eqmtLoadStatus": "FCL",
                "eqmtSealTyp": "BTSL",
                "eqmtSealNmbr": "D2712521",
                "socFlag": "N",
                "cntrAgntCd": "BBBBB1111B",
                "cntrWeight": 13260.0,
                "totalNmbrOfPkgs": 343
              }
            ],
            "itnry": [
              {
                "prtOfCallSeqNmbr": 1,
                "prtOfCallCdd": "CNNSA",
                "prtOfCallName": "NANSHA CHINA",
                "nxtPrtOfCallCdd": "INNSA1",
                "nxtPrtOfCallName": "NHAVA SHEVA",
                "modeOfTrnsprt": "1"
              },
              {
                "prtOfCallSeqNmbr": 2,
                "prtOfCallCdd": "INNSA1",
                "prtOfCallName": "NHAVA SHEVA",
                "nxtPrtOfCallCdd": "INDER6",
                "nxtPrtOfCallName": "ICD DADRI",
                "modeOfTrnsprt": "3"
              }
            ]
          }
        ]
      }
    ]
  }
}

Things worth noticing, because they are what a filing usually gets wrong:

The same container appears twice, once on the master and once on the house, and that is correct. Both copies carry the seal, the weight and cntrAgntCd, as every accepted filing on record does; the house's weight and packages are its own share of the box.The packages and weights agree across the item, the house, the box and the master.consolidatedIndctr is R on the master and H on the house. A master with no house bill under it is M instead, and then the parties and the cargo sit on the master itself.consolidatorPan carries the PAN: prefix and nothing else does — cnsgnesCd, panOfNotfdParty, cntrAgntCd, sbmtrCd and authReprsntvCd are all bare.The itinerary's second leg is modeOfTrnsprt: "3" — road, for the inland move to the ICD. It is not sea all the way through.The trnshpr block is filled because the movement is TI. The MIG's trade-scenarios table requires it on every first-time declaration that moves onward under bond — TI for any cargo type, TC or FT for export and transhipment cargo — and never for LC or DT. The code is the transhipper's PAN, bare; the bond is their transhipment bond at this port, and the same company holds a different one at every port. Both values here are invented. See Transhippers, CFSs and bond numbers, and Cargo type, movement and the combination customs checks for what else that IM + TI pair commits the record to.There is no digSign block here. The signature is applied to the file at submission.

The same filing as an amendment, and as a deletion

A deletion is not its own message type. Both are msgTyp: "A", and what separates them is amdType — U to update, D to delete. Both reference the CSN customs granted, so both need csnNmbr and csnDt from the acknowledgement of the filing being changed.

Copy the two together, from the same acknowledgement. The pair is the reference, not the number alone, and a number carrying someone else's date is the easy mistake to make when you are amending several filings in a sitting. Nothing in the message will catch it — the shape is valid, so it goes to customs as a well-formed reference to the wrong filing.

"decRef": {
  "msgTyp": "A",
  "prtofRptng": "INNSA1",
  "jobNo": 4822,
  "jobDt": "20260901",
  "rptngEvent": "SCA",
  "csnNmbr": "1431790",
  "csnDt": "20260825",
  "amdType": "U"
}

For an amendment, reportingEvent and rptngEvent become SCA, versionNo becomes SCA1102, and the rest of the filing is sent as it should now read — with amdType: "U" on every master bill, house bill, container, cargo item and route leg it carries, changed or not, as the accepted update on record does (SCMTR sets these for you; see Do I have to set the "Amendment" flag). For a deletion, amdType is D and the message carries almost nothing else: the header, decRef, authPrsn and vesselDtls, with no cargo tree at all, because you are withdrawing the whole CSN rather than changing part of it.

indicator stays P on every one of these. It says the message is for production, not what kind of message it is.

Amendments and rejections

If a filing is rejected, the response identifies the specific field(s) and reason. A rejected filing can typically be corrected and resubmitted as a fresh filing (since no CSN number was ever assigned). Once a filing has been accepted and later needs correcting, that's an amendment (SCA) referencing the existing CSN number, not a new fresh filing.

This guide reflects general SCMTR/CSN filing practice as commonly understood. Requirements can and do change — always confirm current mandatory-field rules against the official ICEGATE Message Implementation Guide before filing, or consult a licensed customs broker.