After you file

Signing a filing and sending it is not the end of it. Customs still has to answer, and that answer can arrive in more than one way. Since 22 September 2026 an acceptance usually arrives on its own, read off customs' own record; a rejection still arrives only in the acknowledgement ICEGATE emails. This page is about the gap between "sent" and "settled", because that gap is where most of the questions about a filing come from.

What happens the moment my signed filing is submitted?

Three things, in order:

The declaration was frozen to exact bytes before it was signed — by the scmtr DSC Signer on your computer, or on ICEGATE's portal if you took that route — and the signed file is checked against them. Nothing about it can change after this point without becoming a new version.The file is uploaded to ICEGATE, which either takes it or refuses it outright. A refusal here is about the file — its name, its structure, your credential — not about what you declared.If ICEGATE takes it, the declaration is locked and its status becomes SUBMITTED or FILED_UNTRACKED. Which of the two you get decides everything on the rest of this page.

The lock is deliberate: the file customs now holds is the signed one, so editing the copy here would put the two out of step and invite a duplicate filing of something customs already has. Changing a locked filing goes through Amend or File a deletion.

What are the ways an outcome can reach me?

There are three, and which one settles a filing depends on what customs decided.

Filings go through ICEGATE's file-upload channel, so your mailbox is still where ICEGATE sends the answer — the emailed acknowledgement is customs' own file and the file of record. What changed on 22 September 2026 is that you no longer have to wait for it to learn that a filing was accepted.

How is a filing resolved from customs' record?

ICEGATE's public SAM/IGM enquiry — the one behind BL tracking — began publishing the CSN number and date of an accepted filing in September 2026. The platform re-reads it for each filing still waiting on an answer about every fifteen minutes, for sixty days after the filing was created. A filing sent late on a Friday is resolved over the weekend without anyone opening the mailbox.

It records the number and date and turns the filing ACCEPTED only when all of these hold:

the filing was sent from SCMTR as a fresh filing — not an amendment or a deletion. A deleted CSN stays listed on customs' public record, with nothing to say it was deleted, so a listing can never settle a deletion either way (see My deletion was accepted but the CSN still shows on ICEGATE);customs' record names this very transmission — the tracking id the upload was given;it is your organisation's only filing on that master bill, so the number cannot belong to a sibling job;the record's own cargo — the packages and every container — agrees with what was sent. A record with nothing to compare does not count as agreement.

When any of those fails, nothing is written and the filing keeps waiting for its _ACK. When they all hold, the filing's history marks the outcome as read from ICEGATE's own record, with no acknowledgement file behind it — a different amount of evidence from the file itself, and the page says which you have.

Three limits are worth knowing. A rejection never appears on that record, so a refusal still reaches you only in the emailed acknowledgement, and a filing that stays submitted for a day after its siblings resolved is one to look for in the mailbox. Filings accepted before September 2026 may show no number on the record, because the enquiry did not publish one then. And the sweep is not the only way in: on a filing whose page already says Customs holds this filing, Get the CSN number asks the same record on the spot — see Using the app.

Do I still need to upload the ACK?

Yes — keep it, and drop it on the filing when it comes. The acknowledgement is customs' own file: the one ICEGATE attaches when it emails the CSN, the only document that carries a rejection's reasons, and the one a customs officer, a shipping line or an auditor will ask for. An outcome read off customs' record is a reading of a public page; the _ACK is the answer addressed to your transmission.

Dropping an agreeing acknowledgement onto a filing already resolved from customs' record keeps the file and makes it the transmission's own answer — the status does not change, the history now has the file behind it, and the CSN alert email can attach it. (Before 22 September 2026 such a drop was refused as "already recorded"; it no longer is.) An acknowledgement that disagrees with what the record said — a different verdict, or a different CSN number — is refused and named, because two answers about one transmission need a person to settle, not an overwrite.

What does "Filed — not auto-tracked" mean?

It means ICEGATE accepted the file but gave back no tracking id — nothing to ask it about later. The filing is real and customs has it. What is missing is the handle.

This is the state a filing lands in when it goes through a channel whose acknowledgements cannot be collected — filing straight on the ICEGATE portal is the common way to reach it. The platform marks it FILED_UNTRACKED and locks it rather than pretending an acknowledgement is coming, because a filing that sits waiting forever on an answer that cannot arrive is worse than one that says so plainly.

Nothing is wrong with the filing. Only the way you will hear about it has changed — and for an accepted filing sent from here, the platform can now hear about it for you. Customs' public record of accepted CSNs (see What customs already holds) lists a filing from the moment it is accepted, together with the very tracking handle that was missing. The platform reads that record in the background: if your untracked filing appears there, its handle is recovered, and from there the same reading as above applies — where the record names the transmission and agrees with what was sent, the CSN number and date are recorded and the filing turns ACCEPTED. Only accepted filings appear on that record — as of September 2026; the submission-status enquiry customs announced in ICES Advisory 38/2026 is under implementation, not live — so this is a one-way signal: presence means accepted; absence means nothing yet, not rejected.

My filing has no tracking id. Where do I look for the outcome?

Your registered ICEGATE email address. That is where ICEGATE sends the outcome — and for a rejection it is the only place the answer appears, because as of September 2026 customs' public record lists only accepted filings. Customs has announced a submission-status enquiry utility for manifest files (ICES Advisory 38/2026, 21 September 2026); it is under implementation and not live, and nothing here relies on it.

For an acceptance, watch the filing itself as well: the platform reads customs' record of accepted CSNs in the background and, for a filing sent from here, records the CSN number and date when the record names it. You can also ask directly — BL tracking in the header, or ? → Customs lookup, looks the master bill up on the spot.

The useful habit is still watching the mailbox the ICEGATE registration is under — which is often not the mailbox the person filing uses day to day. It is worth confirming which address that is before you need it.

If a reference number was returned with the acceptance, keep it. It will not let you look the filing up, but it identifies the filing to the ICEGATE Helpdesk if the email never comes.

How long should I wait before assuming something is wrong?

Customs commonly answers within 5 to 8 minutes, sometimes considerably longer, and an accepted filing then appears on customs' public record. The platform reads that record for every waiting filing about every fifteen minutes, so an acceptance ordinarily reaches the filing within half an hour of customs deciding. A filing still submitted a few hours later is one to look for in the registered mailbox: it may have been refused, which the record never shows.

Beyond a day, treat it as an outcome that has to be recorded by hand.

Before assuming the problem is yours, consider that it may not be your filing at all. ICEGATE's acknowledgement generation has stalled service-wide before, for days at a time, with every filer waiting on the same queue. The tell is that it is not just you: nothing is coming back for any of your filings, and others in the trade are saying the same. Your submission is unaffected — it was accepted and queued, and the answer is simply not being produced yet.

Customs attributes past delays on large manifest files to processing bottlenecks it says it has since removed: ICES Advisory 38/2026 (21 September 2026) describes dedicated background schedulers for large JSON manifests and database indexing across ICEGATE and ICES, and announces a submission-status enquiry utility that is under implementation and not yet live. That is customs' account of its own system, not something measured from this side — the timings above were measured before the advisory, and nothing since has been seen from customs' side that confirms or contradicts it. The advice below stands.

Do not resubmit during a stall. There is nothing to resend, and a duplicate filing is a far worse problem than waiting — it has to be settled with a customs officer rather than undone.

The same file will not go twice

Filing a second copy is rarely a decision anyone makes. It happens because nothing came back and there was no way to see what had already left. So the platform remembers.

Every filing frozen for signing is fingerprinted twice over: once on the exact bytes your digital signature covers, and once on the shipment with its transmission identity removed — the control number, the job number and date, the message's own timestamp. That second fingerprint is the one that matters, because regenerating a file changes every byte while the cargo stays identical, and a regenerated file is what a re-send actually looks like.

If a transmission has already gone and customs has not answered, the same filing is refused before it leaves, with the earlier one named and one click to open it. If customs has already accepted it, the refusal points at an amendment instead, which is the only route customs will take.

Can I override it and send it anyway?

Yes, by saying why. If you know better than we do — ICEGATE confirmed they never received the first one, say — type a reason of at least ten characters and send it; the reason is kept with the filing and shows in the audit history. The same warning is shown at the download step, before you sign, so a duplicate is caught before a signature is spent on it. And a retry never re-sends on its own: once the bytes have left, the platform does not try again, however the connection ended.

A refusal is not in the way. If customs rejected the earlier transmission, nothing of yours is sitting at ICEGATE, so the path is clear. That includes a 700: every one on record here — seven — was accepted the same day when it was sent again, so a 700 does not mean the filing is spent.

Two notes beside it that never stop you

Since 26 September 2026 the same step shows two more things it knows, as notes rather than refusals, because on both you may know better than the platform does:

The control number was already used. A file with this control number already went on this job date — sent from here, brought in from the ICEGATE portal, or recorded as made elsewhere — and the note says what came of it. ICEGATE processes one control number once per job date, so the send may come back as "The Control Number has already been processed". Open the filing the note names and see what went under the number; if you know the number is free at customs, send as you are.Customs' record already lists a CSN on this bill. The public record shows a CSN accepted under your PAN on this master B/L, and this file is a fresh CSN rather than an amendment of it. A second accepted copy has to be settled with a customs officer, so if that is the filing you mean to change, amend it instead.

Neither asks for a reason and neither is written to the audit history; they are there so the choice is made with the facts in front of you.

"Delivery unconfirmed" — we could not confirm this reached ICEGATE

Occasionally an upload leaves and no answer comes back — a timeout, a connection dropped halfway. ICEGATE may be holding the file, or may never have received it, and nothing on this side can tell the difference.

The filing shows a Delivery unconfirmed badge. It is locked and marked as sent, because that is the safer of the two assumptions, but no tracking number is claimed and nothing pretends to know more than it does. Do not upload it again. Two things happen without you:

The platform keeps reading customs' public record for that master bill. When your own filing appears there, the doubt is settled and the filing rejoins the ordinary awaiting-an-answer population.If ICEGATE emails the acknowledgement first, dropping it on the filing settles it just the same.

If it turns out nothing ever arrived, an organisation admin can return the filing to draft and you carry on from where you were.

When filings are being held

Two different things, and the message says the same thing for both, because it is the important part: nothing was sent, and your signed file is unchanged.

Pacing. The platform sends at most thirty filings a minute in total, and ten a minute from one organisation. Past that, a send is asked to wait its turn — the message says which of the two limits it met.A pause. If uploads stop completing, sending stops altogether for about five minutes rather than adding to a gateway that is struggling for everyone, not just for you.

Try again in a few minutes.

How do I record an outcome once I have it?

If the filing was sent from SCMTR and ICEGATE emailed you the acknowledgement file, drop it onto the filing. (Filed on ICEGATE yourself instead? See the paragraph after next.) The file is the one whose name ends in _ACK — the reply for that transmission. Three places take it: the filing's Status card on its own page (Upload the acknowledgement for job N, at the top of the status panel), ⋯ → Upload ACK on its row in the CSN list, and Record an acknowledgement on the CSN filing page itself, which needs no row found first — the file names its job, so the filing is found from the file (and you are asked which, if more than one could be it). All three do three things in one step: check that the file really answers this filing — judged on what the file carries (the sender, control number, event and master B/Ls ICEGATE echoes back), with the file name read only where the body is silent and its date never read at all, since that is the day ICEGATE replied rather than the day you filed; a file for another job is refused before anything is written, and told which job to open instead — set the status, CSN, date and consignment id from the file, and explain every error against the payload that was actually sent: the value customs saw, the steps to fix it, and where that field is on our screens. A rejection ends in one button, Refile (or a new amendment, when what was rejected was one); an acceptance says what, if anything, is still owed — usually nothing.

What "Refile" does. A refusal registered nothing at customs, so the fix is a fresh transmission of the same filing — the next attempt under the same job number. The button opens a corrected copy in the full form under the same job and control number: ICEGATE refuses a number it has already processed for that job date, and a refusal does not use one up — a filing refused with a 700 went again the same day under its original number and was accepted. A number is only pushed on by an acceptance, or by a transmission still waiting for its answer, and then the file says so. The refused attempt stays on the filing's page exactly as it was sent, with every error explained and marked on the record, and inside the form a banner lists what customs refused with a jump to each field. When it is signed and filed it appears in the history as attempt 2 beside attempt 1. The same button is on the filing's page and in its row's menu; "Use as template" is for a different shipment and starts a new job.

An acceptance that grants a CSN another of your filings already holds is refused, and names that filing — a CSN belongs to one filing, and the usual cause is the right acknowledgement dropped on the wrong one.

If ICEGATE's own answer grants a filing a CSN that another of your filings already carries, the acceptance is recorded but the number is not: the filing's page says ICEGATE granted this filing CSN …, which job … already carries here, links to that filing, and holds back amending, deleting and e-mailing until it is settled. When the other filing's copy was recorded by hand, an organisation admin settles it from that notice: the CSN moves to the filing ICEGATE granted it to, and the other filing goes back to waiting for its real outcome to be recorded. If both came from ICEGATE's own answers, take both acknowledgements to the ICEGATE helpdesk. Whoever records an outcome, the record shows it came from an uploaded file, and the audit trail names it.

If you filed it on ICEGATE yourself — a draft kept here that you downloaded and uploaded on the portal, or a filing made entirely elsewhere — use Record a filing made elsewhere on the CSNs page, with two files: the one you filed and its acknowledgement, accepted or refused. Dropping the acknowledgement alone on such a draft explains it but records nothing, because the draft may have been edited since it was downloaded, and what goes on record has to be what customs received. The two files are matched to the draft on their control number and job number (and job date where both carry one) — never on the master bill of lading alone — and the version kept on the filing is made from the file you filed. Any member may record a filing they may edit this way; an organisation admin with no acknowledgement file may record an acceptance from the CSN typed off the portal, and the record says it was a person's word. A filing imported with Keep it here keeps the job number, job date and control number the file came with (shown as Imported as job N on its page and in the list), so the original file you filed finds it too. An upload of it that ICEGATE refused at the door does not count as a send from SCMTR; one whose delivery was never confirmed does, and is settled on the filing's own page.

If you had started Sign & upload on that draft and given up — a cancelled PIN window, a signer that failed — the copy it prepared is set aside when the hand filing is recorded, so it can never be sent afterwards. You can also discard it yourself from the top of the filing's page with Discard prepared send, if you prepared it, own the filing or are an organisation admin: nothing is sent to customs, and the draft stays as it is.

If the outcome is already there because the same file was dropped twice, nothing changes and it says so; the errors are still explained. If it is there because the platform read it off customs' record first — the ordinary case for an acceptance since 22 September 2026 — an acknowledgement that agrees is kept and becomes the transmission's own answer, as above. Two answers that disagree about one transmission are never settled by overwriting: that needs a person, and an organisation admin can set the status directly.

If you have only the email's words and no file, open the declaration and use the Status card's form. Choose what the email said, add the CSN number and date if one was granted, and note where the information came from.

Either way the filing then behaves exactly as it would have if the acknowledgement had arrived on its own — an accepted one can be amended, a rejected one unlocks for a corrected re-file.

Two things worth being clear about:

Recording an outcome tells customs nothing. It is a record of what you were told, kept here so the filing's state matches reality. It sends no message and changes nothing at ICEGATE.Every change is audited, with who made it and when.

Who is allowed to record it?

Any member can record an outcome, but only forwards — a filing moves along its lifecycle, never back.

An organisation admin can set any status in either direction, including putting a filing back to draft so it can be edited and filed again. That exists for the cases where something was recorded wrongly, or where a filing needs to be reopened after the fact.

What if I recorded the wrong outcome?

Ask an organisation admin to set it to what it should be. Nothing is lost: the filing history keeps every version and every submission, and the activity log keeps every status change for twelve months, so the correction is visible rather than silent.

What if the email never arrives at all?

For a fresh filing sent from here, first look at the filing itself: if customs accepted it, the platform has usually read the CSN number off customs' record already and the filing is ACCEPTED without the email. A filing that is still submitted is one customs may have refused — and a refusal reaches you by email only. Work through it in this order:

Check the right mailbox. The address on the ICEGATE registration, not the one you use for work — they are frequently different, and this is the most common cause by a distance.Check spam and quarantine. These are automated messages from a government gateway and they are filtered more often than you would expect.Contact the ICEGATE Helpdesk, quoting the reference number if one came back with the acceptance, plus the job number, the job date and your ICEGATE ID.

Meanwhile the filing sits in its locked state, which is the honest place for it: something was filed, and what customs decided is not yet known.

Will I be told if customs stops listing the call my filing names?

Yes — on the filing's page, and by email.

A filing names one call of one ship — the IMO number and the VCN. Since September 2026 the filing's page keeps two things about that pair. The Voyage reference line carries the call's expected arrival and the date customs last listed it. And when customs' latest answer about the ship no longer includes your VCN — or when the shipping line's own accepted filing against your master bill names a different ship or call — a notice says so at the top of the page. It is shown on a draft, on an accepted filing, and on one filed but not auto-tracked — the three states whose call can still be changed. On the untracked one it says the same thing but does not offer to start the amendment: there is no accepted CSN to amend until you record what customs' email said, and recording it is what opens that route. A filing still waiting on customs' answer gets no notice on its page, because there is nothing to do about it yet — but the email below is still sent for one, since a call that has gone is worth knowing about while you wait.

What it rests on is worth being precise about, because the page makes no enquiry when you open it. The line and the notice read customs' latest answer about the ship as this platform holds it, and they name when that was.

That answer is usually a recent one — the platform keeps reading customs' list for the ships your open filings name, more often for a ship that is about to arrive — but it is not kept fresh on any schedule you can rely on, and two things stop it altogether. A filing created long enough ago passes out of what is watched, however far off its arrival still is. And where live checks with customs are switched off, nothing is asked at all: every surface then shows the last answer on record and says so in as many words. How often it is otherwise asked changes with how close the arrival is and with what customs will tolerate being asked, which is why the page names the time of the answer it is showing you rather than a schedule — and why Check now is there. The whole of it is on When the ship changes. Check now asks customs on the spot, one request per click, and the page updates from the answer. The comparison against the line's filing costs no request at all: it reads the record of accepted filings the platform already keeps for your bill (see What customs already holds).

The same answer is kept on the transmission itself. When a filing is sent from here, what customs had last listed for the ship at that moment is recorded with it, so a later refusal can say whether your VCN was among the calls customs listed when you filed, and what it listed at your port instead — for a 700, and for the voyage codes 20, 24 and 212.

Be exact about what that is worth. It gives the refile checklist's voyage step something to read where it otherwise has nothing, and what it reads is what customs' public enquiry listed on the day — not what customs validated your filing against. It can show that your VCN was absent from that list, or that customs listed it at a different port, and both are worth knowing. It cannot show that the absence is why you were refused, and the step is worded to say so: a filing on a call customs has stopped listing is at risk of refusal, and a vessel substituted close to the ETA is offered as a possibility rather than a diagnosis. It applies to filings sent from here from September 2026 for a ship customs had been asked about; earlier filings, and a ship nobody here had looked up, carry no such record and the step stays as it was.

And you are emailed, so a filing you do not open is not a filing you hear nothing about. The email goes to the person who created the filing, once for each fact, and only once customs has said the same thing twice — on two separate answers, hours apart, both of which leave your call out. One odd answer from customs is not a substituted vessel, and it should not put mail in your inbox. It says what customs no longer lists and what it lists at your port instead, and it asks you to look: nothing has been changed on your filing, and nothing has been filed. And when customs answers nothing about every ship the platform asks after at once, that is read as customs having a bad moment rather than as every call vanishing at once: the checking stops itself for a while, records no absence and writes to nobody. A draft gets no such email — it gets the badge on your CSN filing list and the notice when you open it, which is before anything has gone to customs. The one email a draft does get is the opposite case: a draft saved with a ship but no VCN is told the first time customs lists a call for that ship at your port. There is no setting for these emails yet; see I prepared the filing early for what the check can and cannot see.

When the colleague who created the filing has left. The mail goes to whoever created the filing, and only to them. There is no setting to redirect it, no shared-mailbox option and no copy to an administrator — and if that person is no longer a member of your organisation it is not sent at all, to them or to anyone in their place, because a filing's job number, vessel and bills should not go on reaching a mailbox the organisation no longer controls. If they are merely on leave, it goes to them and sits unread.

What the rest of the desk can still see is the CSN filing list: the badge sits on the row, for anyone who can see the filing. Two habits close the gap on a shared filing desk — look down the list for badges when you come on shift, and on any job that matters, open it near the ETA and press Check now rather than relying on mail addressed to somebody who is not reading it.

Where the call has changed and customs has accepted the filing, the correction is an update amendment and the window for it is the line's filing — see The ship changed after customs accepted my CSN.

I have four filings on that ship and only one email came — are the other three fine?

Do not read it that way. Each filing is watched on its own and written about on its own: the mail is per filing, and once for each distinct fact about that filing. Four filings naming the same call that has gone should each produce their own mail.

So one email arriving says nothing about the other three. The ordinary reasons the rest are quiet, none of which means "checked and well":

one of them is a draft, which is badged on the list rather than mailed;it names a different call, or a different ship, from the one that moved;it was created long enough ago to have passed out of what is watched — the clock is the filing's own age, not how far off its arrival is;its cargo has already appeared on the carrier's manifest, after which the filing is left alone;it was refused, cancelled or superseded, and a filing in one of those states is not followed at all;it carries a VCN customs never listed — there is no earlier answer for it to have dropped out of, so there is no change to report;or its vessel has no IMO number, in which case nothing about it is ever checked or mailed at all.

The place to see them together is your CSN filing list. Every row names its vessel by IMO number and its voyage reference, and the search above the list reads every value in every filing — so typing the IMO number, or the VCN, brings up every job carrying it. A row whose call needs a look carries a badge, Not on customs' list or VCN now available, and hovering the badge names the customs answer it rests on.

A row with no badge is not telling you it was checked and found well. It is telling you nothing. When a sailing changes, open each job that names that ship and press Check now — that asks customs on the spot — rather than counting the emails.

Related

Reading an acknowledgement from customs — which of the three files you have, and what its verdict meansEvery ICEGATE error code — including the refusals that arrive by email with no code at allWhy customs rejects a filingAmendments and deletions — changing a filing customs acceptedUsing the app — every status and what it meansTwo-party filing and deadlines — why an amendment window can close before you act