ICEGATE error codes

This is the complete second-level validation table for SACHM22 — 452 codes, in the MIG's own wording, including its own typos (Incoorect, Redundent, Comibination, Aleady). Look a code up by number in the complete list at the bottom, or read the family it belongs to for what to actually change.

There are two levels of validation, and only one of them uses these codes

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 numeric code from this table at all. If you are hunting for a code and there is none, this is why: the file did not get far enough to be business-validated.Business validation runs only on a file that passed structurally. That is where every code on this page comes from.

How do I read an acknowledgement file?

Reading an acknowledgement from customs covers the file itself — which of the three you have, the two levels of validation, and what the verdict means. This page is the code table behind it.

The quickest way is to let the platform read it. Sign in and open Declarations → Check a filing or acknowledgement, then drop the …_ACK.json in. It reports the verdict and what follows from it, and for every error the description below, where in the filing it sits, whether it refuses the whole filing or names one value, and numbered steps for that particular code. Add the declaration it answers and each error is anchored onto the block it names, with the offending value quoted back. The rest of this page is the reference behind that, and what to read when you have the acknowledgement but not the platform.

Read by hand, the acknowledgement mirrors your filing's own structure and hangs a 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.Every block carries its own errorCode array. {"errorCode": "00", "errorMessage": "Successful"} means that block passed. 00 is not an error — it is the positive marker, and on an accepted filing it is nearly all you will see. So a file full of 00s with one real code in decRef is telling you exactly where to look.Absent values arrive as the literal string "null", not JSON null. "csnNmbr": "null" on a rejection means no CSN was granted, which is what you would expect.master.decRef.csnNmbr and csnDt carry the CSN and its date on an acceptance. Those two are what every later amendment or deletion references, so they are the ones to keep.Descriptions are not unique — key on the code, never on the text. Six distinct codes read Invalid Destination Port Code.

A worked reading

accpStatus: "Rejected", authPrsn and vesselDtls each carrying 00 Successful, and decRef carrying 700 Error-Refile with csnNmbr: "null". That says: the message was structurally fine, the authorised person and the vessel were accepted, no CSN exists, and the refusal is the one that names no field. Work the 700 checklist below, correct the draft, and file it again as a fresh filing — there is no CSN to amend.

The problem arrived by email and has no code at all

Not every refusal becomes a numbered acknowledgement. Some fail earlier — before the file is parsed into a declaration at all — and ICEGATE reports those by email to your registered address, in prose, with no code to look up. These are the ones it sends:

And a numbered acknowledgement can carry no numbers. A vessel-manifest amendment refused in September 2026 came back Rejected with the vessel, voyage and authorised-person blocks all stamped 00 Successful, the declaration block's list empty, and not one error code anywhere in the file. The codes existed — the filer asked the ICEGATE helpdesk, and was told by e-mail that the file carried 318 "Incorrect Records in Amendment Request" and 700 "Refile", with instructions to correct it and refile under a fresh job number.

So a reply with no code does not mean customs found nothing; it means the reply does not carry what it found. Ask the helpdesk, quoting the tracking id from the acknowledgement — on the one case followed through, that is what produced the reasons. Then refile: under a fresh job number, as the helpdesk said, which is always safe — or under the filing's own number, since a refusal in an acknowledgement does not use it up (below).

Two of these are worth reading twice.

The DSC that signs must be the DSC registered at ICEGATE. A perfectly valid certificate that is not the one on your ICEGATE registration fails exactly like an expired one. If signing has started failing for no apparent reason, check whether the certificate was renewed or replaced without the registration being updated to match.

"Control Number has already been processed" is about a number customs has processed. A number ICEGATE has already processed for that job date is refused with this email, however much you changed inside the file — so a second transmission of one job on one job date needs a number of its own.

A refusal does not use a number up. A filing refused with a 700 was sent again the same day under its original number and accepted, which is the case on record. So a file that came back refused can go again as it is, and it is a file that was accepted, or one still waiting for its answer, that pushes the next transmission onto a new number. Filings made in SCMTR follow exactly that rule: the job number is the control number, a refile keeps it, and an amendment of an accepted filing takes a fresh one and says on the filing why it differs. When you cannot tell what became of a send — an e-mail refusal that came before any acknowledgement, or no answer at all — a new number is the safe choice.

Where acknowledgements are delivered

When one is generated, ICEGATE emails it to your registered address, and it can also be downloaded from the ICEGATE portal. So if a filing made outside this platform has gone quiet, the registered mailbox is worth checking before the portal.

A rejection reaches you those two ways and no other: customs' public record lists accepted filings only, so an error code is always read from the acknowledgement. An acceptance of a fresh filing sent from SCMTR is, since 22 September 2026, read off that public record without the email — but the acknowledgement is still customs' own file, so keep it and drop it on the filing. After you file covers what to do with one.

Which errors reject the whole filing, and which name one field?

Asked often enough to be worth stating plainly, because the two need completely different responses and the acknowledgement does not label which kind you have.

Filing-level (CSN-level). The declaration is refused as a whole — not because a value is malformed, but because of what it claims relative to something customs already holds. Nothing is wrong with the field the error points at; the filing's relationship to the world is wrong. These are the families above: your filing disagreeing with one customs already has, a prior CSN/CIN reference that does not match, a consolidation shape that contradicts the bills present, a consolidator PAN not authorised for the filing, totals that do not add up across levels, a vessel or voyage that does not resolve, and an amendment attempted in a state that forbids it. Fixing one usually means changing what you are claiming — or discovering that another party filed first and the window has closed.

Field-level. One named value is missing, outside its coded list, or the wrong shape. The message tells you the field, the fix is local, and nothing else in the filing has to change. Container problems are field-level in this sense too: a bad ISO 6346 check digit or an out-of-range size code names one box and leaves the rest alone.

And the one that is neither: 700 Error-Refile refuses without saying why — no field, no family. Work it as the checklist below rather than looking for a field to fix.

The practical difference: a field-level rejection is usually a correct-and-resubmit. A filing-level one is worth reading twice before resubmitting, because sending the same claim again with a fresh control number gets the same answer.

The one code that tells you nothing: 700

700 Error-Refile is a refusal without a reason — and it is worth knowing that it appears nowhere in the MIG's own 452-code table, which is why looking it up finds nothing. Work it as a checklist — by elimination rather than by reading, since the code gives you nothing to read. The order is the cheapest check first, not a ranking of causes: nobody outside customs knows what a 700 usually means. Upload the declaration alongside the acknowledgement on the SCMTR JSON upload screen and all four are run against your own file: the first three settled from the file itself, and the voyage from customs' last answer about that ship where one is on record. Each comes back as a pass, a failure with the offending value quoted, or a plain statement that it could not be settled — which is how you tell a voyage problem from one of the first three.

What happened next, every time. Seven 700s are on record, from 20 August to 5 October 2026, at five ports, on imports and exports alike. Every one of those bills was accepted the same day when it was sent again: 8 minutes, 1 hour 13, 2 hours 46 and 6 hours 8 after the last refusal on the ones timed. The one whose resend is held here went again under its original control number. Customs' record does not show whether the others were changed first. ICEGATE's engineers told the trade on 12 September 2026 that a 700 on a large file was the system refusing it under load at a busy time, the same file going through later. So check the file, then send it again the same day; it does not need a new control number.

The arithmetic. Packages on each item against its house bill, each house against its master, and the master against totalNoOfTrnsprtEqmtMnfsted and totalNmbrOfLines. Then container weights against the declared gross weight.Is it a duplicate transmission? Send a re-sent filing under a fresh sequenceOrControlNumber. That is the safe choice rather than a proven cause: ICEGATE answers a re-used number with an email, not a 700, and every 700 on record (seven) was accepted the same day when sent again — the one whose resend is held, under its original number.The consolidation shape — consolidatedIndctr against the bills 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. Keep this one as a possibility rather than a diagnosis. Every 700 reply read here (seven) marked its vessel and voyage blocks 00 Successful, though one of them also marked 00 on blocks the accepted version of its filing does not contain, so those marks prove little.

The header's indicator is not a cause to check. Two filings flagged T were accepted by customs, each with a CSN issued, so a T has been taken as a live filing and changing it fixes nothing.

Filers also name a timeout, a port code customs does not know, and a wrongly entered PAN, GSTIN or IE code as causes of a 700. That comes from filers' experience, not from ICEGATE, and customs has numbered errors for bad port codes and party codes, so those would normally come back named. Why filings get rejected takes each one in turn.

Rejected, every block 00 Successful, and no error code at all

Sometimes there is not even a 700. The reply says accpStatus: "Rejected", and the declaration, authorised person, vessel, voyage and master bill's blocks all read 00 Successful. No block carries a code to look up. On the such replies read here, each house bill came back with its bill number and date and nothing under it: none of the transport document, items, containers and route that an accepted reply lists for every house bill. A block with no code was not checked, so the master bill was checked and passed, and the house bills were not looked at.

Every one went through in the end. Eight CSN replies of this shape are on record, from 18 September to 1 October 2026, and every one of those bills is accepted on customs' record since: five the same day (two to six hours after the refusal), two the next day, and one five days later — that one very likely the Nhava Sheva consolidation below, refused the same way three or four times first. Customs' record does not show whether the file was changed before it went again. So this is not a worse kind of failure than a 700, but a second identical reply is a reason to stop:

Drop the file and this acknowledgement on SCMTR JSON upload (or scmtr.io/check). The 700 checklist above runs against your own file.Send it again. A refusal does not use the control number up (see the e-mail section above).Refused the same way again? Stop sending it unchanged. Ask the ICEGATE helpdesk, quoting the tracking id (uniqueId) from the acknowledgement. On the one no-code refusal followed through, a manifest amendment, that is how the codes came out (318 and 700).

It does not always clear at once. A filer at Nhava Sheva reported the same reply on three or four sends of one 40-house consolidation (1–2 October 2026; their files are not held here, and none was checked here before it went). A reply that repeats is not load at a busy time. Something in the file is the likelier cause, so read the file, not the reply.

ICEGATE's own explanation, in its 2022 message-filing FAQ, is that a reply of all 00 on a filing that failed means a required block is missing entirely: the reply only mirrors the blocks that were sent. On a consolidation, that means checking that every house bill carries its own transport document, items, containers and route. See Refusals that arrive by e-mail.

999

Reserved for internal amendment use. It should never reach a filer; if one does, it is worth reporting rather than acting on.

Your filing disagrees with one customs already holds

These fire when your filing contradicts a filing that already exists for the same cargo — the carrier's, or your own earlier one. Nothing in your file is malformed; it simply disagrees with what customs already holds. Get the referenced CSN or CIN in front of you and make the seven equipment facts identical: total packages, total equipment, and each box's type, id, size, load status and SOC flag. Where you believe the other filing is the wrong one, it is the other filing that has to be amended — yours cannot be accepted while the two disagree.

They run on the filing that refers to a CSN — the line's manifest, or a later CSN quoting yours — against the CSN it names. Since ICES Advisory 38/2026 (21 September 2026) customs says the container ISO code is "validated solely at the SAM (Vessel Operator/Line) level"; whether 236 is the check that moved is our reading — the advisory names no codes — and one refusal since fits it: on 3 October 2026 a line's SAA was refused 398 (Eqmt Size Not Match With Referred Eqmt Size of CIN) for a size unlike the CSN it quoted — where the CSN's size matched both bills of lading. Keep the code right on your CSN regardless: take it off the box rather than guess.

The prior CSN or CIN you referenced does not match

The filing points at a prior CSN or CIN that customs cannot match. Check the CSN number and its date against the acknowledgement that granted them — both, not just the number — and check that the reporting event you are sending is one that may reference it at all.

Two different references live in the message, and the codes below cover both. An amendment (SCA) names the CSN it is changing in decRef.csnNmbr and csnDt. A fresh filing names an earlier declaration of the same cargo by someone else — a forwarder's CSN a line is building on, or a co-loader's a consolidator is building on — by setting prevDec to Y on the consignment and filling its prevRef block: the CIN type and number, and the CSN number and date, of that earlier filing. A fresh filing with nothing to build on carries prevDec: N and no prevRef. A fresh filing that should have referenced an existing CSN and did not lands on 171/172; one whose bill does not match the referenced CSN's bill — a CSN for a different bill, or the right CSN with the bill written differently — lands on 164/165.

Reading several codes at once

An acknowledgement often carries more than one code, and each sits on a path that says which block failed. Read them together before changing anything. The commonest group, seen on a consignment filing and on a shipping line's arrival manifest amendment alike:

164 "Mentioned MC-BL Not Matching With CSN BL" on MCRef — the master bill on the manifest line (or on your consignment) is not the bill the referenced CSN was filed against.232 "Total Pckg Not Match" and 233 "Total Eqmt Not Match" on trnsprtDocMsr — the line's totals are not the referenced CSN's totals either.

Those three together are one fault, not three. Once customs cannot tie the line to the CSN it names, it compares the totals against nothing it can match, and they fail as well — even when the packages and containers are identical to the CSN's. Adjusting package counts to silence 232 would make it worse. The fault is in how the line names the bill or the CSN, and it has two forms:

The CSN number and date belong to a different bill. Fix the reference — the CSN number and date for this master bill, taken from its acknowledgement.The CSN is right, but the bill is written differently. Customs matches a bill on its number and its date. In a real refused arrival manifest amendment (September 2026), a shipping line's line for a forwarder's bill carried packages, weight and container identical to the forwarder's CSN, and the same bill number — but a master bill date two days earlier than the date the CSN held. (The line's own earlier copy, sent the same morning, quoted that CSN's number and date correctly.) All three codes fired on that line; a neighbouring line on the same amendment, whose bill number and date matched its CSN exactly, passed. Compare the bill number character by character and the bill date against the CSN's, then correct whichever filing disagrees with the bill of lading itself — if the CSN holds the wrong date, it is the CSN that needs amending.

Look the bill up in Customs lookup (under the ? menu) or on BL tracking to see the master B/L date and the CSN customs holds for it before deciding which filing to change.

The same logic runs the other way: 232–238 on their own, with no 164, mean the reference was matched and the physical facts disagree — the count of packages or containers, or a container's id, type, size, load status or SOC flag. That amendment also carried 233 alone on over a hundred other lines, which is a separate problem on each of those lines, not a side effect of the 164.

122 and 123 on a bill you are deliberately splitting

122 "MC-MBL Details Already Exists" and 123 for a house bill normally mean what they say: this bill is already on customs' record, so filing it again is a duplicate.

There is one case where it is not a duplicate and the code still fires — a bill genuinely split across more than one filing, because part of the consignment moves differently from the rest. Customs treated the second filing as a repeat of the first, and until January 2026 lines had to fall back to the old IGM 1.5 format to file the other part at all.

The fix is a field, not a workaround. JNCH Public Notice 15/2026 of 22 January 2026, reciting ICES Advisory 03/2026, publishes what the split indicator means:

The notice is explicit that the F is not optional — it is what closes the set: "The use of 'F' is mandatory to enable proper system validation and closure of the split BL set." A series filed Y, Y, Y with no F stays open. It also warns that getting the indicator wrong causes "system validation errors, processing delays, or rejection of documents", so N on a part-shipment is not a safe default.

The field is locCstm.splitIndctr on the manifest and prevRef.splitIndctr on a consignment filing, and this app offers all three values on both.

This is a different operation from breaking a consolidation out into its house bills. That one is not a split indicator at all — it is the consolidator's CSN, referenced by the line's arrival manifest amendment, and it draws 370/118 rather than 122. See My console's house bills are not on the line's manifest.

The consolidation shape does not match the bills in the file

The shape you declared — how the bills are consolidated, what the cargo is, where it is going, and whether it has been declared before — does not match something. Most of this family is about consolidatedIndctr against the bills actually in the file: it is R on a master that has house bills under it, H on each of those houses, and M on a master filed with no house bill, so a master marked R with no house bill under it, or M with one, lands here.

Two of these codes are wider than that and are the ones filers get stuck on. 115 and 118 do not name one field: they say that cargo type, cargo movement, the consolidation indicator and the prior-declaration flag, taken together, are not a combination customs recognises — at master level for 115, house level for 118. The MIG publishes the list of combinations it accepts as its Trade Scenarios Mapping Table, and the platform reads that table for you; the whole of it, and how to work a rejection back through it, is in Cargo type, movement and the combination customs checks. The single commonest fault is import cargo declared with a transhipment movement: IM goes with LC, DT or TI and never with TC, which belongs to TR and EX.

The consolidator PAN is missing, malformed, or not authorised

The consolidator PAN is missing, malformed, or not the party customs holds as entitled to file this consignment. Remember the wire form: MCRef.consolidatorPan and HCRef.consolidatorPan carry the PAN: prefix — PAN:AAAAA0000A — while every other PAN field in the message is bare. A prefix in the wrong place, or missing where it belongs, lands here.

The numbers in your own file do not add up

The arithmetic inside your own file does not add up. It is the first thing to check on any rejection, including a reasonless one — not because it is known to be the usual cause, but because it is the one family your own file settles completely. Work it in this order: each item's packages against its house bill, each house against its master, the master against voyageDtls.totalNoOfTrnsprtEqmtMnfsted and totalNmbrOfLines, and every container declared at house level also declared at master level. The duplicate codes in this family mean the same sequence number, equipment id or HS code appears twice where it must appear once.

The platform now works this arithmetic for you before you file: a declared total that disagrees with the rows present, a master whose package count is not the sum of its houses, a document count that does not match its items or its equipment, a house container missing from its master's list, and — container by container — a master row whose weight or package count is not the sum of the house rows carrying that box, are all flagged — in the form, on the review screen of the guided steps, and on any JSON file you inspect — before customs ever sees them. The container-level check is the one a bill-level total cannot make: two boxes whose figures are interchanged between the master and the house leave every total agreeing and every box wrong. A gross weight that differs from the container weights' sum warns without blocking, since non-containerized cargo can account for the difference.

The sharpest duplicate of all is the same record twice, and it is returned to a CSN — an import CSN was refused for it on 23 September 2026 — even though the codes are printed in the manifest's list: two master consignments carrying the same master B/L and the same house bill. Customs identifies a record by that pair, so it reads them as one filing sent twice and refuses with 375 and 376, reported against the voyage rather than against either line. The platform blocks that pair before you file. Two lines sharing a master B/L with different house bills is a different thing — declared split cargo — and only warns. 375 and 376 are published in the vessel manifest's shared error list rather than the CSN guide's own, which is why looking them up in the CSN MIG finds nothing.

One box has one seal number. Customs words them "Multiple SealNo for Equipment-Id" (701) and "BL and HBL SealNo Does Not Match" (703). Read by those words, 701 is one container carrying more than one seal number across the bills that name it, and 703 the master bill and a house bill disagreeing about a container's seal. That reading is ours: which difference draws which code is not settled yet. Neither code is in any published list; both were seen on refused CSNs in September 2026, and the platform checks a container whose seal differs between the bills that name it before you file.

A repeated line, sub-line or sequence number is the sharpest version of the duplicate problem, because those numbers are how customs tells records apart: every master consignment is identified by its lineNo, and every house bill by the lineNo + subLineNo pair. Two house bills under one master both carrying sub-line 1 are, as far as customs is concerned, one record filed twice. The platform numbers these rows for you and will not produce a duplicate; a file made elsewhere can, which is why validation — including the SCMTR JSON upload screen — flags a repeated number before you file, naming the row that already uses it.

A container is wrong on its own terms

Something about a container is wrong on its own terms — an id that fails its ISO 6346 check digit, a size or type code outside the coded list, a seal or load status that does not fit. These are field-level and local: fix the box that is named and nothing else needs to change.

The ship, voyage or rotation does not resolve

The ship, the voyage or the rotation does not resolve. The usual cause is the conveyance reference: cnvnceRefNmbr is the VCN customs issued for that ship's call at that port, not the carrier's own voyage number off the bill of lading. Check it character by character, and check the port it belongs to: a VCN carries the code of the port that issued it, so a Nhava Sheva number on a filing reported to Mundra is wrong even when the number itself is real. A VCN can also be one customs has since replaced because the vessel changed — filers report substitutions close to the arrival — and the filing page says what customs listed for the ship when you filed. Check the IMO too — it is seven digits with a check digit, and a transposed pair fails silently everywhere else.

These fall into three groups, and the group decides who fixes it. The number will not resolve at all — 20 for a VCN, 24 for a rotation number or a VCN, 212 for no rotation on record at that port. The number resolves and names somebody else — 243, where customs finds a different shipping line against that call from the carrier code you filed; that is more often the wrong call than the wrong carrier, so check the VCN before you change the carrier code. The call will not accept the filing at all — 245 to 248, "… Can Not be Filed as Per VCN Status". ICEGATE publishes no list of what a VCN's statuses are, and all four name the vessel operator's own messages rather than a CSN.

A fourth thing is mistaken for these and is not one of them. 327 and 328, both worded "VCN of CSN Does Not Match with VCN of CSN/SAM/SDM", do not say your number is invalid — they say it is out of step with a filing customs already holds for the same cargo, which is a different problem with a different owner. See Your filing disagrees with the vessel's voyage filing.

None of these has been seen returned to a filing made from here — they are read off ICEGATE's own published list, which is what this whole document is.

Your filing disagrees with the vessel's voyage filing

The equipment on your bill does not line up with the voyage side — the vessel operator's own declaration of the call and the containers riding it. Nothing in your file is malformed; a container you declared carries a different size, or is absent altogether, on the voyage's equipment list. These surface in two places: as rejections in an acknowledgement, and in SAM-side enquiry responses, where the code rides a per-container record showing the voyage's view of the box (its equipment status, final destination location and event date). Get the voyage's record for that container in front of you — the vessel agent or carrier holds it — and make the box's identity facts identical on both sides: container number, type, 4-digit ISO size code and load status. Where the voyage's record is the wrong one, it is the voyage filing that has to be amended. Whose filing is refused for the disagreement may have changed: since ICES Advisory 38/2026 (21 September 2026) customs says the container ISO code is validated "solely at the SAM (Vessel Operator/Line) level"; whether 705 is that check is our reading, the advisory names no codes. The 705 refusals on record here all predate the advisory; none has been seen since, on either side — so get the code right for the box regardless.

The size code is the usual culprit for 705: the voyage side declares the box as one 4-digit ISO size (2210, 4400, …) and your bill declares another. A 22G1-style type code written where the size belongs, or a 20-footer keyed as 4400, reads to customs as a different container. Note that 705 appears in neither the MIG's 452-code table nor the official SCMTR Error Codes list — like 700, it is observed in real responses but published nowhere, which is why looking it up finds nothing.

Two codes for the same kind of disagreement sit in the catch-all family further down, and belong here as well: 327 and 328, both worded "VCN of CSN Does Not Match with VCN of CSN/SAM/SDM". Those are about the call rather than the boxes — your CSN naming one VCN where another accepted filing on the same cargo names a different one. Nothing in your file is malformed there either, so get the other filing's ship and call in front of you before you change yours; the vessel agent or the line holds it. And note what follows from who filed it. If it is another party's accepted CSN, customs' list has 320 for changing yours whichever of you is right — not yet seen on a reply, and if it comes, the route is the shipping line and your jurisdictional customs officer. If it is the line's accepted manifest, an amendment is still filed (ICES Advisory 37/2026, 18 September 2026) — but it cannot change the VCN itself, so a wrong call goes to the shipping line and your jurisdictional customs officer.

Most of these also appear under an earlier family — the totals under the numbers in your own file do not add up, the line-reference ones under a container is wrong on its own terms — and keep the family that first names them; this table is the voyage-matching view across them. 700 and 705 are the only 7xx codes we have seen in real responses; the range is in no published table. If an acknowledgement or enquiry response hands you another 7xx code, it is worth reporting — to the ICEGATE Helpdesk, and to us.

The amendment or deletion is not allowed in this state

The amendment or deletion is not allowed in the state the CSN is actually in — already amended, already deleted, past the point where it may be changed, or referencing a CSN that was never granted. Mind the direction: a refused original never got a CSN and is filed fresh; a refused amendment leaves the original standing and is re-sent as an amendment, never as a fresh filing.

318 "Incorrect Records in Amendment Request" is the one seen on a real vessel-manifest amendment (an SAA, September 2026), alongside 700. Both arrived by e-mail from the ICEGATE helpdesk; the acknowledgement itself named nothing at all. The remedy given was to correct the details and refile under a fresh job number.

What "incorrect records" covers is not published, and the acknowledgement cannot be used to work it out — an acknowledgement is not a copy of the file it answers. It rewrites the header's version to ICES1_5, reports the message type as F whatever was sent, drops every record's amendment type, and echoes each line's prior reference as "null". An accepted amendment's reply reads exactly the same way on all four, while the file that earned it carried SAA1102, A, S and a real reference. So check the file you sent, not the reply: on an SAA or SDA, the message type should be A, the header version should name the event, and every record the amendment touches should carry its amendment type (S, U or D) — see Amending a shipping line filing.

An amendment names a record customs does not hold — or one it already holds

An amendment finds every record it changes by that record's own numbers — a consignment by its line and sub-line, a container by its sequence number, a cargo item by its serial, a port of call by its sequence, a person, crew member, ship's store or passenger by theirs — never by the bill of lading, the container number or the name written beside them. So "Not Exists For Update/Delete" means the amendment updated (U) or removed (D) a number the filing customs holds does not have there, and "Already Exists For Addition" means it added (S) a record under a number that filing already uses. Take the numbers from the filing as customs holds it now, with every amendment it has accepted since — not from an older copy, which is the usual cause — and give an added record the next unused number. On a shipping line's manifest, check first that the line itself is right: ICEGATE's public SAM enquiry shows the line customs holds each bill on and its containers' sequence numbers. And on a line that quotes an earlier declaration (previous declaration Y), customs holds no item details at all, so an item updated there is refused whatever its number.

394, 748 and 749 are published nowhere; each was seen on a refused SAA in September 2026 — 394 on boxes added to the vessel's list under numbers the manifest already used (the list is numbered 1 to N; an added box takes N + 1), 749 on a line removed under a number customs held for a different bill, 748 on an item of a line that quotes an earlier declaration. 750 is their itinerary twin, seen on a refused SCA in October 2026: a port-of-discharge change addressed a port-of-call row 2 on a house bill that customs did not hold. A leg an amendment adds is S, after the last one held. Customs words its unpublished codes the same way as the published ones, so a code in no list that says "Not Exists For Update/Delete" or "Already Exists For Addition" is read here as one of these. Amending a shipping line filing walks through the manifest's, and Amendments and deletions the CSN's.

An export's shipping bill, ports or containers do not fit

An export (SCX, CSN Exit) is refused for a small set of reasons, all seen on real refusals in September 2026 and all absent from filings customs accepted. Name each shipping bill's PCIN exactly once: a straight bill (master consolidated indicator S, prior declaration S) carries its shipping bill's PCIN in the previous-reference block; a consolidation's master (C, N) carries none — customs issues it an MCIN — and each house bill (H, S or B) carries its own shipping bill's PCIN. Repeating a PCIN — on a master and a house, or on two houses — is 383 and 384; leaving it off a straight master is 159. The destination and the port of receipt are the foreign port the bill of lading delivers the cargo to — the port of discharge, unless the bill shows on-carriage beyond it; an Indian destination is 286 and an Indian receipt port is 365. Every house bill lists its own containers, at least one of type CN for containerised cargo — a house with none is 239 together with 381, whatever the MIG's field table says about house equipment being optional. Every item carries its package count: customs adds them up, and a blank one leaves the items short of the declared total, 709.

381, 383, 384 and 709 appear in neither the MIG's code table nor the official SCMTR error list — like 700 and 705, they are observed in real acknowledgements and published nowhere. The platform checks all of these on an export before you file, and the guided steps build a filing that cannot trip them. Exports: shipping bills and PCINs walks through both shapes.

Where each export code is published, checked against ICEGATE's own lists on 2026-09-20. 381, 383, 384 and 709 are in no published list at all. 365 and 366 are in the message guide's newer code table only, not in ICEGATE's separately published SCMTR Error Codes & Descriptions. The rest an export meets are in both: 53, 73, 91, 99, 115, 124, 128, 148, 149, 159, 161, 220, 221, 225, 232–238, 239, 251–256 and 286. Two are worded differently between the two lists — 124 reads "Already Used" in the published list and "Already Referenced" in the guide, and 255/256 read "Cin_Type+Cin_No … Differ Port/Linked" in the published list and "CSN No+Date … Differ Port/Linked" in the guide; a reply may carry either. No customs document explains any of these beyond its one line. What each means on an export, what to change, and which have actually been seen on a refusal are in Why customs rejects a filing.

The cross-checks against the shipping line's manifest do not include weight. 232–238 compare a CSN with the line's manifest on total packages, the number of containers, and each container's type, number, size, load status (237) and shipper-owned flag. A container weight that differs between the two filings, or between a master bill and its lines, has no published code — which is why the app warns about it on an export rather than blocking.

A shipping line's SAM or SDM is refused for how it refers to what customs already holds

A shipping line filing (SACHM23 — SAM, SDM and their amendments SAA and SDA) is refused for a small set of reasons of its own, each seen on a real refusal in September or October 2026. A line that quotes an earlier declaration does not repeat what that declaration already holds: where its house bills also carry the transport document or the item details, customs refuses the line as 370 with 118 on each house bill. The house bills themselves belong there — customs' own Trade Scenarios table asks a house bill on such a line for its reference, its prior reference, its customs location and its containers, and excludes only the parties, ports and goods the earlier declaration carries. Two ways out, and only one has been seen to pass: thin the house bills to what the table asks for (no filing on record has been accepted in that shape), or drop the house rows and let the line quote the CSN alone, the only shape on record that has passed customs' checks; see My console's house bills are not on the line's manifest. A container the vessel's list already holds is not added again by an amendment: 156 on each row of the list involved, with 153 on the vessel details. A container has one load status: a line that says LCL where its only house bill says FCL is 707, and a status that differs from the CSN or CIN the line quotes is 399. A shipping bill's PCIN is used once: a departure manifest that quotes a PCIN an export CSN (SCX) or another SDM already used is refused as 385 on the line and 254 on a house bill. On the refused SDM seen, every line quoting a PCIN directly was refused and every line declared as already declared (previous declaration Y, quoting the export CSN) was not — so check first whether an export CSN has been filed for the shipping bill, and declare the line Y against it; only where none exists look for an earlier SDM, which is changed with an amendment (SDA), not a second SDM. A master bill customs already holds is quoted, not declared again: an amendment that adds a line declaring a bill afresh, where customs already holds a declaration for that bill, is refused as 753 "Amd-MC-MBL Details Already Exists", on that line — the amendment's twin of the published 122. On the refusal seen, the new line declared the bill as not declared before (previous declaration N), as a consolidation with its three house bills in full. Customs' public record showed that bill held by an accepted CSN on the same rotation, a straight bill with a PCIN, and on no SAM. So look the bill up first: if a CSN holds it, the line quotes that CSN (Add a line from a CSN builds it); if the CSN itself describes the cargo wrongly, the CSN is changed by whoever filed it, since the manifest cannot overrule it. No corrected line has yet been seen accepted. An amendment finds what it changes by its numbers: a line by its line number, a container by its line, subline and sequence number. An SAA or SDA built from a manifest numbered differently from the one customs holds — usually the original SAM, where customs holds a later version — changes or deletes a record that is not there: 749 on a container, 306 on a line. The bill number beside it does not rescue it: on the refusal seen, an SAA removed a bill under a line number customs held for a different bill, and the reply raised nothing about the line or its bill — only 749 on one of its four containers, the one numbered 3, where that other bill's line holds a single container. Ask customs' public record where it holds the bill — the line, and the containers' sequence numbers — and use those numbers. 748 is the same for an item, and has a second cause: a line that quotes an earlier declaration (previous declaration Y) carries no item details at all in customs' Trade Scenarios table — the declaration it quotes holds the goods — so an amendment that updates an item there is refused even on the right line. Leave the item details off such a line; correct the goods in the declaration it quotes. A removed line still names what it quoted: an SAA that deletes a line declared before (previous declaration Y or C) gives that line's prior reference — the MCIN or PCIN, or the CSN number and date — beside its line reference; removed by the line reference alone it was refused as 724 "CIN No Should be Provided in Prev-Decln of SAA/IM-SCA" (one SAA, October 2026), and nothing in the file was taken. And it goes whole: customs appears to process a line's containers and route legs along with it — the same removal re-sent with its prior reference but nothing under the line drew 242 "MBL/HBL Details Not Exists for Given Itinerary Line+Sline No" on its two route legs and 300 "SQL/Run-Time Error Occurred While Validation", beside 00 on its containers, none of which the file had named — so send the line as the accepted manifest holds it, its containers and legs marked D, leaving the item details off a line that quotes an earlier declaration (748). Re-sent that way, beside the bill re-added as a consolidation, it was accepted (October 2026).

385, 394, 398, 399, 707, 724, 748, 749 and 753 are in no published list — like 700 and 705, they are observed in real acknowledgements only. 254 is published as "Cin Mentioned in HC is Not Top Most CIN" and arrives from the live system worded "HC-CIN is Already Used in Other SDM/SCX"; read the words in your own ACK, which the app shows beside the published ones whenever the two differ. Before you send a SAM or SDM, the platform checks for 370, for 707, and for a container listed twice on the vessel's own list (156/153); before you sign an amendment, it asks customs' public record where it holds each line the amendment changes or removes, and stops a line or container addressed by a number customs does not hold it under (749). An amendment re-adding a container the accepted SAM already holds, 399 and 385 cannot be seen from the file alone (the ICEGATE check on an open manifest compares each line's load status with the CSN it quotes, and marks a difference Fix); when you open customs' ACK the platform reads the whole reply and says which of them happened. Working with a shipping line filing and Customs rejected my SAM walk through them.

A reply to an amendment lists the whole manifest, not the file you sent. A two-line SAA comes back as every line customs holds: the lines you sent echo their bill numbers, and the rest are written as "null" — they are not lines customs accepted, and not lines it refused. Customs does check the whole manifest it holds, though, so a line that was already wrong there can be refused again on an amendment that never touched it; those rows carry a code and no bill number. Not every refusal lists it, though: one of October 2026 listed only the two lines its SAA sent, so a reply's row count is the manifest only when it lists more than the file carried. And a file can be refused with no code at all — every block stamped 00 and the declaration's list empty. That is a refusal before the checks that name a fault were run. On every one seen (three SAAs by October 2026), the declaration block was the only one customs had not stamped as checked, which is where to look first — though on one of them the declaration matched customs' own record in every field, so it can also stand for a fault customs does not name; nothing can be read from the lines' references, because a refused reply writes every reference as "null" whatever the file quoted.

Field-level problems — missing, invalid, or out of format

Everything the families above do not cover: mandatory fields absent, codes outside their permitted list, dates and lengths that fail their own format. These are field-level, and the message names the field. The one worth knowing on sight is 700 Error-Refile, which carries no field information at all — see the checklist below.

The complete list, by number

Every code in the table, sorted. The families above are a reading aid and some codes appear in more than one; this list is the authority.