What the app’s checks mean
What the app's checks mean, and which ones stop you filing
Every screen that looks at a filing — the wizard's review step, the checklist drawer in the full form, the file inspector, and Sign & upload — reports what it found in two tiers. They look different on purpose, and the difference is the whole point: one of them stops the filing and the other does not.
Red is a rule. Amber is a second opinion
Red — "issues", "to fix". The message format itself is broken: a mandatory field is empty, a value is outside its coded list or too long for the field, a total contradicts the rows it counts, two rows share a line number. Customs refuses these, and so does the app — Sign & upload will not send a filing carrying one. Fix them.
Some red rules are not in the message format at all — they are customs' refusals, read off real
acknowledgements and named for the code they would draw. On an export (SCX, or cargo type
EX): an itinerary leg whose port of call is also its next port of call (091); a previous
declaration of type S, B or Y with no CIN type and PCIN in the previous-reference block (159);
transhipment cargo whose port of receipt is an Indian port, which customs wants filed as local
clearance (365); an Indian port as the export's destination (286); one PCIN named twice
anywhere in the filing (383/384); a line under the B/L that lists none of its containers, or
no container of type CN among them (239 with 381); items whose packages do not add up to
the bill's, usually because one was left blank (709); a master whose packages are not the sum
of its lines' (225); and a net weight of zero, which is left out or given as a real figure
(053). And on any filing, a cargo-type and movement pair the trade-scenario table does not
allow (115), or a package count that disagrees with the containers (221). Each of those
refused a real filing in September 2026; see Rejection reasons and
Exports, shipping bills and PCINs. The export list was
extended on 2026-09-20, and it rests on a small base — three exports customs accepted that month
and the refusals filed beside them — so it is what customs has refused, not a promise of
everything it would.
Amber — "to check", "worth checking". The filing is well formed and something in it is unusual. Nothing on record has ever been refused for any of these: for each one, either no acknowledgement anybody has shown us mentions it, or the practice appears in filings whose outcome we have never seen. They do not block Sign & upload and they never will on their own. Read them, decide, and move on.
A filing can be Valid and still carry a row of amber. That is not a contradiction — it means every rule the message format enforces is satisfied, and there are still things worth a look before you send.
Why we mark something amber instead of just fixing the rule
Because being wrong in that direction is expensive. Telling you a value is a refusal when it is not sends you to change a field that was fine, and on a filing of a hundred containers it buries the one line that actually matters. The bar for red is a rule we can point at — the field table, a coded list, an arithmetic ICEGATE re-derives. Everything short of that is amber and says, in the message itself, what the evidence actually is.
Where the evidence changes, the tier changes. An acknowledgement that names one of these as a reason for refusal turns it red the same week.
What is amber today, and why
| What it says | Why it is not red |
|---|---|
| A weight on an empty container | ICEGATE publishes error 128, "Weight > 0 for Empty Container", but every empty-container filing we hold declares the box's tare and none of them has an acknowledgement beside it. The same list also carries 295, which says the opposite about the package count. See Containers and shared boxes. |
| Gross weight does not equal the container weights | No single error code covers it, but the carrier's manifest is cross-checked against these quantities (codes 232–238), so a difference is worth resolving before the line's manifest is refused for it — those codes fire on the filing that refers to a CSN. |
| A container number fails its check digit | Real equipment turns up without a valid ISO 6346 number — shipper-owned boxes, trailers, non-standard gear — so a failed check digit is "look at the box", not "this is wrong". |
| The same bill of lading appears twice | Customs accepts this only as declared split cargo. Usually it is one record entered twice. |
| The container agent code is not the master's consolidator PAN | On every filing on record carrying a house bill the two are the same. If the consolidator PAN was corrected after the containers were added, this is the old one. And since ICES Advisory 38/2026 (21 September 2026) customs says the container agent PAN is validated on the line's manifest only, not on the CSN — unseen from customs' side either way — so this stays amber whatever the value. |
| A bonded movement with no transhipper block | The MIG's trade-scenarios table lists the transhipper block for every first-time bonded movement, but accepted filings carry it on movements the table does not ask for it on, and nothing has ever been refused for omitting it. It does not fire on an export at all (since 2026-09-20): none of the exports customs accepted in September 2026 carries the block and no export refusal has asked for one, so the warning was only noise there. See Transhippers, CFS and bonds. |
On an export, a bill that refers to one shipping bill (S) and quotes a CIN type other than PCIN | Every export customs accepted in September 2026 refers to its shipping bill as a PCIN, the message guide's table says "PCIN of SB", and customs' own table of which CIN each bill quotes says PCIN for an S master and an S line alike — the published codes for getting it wrong are 159 (master) and 161 (line). No refusal seen names another type as the reason, so it warns. A line covering several shipping bills (B) may quote PCIN or MCIN and nothing is said: customs' table says MCIN there, every accepted B line seen quotes a PCIN, and we will not warn against what customs is seen to accept. |
| On an export, a number that does not look like the CIN type beside it | An MCIN-shaped number (MC after the year) filed under type PCIN, or a number filed as MCIN that is not MCIN-shaped. Almost certainly the wrong choice in the type list; nothing on record shows how customs answers it. |
| On an export, a PCIN that is not 20 characters | A PCIN reads as year, PC, two letters and fourteen digits — 26PCEG09010000000100. One of another length is almost certainly a slip of the paste, but no refusal on record says so in those words. (CBIC's 2019–2020 training decks speak of an "18 digit" PCIN; no real one seen is that length.) |
| The same HS code on two items of one bill | Amber since 2026-09-20 — it used to stop the filing. Customs publishes a code for it (157, Duplicate HS Code in Cargo Items), and that published list was all the red rested on: no refusal we hold carries 157, and a refused line with six items under one HS code, whose items customs had read, drew none. No accepted filing we hold repeats a code in one list, so combine the rows where you can — it costs a minute and removes the question — but it will not stop you. |
| A container whose weight on the master is not the sum of its house bills' (or, on an export, its lines') shares | Amber since 2026-09-20, on imports and exports alike — it used to stop an import. Customs' published cross-checks between a CSN and the line's manifest (232–238) cover packages, container count, and each container's type, number, size, load status and shipper-owned flag — not weight; nothing published says a master box's weight must equal its lines'; and one refused export whose boxes disagreed by a few hundred kilograms was told about other errors and nothing about weight. Every accepted consolidation seen, import or export, does agree box by box (bar a fraction of a kilogram of rounding), so make yours agree — but it will not stop you. A package count that does not add up is still red everywhere (221, 225). |
| On an export consolidation, a PCIN on the master | The accepted consolidations name no PCIN on the master — customs issues it an MCIN — and each PCIN sits on its own line. A PCIN on the master that repeats a line's is red (383/384); one that repeats nothing has not been seen refused, so it is amber. |
On an export, cargo movement TI or FT | The message guide's table allows both on an export row, and every export seen accepted is TC. Allowed on paper, untested in practice. |
| A weight with more than two decimals | Customs' public record shows weights to two decimals — an accepted amendment filed 10290.184 and the record holds 10290.18 — and accepted filings carry three-decimal weights, so nothing is refused. But the third decimal is a figure customs will never show back, and every later comparison against its record sees a difference you did not make. Three decimals are fine to file and go out as typed; round only if you want your file and customs' record to read the same. |
| The consignor's country is one letter from the port of acceptance's | Customs accepted a Busan shipper filed as KP, North Korea. Only the pairs that are a slip in a country list and nothing else are flagged (North/South Korea, Niger/Nigeria, the two Congos, Slovenia/Slovakia, Austria/Australia, Dominica/the Dominican Republic); a consignor whose country differs from the port's is ordinary trade — a Hong Kong trader shipping from Shenzhen — and is not. |
| The file's name does not match what is inside it | ICEGATE reads six identifiers out of the filename before it opens the file, and refuses a name it cannot parse — that part is certain. Whether it then checks them against the header is not: real filers put their portal login id in the name and a PAN-derived code in the file, and none of those filings has an acknowledgement beside it. That precedent is the sender ID's alone. When the message type differs, the reporting event says which side is right — an Entry is F, an amendment is A — and the notice names the likelier mistake. It only suggests a new filename when the file is the side to trust, so it never tells you to rename a fresh filing as a deletion. |
| The message type does not fit the reporting event | Every Entry on record is message type F and every amendment A, deletions included — a deletion goes as A with amendment type D, never as message type D (see Amendments and deletions). A D in the header, an A outside SCA, or an F under SCA matches no filing we hold, but no acknowledgement we hold names it as a refusal either. This app sets the message type itself — F on a new filing, A from Amend or File a deletion — so you meet this on a file made elsewhere. |
| On an import, a consignee or a notify party in India with no PAN | The message guide's field table marks both codes optional, but its notes ask for the consignee's code on an import and the notify party's PAN on a coastal filing, and ICEGATE's list of what an import CSN must carry names both. Almost every accepted import bill gives them, yet customs has accepted bills with either left blank and none has been refused for it. A blank PAN is left out of the file, so add it from the bill. When the notify party is the consignee, it is the consignee's PAN. A notify party abroad has no PAN, and nothing is said. |
| A value the field table calls optional that every accepted filing gives | A bill's gross weight and its unit; each item's number and type of packages; the port of call and next port of each leg; each container's seal number and weight (neither asked of an empty) and its container agent code; a code type beside a party code; the notify party's country; and on an export, the exporter's code (the message guide calls it mandatory there) and PIN code — not asked of a consignor abroad, such as foreign cargo transhipped out (cargo type TR), who has neither. The field table leaves each one optional, and a blank one used to pass without a word, but every accepted CSN on record gives it. Customs publishes "is Null" codes for a few and we hold no refusal under any of them, so each is a reminder at the field. A vessel manifest (SAM or SDM) gets the same reminders, plus each box's size/type code and the vessel list's package count. ICES Advisory 38/2026 says customs checks the container agent PAN and ISO code on the manifest rather than the CSN, so on the manifest those two matter most. Break-bulk rows and amendments are not asked, because an amendment sends only what changes. |
| A field the rules mark mandatory that customs has accepted blank | The field table says mandatory; accepted filings say otherwise. We follow the filings and tell you what the table says. |
What was amber and is no longer
Evidence moves a check in both directions. When an accepted filing carries the very thing a check warns about, the check goes.
| What it said | Why it went |
|---|---|
The file is flagged T, not P | It said every accepted filing carries P, and told you to correct a T first. Then two filings flagged T came back accepted, each with a CSN issued, so customs has taken T files as live filings. Nothing is said about the indicator now. Filings made in this app still go as P. |
Why the app sometimes will not accept the fix you were about to make
A few of these have a remedy that is not the obvious one, because the field is optional but not zeroable:
- Taking a weight off an empty container: clear the container's own weight field — Container
weight on the equipment row,
cntrWeight in the file — and do not type 0. Every weight and
count in this message is positive by nature, so 0 is refused as a typo, and that field is
optional, so blank is a perfectly good answer. It is not the bill's Gross weight
(trnsprtDocMsr.grossWeight) the finding is about.Packages on an empty container: 0 is correct here and is accepted everywhere it appears —
on the container, on the item line and on the bill.Where each tier shows up
- The wizard's review step and the full form's checklist drawer — the same two tiers, listed
by section, each one jumping to the field. Since 8 October 2026 every section on a bill says
which bill it is on — House bill 4 · <its HBL number> above Item 1, or Master B/L <number>
— so eight house bills' "HS code is required" no longer read as eight identical Item 1 rows.Sign & upload — blocks on red only. Amber never stops a filing going out.The file inspector — a badge for each tier beside the filename,
two lists beneath it (each finding on a bill names the bill, as the checklist does), and the
field itself marked in the record below with a red or amber rail so you can see where it sits.An acknowledgement's errors are always red. Customs has already refused the filing; there
is nothing left to be unsure about. Beside each code the app shows what to change; since
2026-09-20 that includes the export codes
53, 91, 161, 221, 225 and 239.On an export, the same findings are also laid out as a checklist — "What customs checks on
an export": each PCIN named once, a foreign destination, an export's cargo type and movement,
the voyage to the foreign port, every line's own containers, the packages, the weights, the
voyage totals. It is in three places: the guided steps' last screen, the file inspector for an
uploaded export, and the full form's issue list, which opens with "Export checks: N of 8 clear". It is a view of the red and amber findings, never a second opinion:
a tick there cannot disagree with whether the filing can be sent.The help under a field says what customs' own documents say. Container weight is cargo plus
packing without the container's tare; load status is how full the box is and must match the
shipping line's manifest (237); a PCIN is a Primary Cargo Identification Number."Differs" under Check against the bill of lading — what it means
Check against the bill of lading is a different check from everything above: it holds what your filing declares against the bill of lading PDF your organisation has stored here, not against customs' rules and not against customs' record. It sits on a filing's own page and in the line panel of the manifest editor. For each bill it lists the number, the date, the packages, the gross weight and the containers with their seals, as your filing has them beside what the bill prints. The small page 1 beside a value is the page of the stored PDF it was read from; press it to open that page.
- Agrees — the two say the same thing. Same, written differently — the same value spelt
another way, such as a seal with and without its prefix; not a difference.Differs — both sides state the value and they disagree. A row reading Packages, then your
filing's count and kind, then the bill's count and kind, then page 1 · Differs, means the count
your filing declares is not the count read off page 1 of the stored bill. Only the count is compared; the kind (
CTN, "CARTON", "PACKAGE(S)") is
shown beside it and never judged, because a bill prints a word and a filing files a code. It
does not say which side is wrong: the bill's figure is what was read off the PDF, and a bill
printing two counts (outer packages and the cartons inside) is often read as the other one. Open
the page and read the bill before you change anything.Not read off the bill — the bill did not yield that value. That is not a disagreement and
asks nothing of you. Not declared — the bill prints it and your filing leaves it blank.It is not an ICEGATE error, and it blocks nothing. Customs never sees it and Sign & upload does not wait on it. Do not change your filing to the bill's figure straight away — the figure shown is what was read off the PDF, and a bill that prints two package counts is read wrong as often as a filing is typed wrong. When it says Differs, open the page it names, read the bill yourself, and decide which of these it is:
- The filing is wrong — correct it: on a draft, in the form; on a filing customs has accepted,
through an amendment (see amendments and deletions). The
shipping line's manifest is checked against your CSN's figures, so a wrong count there is a
refusal waiting to happen.The bill prints two figures — outer packages and the cartons inside them, say — and the
reading took the other one. Your filing is right; file the count the bill gives as its number of
packages.The stored PDF is a different version of the bill — an earlier draft, or a bill re-issued
after a correction. Store the current one and press the check again.
Related
- SCMTR JSON upload — dropping a file in and reading what comes back.Reading an acknowledgement — what customs said, code by code.Rejection reasons — the refusals filers actually meet.Containers and shared boxes — empties, tare weights and shared equipment.
Still stuck on this?
The assistant answers from this exact page and the rest of our reference material, and names the documents behind every answer.
Have the file? Check it free — no sign-in
General information only — not legal or customs-compliance advice, and it may not reflect the most current ICEGATE/CBIC requirements. Verify against the official sources, or a licensed customs broker, before filing.