Checking a manifest against ICEGATE

A shipping line filing (SAM / SDM) and the Cargo Summary Notifications filed against its bills are cross-checked by customs on a small, fixed set of facts. A disagreement found before filing is one the line can still fix; found by customs, it rejects a filing. This page is about asking ICEGATE, from an open manifest, which of its bills already carry an accepted CSN and whether the two agree.

What does customs compare between a manifest and a CSN?

A small set of facts about the bill and its boxes, and nothing else: the master bill's date (164), the total packages (232), the number of containers (233), and per container its number, type, size, load status and SOC flag (234–238, 399), with the quoted CSN or MCIN/PCIN itself. Shippers, consignees, goods descriptions and values are outside the comparison entirely. Of those, only the bill date, packages, container count and load status have been seen refusing a filing; the rest are published checks no reply on record shows firing.

Customs compares a line with a CSN only when the line quotes it, and the bill's date (164) is compared as well as its number. Each CSN the check finds is shown as a scorecard: every field the two can be compared on, side by side, grouped as Fix (customs has refused filings where these differ), Check (should match) and OK to differ. What must match between the line's manifest and the forwarder's CSN lists them all.

Two-party filing and deadlines explains why both parties file against one master bill and what happens when they disagree.

Do I have to upload the SAM / SDM again to check it?

No. Every SAM / SDM opened, uploaded or recorded here is listed under SAM / SDM files kept here on the editor's page, and each vessel call's manifest has Open in the editor — press it and check it again against the CSNs the forwarders have filed since.

How do I run the check?

Open the manifest (see Working with a shipping line filing), narrow the table to the lines you care about if you want to, and press Check. Nothing runs on its own: each bill is a handful of requests to a public customs enquiry, and a whole ship is several hundred, so the check is something you start, watch by a live count, and can stop.

With nothing filtered, the button is Check the whole manifest and asks about every bill. Search or filter first and it checks only what you filtered to — the button says so — with Whole manifest beside it; a line under the results says how many bills are checked and how many are not yet.A bill already answered is not asked again. Press Check a second time and only the unanswered lines are sent.A bill carried by two lines is looked up once and the answer written to both.Stop keeps everything that has come back.Before any bill is asked about, the platform asks one manifest-level question: has customs granted the vessel entry inward? If it has, amending is no longer self-service — the shipping line files the SAA and the jurisdictional officer approves it (ICES Advisory 37/2026) — and none of that happens on this screen. So the per-line sweep is withheld, because several hundred enquiries would buy nothing you could act on here, and the panel says so. That is a saving, not a verdict that the manifest can no longer be amended: the message guide's errors 373/374 say that, and ICES Advisory 37/2026 §5.2 says the opposite, so nothing here takes a side. Check the lines that quote a CSN stays available. Only an actual inward date withholds the sweep; a lookup that failed does not.The same question compares the first bill's line number with the one customs holds it on. If they differ, the file is not numbered like the manifest customs holds — usually because customs holds a later version, with amendments the file does not have — and the panel says so (amber): an amendment built from it would address the wrong lines, which customs refuses as 749 or 306. Build amendment then checks every line it changes or removes the same way.

The lookups are batched and paced so that a large manifest never overloads ICEGATE's public enquiry, which is run for people clicking through a web page and has no published limit. That pacing is why a 238-bill check takes about half a minute rather than a few seconds.

Does it work on a departure manifest?

Yes — and since 24 September 2026 it asks the right question there. An export line's CSN is an SCX, not the SCE an import line has, so on an SDM or SDA the check asks customs for SCX records (it used to ask for SCE on every manifest, which would have read every export line as "no CSN"). The check also compares the PCIN or MCIN the line quotes with the CIN customs shows on the CSN's master row: an export CSN's own 26PCSX…/26MCSX…, or the shipping bill's 26PCEG… it referenced. On a real 284-line SDM every sampled line quoted exactly one of those two, so a line quoting neither now shows as a difference. That is the disagreement customs' cross-check exists to catch; no refusal for it is on record here yet, so read it as a check to make before sending, not as a refusal foretold.

How do I know customs took my entry inward (SEI)?

An SEI carries no bills, so there is nothing for the line-by-line check to ask about, and ICEGATE has no public enquiry that looks up an SEI by rotation — the rotation-status enquiries its service lists answered "No details found" for every SCMTR call we tried, logged in or not (September 2026). What does show it is the arrival manifest's record: open the SAM of the same call and check any one of its bills with ICEGATE, and the answer carries the date the vessel was granted entry inward, or nothing while it has not been. Entry inward is what the SEI applies for, so once that date appears the SEI (or a re-send of it) was taken.

Before you send an SEI, the Checks tab compares its counts with the SAM of the same call that you have saved here — see Working with a vessel manifest.

What do the answers mean?

Each line gets one of five verdicts, shown in the CSN at customs column and counted above the table:

Agrees — an accepted CSN is on record for this bill, and nothing it was compared on needs fixing or checking (a difference customs allows, such as the first Indian port, is not one). The filer's PAN and the CSN's tracking id are shown.Fix — a CSN is on record and differs on something customs has refused filings for: the bill date, the packages, the number of containers or a load status. Open the line to see the scorecard — each field, what the manifest says, what the CSN says — and a message to the forwarder ready to copy. Correct the line, or tell the forwarder.Check — a CSN is on record and differs only on fields that should match but that customs has not been seen refusing (a container type, a weight, a port). One side is most likely mistyped; worth a look before filing, not a refusal waiting to happen.No CSN — nothing is on record against this bill as this line writes it. This is the ordinary case, not a fault: a CSN is filed by the consignment's forwarder on their own schedule, so a manifest whose lines are mostly unanswered is one filed early rather than one that is wrong. One other reading is worth holding in mind: customs matches on the master B/L number exactly as written, its date and the port, so a forwarder's CSN keyed on a slightly different bill number (a prefix added or dropped) or a different date is on record and still answers No CSN here. When a forwarder insists they have filed, compare the bill number and date character for character before concluding they have not.No answer — the lookup itself failed. Kept deliberately distinct from No CSN: a lookup that timed out must never read as "nobody has filed". Press Check again and the failed lines are asked again.

Does the check ask customs about the consignee's IE code?

Yes, for the codes typed IEC, and only as a note. Since 22 September 2026 the same check asks customs' own Import-Export Code register whether each distinct IEC-typed consignee code on the manifest is a code it knows. That register answers about a code, not a bill, so one consignee who owns forty house bills is asked about once, and the answer is written once with every line and house bill that carries the code. A check asks about at most 200 distinct codes.

What comes back is amber, never a verdict: a code the register does not return changes no line's verdict, no count and nothing in the lead — it is listed under the lead with where it is used, and the note says in as many words that it does not stop a filing. Customs has refused no filing here for an unknown consignee code, and a code just issued by DGFT, or one being updated there, can be absent from the register while being right. Read it as "check this code against the bill of lading before you send", nothing more.

Three things the check deliberately does not do:

It never asks about a PAN-typed code. DGFT has issued the PAN itself as the IEC since 2017, so some PANs are in that register and most are not — a consignee who is simply not an importer would come back unknown while being perfectly correct. On every real manifest this platform has seen, the consignee codes are typed PAN, so on most files this part of the check asks nothing at all.It never asks about a malformed code. A code that is not ten digits (or the PAN shape) is already the schema's finding, in red, with the value quoted.It never turns "the enquiry did not answer" into "customs does not know this code". If the register cannot be reached, the check tries again on later ticks; after three tries it moves on to the bills and says how many codes were not checked, in neutral words. Press Read again to ask once more.

Why did the check pause?

The platform limits how fast it asks ICEGATE — across everyone using it, and per organisation — so that a busy day never reads as an attack on a government host. When that limit is reached the run pauses, says so, and keeps what has come back. Wait a minute, then press Check again for the rest; the paused lines are asked again, not skipped.

I edited a line after checking it — is the answer still good?

No, and the platform says so: the line's answer is marked stale rather than silently kept. The verdict described a version of the line that no longer exists, and a green tick on a line that has since changed is exactly the reading a filer would act on wrongly. Check it again.

Are the answers kept?

Yes, with the manifest. Saving the manifest saves every answer with it — the verdict, the differences and the time it was asked — so reopening it tomorrow does not re-ask a public government endpoint about hundreds of bills it already answered for. Each answer shows when it was obtained, so an old one reads as old.

If you later replace the saved copy with a newer file of the same manifest, an answer is kept only for a line the new file carries exactly as the saved copy held it, with the same bill — see Working with a shipping line filing.

Can I ask again about one bill?

Yes, where there is something to ask. A refresh appears on a row in two cases:

You edited the line after it was checked. The row reads edited since, because the stored answer describes a version that is gone. Refresh asks about that bill alone and writes the answer to every line carrying it.The check did not get an answer for that bill, and the row reads no answer.

On a row that holds an answer — it agrees, it disagrees, or customs has no CSN on record — there is no refresh, and that is deliberate. Nothing has changed since the answer was given, so the button would only offer to re-ask a question that was just answered; on a manifest of several hundred lines, a button on every row is a bulk re-sweep arriving one click at a time. There is no "clear everything and start over" either, for the same reason.

If you are waiting on a forwarder to file a CSN, the thing that changes is at their end, not yours — check the bill again on a later day by reopening the manifest and running the check on the lines that have not been asked about yet.

Whose CSNs can I see?

Only what ICEGATE's public tracking already shows about a bill: that an accepted CSN exists, the filer's PAN, the tracking id customs assigned, and the seven container facts. The platform never shows another filer's consignee, goods or values from a CSN — those are outside the public record and outside the comparison.

Counting the whole manifest. To check an amendment's totals and line numbers against what customs holds, opening an SAA counts ICEGATE's public record line by line by itself, at the top of the page, with no login — see amending a shipping line filing.