Amendments and deletions

Once a CSN is accepted it cannot be edited, and while customs holds it it cannot be filed again. Anything that changes afterwards goes through an amendment — reporting event SCA — which points at the CSN customs granted and says what changed. Same cargo, same filing, one more message about it. (A deletion before the shipping line's manifest was already the submitter's own under ICES Advisory 37/2026; since ICES Advisory 38/2026 customs says it can be followed by a corrected re-file — see amend, or delete and re-file?.)

My CSN was accepted but the details in it are wrong — what do I do? Can I delete it?

Amend it, and do it today. An accepted CSN cannot be edited; the correction is an amendment against it, which keeps the CSN everyone downstream already quotes. You can delete it and file a corrected one instead — as long as the shipping line has not yet filed its manifest against the CSN. That is customs' stated position since ICES Advisory 38/2026 (21 September 2026): the ANC may cancel a CSN before the SAM and "promptly re-file corrected particulars without generating mismatch conflicts". Before that advisory the same sequence was measured failing once (122/123), and no re-file after a deletion has yet been seen accepted from customs' side since it — see deleting does not free the bill of lading for what is known. Once the line's manifest is filed, a deletion is the customs officer's (ICES Advisory 37/2026) and amendment is the route.

The quickest way, wherever you filed it: drop the CSN on SCMTR JSON upload. Drop the CSN JSON you filed on SCMTR JSON upload at the top of CSN filing. Amend or delete this CSN offers File an amendment and File a deletion — no ACK file needed:

Choose one, and SCMTR asks ICEGATE's own record for your filing — the public enquiry, on the port, master B/L and your PAN in the file — and compares what customs holds with the file, field by field.If customs holds this filing, you are shown what it holds — the CSN number and date, the transmission, the bills — before anything is saved.Fetch CSN & open the amendment (or deletion) records the filing as accepted on customs' record — marked in its history as read from ICEGATE, not typed by hand — and opens the change.

If ICEGATE's public record holds your filing but not its CSN number, the organisation's ICEGATE portal login reads it: an organisation admin can add it right there (it is checked with ICEGATE before it is saved, and kept encrypted); anyone else is pointed to Settings → ICEGATE portal login. If customs holds your filing differently from the file you dropped, nothing is opened — you are shown which fields differ, because an amendment built on the wrong version changes what you did not mean to. Drop the version you actually filed, or its ACK file.

If customs holds nothing — no accepted CSN by your PAN for the bill — there is nothing to amend or delete, and the same panel offers File it fresh instead: a new CSN under your job number, with a control number never used before and the cargo exactly as in the file, opened ready to Sign & upload. It is also a button of its own beside amend and delete, and it asks customs first too: a CSN customs already holds is never filed twice (ICEGATE refuses the second with 122/123), so that answer turns into amend or delete instead. A CSN kept here as a draft opens that draft rather than a copy; one customs rejected opens its Refile; and one sent from SCMTR that is still waiting for customs' answer is not filed again at all.

With the ACK file it is quicker still: drop the CSN and the ACK file that accepted it, either order, and the same two buttons open the change straight away — on a filing already here, on one you uploaded from here and were waiting on (the ACK file is recorded first), or on one filed on the ICEGATE portal or in other software (brought in under your organisation, its own ICEGATE job number kept, so later ACK files find it). An ACK file dropped on its own for a filing of yours offers the same two buttons as soon as it is recorded.

Either way the draft opens with Your amendment is ready (or Your deletion is ready) above the form and Sign & upload highlighted — it is filed with your DSC from here, so there is no JSON to download. (If the DSC signer cannot be installed on your computer, the window that says so still offers Sign on ICEGATE, the portal route, so you are never left without a way to file.) Correct what was wrong, check the changes, sign. If another party's CSN against the same master bill is already accepted, the upload warns that customs' error list has a refusal for changing a CSN linked to another (320) — none has been seen yet, so the change still opens. If only the shipping line's manifest covers the bill, the amendment is still offered, but a deletion and a fresh filing are not — see how long you can amend or delete.

If you filed it from SCMTR, from the filing itself:

Open CSN filing and find the filing — it shows as accepted, with its CSN number.Choose Amend this filing, on its row or on its page (under ⋯ on a narrow screen).Correct what was wrong. Every field you change is highlighted with what the accepted filing said, and Changes in the toolbar lists old and new values — read it before signing.Sign & upload, exactly as for the original. It goes to customs as an amendment against your CSN, and customs' answer comes back to your registered ICEGATE e-mail like the first one — drop the _ACK file on the filing to record it.

To withdraw the CSN altogether, the same places carry File a deletion — until the shipping line's manifest covers the bill; from then on a deletion is your jurisdictional customs officer's to make (ICES Advisory 37/2026), and the action is withdrawn. Since ICES Advisory 38/2026 customs says a CSN deleted before the manifest can be re-filed corrected — whether by this message or by a new option it does not say; read deleting does not free the bill of lading first all the same, because the one re-file after a deletion on record here was refused (122/123) — before the advisory — and none has been seen accepted since.

If you filed it on the ICEGATE portal or in other software, either amend it on the portal where you filed it, or bring it here first: CSN filing → Record a filing made elsewhere, upload the file that was filed and the acknowledgement that accepted it, and Amend this filing then works as above. The detail is under the filing I want to amend was made on the ICEGATE portal.

Check the window before either. Amend or delete before another party's CSN against the same master bill is accepted if you can: customs' error list has 320 for changing a CSN linked to another, though no reply carrying it has been seen. The shipping line's manifest does not close the amendment — since ICES Advisory 37/2026 (18 September 2026) you still file it, and the line follows with a matching manifest amendment — but it does take the deletion out of your hands. See how long you can amend or delete. A filing's page here says which applies.

A filing customs refused is not amended — it never received a CSN. Correct it and send it again with Refile.

I am the consolidator — which amendments can I make, and which must the line make?

You amend your CSN; only the line amends its manifest. Each party changes only what it filed, on its own ICEGATE login. When the line's manifest has to change, your part is to give the line the details, and the line files the amendment.

Yours (CSN amendment, SCA):

Anything in your CSN except the VCN and rotation number. Those two cannot be amended at all (ICES Advisory 37/2026).Deleting your CSN and filing it again, only while no SAM has been filed against it (ICES Advisory 38/2026, Q5). Once a SAM refers to the CSN, a deletion is the jurisdictional officer's (Advisory 37/2026).

The line's (manifest amendment, SAA):

A master bill changing from straight to consolidated (or back), a change of consolidator PAN, or of the prior reference (CSN / PCIN / MCIN). Customs refuses these as an update. The line drops its line item and re-adds it as consolidated against your CSN (Advisory 38/2026, Q1–Q2).The container size (ISO) code and container agent PAN. Since Advisory 38/2026 (Q4) customs checks these on the SAM only.Its matching amendment after yours. If you amend after the SAM, the SAM still shows your old data until the line files an SAA for your bill's line.

Who files what, and when:

What to send the line: your CSN number and date, the master B/L, and exactly what changes. For a change of consolidation, write "drop our line item and re-add it as consolidated against CSN … dated …". My console's house bills are not on the line's manifest has the full ask, and ICES Advisory 38/2026 has customs' own words to quote.

Will my amendment make the line file an SAA — and pay for it?

Only if it changes something the line's SAM carries, and only once the SAM is filed. Before the line files, every change is free. After it, a change to the master BL date, packages, containers, load status, weight or ports, or to a house BL's number, PCIN, customs location or containers, means the line files an SAA (lines charge up to ₹10,000 a request); a change to a house BL's parties, addresses, marks, goods or HS codes should not, because customs' own table leaves those to your CSN. When you sign an amendment, SCMTR sorts every change this way against the line's SAM as customs holds it — the full table and its caveat are in Check your CSN against the line's SAM.

The rule that decides everything else

An amendment references a CSN. That is what makes it an amendment rather than a second declaration. decRef.csnNmbr and decRef.csnDt carry the granted number and date, and both are mandatory for SCA. Get the CSN wrong and you have amended somebody else's filing.

The CSN this amendment names does not exist

This is what a wrong reference comes back as. Customs matches the number and the date together, so a date one day out fails exactly like a wrong number — and the date is the half that is usually wrong, because four plausible ones are within reach. Take both from the positive acknowledgement of the filing being amended, master.decRef.csnNmbr and master.decRef.csnDt in that file: not the date it was filed, not the date on the acknowledgement's own header, not today. Two other causes reach the same code — the filing being amended was refused and so never received a CSN, in which case the cargo is filed fresh rather than amended; or the CSN belongs to another sender ID or another port.

A refusal of an amendment leaves the original exactly as it was. Do not respond to one by filing the cargo fresh: the original is still on record and the bill numbers collide with it (122/123). Correct the amendment and send it again as an amendment, under a new control number. (An accepted amendment is a different matter — see an accepted amendment can empty the record below.)

Where SCA and the CSN number actually go

Filers ask "in which field does the CSN number appear" and "in how many places do I write SCA". Read off real amendment files, the answer is short:

So SCA is written in four places — the file name, the header's reporting event, the header's version and the declaration reference's reporting event — and the CSN number lives in exactly one, decRef.csnNmbr, with its date beside it. Everything else in the header (senderID, receiverID, indicator, messageID) stays as it was. Both values come from the positive acknowledgement of the original: master.decRef.csnNmbr and csnDt in the ACK. Do not take them from a tracking enquiry — the public enquiries do not return the CSN number.

A deletion is not its own message type

This surprises people. To withdraw a filing you send an amendment whose amendment type is delete:

msgTyp:  "A"      ← amendment, not "D"
amdType: "D"      ← what it does to the CSN

There is no msgTyp: "D" on the wire.

A deletion also carries almost nothing. Header, decRef, authPrsn, vesselDtls — and no voyageDtls, no cargo tree at all. Which stands to reason: you are withdrawing the whole CSN, so there is nothing left to describe. Some filing software writes voyageDtls into a deletion anyway — the original CSN's totals, or zero lines over nothing. No refusal on record says either is wrong, so the check here does not stop a deletion for it; the deletion SCMTR builds leaves them out. A real deletion message is under 600 bytes against a 3,500-byte original. This is the whole of one, with the parties made up and the shape kept exactly as an accepted filing's deletion carried it:

{
  "headerField": {
    "senderID": "YOURICEGATEID",
    "receiverID": "INENR1",
    "versionNo": "SCA1102",
    "indicator": "P",
    "messageID": "SACHM22",
    "sequenceOrControlNumber": 18561,
    "date": "20260827",
    "time": "T09:38",
    "reportingEvent": "SCA"
  },
  "master": {
    "decRef": {
      "msgTyp": "A",
      "prtofRptng": "INENR1",
      "jobNo": 18561,
      "jobDt": "20260825",
      "rptngEvent": "SCA",
      "csnNmbr": "1431790",
      "csnDt": "20260825",
      "amdType": "D"
    },
    "authPrsn": {
      "sbmtrTyp": "ANC",
      "sbmtrCd": "AAAAA0000A",
      "authReprsntvCd": "AAAAA0000A"
    },
    "vesselDtls": {
      "modeOfTrnsprt": "1",
      "typOfTrnsprtMeans": "10",
      "trnsprtMeansId": "9334686"
    }
  }
}

Note what is not there. There is no cargo movement, no port, no consignee — so there is no such thing as a "DPD deletion" or a "CFS deletion". A deletion is the same three blocks whatever the cargo was doing, and the only thing that identifies the filing being withdrawn is the CSN number and date.

An update carries the whole filing

An update (amdType: "U") is the opposite: the accepted filing re-sent in full — every master consignment, house bill, container, item and itinerary leg — with the CSN reference added and the changed values corrected in place. Nothing is removed and nothing is restructured.

One house bill's weight is wrong in a consolidation — do I amend only that bill?

How to do it, once customs has accepted the console:

Open Your CSNs, find the console, and choose Amend this filing — on its row or on its page (under ⋯ on a narrow screen). A console filed on the ICEGATE portal or in other software is brought in first with Record a filing made elsewhere (the filed file and its ACK).The editor opens a copy of the accepted filing with the CSN reference already filled in. Correct the house bill's Gross weight, its share on each container row, and the master's row for the same box — the table below says which is which. Leave everything else as it is.Press Sign & upload. It goes to customs as an amendment (SCA) of the whole console, and its acknowledgement comes back the same way as the first filing's.

Editing the saved draft is not an amendment — an accepted filing only changes at customs through an SCA.

No, and there is no way to. An update carries the whole filing: the console goes back to customs entire, every house bill in it, with that one bill's weight corrected in place. What makes it an amendment of that bill is not what you leave out — it is the line numbers. MCRef.lineNo and HCRef.subLineNo are how customs finds the record you mean, so correcting the figure and changing nothing else updates exactly the one house bill.

Both ways of trying to send "just that bill" make it worse:

Do not flag the other house bills D. D on a house bill asks customs to delete that record. Every record opens flagged U when the amendment opens, which is what the one accepted update on record carried, and correcting a weight never means touching a flag — see do I have to set the flag.Do not renumber the rows to bring the corrected bill to the top. A line number is an identity, not a position, and renumbering silently re-points customs' records at each other (306, 307) — see line numbers are identities.

Where a house bill's weight actually lives

On a consolidation the weight is stated in more than one place, and they have to move together or the filing contradicts itself:

Containers, shared boxes, and FCL vs LCL has the rule and a worked example of two bills in one box. The app checks the two levels against each other box by box, in the amendment exactly as in a first filing: a package count that does not add up blocks filing, a weight that does not add up warns.

Does the shipping line have to amend its manifest too?

For a weight alone, on customs' published list, no. A CSN and a manifest are cross-validated on the bill's date and seven physical facts about the container — the total packages, the total equipment, and per container its type, number, size, load status and shipper-owned flag (164, 232 to 238). Weight is outside that comparison. The app still shows a weight that differs from the line's as Check, because on the accepted pairs measured where the line quotes the CSN the two agreed on it all but once — see What must match.

If the package count moved with the weight, that is a different matter: the totals are compared, so give the line the amended CSN and its MCIN/PCIN and ask it to file the matching manifest amendment (SAA) — its SAM was filed against your original figures and does not update itself. Either way, tell the line if the bill is already on its manifest.

Check the window before you start. Another filer's accepted CSN against the same master bill may close it without notice (320 in customs' list, not yet seen on a reply), and once Sea Entry Inwards is granted your SCA and the line's SAA both need the jurisdictional officer — see how long can I amend or delete.

The amendment's shape is the one accepted update on record here plus the message guide; the weight and package rules are read off accepted consolidations; 232–238 and 320 are ICEGATE's published list. No refusal we hold is for a house bill's weight.

The ship changed after customs accepted my CSN — how do I correct the vessel and VCN?

As of 18 September 2026, you cannot correct the VCN this way — read this whole section before you send anything. ICES Advisory 37/2026, "Process of amending CSN(SCA)/SAM(SAA)", states plainly that anything in a CSN can be amended except the conveyance reference (VCN) and rotation number — not before Sea Entry Inwards, not after, not with a customs officer's approval. It is a flat exclusion from the field, not a timing question, and it is worded no differently for a wrong VCN than for any other one: the advisory does not carve out "unless the call was mis-picked".

This corrects what the rest of this section used to say. Until this advisory, the only source on this was the message guide's own shape — the vessel and voyage blocks carry an amendment flag in its 2026 revision, which reads as intent to allow exactly this correction — and the one accepted update on record here never exercised it, so the route was marked unproven rather than wrong. The advisory is a stronger source than an inference from an unused flag, and it says the opposite of what the guide's shape suggested. Do not amend a CSN to change its VCN. Whether the vessel block's IMO number (vesselDtls.trnsprtMeansId) can still be corrected on its own — where the hull changed but you leave the conveyance reference exactly as accepted — is not addressed by the advisory either way, and untested here; treat it as unresolved rather than assume the exclusion stops at the voyage block.

What that leaves you with is not settled, and this page says so rather than guessing. The advisory gives no remedy for a CSN that already carries the wrong VCN — it only says the field cannot travel in an amendment. Deleting and re-filing is the one route customs has since named for a CSN that is wrong before the line's manifest — ICES Advisory 38/2026 (21 September 2026) has the ANC cancel the CSN and re-file corrected particulars — and it is the obvious fit for a field an amendment cannot carry. But it is stated, not yet seen: the one re-file after a deletion on record here was refused 122/123, before the advisory, and none has been seen accepted since (see Deleting does not free the bill of lading); and it is open only while the line has not filed. Whichever way you go, raise a stale VCN with the shipping line, whose own manifest carries the call your CSN is cross-checked against, and with your jurisdictional customs officer, and do it as soon as you notice it — not because an amendment will fix it, but because whatever the eventual fix turns out to be, fewer doors are open to it once the line's manifest is filed and fewer still after Sea Entry Inwards (see how long you can amend or delete).

In the app, the notice on a filing's page no longer offers an amendment for this. When customs' latest answer stops listing your call, or the shipping line's own filing names a different ship, the notice says so and tells you to take it to the shipping line and your jurisdictional customs officer; the voyage e-mail says the same. (Until 19 September 2026 it offered Amend on Vessel details, which opened an amendment draft to pick the new call in.) If you open an amendment yourself and change the VCN in it, the field is marked with a warning citing the advisory. Nothing stops you sending it, because no refusal for this has been seen yet and nobody here knows what ICEGATE's system does with such an amendment: it could accept it, accept the message but ignore the VCN, or refuse it. So treat sending one as going against advice customs has published, not as the fix. If you do send one, read what happens after you send it knowing that "accepted" may mean customs took the message but did not apply the VCN inside it.

It costs one submission, signed like any other, and while it is pending customs refuses a second amendment on the same CSN (319).

The line reissued the master B/L with a new number — can I amend that?

Stop before you touch the form, because both of the obvious moves are traps.

An update amendment re-sends the whole filing, so a master bill number can travel inside one like any other field, and the Changes list will show the old number against the new. But the bill number is the identity customs matches your CSN and the line's manifest on, and customs' own list carries 164 Mentioned MC-BL Not Matching With CSN BL and 165 for the house level — which is what an amendment that moves the bill out from under the CSN looks like. No filing we hold has tried it, so treat that route as untested rather than as available.

Two more things to weigh, and they are firmer than that.

Delete and re-file only with your eyes open. Since ICES Advisory 38/2026 (21 September 2026) customs says an ANC may delete a CSN before the line's manifest and re-file corrected particulars — which would cover a reissued bill number as much as any other field. What was measured before the advisory runs the other way: a deletion acknowledged, then a fresh filing on the same bills refused 122/123 (6 September 2026), and no re-file after a deletion has been seen accepted from customs' side since. A new master bill number on its own did not rescue that filer either, because the house bills kept theirs and 123 HC-HBL Details Already Exists refuses the fresh filing on those alone. See Deleting does not free the bill of lading before choosing it.

Renumbering both levels is a different matter, and it is the one route known to have worked. 122 and 123 are two checks on two numbers, so clearing one and leaving the other clears nothing — which is what the paragraph above is about. A filer whose gateway port moved had the master and the house numbers reissued together and filed fresh on the pair, and it went through, while the shipping line had not yet filed. That is not "a new master bill number rescues you"; it is the whole set of bills being new, and the line's silence is half of why it worked. The account, the condition it depended on and what about it is still unknown are all in deleting does not free the bill of lading.

Do not simply file a second CSN under the new bill number while the old one still stands. That leaves two records against one shipment, one of them wrong, and both visible to the line and to customs.

So the first question is for the line rather than for the form: has the bill number itself changed, or only the sailing under it? The two arrive in the same email and need opposite answers — a new vessel and VCN on the same bill is the ordinary vessel correction, and only a genuinely reissued number is this problem. If it really has been reissued, settle it with the line and your jurisdictional customs officer rather than in the form, and do it today: another party's CSN against the master bill may shut your window without notice (320 in customs' list, not yet seen on a reply), amendment route included; and once the line's manifest is filed, a fresh filing is no longer the route and a deletion becomes the officer's (ICES Advisory 37/2026).

Read off customs' published error list and the amendment shape in the message guide. No acknowledgement we hold answers a bill-number change either way.

The new ship arrives at a different port — can I change the port of reporting?

On a draft, yes — it is a field like any other. Picking a call at another port with Use does most of it for you: the call's port is written into the port of reporting and into the header's receiver where those still hold the value the draft opened with, and the panel lists what it filled ("Filled: VCN · receiver INMUN1 · port of reporting"). Check the rest by hand afterwards, because they do not all move together — the first port of entry on each bill, and the cargo's own ports of acceptance, unlading and receipt, stay as they were.

If the two end up disagreeing, two different things say so. Customs' own list carries 59 First Port is Not Same as Port of Reporting, whose published resolution is that the port of reporting should be the first Indian port the vessel enters — that one arrives as a refusal. Before that, the check against customs' list pauses on exactly this case: a call customs does list, but at a different port from the one you are reporting to. It says so and offers to continue anyway — the VCN is never rewritten for you, and nothing is ever filed on your behalf.

On an accepted CSN, treat it as a bigger change than the vessel. The port of reporting is where the filing was made: it runs through the first port of entry, it decides which customs location the filing sits at and therefore which officer can help you, and a CSN is found within the port it was filed at — customs' 255/256 refuse a referenced CSN number and date that differ by port. An update amendment can carry a new one, since it re-sends the whole filing. But no filing here has corrected a port of reporting after acceptance, and a changed gateway port may be a matter for a fresh filing at the new port rather than an amendment at the old one — which is the question to put to the jurisdictional officer at the port you filed at, inside the window, before you send anything.

One thing to know if you do it in an amendment here: a changed port of reporting does not appear in the Changes list. That list deliberately leaves out the message envelope and the declaration reference — the blocks the amendment machinery fills for itself — and the port of reporting lives in the declaration reference. So a port moved by a Use click on a call at another port is a real change to your filing that the count will not show you. Read it on the declaration reference itself before signing, the same way you would read the CSN number there.

Marked as unproven: this is read off customs' published error list and the port fields, not from an acknowledgement we hold.

The app shows you exactly what your amendment changes

An amendment opens as a copy of the accepted filing, and from then on the app keeps score against it:

Every field you change is highlighted where it appears, with a line underneath saying what the accepted filing had — "Was EGLV000000000101 in the accepted filing", or "Blank in the accepted filing — this is an addition".The Changes button in the toolbar counts them live. Open it and you get the whole list — old value, new value, grouped by section, each entry a link straight to the field. This is the last thing to read before signing: it is exactly what you are asking customs to change.Changes (0) is itself a warning. An amendment that changes nothing asks customs to update a CSN with itself — if the count is still zero, you have not yet made the correction you opened the amendment for.

The fields the amendment machinery fills for itself — the message envelope, the CSN reference, the per-block amendment flags — are never counted or highlighted. The list is only what you changed.

A deletion gets no change list, because there is nothing to edit: it opens read-only, every field locked and nothing to add or remove, with a clear warning that signing it withdraws the whole CSN at customs. It is the filing customs holds, CSN number and all, so the only thing to check is that it is the filing you mean to withdraw. The CSN number is checked again when you sign — a deletion is only ever sent for the CSN it was opened for. If you meant to correct the filing rather than withdraw it, discard the deletion and use Amend.

An amendment or deletion in progress appears on the filing's page as Continue amendment or Continue deletion, with a matching Discard action if you change your mind — discarding throws away only the unfiled copy; the accepted filing at customs is untouched.

Do I have to set the "Amendment" U / D / S flag on the fields I change?

No — correct the values and leave the flag alone. Every master bill, house bill, container, cargo item and route leg in the amendment has an Amendment dropdown (U — Updation, D — Deletion, S — Supplementary), and when the amendment opens each one of them is already set to U for you. That is what an update carries: the accepted update on record here (job 22) re-sent every one of those records flagged U, not only the ones whose values changed. Changing a weight or an address does not mean touching the flag.

Vessel and voyage are marked U for you when you pick a different call or change the IMO number — see the ship changed after customs accepted my CSN. Anything you set there by hand is kept.The message's own type (update or deletion) is set by the button that opened the draft — Amend this filing / File an amendment or File a deletion — and cannot be edited.The Changes list never counts the flags. It shows only the values you changed.

You change a flag in two cases only:

To remove one record from the filing — one container, one cargo item, one house bill — set that record's flag to D. To withdraw the whole CSN, do not mark everything D: use File a deletion, which sends the short deletion message customs expects. No accepted amendment on record here removes a single record this way — it is the guide's own meaning of D — so if customs refuses it, ask the ICEGATE helpdesk before trying again.A record you add during the amendment (a house bill, container, cargo item or route leg that was not in the accepted filing) starts with the flag blank, and the checklist asks you to set it: S is the guide's value for a new record. The guide allows S on every one of these; only the vessel, voyage and authorised-person blocks take U alone (error 304, "Only Update-U is Allowed"), and the form offers only U there. A new row marked U is red in the checklist with Mark it added (S) — customs refused an amendment that addressed a route leg it did not hold (750, October 2026). An amendment brought in from other software has its blank flags on new records set to S for you, and U on the rest. No accepted amendment on record here adds a record with S yet.

Where the amendment flags go

The per-record flag is amdType, the same name as the message-level one. It does not go on every block. It is mandatory on the six things that own an identity or a sequence number, and optional on the rest:

That is the same set customs matches amendment records on, which is what makes it a rule rather than a convention. The right-hand column is where the guide's 2026 revision lists the flag as optional; the accepted update on record carried it on none of them, because none of them had changed, and the one case that uses it is a substituted vessel. The supplementary reference (supRef), which no filing here has carried, is mandatory under the same revision, like the six on the left.

Values: U updates an existing record, D deletes one, S adds a new one.

Line numbers are identities, not positions

MCRef.lineNo and HCRef.subLineNo are how customs finds the record you mean. Two error codes exist purely for getting them wrong:

306 Line_No+Sline_No Not Exists For Update/Delete — you updated a record customs has no such line for.307 Line_No+Sline_No Already Exists For Addition — you added a record on a line number already in use.749 Line_No+Sline_No+EqmtSrNo Not Exists For Update/Delete in TrnsprtEqmt — the container twin of 306, on a shipping line's SAA: a container updated or removed under a sequence number customs does not hold it under on that line. Published nowhere; seen in September 2026 on an SAA that removed a bill under a line number customs held for a different bill.394 Line_No+Sline_No+EqSrno Already Exists in Equipment — the other direction, on a shipping line's SAA: a box added to the vessel's list under a number the manifest already uses. The list is numbered 1 to N; an added box takes N + 1. Published nowhere; seen in September 2026.748 Line_No+Sline_No+Srno Not Exists For Update/Delete in TrnsprtItems — the same for a cargo item. Also published nowhere; seen in September 2026 on an SAA that updated item 1 of a line quoting an earlier declaration — a line customs' Trade Scenarios table gives no item details at all.750 Line_No+Sline_No+SrNo Not Exists For Update/Delete in TrnsprtItnery — the same for a port of call in the itinerary. Published nowhere; seen in October 2026 on a CSN amendment that changed a house bill's port of discharge: customs held no port of call 2 on that house bill, and read the amendment as updating or deleting one. Most likely the change added a second leg (the Indian port → the new destination) and marked it U. A leg the amendment adds is marked S — the guide's value for an addition — and comes after the legs already held; no accepted CSN amendment on file has added a leg yet.

An amendment opened here checks every record it marks U or D against what customs holds: every version of the CSN accepted here, oldest first, less what a later one deleted. A record none of them holds is red in the checklist, with Mark it added (S) beside an update, and Sign & upload stops on it. If an amendment made outside SCMTR added it, press Customs holds it: the entry turns amber, and the send goes on your word, kept with the filing. An S on a number customs already holds is amber, with Mark it updated (U). The numbers an amendment opens with are kept as they are — a CSN whose house bills are numbered 1 and 3, or whose one container is numbered 2, keeps those numbers — and a row you add takes the next number after the highest.

The numbers are customs', not your file's. If customs has accepted an amendment since your copy of the filing was made, your copy may be numbered differently — and an amendment built from it then addresses the wrong records, whatever bill or container number is written beside them. Take the numbers from customs' record: ICEGATE's public enquiry shows the line a bill is held on and each container's sequence number, and a shipping line's Build amendment here checks them before signing (Why was my amendment refused with 749 or 306?).

The consequence: never renumber rows inside an amendment. In a fresh filing, closing the gap after deleting row 2 is tidy. In an amendment it silently re-points what used to be row 3 at customs' record 2. A new row added to an amendment takes a number past the highest already in use, so it cannot collide.

What the amendment must regenerate, and what it must keep

"Keep" means send them as the accepted filing had them — not leave them alone when they are the thing you are correcting. An amendment opened for any other reason re-sends the vessel and voyage blocks exactly as they were and marks neither, which is what the one accepted update on record does. An amendment for a substituted vessel or a replaced call is the exception the message guide allows for: the new conveyance reference goes in voyageDtls.cnvnceRefNmbr with voyageDtls.amdType: "U", and where the hull changed too, the new IMO in vesselDtls.trnsprtMeansId with vesselDtls.amdType: "U". See The ship changed after customs accepted my CSN. A deletion is different again: it carries vesselDtls and no voyageDtls at all, so there is nothing about the call in it to keep or change.

The control number is a transmission id. Re-sending a number ICEGATE has already accepted, or one still waiting for its answer, makes it a duplicate transmission — which is why an amendment of an accepted filing always goes under a new control number. A number whose send was refused is not used up: a file rejected with 700 "Error-Refile" can go back under its original number, corrected or not (every 700 on record, seven, was accepted the same day when sent again). Only when you cannot tell what became of the earlier send — an e-mail refusal that came before any acknowledgement, or no answer at all — is a new number the safe choice. See One filing, many transmissions.

decRef.jobNo and decRef.jobDt sit between the two columns. The real deletions we hold do not agree — one kept the original's job date and issued a new job number, another regenerated both — and no acknowledgement or MIG text settles which customs requires. The identity customs matches an amendment on is the CSN number and date, not the job fields, so either has been sent; the platform keeps the job date and issues a new job number, the shape of the deletion above.

What happens after you send it

The original filing stays accepted and locked the whole time the amendment is in flight — the CSN still stands at customs until the amendment is decided. Then:

Amendment accepted — the CSN, its date and the MCIN/PCIN update. The filing stays accepted.Amendment rejected — only the attempt failed. The original accepted filing is untouched at customs; retry by starting a fresh amendment.Deletion accepted — the filing is cancelled. Whether the bills are then free for a corrected fresh filing is where customs' word and the one measurement disagree: ICES Advisory 38/2026 says they are, before the line's manifest; the one re-file on record here, before the advisory, was refused 122/123. See Deleting does not free the bill of lading.Deletion rejected — the original filing still stands.

My deletion was accepted but the CSN still shows on ICEGATE — why?

That is what customs' public record does after a deletion. A deleted CSN stays listed on ICEGATE's public enquiry, and the listing does not say it was deleted. So seeing it there does not mean the deletion failed, and it cannot show that the deletion went through either. The evidence is the acknowledgement of your deletion.

What we have measured, on one deletion of our own (read on customs' public record on 13 September and again on 1 October 2026):

Five weeks after the deletion, the CSN was still listed in full: master bill, house bill, PCIN, packages and weight. Nothing on the record marked it deleted.The version listed was the deletion itself. It was dated the day of the deletion, and its CSN number was a new number issued that day, not the one that was deleted. A deletion takes a number from the same counter as any filing, which is why the acknowledgement of a deletion carries a CSN number other than the one you deleted.

Customs does keep a deleted state: its error table has 251 and 253, "Cin_Type+Cin_No … is Closed/Deleted". The public enquiry does not show that state. Whether ICEGATE's signed-in enquiries do, we have not seen.

To confirm the deletion instead:

Check the file you sent was a deletion. An SCA with amdType D in decRef, naming the CSN number and date you meant to delete. An SCA with U is an update and deletes nothing.Check its acknowledgement says Accepted with a CSN number returned, not only individual blocks saying 00 Successful. Drop the SCA and its _ACK on SCMTR JSON upload (or https://scmtr.io/check) to read both together.If you mean to file the bills again, read Deleting does not free the bill of lading first, and file before the line's manifest.

If the acknowledgement is Accepted and the CSN is still listed, that matches everything we have seen. Your CFS and the shipping line should be told the CSN is withdrawn, because they can still find it on the portal.

How long can I amend or delete my CSN?

Two events matter, nothing announces either, and since ICES Advisory 37/2026 (18 September 2026) only one of them may close the window.

Another party's CSN may close it. Once another filer's CSN against the same master bill of lading is accepted — the shipping line's own CSN, or another forwarder's — your CSN is linked to it, and customs' error list has a refusal for amending such a CSN: 320, "CSN is Linked to Other CSN — Amendment is Not Allowed". No reply carrying 320 has been seen, here or in a filer's hands, so it is a risk rather than a certainty — but a real one, with no notice and no grace period: somebody else's action, at any time. So amend before another party's CSN lands if you can. If customs does answer 320, the correction is settled with the shipping line and your jurisdictional customs officer. (Since 29 September 2026 the app warns of 320 rather than stopping the amendment, because no refusal carrying it has been seen.)

The shipping line's manifest (SAM) does not close it — it changes what each route looks like:

An amendment is still yours to file. Before Sea Entry Inwards, file the amendment (SCA) as usual, then give the shipping line the amended CSN and MCIN/PCIN so it can file a matching manifest amendment (SAA) — its SAM was filed against your original data and does not update itself. After Sea Entry Inwards the same two steps apply, but both need the jurisdictional customs officer's approval (see the section below).

Ask the line for one thing more than the reference. The process CBIC's SCMTR team set out for the trade has the line delete what it already filed before the corrected picture goes in — the step most often left out of a request. That process was said of the console split, and ICES Advisory 38/2026 publishes a deletion for that case: a straight master re-added as consolidated (Q1), or any change of the line's consolidation indicator, consolidator PAN or previous reference (Q2) — the drop and the re-add both inside the SAA. For an amendment of figures or a party the line's matching SAA updates the line instead (U, "modification of allowable fields", Q3). An SAA filed on top of an untouched SAM is the likeliest explanation we have for an amendment that "goes in" and changes nothing. What is deleted, where a deletion is due, is your bill's own line out of the manifest — what an SAA carrying amdType D does — which is also the only thing the message set allows: SACHM23 has no message that withdraws a whole manifest (its six events are SAM, SAA, SDM, SEI, SDA and SDN). Phrase the request as delete our line rather than withdraw the manifest — see My console's house bills are not on the line's manifest and the advisory's six answers.

A deletion is no longer yours. After the SAM, the advisory has a CSN deletion carried out by the jurisdictional customs officer, not filed by the CSN's submitter.

A fresh CSN is not the route. The advisory's starting point is that the CSN is filed before the SAM; where house bills were missing when the line filed, it has the line add them by amending its own manifest (SAA, "splitting of BLs"). Ask the line, not the form. (The process CBIC's SCMTR team set out — reported, in no notice — does have a CSN filed after the SAM once the line has deleted what it filed; see My console's house bills are not on the line's manifest. Unobserved either way.)

The VCN and rotation number cannot be amended at all, manifest or no manifest — see the ship changed after customs accepted my CSN.

What this corrects. Until 19 September 2026 this page said the line's manifest closed your window exactly as another party's CSN does. That was an inference: 320 names a linked CSN, and on 6 September it was extended to the manifest because the two sit on the same master bill. No ICEGATE refusal ever showed a manifest closing a CSN to amendment. The advisory is customs' own published process and says the amendment continues after the SAM, so it replaces the inference. Nothing on record here has yet been seen amended after a manifest either — what is above is what the advisory says, not something we have watched happen.

You can see where you stand. The app looks the master B/L and the port up on customs' accepted-filings record and on the Sea Arrival Manifest enquiry for every filing, and the filing's page says which case you are in:

Only your own filing found — amend or delete as normal.The line's manifest covers the bill — the page says the filing can still be amended, explains the SAA follow-up and the officer's approval after Sea Entry Inwards, and withdraws File a deletion. Sign & upload refuses a deletion or a fresh CSN on such a bill, but lets an amendment through.Another filer's CSN on the record — Amend this filing and File a deletion stay offered, with a warning that customs' list has 320 for this and that it has not been seen yet; if customs does answer 320, the page sends you to the shipping line and your officer.

So the practical rule is unchanged: if something is wrong with a filing, amend it now. Another party's CSN can land on the bill any day, and once Sea Entry Inwards is granted every amendment waits on an officer.

Note what this does not mean: the shipping line filing against your master B/L is normal and expected. Both of you file — you for the house cargo, they for the master — and customs cross-checks the pair. Their filing is not a conflict with yours.

Once Sea Entry Inwards is granted, your amendment needs a customs officer too

This is a later stage, and it does not replace the risk above — another party's CSN may still close the window (320) whenever it lands. It is what happens if you are still inside your window when Sea Entry Inwards arrives.

Sea Entry Inwards (SEI) is the vessel operator's application for entry inward, filed on the carrier's manifest message just before arrival — see Which SCMTR message do I file?. ICES Advisory 37/2026 states plainly that once SEI is granted, a CSN amendment stops being automatic:

Before SEI, a CSN amendment applies directly — the ordinary case this page otherwise describes. If a SAM already exists referencing your CSN, the amendment still applies directly, but tell the shipping line the amended MCIN/PCIN/CSN afterwards so they can bring their own SAM into line with a matching SAA amendment — the SAM was filed against your original data and does not update itself.After SEI, your CSN amendment (SCA) has to be followed by a SAM amendment (SAA) from the shipping line, and both need the jurisdictional customs officer's approval before either is reflected on ICEGATE — the advisory's own words are that the amendment "requires Customs officer approval … before the amendment is reflected".

The one public sign that SEI was granted is the inward date on the shipping line's SAM record for your bill. When customs' record shows it, your filing's page says so — "Customs' record shows the vessel granted entry inward on …" — and its amendment note turns to the officer. Before the line's SAM is on record there is nothing to show, so the practical reading is the same one the deadline above already gives: amend the day you notice something wrong, because neither stage announces itself on your CSN. SCMTR rollout, amendment windows and penalties has the summary table and the manifest-side error codes (373, 374) this pairs with.

Until 19 September 2026 this section went on to set the advisory's "before SEI, SAM already filed" scenario against this page's older rule that the manifest refused any amendment outright (320), and treated the older rule as operative. That rule was an inference no refusal ever confirmed; the advisory is customs' published process, and this page now follows it — see how long you can amend or delete.

The filing I want to amend was made on the ICEGATE portal

You can still amend it here, but the filing has to exist here first — and it has to exist as a filing this platform can see was accepted, not as an assertion that it was.

Drop the amendment on SCMTR JSON upload and, if the CSN it references belongs to no filing in your organisation, the screen says so and offers Record the original filing. That opens a short wizard — Record a filing made elsewhere, also reachable from the link under the cards on the CSN filing page — which asks for three things in this order:

The amendment you are trying to file. Everything after it is checked against it.The original filing — the fresh _DEC.json (msgTyp F) that was accepted. It has to name the same master bill of lading; a file with no bill in common is refused, because the two are then about different consignments.The acknowledgement — the _ACK.json that accepted it. It has to be an acceptance, and it has to grant the exact CSN number and date your amendment references. A refusal grants no CSN, and an acceptance for a different CSN means the amendment was built against a different filing.

The filing is then recorded as accepted under that CSN — nothing is sent to customs — and your amendment opens against it, keeping one job number and one history. The review step lists what your amendment file changes against the original, field by field, and you choose whether the draft opens with those changes already made or as the accepted filing for you to edit.

If you do not have the acknowledgement file. ICEGATE emails it to the address registered against the licence, which is often not the person filing. An organisation admin can type the CSN number and date off the portal instead; it is recorded as somebody's word rather than as a customs document, the audit trail says which, and an ordinary member cannot do it. Supplying the file is better in every respect — and if what you hold is the CSN you filed rather than the amendment, any member can skip the acknowledgement altogether: drop the CSN on SCMTR JSON upload, and SCMTR reads ICEGATE's own record of it instead (see the top of this page).

Or do it on ICEGATE. A filing accepted on the portal can be amended on the portal, with none of this. Recording it here afterwards is worth doing to keep the history in one place, and it is not a precondition for anything.

Why we do not simply take the CSN from your amendment. Nothing here can confirm that a CSN you name was granted to your organisation, and an amendment rewrites what customs holds — a withdrawal removes it entirely — against whichever filing customs matches the reference to. The two files are what turn the reference into something checkable. This is also why an amendment can never be imported as a fresh filing: resetting it to msgTyp F and clearing its CSN turns "change CSN 1448812" into "file this cargo again", which reaches customs as a duplicate of a consignment they already hold.

When you cannot amend at all

Some states are closed to amendment, and the error tells you which:

319 — an earlier amendment on this CSN is still pending approval. Wait for it. Seen on a reply a filer shared on 3 October 2026: a CSN deletion sent while an earlier request on the same CSN waited for the customs officer was refused 319, and nothing was deleted. Sending it again draws the same answer until the officer decides the first one, so follow that one up with the jurisdictional officer, quoting its reply's unique id.320 — the CSN is linked to another CSN. Read this as another party's CSN — the shipping line's or another forwarder's — accepted against the same master B/L. It is in customs' list but has not been seen on a reply; if it comes, settle the change with the shipping line and your jurisdictional customs officer. Since ICES Advisory 37/2026 the line's manifest on its own is not a reason for it — see how long you can amend or delete.321 — the CSN is closed. A deletion you sent yourself puts it here.230 — the filing belongs to a different submitter.

And two states are closed to self-service, without necessarily being closed to amendment altogether:

A deletion, once a SAM already exists referencing your CSN. ICES Advisory 37/2026 says a deletion at that point has to be carried out by the jurisdictional customs officer, not by the CSN's own submitter — this is independent of Sea Entry Inwards and stricter than a correction: a CSN with no SAM against it can still be deleted directly, either by its own submitter or, at any stage, by the officer. Since 19 September 2026 the app holds to this: once the line's manifest is found against your bill, the filing's page withdraws File a deletion, SCMTR JSON upload does not open one, and Sign & upload refuses to send one.Any amendment, once Sea Entry Inwards has been granted — see the section above. ICEGATE's own answer is what tells you which of these you have met; nothing on this platform currently distinguishes "refused" from "accepted, pending officer approval" for you.

Amend, or delete and re-file?

Amend, where the filing is otherwise right. An amendment keeps the CSN everyone downstream already quotes; a deletion followed by a fresh filing gets you a new CSN and a different paper trail, and the CFS and transporter quoting the old one have to be told. It is also the only route once the shipping line's manifest is filed, when a deletion is the customs officer's (ICES Advisory 37/2026).

Delete and re-file is a route too, before the manifest — on customs' word, not yet on any acknowledgement. ICES Advisory 38/2026 (21 September 2026), Q5: an option for cancellation of a CSN by the ANC "has been enabled on the customs system, provided that the corresponding SAM has not yet been filed against that CSN. Once deleted, the ANC can promptly re-file corrected particulars without generating mismatch conflicts." That is customs' published text, and this page states it as customs' rule. What it does not yet have beside it is a single re-file after a deletion seen accepted from customs' side; the one on record, from before the advisory, is the next section. Until 22 September 2026 this page said "amend, effectively always" and called delete-and-re-file the route that fails — on that one measurement. The advisory says the system has changed; whether it has is what the next such case will show.

Do not confuse this with the manifest's "drop and re-add". Two different messages, two different objects. What this page is about is a CSN: your SCA with amdType D withdraws the whole notification, and a fresh SCE files it again (whether the "option for cancellation/deletion" the advisory says has been enabled is that message or a new one, it does not say). What the shipping line does when it changes a bill from straight to consolidated, its consolidator PAN or the previous reference it quotes is on its manifest: an SAA that drops one line (amdType D) and re-adds it (S), because the same advisory's Q2 says an in-place update of those fields is refused. That is the line's move, on its own filing, and it never touches your CSN — see Amending a shipping line filing (SAA or SDA).

Deleting does not free the bill of lading

Read this as the record of what was measured, not as the rule. Since ICES Advisory 38/2026 (21 September 2026) customs says otherwise, and until a re-file after a deletion is seen accepted the two stand side by side. The heading is kept because it is what filers search for.

What customs says now. An ANC may cancel a CSN before the shipping line's manifest is filed against it, and then "promptly re-file corrected particulars without generating mismatch conflicts" (ICES Advisory 38/2026, Q5). That is customs' statement that a CSN deleted before the SAM can be re-filed corrected without a mismatch. Whether the option it says has been "enabled" is the SCA with amdType D already in use or something new, the advisory does not say; and no re-file after a deletion has been seen accepted from customs' side.

What was measured, before the advisory (6 September 2026). A deletion amendment acknowledged as accepted with a CSN number returned, then a fresh SCE on the same master and house bills refused with both:

122 — MC-MBL Details Already Exists123 — HC-HBL Details Already Exists

with the shipping line reported not to have filed. Customs' own validation table has a state for a withdrawn consignment — 251 Cin_Type+Cin_No in MC is Closed/Deleted and 253 for the house level — so the deleted record went on existing at customs, marked deleted, and the reading at the time was that the duplicate check counted it. That reading was inference from the symptom, never something customs documented. The advisory's Q5 says trade asked for relief where "incorrect data was transmitted in a CSN before the vessel operator integrated it into the SAM" — the same situation, not this symptom by name; that it was this symptom customs dealt with is our inference. Three weeks on, the deleted CSN was still listed on the public enquiry, dated the day of the deletion — and still was five weeks on (read again on 1 October 2026), see My deletion was accepted but the CSN still shows on ICEGATE.

What has not been seen. No re-file after a deletion has come back from customs, accepted or refused, since the advisory. So the app keeps a warning on File a deletion — not "this route fails" but "the one case on record failed, before customs said it was fixed" — and the sequence under if you are already in that state is still the way to go about it.

So the sequence that looked reasonable and once failed — delete the wrong filing, file a corrected one — is now the sequence customs describes. If you take it, take it before the line files, look the bill up first, and tell us what came back.

An accepted amendment can empty the record

The opposite surprise, measured once and explained by the filer who lived it (September 2026). A CSN was accepted on the 5th. On the 9th the filer learned the CFS's PAN and bond had changed and sent an update amendment, accepted at 20:13 — CSN number echoed back, Amend_det: U on every block, PCIN returned as null. Five minutes later they looked the bill up on ICEGATE's public enquiry and nothing was there. So they sent the original file again as a fresh CSN — new job number, corrected PAN and bond — and at 20:27 it was accepted as a second CSN with a new PCIN (26PCSE0009053… became 26PCSE0009093…). Customs' record now lists only the second.

Three things follow. First, 122/123 fires when customs holds your bill; after that amendment it held nothing, so the fresh filing passed where a refile after a deletion or a vessel substitution is refused. Second, a fresh filing that passes is a new CSN and a new PCIN — the CFS and transporter quoting the old PCIN have to be told. Third, an accepted amendment followed by a blank enquiry is not on record: check the bill with SCMTR JSON upload before relying on it, and before re-entering it. Why the update emptied the record is not known; it happened once, on the day many filings were being corrected for the same PAN change.

Two more measurements, both from customs' own public record (September 2026, before ICES Advisory 38/2026). A CSN whose deletion was acknowledged is still listed in the public enquiry three weeks later (and five weeks later, 1 October), dated the day of the deletion — consistent with the deleted record being what refuses the fresh filing, though whether the deletion itself was accepted is not known. And the rule is not absolute: one filer's fresh CSN on bills customs already held under their own accepted, freshly amended filing was taken as a second CSN, and the record now shows only the second. Nothing documents the difference.

If you are already in that state

In order, because the first two cost minutes and the third costs days:

Check whether the shipping line has filed, on customs' accepted-filings record. 122/123 is also the signature of a master bill closed to you because the counterparty filed — see how long you can amend or delete. Never take "they haven't filed yet" on trust; it is one lookup.Stop re-sending the fresh filing unchanged. On the case measured it returned the same pair every time. If both the deletion and the re-file date from after ICES Advisory 38/2026 (21 September 2026), the refusal is itself news — the first sign the advisory's change has not reached your case — so keep the acknowledgement and send it to us and to the helpdesk.Try an update against the deleted CSN — SCA with amdType: "U", carrying the corrected filing in full and referencing the CSN number and date from the deletion's acknowledgement. Either it is accepted and you are done under the original CSN, or it comes back 321 CSN is Closed — Amendment is Not Allowed, which tells you the deletion is final and makes the case concrete enough to raise. Whether customs permits this is unconfirmed — no filing we hold has tried it — which is precisely why it is worth one submission before escalating.Ask the carrier to reissue the bills with new numbers, and file fresh on those. 122 and 123 are keyed on the master and house bill numbers, so a bill that never existed before cannot collide with a closed record — which, on the one case measured, is the thing a deletion did not buy. It costs a conversation with the line rather than a submission, and it is the route that has actually worked.Raise it with the helpdesk with the deletion's tracking id, its acknowledgement, the CSN number returned, the refiling's tracking id and complete error response, and both bill numbers with their dates and the port.

Reported by a working filer, September 2026, and the only route in this list known to have carried a filing through. Their gateway port moved after they had filed; they had the master and house bill numbers changed and filed fresh on the new ones, and it went through because the shipping line had not yet filed the SAM. That condition is doing the work, not the renumbering on its own: once the line's manifest is accepted against the master bill, the old bills are manifested and a fresh CSN is no longer the route — ICES Advisory 37/2026 (18 September 2026) has the CSN filed before the manifest, and the line add missing house bills by amending its own (SAA). It is also why this sits below step 1 — checking whether the line has filed is what tells you this route is still open. (Until 19 September 2026 this said the manifest locked the master with 320. That was an inference; 320 is another party's CSN, and the advisory leaves an amendment open after the manifest.)

Corroborated, not proven: one filer's account of their own case, relayed to us. No acknowledgement for it is in our hands, and two things about it are simply unknown — whether the earlier filing was deleted first or left standing, and what customs makes of two CSNs covering one physical consignment under different bill numbers. There are very likely other routes and we do not know them yet. Treat this as one thing that worked once, not as the procedure.

Keep the shipping line from filing while you sort it out

The cut-off is the obvious reason to ask them to hold. The stronger one is that the moment their manifest is accepted against that master bill, the routes narrow: a fresh filing on renumbered bills is no longer the route, the delete-and-re-file route ICES Advisory 38/2026 opens is shut (it is "prior to SAM" in customs' words), a deletion becomes the jurisdictional customs officer's, and after Sea Entry Inwards even the update route above waits on the officer's approval (ICES Advisory 37/2026). Holding the line is what keeps the problem in your own hands, so say that to them rather than only asking for time. (Until 19 September 2026 this said their manifest locked everything with 320. It does not, by the advisory; customs' list has 320 for another party's CSN against the bill, not yet seen on a reply.)