Why customs rejects a filing

ICEGATE returns a numeric error code and a terse description. This maps the ones filers actually hit onto what went wrong and what to change. Codes are grouped by cause, because the fix is usually shared across a whole family.

Two levels of rejection exist and they look different:

Structurally invalid — the file is not a valid SCMTR message at all. Comes back as an _SFL.json carrying JSON-Schema vocabulary and no error code from this list. Something is malformed rather than merely wrong.Business validation — the file parsed, and customs disagrees with its contents. That is everything below.

Why would customs reject my CSN? The reasons in plain words

A CSN — or its amendment, or an export's SCX — is refused for one of a handful of reasons. Each has its own section below, with the error codes that name it and what to change:

The file disagrees with itself. Package counts, weights, the number of containers or the number of lines do not add up across master bill, house bills and containers. See The arithmetic ones below.Something is declared twice. The same container twice on one bill, or two master consignments carrying the same master B/L and the same house bill (375/376). See Duplicates.The bill has been filed before. Customs already holds this master or house bill, often from an earlier filing or from other software (122/123), or the CSN or CIN quoted has already been referenced by someone else. See Referencing a prior filing.The consolidation shape is one customs does not recognise. Cargo type, cargo movement, the consolidation indicator and the previous-declaration flag are checked together (115/118); a master marked consolidated with no house bills under it is 163. See Consolidation shape.The wrong PAN is in the wrong place, or the filer is not allowed to file it. Your PAN goes on the house bill, the carrier's on the master. See Consolidator PAN and who is allowed to file.A party's country or identity code does not match. See The parties.The cargo movement does not suit the port the goods are received at (365/366). See Cargo movement against the port of receipt.The amendment points at the wrong CSN, the wrong line, or comes too late. See Amendments and deletions.The vessel call does not match the carrier's. The conveyance reference or rotation is not the one the shipping line filed under, or its manifest is not in yet. See Vessel and voyage.Customs gives no reason at all — 700 Error-Refile. See What to do about a 700.The file never reaches validation, and ICEGATE sends an e-mail instead of an acknowledgement: a control number already processed for that job date, a DSC it will not accept, a character that is not plain text, or a sender ID it does not know. See Refusals that arrive by e-mail.

Before you send, the platform checks your CSN against the refusals customs has been seen to make that a file can show in advance, and shows those in red. Some cannot be seen from your file alone — a bill someone else already filed, a 700. Checks drawn from the published rules alone, with no refusal behind them yet, show in amber (what the checks mean). After a refusal, drop the acknowledgement together with the CSN it answers on SCMTR JSON upload. Each error is then shown on the field it names, beside the value your file actually carries.

The arithmetic ones — the cheapest to prevent

Customs adds up what you declared and checks it against itself. These are the cheapest to prevent, because every one of them can be settled from your own file before it is sent. How often they cause a refusal is not known: none of the refusals we hold is an arithmetic one.

The fix is nearly always the same: count again and make the three levels agree. A container must exist at every level that mentions it, and the totals must be the real totals.

The wizard keeps 105 from happening on a filing built in it: containers are typed once, on the master bill, and each house bill ticks the ones it is in, so a house cannot name a box the master lacks. A draft made before that layout, or an imported file, can still carry one — the house bill step then shows the box in red with Add it to the master B/L, and the review says so until it is done.

Duplicates

Two rows carrying the same container number is the classic one — it happens when a row is duplicated to save typing and the container id is not changed afterwards.

375 and 376 come back on a CSN acknowledgement — an import CSN was refused for them on 23 September 2026 — and are the same mistake one level up: two master consignments carrying the same master B/L and the same house bill — usually a line copied to start a second and then left. Customs identifies a record by that pair, reads the two 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. The platform blocks that pair before you file (since 23 September 2026, when an import was refused for it). The same master B/L with different house bills is declared split cargo and only warns. Both codes are published in the vessel manifest's shared error list rather than the CSN guide's own, so looking them up in the CSN MIG finds nothing — but they are returned to a CSN all the same, not only to a manifest.

Consolidation shape

The combination of consolidation indicator, cargo type, cargo movement and previous-declaration flag is validated as a combination, not field by field. That is why these read so opaquely.

163 is worth calling out: you marked the master as consolidated and then filed no house bills under it. Either add the houses, or the master is not consolidated.

115 and 118 are the wider pair and the ones that read as though nothing in particular is wrong: they say that cargo type, cargo movement, the consolidation indicator and the prior-declaration flag together are not a combination customs recognises. The MIG publishes the list of combinations it accepts, and cargo type, movement and the combination customs checks has all of it. The single commonest cause is import cargo declared with a transhipment movement — IM never takes TC, which belongs to TR and EX.

Consolidator PAN and who is allowed to file

The convention that prevents most of these: your PAN goes on the house bill, the carrier's on the master. If your own PAN is on the master consignment, you are claiming to be the carrier.

The parties: a country code that looks right and is refused anyway

"Buyer" means the consignee. ICEGATE's error list uses the trade's word where the message uses the customs one, which is why a filer hunting the CSN for a "buyer" field finds none. Three codes name three fields, each on the party block of the transport document the error hangs off:

All three take two characters, ISO 3166-1 alpha-2: IN India, US the United States, CN China. So a filing refused on a value that is genuinely a two-letter ISO code is being refused for something other than the country not existing, and re-typing it changes nothing. Work it in this order.

1. Read the file, not the form. The trade writes countries three letters long — IND, USA, CHN — and this field is two characters wide. An alpha-3 code, a country name typed in full, a stray space or an empty value all read as invalid, and the value that was on your screen is not always the value that reached customs. This is the commonest cause by a distance.

2. Check which bill the error names. The master consignment carries its own consignee, and so does every house bill under it. The acknowledgement hangs the code off one transport document — the value to change is the one on that document, not the one you remember typing.

3. Ask whether the country contradicts the party's own code. On an arrival message the consignee is the Indian importer: the MIG makes the consignee code mandatory for SCE and SCD, and every code type customs accepts — IEC, PAN, GSN, GSD, GSG — is an Indian registration. Inferred, not published: a foreign consignee country sitting against an Indian PAN or IEC reads as a contradiction, and that is a likelier account of this code than a country customs does not recognise — but ICEGATE states no such rule, so treat it as the thing to check rather than as the answer. The other half of the same check: that the consignor and consignee have not been filled in the export way round, with the overseas buyer where the Indian importer belongs.

4. Clear an Indian state code from a foreign party. The country subdivision code is the MIG's Indian state numbering, and nothing else. A foreign party carries its province as a name with the code left empty — a 07 inherited from a copied address book beside a country of US is a party block that disagrees with itself. A province name typed into the shipper's code field is not, on the record, a refusal: customs accepted five import CSNs in September 2026 that carried one there, some longer than the field's nine characters. Blank is still the clean shape, and SCMTR flags it in amber rather than blocking the file.

5. If the consignee's country really is right, read the notified party's. Inferred, and worth knowing: ICEGATE's own published error list gives the description Invalid Buyer Country Code to both 44 and 46, where the MIG's table gives 46 to the notified party. The notified party is usually copied from the consignee, and its country is the field most often not carried over.

Is a foreign consignee allowed at all?

Yes — and it is rare enough to be worth checking rather than assuming. In every real arrival filing we hold, the consignee's country is IN and so is the notified party's: 62 consignee blocks across fifteen files, IN every time, while the consignor is foreign in 60 of the 62. A SAM / SDM measured separately came out the same way — 176 consignee blocks, 175 IN and one US, on a real consignment. A US buyer is legitimate; it is also the shape that gets typed by mistake.

The value the code names looks correct — now what?

That is a family of situation rather than a family of code, and the same three checks resolve nearly all of it, in this order:

The file does not say what the form says. Codes get truncated, padded, uppercased, pasted with a trailing space, or typed into the field beside the one you meant.The same field exists at another level. Master and house each carry a full set of parties; containers are declared at three levels. Being right in one place is not being right in the place the error names.A second field contradicts the first. Customs validates combinations — country against the party's identity code, package type against packages, size against the referenced CSN — and reports the failure on one field of the pair. The other one is often the one to change.

Uploading the declaration and its acknowledgement together does the first two mechanically. SCMTR JSON upload places each error on the block it names and quotes back the value sitting there, so "we entered US" and "the file says USA" stop being the same sentence. Reading a rejection with the declaration to hand is a different job from reading it alone.

A code may arrive zero-padded. Real acknowledgements write "044" where this page and the MIG table write 44 — the same code, and the padding is not applied to every code in the file. Strip the leading zeros before looking a code up here.

Cargo movement against the port of receipt

These two check locCstm.crgoMvmt against trnsprtDoc.prtOfReceiptCdd — one field against another, in a different block. The rejection arrives on the transport document, and the field to change is in Location & customs, which is why it reads as though it names nothing.

A 365 has two possible fixes and customs cannot tell you which: set the movement to LC, or — if the cargo really is going inland — correct the receipt port to the ICD's code. Decide from where the cargo is actually going, not from the error. The full rule, the evidence behind it and the one shape that has gone both ways are in cargo type, movement and the combination customs checks.

On an export the same code means the other thing. An export moving on to a foreign port is TC, and EX + LC is a pair the trade-scenarios table does not list at all (115). So when 365 arrives on an export, it is the port of receipt that is wrong: it named the Indian port the cargo leaves from, and it should carry the foreign destination's code — where the cargo is received. One filer collected 365 (Indian receipt port), then 115 (movement changed to LC), then got the structure through with the foreign port; the app now refuses the first shape before it is sent. The same filing was refused 091 — Port of Call Can Not Be Same as Next Port of Call — for an itinerary whose only leg ran from Kattupalli to Kattupalli: an export's leg is the one to the foreign port. An import's terminal leg may repeat the arrival port, and customs holds an accepted filing that does.

What else is an export (SCX) refused for — 286, 383/384, 239 with 381, 709?

Four more, all seen on export refusals in September 2026 and all absent from the exports customs accepted that month. It is a small base — three acceptances and the refusals filed beside them — but each refusal is unambiguous about what it objected to. The app checks every one before an export is sent, and the guided export steps build a filing that cannot trip them.

381, 383, 384 and 709 are in neither the message guide's code table nor the official error list — like 700, they are known only from real replies. The whole export shape, and where each of these is prevented in the guided steps, is in exports: filing an SCX, shipping bills and PCINs.

The CIN, container and weight codes an export can meet — 053, 073, 091, 099, 124, 128, 148/149, 159/161, 220, 221, 225, 237, 239, 251–256

Every code in this table is in ICEGATE's published error list (SCMTR Error Codes & Descriptions), in the wording shown. A reply prints the two-digit ones with a leading zero — 053, 073, 091, 099 — and the lists write them without. Only some have been seen on real export refusals; the last column says which, so that a reading of the wording is not mistaken for experience.

Which export codes are in no published list? 381, 383, 384 and 709 appear in neither ICEGATE's published error list nor the message guide's code table — they are known only from real acknowledgements. 365 and 366 are in the message guide's newer table and not in the separately published list. Every code in the table above is in both. And for none of them does any customs document say more than the one line of wording: there is no published explanation of 159, 286 or 365, which is why what they mean on an export had to be learned from refusals.

Referencing a prior filing

122/123 usually means a duplicate submission rather than anything subtle — the bill went in already, possibly from other software, and customs still holds it. Look the bill up with Check an ICEGATE file before re-entering it; the three situations that produce the pair, and the one measured case where a fresh re-entry was taken, are in Troubleshooting.

Amendments and deletions

306 and 307 are the ones to understand, because they explain the whole amendment model: customs matches amendment records by line number and sub-line number. Those numbers are an identity, not a position. Renumbering rows after deleting one will point your update at somebody else's record — which is why line numbers are never rewritten inside an amendment.

Vessel and voyage

These generally mean the carrier's arrival manifest is not in place yet, or your voyage reference does not match the one it was filed under. Check the conveyance reference number against the carrier's, not against your own paperwork.

One code you should never see

999 is reserved for internal amendment use and should never reach a filer. If it does, it is not something you can fix by editing the filing.

When the response carries no field detail

Some rejections — notably 700 Error-Refile — come back with no field-level information at all. There is nothing to read into it: the filing has to be checked over and sent again. The arithmetic checks at the top of this page are the first place to look — not because they are known to cause a 700, but because they can be settled entirely from your own file.

What to do about a 700

700 Error-Refile is a refusal without a reason, so work it as a checklist rather than looking for the field it names — it names none.

Work it by elimination rather than by reading, because these four are not four guesses. Upload the declaration alongside the acknowledgement on SCMTR JSON upload and all four are run against the bytes you actually sent, each answering pass, fail with the offending value quoted, or an honest "this one could not be settled". Three are settled from the file itself — though the duplicate check can only speak where the filing is one recorded here, since a control number is only re-used against transmissions already on record. The fourth, the voyage, is answered from customs' last answer about that ship as it already stands: it can say your VCN was among customs' calls, or that it was not and name what customs listed at your port instead, or that the answer on record is missing or too old to stand for today. What is still open at the end is the short list to work by hand.

The order is the cheapest check first, not a ranking of causes. Nobody outside customs knows what a 700 usually means: none of the seven on record here names a field, and neither does anything ICEGATE has published. Treat any claim that one cause is "the usual one" as a guess.

The arithmetic, in this order: package counts on the boxes against the consignment total, container weights against the gross weight, each master container's weight and packages against the house rows carrying that box, and totalNoOfTrnsprtEqmtMnfsted and totalNmbrOfLines against what the file actually contains. SCMTR JSON upload runs every one of these checks on the file for you.Whether it is a duplicate. If you have sent this filing before, send the new transmission under a fresh sequenceOrControlNumber. That is the safe choice rather than a proven cause: ICEGATE's published answer to a re-used number is an e-mail, "The Control Number has already been processed", not a 700 — and the 700 whose resend is held was sent again the same day under its original control number and job number, and accepted — as was every other 700 on record, seven in all.The consolidation shape — consolidatedIndctr against whether house bills are actually present, and the consolidator PAN carrying its PAN: prefix.The voyage — the VCN in cnvnceRefNmbr against the call you mean, and the IMO in trnsprtMeansId against its check digit — or a VCN customs has since replaced because the vessel changed; the filing page says what customs listed for the ship when you filed, and whether your VCN was among it. A possibility rather than a diagnosis. Every 700 reply read here (seven) marked its vessel and voyage blocks 00 Successful, but that is thin evidence either way: one of them also marked 00 on master-bill blocks that the accepted version of its filing does not contain at all.

The header's indicator is not on this list. It used to be — "it must be P, a T is test-flagged" — until two filings flagged T came back accepted, each with a CSN issued. Customs has taken T files as live filings, so the flag is not a reason for a 700, and changing it is not a fix. Filings made in this app go as P regardless.

Then correct the draft and file it again. A rejected filing never received a CSN number, so this is a fresh filing rather than an amendment — there is nothing yet to amend.

ICEGATE has published no explanation of 700 itself — it is absent from the MIG's table and from every official list we hold. Its published guidance for the refusals that arrive by e-mail (below) is the same shape as the checklist above: correct the file and re-file it under a different job number. Two things have been said about it since, one published: on 12 September 2026 ICEGATE's engineers described a 700 on a large manifest file as database contention that clears on a later identical send, and ICES Advisory 38/2026 (21 September 2026, Q6) says the processing of large manifest files has been moved to dedicated schedulers with re-indexed databases. Neither names 700, so a 700 on a small, correct file is still worth the checklist; a 700 that clears on an unchanged re-send was most likely load.

Can a timeout, a wrong port code or a wrong PAN cause a 700?

Filers pass round a list of causes for a 700 — a timeout, a port code that is not in customs' database, or a party's PAN, GSTIN or IE code entered wrongly — with the advice to check the last two, then regenerate, sign and upload afresh. The list comes from filers' experience, not from ICEGATE, and none of it is confirmed. What can be said about each:

A timeout, or a failure on ICEGATE's side. Plausible, since "Error-Refile" reads as an instruction to send it again rather than as a verdict on your data. But the transient failures ICEGATE has documented arrive by e-mail — "Something went wrong", "Please try after some time" — not as a 700 in an acknowledgement. If the checklist above finds nothing wrong, re-sending the unchanged file under a fresh control number is a reasonable next step. If it is refused again, stop and raise it with the ICEGATE helpdesk.A port code customs does not know. Less likely to show up as a 700. Customs has numbered errors for nearly every port field — 37 and 38 for the ports of acceptance and receipt, 58 first port, 60 destination, 61 next port, 28/29 for the itinerary — so a port it refuses would normally come back as one of those, naming the field. Checking your port codes costs nothing, though; see which port goes where.A wrong PAN, GSTIN or IE code for a party. Less likely for the same reason. There are numbered errors for the consignor's code (40), the notified party's PAN (111, 144), each party's code type (39, 41, 45, 136), and the consolidator's PAN (92, 168 and more). ICEGATE's own guidance files a wrong consignee PAN or IE code under 42, Invalid Buyer Code. It is still worth checking the consignee's code and code type against their GSTIN or IEC certificate — see party codes and PANs.

But a 700 names no numbered check at all, so none of these is ruled out either. One further observation from the single specimen: the refused reply listed the house bill's reference and location blocks and stopped there. Its transport document (parties and ports), items, containers and itinerary do not appear, though all four do in the reply that accepted the same filing. From one file there is no telling whether the refused version lacked those blocks or ICEGATE simply stopped reading there. It is worth checking that every house bill carries all four.

Changing the job number by hand. A new transmission needs a new sequenceOrControlNumber in the header. Changing decRef.jobNo with it, and the job number in the file name, so all three agree, is harmless, and it is what ICEGATE's e-mailed refusals ask for ("re-file with a different job number"). Make the change before you sign: editing a signed file breaks the signature, and ICEGATE refuses it with "DSC Failed". Re-sign after any change — see signing your filing.

Refusals that arrive by e-mail, with no acknowledgement at all

Some refusals never produce an _ACK or _SFL file. The filing is stopped before validation and ICEGATE e-mails the registered address instead. Its 2025 FAQ on SCMTR filing names them, and its answers are quoted here because they are the only official text on the subject:

The 2022 message-filing FAQ lists the same silence from the other side — why an acknowledgement never arrives: the file name does not follow the seven-part convention; the sender ID is not the entity's registered ICEGATE ID; the DSC is not the one registered; the wrong signing utility was used; the file was opened after signing; or it was sent from a different computer than the one that signed it. It adds one case that does produce an ACK: every block reads 00 Successful while the e-mail says the file failed. That happens when a required object is missing entirely — the acknowledgement mirrors the objects that were present, so an absent block has nowhere to show its error. ICEGATE asks for such cases to be reported to its helpdesk.

What ICEGATE itself says to do about the common codes

In the same 2022 document ICEGATE published the sea-message errors it saw most, each with its own resolution. The wording below is ICEGATE's, lightly trimmed; the code is the number in the acknowledgement, and the letter prefix ICEGATE attached (HTD111, MTE082) reads as the level and block — H house, M master; TD transport document, TE equipment, ID items, TR measures, LC location, CT transhipper, CR consignment reference, VGD voyage.

Three of its answers are worth reading against the MIG and against real filings. On 20, the format it quotes is 2021's: every VCN on an accepted filing seen here is a four-character port code, the year, then a six-digit serial — NSA12026081299, fourteen characters — not a six-character location code and a four-digit serial. Do not "correct" a VCN that customs' own enquiry lists to match the example; the number the port issued is the one to file. On the previous-declaration block, the document says: when quoting a CSN number, write csn in cinTyp; when quoting a PCIN or MCIN, write that in mcinPcin. The MIG's own definition of cinTyp lists MCIN/PCIN, and every real reference we have measured carried PCIN — so treat csn there as ICEGATE's 2022 advice for the CSN-number case, not as the everyday value. And on SOC, its gloss — owned "by the Shipping" — is ambiguous where the field name is not: SOC is shipper-owned container, so Y means the shipper's box, N the line's. Almost every container on a consolidated filing is the line's, and N is what accepted filings overwhelmingly carry.

How many error codes are there?

453, transcribed from the MIG's own table for SACHM22 v1.5. This page groups the ones that actually occur into families rather than listing all of them, because the great majority never appear in practice.

A code that is not in that table is worth a second look before you search for it. 700 "Error-Refile" appears in real acknowledgements and in no published list. And ICEGATE fronts several customs systems, each answering from its own list — the Bill of Entry, the legacy Sea IGM, the custodian messages — so a number that is not a CSN code may simply be another system's: Which error list does my code come from? tells them apart by the message id in the reply. 994 has been asked about and, as of September 2026, is in none of eighteen published lists, the Bill of Entry's included (that one has 995, 998 and 999 — all system-side errors — but no 994). The same page says what can and cannot be inferred from that, and what to send the helpdesk.

They are the second level of validation, and that distinction matters when you are reading a rejection:

Structural validation runs first. A file that is malformed against the schema comes back as an _SFL.json carrying JSON-Schema vocabulary — maxLength, pattern, required — and no error code from the table at all. If you are looking for a numeric code and cannot find one, this is why.Business validation runs only on a file that passed structurally, and that is where the 452 codes live.

How do I read an acknowledgement file?

The acknowledgement mirrors your filing's own structure and hangs the verdict off each block, so read it block by block rather than top to bottom.

headerField.accpStatus is the overall verdict — Accepted or Rejected.headerField.uniqueId is the transmission id ICEGATE assigned. It identifies the transmission, not the filing, and it is how the platform tells that a CSN number on customs' public record belongs to this send and not to another filing on the same bill.Each block carries its own errorCode array. {"errorCode": "00", "errorMessage": "Successful"} means that block passed — so a file full of 00s with one real code in decRef is telling you exactly where the problem is. 00 is not an error.Absent values arrive as the literal string "null", not as JSON null. "csnNmbr": "null" on a rejection means no CSN was granted, which is what you would expect — a rejected filing never gets one.master.decRef.csnNmbr and csnDt carry the CSN and its date on an acceptance. Those two values are what every later amendment or deletion references, so they are the ones worth keeping.

A worked reading: accpStatus: "Rejected", authPrsn and vesselDtls both 00 Successful, and decRef carrying 700 Error-Refile with csnNmbr: "null" — the message was structurally fine, the authorised person and the vessel were accepted, no CSN exists, and the refusal is the reasonless one. Work the 700 checklist above, then file again.