One consignment, several transmissions

A shipment that gets refused and corrected leaves you holding more files than filings. Two acknowledgements, one CSN in the folder, and both replies naming the same containers and the same bills of lading. Everything looks like it should go together, and the only thing that says otherwise is a number.

This page is about that number, because it decides which reply answers which file — and getting it wrong means reading customs' verdict against a document customs never saw.

Customs answers a transmission, not a shipment

Every time you send a message to ICEGATE it is a transmission, and it carries a sequence / control number of its own. Send the same consignment three times and there were three transmissions: three control numbers, three replies, one shipment.

That matters because ICEGATE's acknowledgement answers the transmission it received. It is not a statement about your cargo, or about your job, or about the file still open on your screen. It is the verdict on one message that arrived at one moment.

So when a filing is refused and you correct it and send it again:

the corrected message should carry a fresh control number where the first one was used up. ICEGATE refuses a number it has already processed for that job date as a duplicate, by email, whatever else you fixed — but a refusal does not use a number up: a filing refused with a 700 was accepted under its original number the same day, and so was every other 700 on record. So a file that came back refused can go again under the same number, and a file that was accepted, or that is still waiting for its answer, needs a new one. That is the rule this app applies for you, and it says on the file which of the two it did. When you cannot tell what became of the earlier send — an e-mail refusal that came before any acknowledgement, or no answer at all — give the next one a new number: that is the safe choice. (On the 700 itself: ICEGATE's engineers described a 700 on large files as database contention on 12 September 2026, and ICES Advisory 38/2026 of 21 September says large-manifest processing has been re-engineered — an answer about acknowledgement delays that does not mention 700; linking the two is our reading — so a 700 that clears on an identical re-send was likely load rather than the file, while a 700 on a small correct file is still worth the checklist in Reading an acknowledgement);ICEGATE replies to the new transmission;and the reply to the old one does not stop existing. It is still in your mailbox, still naming your master bill of lading, still looking exactly like the file you want.

One number, in all three places

There are three places a number appears on a transmission, and on almost every filing customs has accepted they are the same number:

The first two cannot disagree: ICEGATE's required file name is built from decRef.jobNo. The third is the one some software fills in separately — and of 250 declarations on record here, from several filers, 244 carry one number in all three.

Customs takes a file where they differ. Two of the six that differ were accepted, and seven more CSNs from one filer, made by this app before its control number followed the job number, are on customs' record as accepted (read in October 2026) — so this is not a refusal and nothing should be re-sent over it. What it costs is the ability to recognise the answer: customs names its reply after the control number. One accepted amendment filed as job 100114 came back named …_65717_…_ACK.json, and the body echoed 65717 as the job number too — a value that appeared nowhere in the filer's own records. Keep the two equal and the question never arises.

Filings made in this app take the job number as the control number, in both fields and in the name — amendments and deletions included. You never type it: the field is locked, and the app sets it, and the job date, every time the amendment is opened and again when it is sent.

Until 23 September 2026 the app gave an amendment a second number, on the reading that the CSN entry had already used the first for that job date. Customs showed otherwise: an amendment carrying its job number in all three places, dated the same day as the CSN entry that went out under that number, was accepted. So the entry does not use the number up for its amendment.

The one exception left is a second amendment of the same job on the same day — no filing on record shows whether customs would take the number twice as an amendment, and ICEGATE's FAQ says it refuses a control number it has already processed for a job date. There the file carries a number of its own. A refusal does not use a number up, so filing again after one keeps yours.

Two acknowledgements and one CSN: what actually happened

A worked example, from a real console-agent filing:

Same vessel, same containers, same ten house bills, same error. The only difference between the two replies is the transmission they answer. And in this filer's folder there was one CSN — the first attempt, job 148 — sitting beside the acknowledgement for job 152, because the second CSN had not been saved.

Dropping that reply onto that CSN is refused, and the refusal is right: every error in it is positioned against a document that was sent separately. Reading them together would send you to inspect a house bill in a file customs never looked at.

How to tell which reply is which

Three identifiers, in the order of how much they prove:

The control number (headerField.sequenceOrControlNumber). This is the one. A reply and the message it answers carry the same one.The job number (master.decRef.jobNo). Usually agrees — but on a rejection ICEGATE sometimes puts the transmission id in that field instead of a job number, so a reply whose job number looks like 113465834011420082026SACHM22 is not carrying one at all.The file name. ICEGATE names its reply after the file it answers, so F_SACHM22_SCE_<sender>_<job>_<date>_ACK.json usually repeats the CSN's own stem. Usually: some software names the outgoing file by the job number and puts a different control number in the header, and ICEGATE names the reply by the control number — a real amendment left as …_100114_… came back as …_65717_…_ACK. The header decides, not the name.

The date in the name is not the filing's date

This trips people sorting a folder by name. The date in an acknowledgement's file name is the day ICEGATE replied, not the day you filed. A CSN sent late on the 5th and answered on the morning of the 6th produces a reply named for the 6th, and the two file names differ in a position that looks like it should match.

So compare the job number segment, never the date one. A reply dated the next day is normal and proves nothing about whether it belongs to your filing.

What the app does with this

SCMTR JSON upload compares the two before it explains anything. If the identifiers disagree it refuses the pairing rather than warning about it, because a refusal explained against the wrong CSN is worse than no explanation.

Where the two files disagree only about which transmission they are — same sender, same reporting event, and a master bill of lading in common — it says so, because that is the case above rather than somebody else's reply landing in your folder:

Both files rule on master B/L ONEYTYO000000102, so this is the same consignment — but ICEGATE answers the exact transmission it received, and this reply is for job 152 while the CSN open here is job 148.

You then have two ways forward, and either is fine:

Find the other CSN. The one for job 152 is the file customs actually saw, and pairing it with this reply puts every error on the record it names.Find the other acknowledgement. The reply for job 148 answers the CSN you already have. The screen spells out the file name to look for, part by part, before you go and search.

Keep the file you sent, every time

The reason this comes up at all is that a corrected re-filing is often sent and never saved. The reply arrives days later, by which time the only CSN anyone can find is the attempt that failed.

Keep the exact file you uploaded for every transmission — including the ones you expect to be refused — and name them by their job number. It costs nothing and it is the difference between reading a rejection and guessing at one.

Filings made in this app do this for you: every transmission is kept as a version of the filing, so a reply can be dropped onto the filing itself and lands on the right one. See After you file.

Related

What the three files are and how to read a verdict: Reading an acknowledgement from customsUploading them to be checked, and how the screen names the file it wants: SCMTR JSON uploadWhat each identifier is and who mints it: Identifiers and trackingWhy a filing was refused, by code: Why customs rejects a filing