Amending a shipping line filing (SAA or SDA)

A shipping line or its agent amends an accepted arrival manifest (SAM) with an SAA, and an accepted departure manifest (SDM) with an SDA. The amendment is its own file with its own job number. This page is about what that file should carry, what amdType means on it, and how SCMTR builds one from the manifest you already hold. When an amendment needs approval, what it costs and how late it may be filed are on SCMTR rollout, amendment windows and penalties.

What is a minimal amendment, and why send only the lines that changed?

An amendment does not have to repeat the manifest. The real SAA files on file carry a handful of lines under the voyage's totals — one, two, a dozen — not the several hundred lines of the manifest they amend. A file that carries only what you touched cannot re-open a line you did not touch, and it is far easier to read when customs answers it. That is what Build amendment produces.

How do I build one?

Open the accepted manifest on the Shipping line filing page — the SAM or SDM as customs holds it now. (An amendment cannot be built on top of another amendment's file; open the manifest.) If customs has accepted an amendment since that file was made, the file may no longer be numbered the way customs' manifest is — see Why was my amendment refused with 749 or 306?Make the changes in the editor: correct a line, add a line, or remove a line (a removed line can be put back until you build).Press Build amendment. The dialog shows what the file will carry: which lines are added, changed or removed, the voyage's new totals, the job number and the file name. For every line it changes or removes, it also asks customs' public record where customs holds that bill — the line number, and the containers' sequence numbers — and will not let you sign one addressed to a number customs does not hold it under.Download it to sign and file elsewhere, or Sign & upload it from the same screen — it goes through the same checks and the same duplicate gate as any manifest.

The manifest never has to leave your browser to be amended, which is what lets it be the size it is.

What is amdType, and where does it go?

amdType is the flag that tells customs what an amendment does to a record:

Those are customs' own glosses, from the table in ICES Advisory 38/2026 (Q3): S "addition of new data elements", D "dropping or deleting existing records or invalid lines", U "modification of allowable fields in existing records". The same table settles the header flag beside it: msgTyp in decRef is F for a fresh manifest and A — "mandatory for all SAA transmissions" — for an amendment. D is in the MIG's code list for msgTyp but never on the wire — the advisory's table lists only F and A — and a deletion is A with D on the record.

It goes on the records customs addresses by a number of their own — the declaration reference, each line's bill reference, each container, each itinerary leg, each house bill and each cargo item — and on the vessel's container list. The real SAAs and every accepted CSN amendment seen here flag exactly those, and leave the rest of the line's blocks unflagged. The authorised person, vessel and voyage blocks ride unflagged unless you changed them.

What does an added, changed or removed line carry?

Added (S) — the whole line.

Changed (U) — the whole line as it now reads: U on records that were there before, S on a record that is new (a container added to the bill), and the old record with D where one is gone. That split inside a changed line is a reading of the flags' own definitions; no real manifest amendment seen here settles it either way. Except item details on a line that quotes an earlier declaration (previous declaration Y or C): customs' Trade Scenarios table gives such a line none — the declaration it quotes holds the goods — so the builder leaves them out and says so. An SAA that updated item 1 on such a line was refused as 748 in September 2026.

Removed (D) — the whole line, as the accepted manifest holds it: its bill reference flagged D; its prior reference exactly as held (the MCIN or PCIN, or the CSN number and date); its customs location, transhipper, transport document and measures; and every container and route leg flagged D. Item details are left off a line that quotes an earlier declaration — customs holds none there, and an item updated on such a line was refused 748, whose words cover a deletion too. Two refusals of one Kolkata SAA taught this. Sent as the bill reference alone (1 October 2026), the removal of a straight line quoting a PCIN drew 724 "CIN No Should be Provided in Prev-Decln of SAA/IM-SCA". Sent again with its prior reference (2 October), it passed that — and customs answered for the line's records, which the file had not named: 00 on each of its six containers, which the file had not named, then 242 "MBL/HBL Details Not Exists for Given Itinerary Line+Sline No" on its two route legs, and 300 "SQL/Run-Time Error Occurred While Validation" on the declaration. Nothing in the file was taken either time. The file had given no bill details for those legs; every other removal on file — five SAAs from one agent at Kolkata, one from Nhava Sheva — sends the line whole with its records marked D. So the builder now writes the line that way. The checks stop a removal of a line quoting a CIN without its prior reference (for a line quoting its CSN by number and date, which customs has not been seen to refuse this way, they point it out), and point out a removal that carries nothing under the line. That the bare removal caused the 242 is our reading of customs' words — and the same removal, re-sent whole, was accepted on 3 October 2026, after entry inward, with the bill re-added as a consolidation in the same SAA: the first removal seen accepted in any shape. The other removals on file were refused for something else (a container number, September 2026) or with no code at all, or have no reply yet.

The vessel's container list moves too. Removing a line takes its containers off the line, not off the vessel: a box stays on the vessel's list until the amendment removes it there as well, with D under the sequence number the vessel's list holds it by. So every container the removed line held that no other line carries goes on the vessel's list in the same file with D, and the container total counts it out. Every real SAA on file that removes a box does so on both lists. A shipping line's SAAs of 1 October 2026 removed a line with eleven containers but marked only ten D on the vessel's list — the eleventh row was sent with no amendment type, or left out — and the totals then disagreed whichever way they were set: 121 counts the box out, 122 keeps it on the vessel with no line. SCMTR's count of customs' manifest knows which lines carry each box, so it names a box that would be left behind (an error on a count of the version customs holds now), with Mark it removed (D) where its row is in the file, and the container total it asks for counts that box out. A box that really stays aboard as an empty is the other answer: Keep it aboard as an empty gives its row U and load status EMP, the error becomes a warning, and the box stays in the total.

How do the voyage totals move?

By exactly the difference. The totals on an amendment restate the whole voyage, not the file: one real SAA declares 795 lines and 2,389 containers on a manifest whose accepted totals were 793 and 2,387, and carries two lines. The builder moves the accepted totals by what you added and removed, and shows both.

A total is a count, not the highest number. Customs does not renumber a manifest when a line is deleted: a refused SAA of September 2026 was answered with the manifest's lines listed as 1 to 627 without 456, so that manifest held 626 lines, not 627. Get this wrong — or build the amendment from a copy older than the last accepted amendment — and customs refuses it with 90 "Total Lines in Vessel Not Match with Cargo Lines" and 89 for the containers. The refusal itself tells you the line total: a refused reply to an amendment lists the manifest customs holds together with every line the amendment sent, one row each — the added ones included, and a line the amendment deletes still among them, since customs applied nothing — so its rows, less the lines the amendment deletes, are the total to declare. Not every refusal does: one that lists only the lines its file sent (a Kolkata refusal of 1 October 2026 listed just its two) is the send, not the manifest, and says nothing about the total. Opened here with the file it answers, the reply says so and sets the line total in one press. The container total is not in a refused reply; take it from the SAM customs accepted and every amendment accepted since — or let SCMTR count it from an accepted reply it keeps for the call (see Can SCMTR stop a wrong total or number before I send? below).

What job number and file name does it get?

A new job number — the next one after those your organisation has used, which you can change — and today's job date. ICEGATE refuses a job number it has already processed. The file name follows ICEGATE's rule for an amendment: A_SACHM23_SAA_<sender>_<job>_<date>_DEC.json.

How do I add a line from a CSN?

A forwarder's CSN arrives late and the bill has to go onto the manifest. Add a line from a CSN writes the new line from the CSN's own data, so the fields customs is known to compare between the two — bill, bill date, packages, containers — start out the same. Pick one of your organisation's accepted CSNs, or drop the forwarder's CSN file together with its acknowledgement.

What the line takes from the CSN is everything the CSN's master bill holds: the bill and its date, consignor, consignee and notify party, goods description, ports of acceptance, receipt and destination, the transhipper, packages and weight, the item details, every container with its seal, size and status, and the route. The line quotes the CSN the way lines customs accepts do: by the MCIN for a consolidation (C/Y) or the PCIN for a straight bill with no house bills (S/Y), read from the CSN's acknowledgement. On an amendment the added line and its containers are marked S.

When the forwarder's CSN only refers to the master bill (its master is R, with the house bills under it), customs gives that CSN a PCIN for each house bill and no MCIN. The MCIN belongs to a second CSN on the same bill — the one that declares the master itself — and that is the one an accepted line quotes. The dialog asks customs' public record for it by itself and quotes it (C/Y), naming the CSN it came from; if customs holds more than one, you choose. When customs' record holds none, the line quotes the forwarder's CSN by its number and date (C/C), and the dialog says so.

That second shape is accepted too, and common: read against customs' record in October 2026, 70 manifest lines quote a referenced-only CSN by number and date — 63 in Kolkata SAMs and 7 in SAAs at Chennai and Ennore, one sent after entry inward — and at Kolkata customs issues such a line an MCIN of its own. On every one of them the consolidator PAN is the manifest's own filer (the PAN the SAM is filed under), not the forwarder who filed the CSN; a line that quotes an MCIN or PCIN names the CSN's filer instead. The dialog writes it that way, taking the PAN from the manifest you are amending, and the checks point out a line quoting a CSN by number with anyone else as consolidator. Most of those lines also carry the item details.

A second CSN under another date is not that partner. A bill number can carry two CSNs under two bill dates — the carrier's own straight CSN of one date and the forwarder's referenced-only CSN of another — and customs treats bill number and date together as the bill. A CIN of the other date is another bill's, so the dialog asks only the CSN's own date; with no master CIN there, the line quotes the forwarder's CSN by number and date. When that re-added line replaces one that quoted the carrier's CSN, the carrier's CSN stays on customs' record with the same containers and nothing quoting it. The builder says so. Whether it should go is for its filer to ask, and after entry inward a deletion is the jurisdictional officer's to approve. No refusal on record is for leaving it standing.

The added containers follow the manifest they join: the bond flag starts as the one every box on the manifest already carries, and the final destination is written only if the manifest's other boxes have one.

The dialog shows what was taken, and asks in one place for whatever the CSN does not hold — typically the containers' bond flag and any party detail the forwarder left out, with a button to copy the consignee as the notify party. What you type goes onto the line as you add it. It also warns if the bill is already on another line. Customs still decides whether the line is accepted.

The forwarder can also send you a CSN reference card: the reference and the cross-checked fields, without the filing. Its reference block (the line starting PREVREF1|) pastes straight into a line: open the line, Paste a CSN reference from a handover card, and all eight prior-reference fields are filled at once. The block ends in a check character, so a mistyped digit or two swapped characters are refused rather than filed — which is where most 164 refusals come from. Whether the line declares a prior declaration, and how it is consolidated, stays yours to set. Drop your manifest file back on the forwarder's card and each field — including the SOC flag and the seal, which no customs enquiry publishes — is compared with theirs. And answer them on the card itself — quoted on our line, amendment filed, our figures are right — with a short note if you want; no account is needed, and only the forwarder who sent the card sees it.

Can SCMTR fill the CSN number and date on my lines?

Yes, if your organisation saves its own ICEGATE portal login (Settings → ICEGATE portal login; an Org Admin sets it). Customs shows the list of CSNs filed on a vessel call only to a signed-in ICEGATE user. Fill CSN references reads that list under your login, matches it to the bills on your manifest, and offers the CSN number and date for each line that is missing them — for you to review before anything is written.

It only reads. Nothing is filed, changed or signed with the login.It is used only for your organisation's own enquiries, started by one of its members.The call's list names other filers too. Only CSNs on bills your own manifest carries are shown.The password is checked with ICEGATE before it is saved, kept encrypted and never shown again. An Org Admin can remove it at any time.

A forwarder has asked me to amend for their console — what is the sequence?

This is the commonest amendment request a line gets, and it has a step that requests usually leave out. The process CBIC's SCMTR team set out for the trade puts it like this: once the arrival manifest is filed, the consolidator amends or files their CSN, and the line deletes what it already filed before the corrected picture goes in — then files the SAA against that CSN. Since 21 September 2026 that step is published for this case, with the drop inside the SAA itself: ICES Advisory 38/2026 (Q1, Scenario A) has the line "first drop (delete) the existing Straight BL line item and subsequently re-add the Master BL configured as consolidated, linking the reference details of the CSN and House BL provided by the forwarder".

Two things are worth pinning down before you act on such a request:

"Delete the SAM" means one line, not the manifest — our reading, and since ICES Advisory 38/2026 a well-founded one. The phrase is the reported process's; the advisory never uses it. What the advisory describes, for a straight master that must become consolidated, is dropping "the existing Straight BL line item" and re-adding it, inside the SAA — an SAA carrying amdType D on that line and S on its replacement. The message set says the same thing from the other side — SACHM23 has no deletion message at all: its six events are SAM, SAA, SDM, SEI, SDA and SDN, so there is nothing that withdraws a manifest, and an SAA amends a SAM and so needs one to exist. That is what the reading rests on; the advisory's procedure is what it agrees with. If a requester insists they mean withdrawing the whole manifest, ask them which message they expect you to file — there isn't one — and send them Q1 of the advisory.Entry inward is the line Advisory 37/2026 and JNCH Public Notice 18/2026 draw for officer approval. Before it, none is needed; once the vessel is inward, the SAA is filed and then the jurisdictional officer approves it, and the amended data appears only after that. Circular 43/2020's 6/24/48-hour windows before arrival are still on the books and the advisory does not mention them. See SCMTR rollout, amendment windows and penalties, which carries all three windows and the fee.For empty containers and foreign transhipment cargo, Nhava Sheva has fixed the officer's papers. JNCH Public Notice 115/2026 (22 September 2026): a letter explaining the amendment, the terminal's or custodian's discharge confirmation and the B/L particulars for empties; the letter and the B/L for foreign transhipment cargo — and no more as routine. Mundra adopted JNCH's procedures on 25 September. See what to give the officer.At Chennai, customs has told lines in writing to do these and report every failure. Chennai's Public Notice 130/2026 (23 September 2026) asks each line filing SAA to name a nodal person to scmtr-prevchn@gov.in and to send a refused SAA's Unique ID — the acknowledgement's uniqueId, shown here as Tracking id — to the help-desk officers allocated to the vessel. The Commissioner's letter of 24 September tells every line to work the consols' pending cases and send the Unique ID of each delete-and-re-file that fails, and that delay "would be viewed adversely". See Chennai customs' SCMTR help desk.

Doing it here, step by step

Open the manifest customs accepted on Shipping line filing — the SAM as it was filed, not an earlier amendment. Everything below is measured against it.Ask customs about the manifest from the Checks tab, once. It answers one thing that changes what happens next: whether the vessel has been granted entry inward.Find the bill — search by its number. If the bill is to quote another CSN (the forwarder's consolidation instead of the carrier's straight filing, say), press Quote another CSN on its row (the two-arrow icon) and go to step 4; nothing changes until you add the bill back, and Cancel leaves the line as it was. If the bill is simply coming off the manifest, press Remove: it appears above the table under "1 line removed from …", with Put back beside it (that list is on the Lines tab). Nothing has gone to customs either way.Choose the CSN the bill quotes. The dialog asks customs' public record — no login — for every CSN filed on the bill, and shows each with its date, the bill date it holds, its filer (masked), its packages and containers, and how it declares the master: straight with a PCIN, a consolidation with an MCIN, or a consolidation whose master is only referenced (house PCINs, no master CIN). It marks the one the line quotes now and picks the other when there is one. If customs' record cannot be asked, type the CSN number, its date and the bill date it holds. The bill comes back under a new line number (a removed line's number is not reused) keeping its parties, goods, ports, transhipper, route, seals and weights; what the chosen CSN decides is changed and listed, with why, before you add it:
a referenced-only CSN is quoted by its number and date (C/C), with your own PAN as consolidator — the shape customs accepted on a re-add (Kolkata, October 2026). (Add a line from a CSN quotes such a bill by the other CSN's MCIN instead, as a line customs accepted on a SAM did; both ways are accepted — this dialog keeps to the shape seen accepted on a re-add);a consolidation's MCIN (C/Y) or a straight bill's PCIN (S/Y) names the CSN's filer as consolidator — type that PAN; the dialog checks it against the last four characters customs shows (a different consolidator is refused 360);the bill date becomes the one the CSN holds (164), the packages and package type the CSN's (232), and each container's load status and size the CSN's (399, 398); a different set of containers (233) is pointed out, never changed for you;the re-added line carries no house bill rows — the CSN holds them. Once added, the old line is listed under "1 line removed from …" as added back as line N — take the new line off first to put the old one back. A bill split across lines (split cargo) keeps its split flag and its own share of packages and containers; the CSN's figures are the whole bill's. The amendment then carries a D on the old number and an S on the new one: one amendment for the drop and the re-add, as ICES Advisory 38/2026's "first drop… and subsequently re-add" reads, and as customs accepted it once (October 2026). If you hold the forwarder's CSN file and its acknowledgement, Add a line from a CSN builds the line from the CSN itself instead.
Press Build amendment. It shows exactly what the file will say — which lines are deleted, added or changed, how the voyage totals move, the job number and the file name — and, above the button, whether an officer has to approve it, what happens after you send, and the ₹1,000 fee.Sign and upload, or download the file to file it elsewhere. Nothing reaches customs until you sign.

The amendment carries only the lines you touched. Every other bill on the manifest stays out of the file and is not re-sent.

What the SAA itself should carry for a consolidation — the house bills belong on it, but without the transport document or item details the CSN already holds — is on My console's house bills are not on the line's manifest. Getting that wrong is 370, with 118 on every house bill. Where the forwarder filed no CSN, the opposite applies: ICES Advisory 38/2026 (Q1, Scenario B) has you put "the full underlying House BL details within the houseCargoDec object" — the house bills in full, because nothing else holds them.

Can I change a line from straight to consolidated, or its consolidator PAN or CSN reference, as an update?

The advisory says drop the line and add it back — the two replies since (Chennai, October 2026) named no code for a reference changed in place, but refused the line 360 both times; see the advisory's FAQs. ICES Advisory 38/2026 (Q2) is explicit: changing a bill "from Straight to Consolidated (or vice-versa)", changing the consolidator PAN, or changing the previous reference — the CSN, PCIN or MCIN a line quotes — as an in-place update "is prohibited by system validation rules", and the record "must be explicitly dropped (deleted) using the amendment deletion procedure and then re-filed in the SAA JSON structure with the correct cargo relationships".

Build amendment does the same: it refuses to build an update (U) that changes a line's consolidation indicator, its consolidator PAN or its prior reference, and tells you to Remove the line and add it back. Because a removed line's number is not reused in the same editing session, the amendment then carries a D on the old line number and an S on a new one, with the line's other fields free to change on the way. Customs has accepted that D and that S in one SAA — once on record, at Kolkata in October 2026, after entry inward — and the advisory's "first drop… and subsequently re-add" reads as one amendment. If a line insists on two, the deletion goes first.

A bill customs already holds is quoted, not declared again. On 21 September 2026 an SAA added a new line declaring a master bill afresh (previous declaration N), as a consolidation with its three house bills in full. Customs refused it as 753 "Amd-MC-MBL Details Already Exists", the amendment's twin of the published 122. Customs' public record showed what it held: the bill was already declared, by a forwarder's accepted CSN on the same rotation, and was on no line of the manifest. So before adding a line, look the bill up — SCMTR now does it when you open the SAA (see the next section). That quoting the CSN is what customs then accepts is our reading; no corrected line has yet been seen accepted. If a CSN holds it, Add a line from a CSN builds a line that quotes it. If the CSN describes the cargo wrongly, whoever filed it changes it first; the manifest cannot overrule it. And if you add a line for a bill that a line you keep already carries, Build amendment says so, although it still builds. Declared split cargo (split indicator Y or F) is left alone, because a split bill does sit on more than one line.

SAA refused 753 "Amd-MC-MBL Details Already Exists" — what to change

753 is in no published list. It has been seen once, on an SAA of 21 September 2026, and this reading rests on that one refusal: the SAA added a master bill as a new consolidated line declaring it afresh — consolidation indicator C, previous declaration N, its own house bills in full — while customs already held a forwarder's CSN on that master bill (the house bills under it, the same consolidator PAN) and no line of the manifest held the bill. The line re-declared a master bill a CSN already declares.

What to change: quote the CSN instead of declaring the bill again, as accepted lines do. Of 999 lines on file that quote a CSN (September 2026, the file store), 192 are C with previous declaration Y and the CSN's MCIN, 791 are S with Y and a PCIN (a straight bill), and 16 quote the CSN's number and date (C with previous declaration C, CIN type CSN) — 70 such lines were on customs' record when read on 2 October. Keep the two apart: a line declared C that names the CSN by its MCIN instead is refused 159, "Incorrect Cin Type in MC" — nine lines of one SAM in September 2026, accepted once filed again as Y with the same MCIN. A line that quotes the CSN carries none of its own house bill rows — the CSN holds them. Ask the forwarder who filed the CSN for its MCIN or PCIN, or use Add a line from a CSN, which builds that line from the CSN and its acknowledgement. If the CSN itself describes the cargo wrongly, whoever filed it corrects it first; the manifest cannot overrule it. No corrected line has yet been seen accepted.

SCMTR stops this before you send. When you open an SAA, every line it adds with previous declaration N is asked of customs' public record: is there a CSN on that master bill, under the same bill date, on this vessel call? If there is, the line is an error (753) — only that a CSN exists is shown, never who filed it or its number. Not flagged: a line that already quotes a CSN, declared split cargo, a bill the same SAA deletes and adds back, a departure amendment (SDA, whose export lines are C / N over exporters' CSNs as a rule), and a bill the question could not be asked about — that one is listed as not checked yet, and the page is not shown as clear.

Why was my amendment refused with 749 or 306?

749 comes back on a refused SAA — a shipping line's manifest amendment — and was seen there in September 2026; it is in no published list. 306 is its published sibling. Both mean the amendment changed or removed something under a number customs does not hold it under. An amendment finds a line by its line number and a container by its line, subline and sequence number — not by the bill of lading or the container number written beside them. 306 ("Line_No+Sline_No Not Exists For Update/Delete") says a line is not there under that number; 749 ("Line_No+Sline_No+EqmtSrNo Not Exists For Update/Delete in TrnsprtEqmt") says a container is not.

What happened there is the usual cause. The SAA removed a bill as one line number, with its four containers numbered 1 to 4. Customs' public record held that bill on a different line, with the same four containers under the same numbers — and the line number the SAA used held another bill, with one container. Every field of the line was right except its address. The file it was built from was numbered differently from the manifest customs held, which usually means customs holds a later version: an amendment accepted since, or a manifest re-filed.

What to do:

Look the bill up on ICEGATE's public SAM / SDM enquiry. It shows the line customs holds the bill on, and under Container Details each container's sequence number.Build the amendment again from the manifest customs holds now, or correct the line number and every container's sequence number to customs'. A file numbered differently is usually out everywhere, so check the vessel container list's sequence numbers too.Send it under a fresh job number.

Why it matters more than one refusal. The refused file happened to carry its containers under the removed line, and one of their numbers not existing on that line is what stopped it. The builder here sends a removed line whole — its containers and legs D — so a stale number trips on them and is refused rather than removing whatever customs holds under that number, which may be somebody else's bill. That is why Build amendment asks customs' record before you sign, and why a wrong address there is red. The Checks tab says the same thing earlier: when you ask customs about the manifest, it compares the first bill's line number with customs', and says so when the file is numbered differently.

Why was my amendment refused with 394?

394 — "Line_No+Sline_No+EqSrno Already Exists in Equipment" — is an SAA adding (S) a box to the vessel's container list under a sequence number the manifest already uses for another box. It is in no published list; it was seen in September 2026 on an SAA adding a late bill — one that was not on the SAM — with its ten containers.

The vessel's list is numbered 1 to N, N being its declared total: every real SAM and SDM on file is numbered that way, and the real SAAs on file add their boxes at N + 1 and N + 2. The refused one gave its ten boxes the places they would take in a list sorted from scratch — 10, 152, 458 and so on — on a manifest of 1,025 boxes, so every one of those numbers was already someone else's. Customs marked one; the rest were numbered the same way.

What to do: number every box the amendment adds from N + 1 upwards — the manifest's declared total before this amendment, with every amendment accepted since — and send it under a fresh job number. Only those numbers change: a line numbers its own containers, so nothing else in the file refers to the vessel list's. Opened here, the file's Checks tab finds it before sending (red, 394) and Number the added boxes fixes it in one press; Build amendment numbers added boxes that way on its own, and addresses a box it changes by the number customs holds it under, never the working copy's.

A line added under a number the manifest already uses is the same mistake one level up — 307, "Already Exists For Addition". It is shown as an error when a count or a reply of your own manifest shows the number in use (a free number always exists), and as a warning when only the rotation enquiry shows it, or when a reply cannot be tied to your own submitter on customs' record.

Why was my amendment refused with 748?

748 — "Line_No+Sline_No+Srno Not Exists For Update/Delete in TrnsprtItems" — is the item twin of 749: the amendment updated or removed a cargo item customs does not hold under that line and item number. It is in no published list.

It has the wrong-address cause above, and a second one worth checking first. On the refusal seen (September 2026), the line number was right — customs held the bill on the very line the SAA named — and the line was a straight bill that quotes an earlier declaration (S / Y). Customs' Trade Scenarios table gives such a line its reference, its prior reference, its customs location and its containers, and no item details: the CSN it quotes holds the goods. A SAM customs accepted on 7 September 2026 did carry items on all 56 of its S / Y lines, so a fresh SAM may send them; whether customs stores them is not on record — the refusal of item 1's update suggests it does not, and that updating it addressed nothing. Item rows under a line your SAA removes are a warning: no refusal is on record for them, and the one removal seen accepted sent none.

What to do: take the item details (itemDtls) off that line in the SAA, and send it under a fresh job number. If the goods themselves are wrong, they are corrected in the CSN the line quotes — the forwarder's amendment — not on the manifest. Build amendment here leaves item details off such a line. The checks stop an SAA that updates or removes an item on a straight line quoting an earlier declaration (S / Y, red, 748) — the shape customs refused — and warn (amber) on a consolidation quoting one (C / Y, C / C), which the same table gives no items but no reply has refused yet.

What is not settled. Whether customs refuses an item added (S) on such a line; whether a SAM that carries items there has them stored or ignored; and whether itinerary legs there — also left off by the table — draw the same kind of refusal. And the table is not the whole truth: it also leaves items off an export consolidation (C / N), yet the real departure manifests on file carry them on such lines (one SDM on all 19), which is why nothing is flagged on a fresh filing.

How does SCMTR count the manifest customs holds, without my ICEGATE login?

Open your SAA (or SDA) in SCMTR. The count starts by itself, under the verdict at the top — What customs holds for this vessel now — with nothing to press. SCMTR reads ICEGATE's public enquiry for your vessel call, line by line: first every line customs holds under the manifest's current version (about a line a second), then the containers on those lines. No ICEGATE login or password is asked for or used.

It finds the manifest from one bill already on it — a line your SAA updates or deletes, a bill it adds that customs has since accepted, a SAM of yours kept in SCMTR, a bill from a recent count of the same manifest, or one master B/L you type when it asks for one. If it asks, it says which of your file's bills customs no longer holds — usually because a later amendment already made the change your file makes.It counts a manifest only when ICEGATE names your file's own submitter as its filer — your own manifest. For the line map it keeps everything ICEGATE's public record shows for each line, with the count (shared with other agents counting the same manifest) and for 30 days at most. The public record names no party, so no name or address is kept.The line map shows every line number of customs' manifest as a square: point at one (or tap it, or move with the arrow keys) to see that line whole — its master B/L and date, the CIN it quotes, cargo type and movement, every port, the transhipper, packages and weight, each house bill with its CIN and figures, and each container with its type, size, weight, status, agent and bond — and what your file does there. Copy this line puts it all in a message for whoever holds the SAA. Your file's lines are outlined, red where one has an error. Under the count, What ICEGATE says about this vessel call lists customs' own record of the call — VCN, IMO, voyage, terminal, entry inward, filer and version — as ICEGATE gave it; when ICEGATE names another filer, their PAN shows only its last four characters.Several agents on one vessel call each open their own SAA. When one of them has finished counting the same shipping line's manifest, the next is given that count at once — while customs still holds that version — instead of counting it again. Nobody sees who counted it; Count again always makes a fresh count.A 600-line vessel takes five to ten minutes for the lines (one or two a second). Keep the page open and in front (in a background tab it carries on, more slowly): the line total is checked the moment the lines are counted, the container total when the containers are. The count is kept: open the call again and it is reused at once, for as long as customs still holds that version; after customs accepts an amendment, it counts again by itself — and a count more than seven days old is made again whatever the record says.

Then your SAA is checked against customs' own count: the line total (90, with Set the line total), the container total (89, with Set the container total — the count is the containers customs' lines name, and an empty being repositioned can sit on the list with no line), every line you update or delete, and every line you add. A wrong line total is an error when customs' record confirms the count is of the version it holds now, on an arrival manifest: a line deleted earlier answers nothing on the enquiry, exactly as customs counts it (measured against customs' own refusal, September 2026). A container total below the count is an error too — customs' list holds every box its lines name; one above it is a warning, since an empty can sit on the list with no line. A count with more than ten numbers out of use gives warnings only. If a line your SAA adds is already counted, it is an error either way — this very SAA was accepted before the count (do not send it again) or it is a copy older than customs' (the added line needs the next free number) — and SCMTR says both. If customs accepts another version after the count, the checks ask you to Count again. A line deleted earlier leaves its number out of use, and the count shows it: 626 lines, numbered up to 627.

Can SCMTR stop a wrong total or number before I send?

It can check them, by counting customs' record as above or once it has seen a reply customs accepted for that vessel call, and it stops the upload on an error from a count of the version customs holds now, or from an accepted reply to the SAM itself. An amendment file alone cannot say what customs holds now: its totals and numbers are only as good as the copy it was built from. But an accepted reply lists the whole manifest customs holds after that send — every line by number and every box on the vessel's list by sequence number. SCMTR keeps every reply your organisation drops or receives here, so it reads the newest accepted one for the same port and rotation, and checks your SAA or SDA against it before you sign it:

the line total and the container total (90, 89): what customs holds, plus what you add, less what you delete. Each has a Set the … total button. Red when the reply answers the manifest itself; amber when it answers an earlier amendment — a reply lists every row the amendment sent, so one that deleted a line may still show it, and no accepted deleting amendment has yet been seen either way;added boxes numbered inside customs' list (394): Number the added boxes moves them past it;a line you update or delete that customs holds under no such number, as a warning: customs has refused the container under such a line (749); the line itself (306) has not been seen refused;a line added under a number customs already holds (307): an error when customs' record confirms the reply is your own manifest as it stands; a warning when it cannot.

It runs in the editor's Checks tab, in Build amendment and again on the server just before upload, so an error there is stopped, not just flagged. What is an error from a count of customs' manifest is listed under What does SCMTR check the moment I open an SAA? below; a total read from a reply to an earlier amendment is a warning. It also asks ICEGATE's public record which version of the manifest customs holds. If that is a different version from the reply's, an amendment was accepted since, perhaps filed from another system; and if the record cannot be read at all, the version is unconfirmed. Either way the totals and numbers read from that reply become warnings and say so: drop the newer reply on Check a file and they read it.

A refusal helps too. If your SAM and earlier amendments went through other software and the only reply SCMTR has for the call is customs' refusal of your SAA, it still reads the lines from it: a refusal of an amendment usually lists every line customs holds together with the lines that amendment added, and customs applied none of it — unless its rows are only the lines the file sent (a Kolkata refusal of 1 October 2026 listed just its two): then it is the send, not the manifest, and nothing is read from it. So reopen the refused SAA (or a corrected copy — keep the refused file here too, so SCMTR knows which lines it added) and the line total is checked, with Set the line total, as a warning. A refusal does not list the vessel's containers, so the container total needs an accepted reply or a count. Reopen the very SAA customs refused, with both files kept here, and every total customs refused is named as refused on that very send — sent again unchanged, it will be refused again, so it is an error when the file makes the very same change customs refused (the same number of lines or containers added and removed) and nothing newer has been accepted since. A different change leaves it unjudged: you may have corrected the file where the total does not show (a container row added to the vessel's list for a box your lines already named leaves the container total as it was, and makes it right). With no reply at all kept for the call, nothing changes — so drop each reply here as it comes back, even for files sent from elsewhere.

What does SCMTR check the moment I open an SAA?

Without anything else kept here, and without your ICEGATE login. The top of the page says whether the file can be sent, and every error has How to fix beside it, with Copy the fixes and Share on WhatsApp for whoever made the file.

Shown as errors — SCMTR is a pre-check: anything customs refuses, or that would change the manifest in a way you did not mean, is shown as an error to fix before you send:

A line you update or delete that customs holds under another number, or whose containers customs numbers differently — the address mistake customs refuses as 749. Take the numbers customs holds.A bill you add that customs already holds on this vessel call, from your own submitter. If an earlier send of the same change was accepted, the bill is already on the manifest (say on line 628) and this SAA would add it again (as line 638) — do not send it. Not flagged when the bill is split cargo on a second line (declare the split), or when this SAA deletes that bill's line first — the drop-and-re-add ICES Advisory 38/2026 asks for.A line you add declaring afresh a master bill a CSN already declares (753): previous declaration N on a bill where customs holds a forwarder's CSN. Quote the CSN instead — see SAA refused 753.A line you add under a number customs already holds (307), from a count, or a reply customs confirms is your manifest as it stands: line numbers only grow, and a deleted line's number stays unused, so a new line takes a number past every one in use — a free number always exists. If this very SAA was already accepted, the line is its own: do not send it again.A container you add that customs' lines already name (156, with 153): it is on the vessel's list already — take it out of the vessel's container list. A total that looks right only because the line or container you add is already counted proves nothing.The line total (90) from the count of customs' manifest, which starts by itself, and a container total below that count (89) — the vessel's list holds every box its lines name (arrival manifests, counted on the version customs holds now; a count with more than ten numbers out of use gives warnings only) — and the total customs refused this same job for (89/90) when nothing newer has been accepted since.A container left on the vessel's list with no line: a line you remove held a box no other line customs holds carries, and the vessel's container list in your file does not remove it (its row has no amendment type, or is not there). Mark it D — Mark it removed (D) does it where the row is in the file — and the container total the count asks for already counts it out. If the box really stays aboard as an empty, say so on its row instead — Keep it aboard as an empty sets U and load status EMP — and it is a warning, counted in the total. No reply on file yet shows customs taking a box changed to empty this way.The vessel's container list written under a line's field names — eqmtId, eqmtSeqNo, cntrWeight where the vessel list has equipmentId, equipmentSequenceNo, containerWeight. Those are not the vessel list's field names, so customs may read no container on the row, and its D may remove nothing. Use the vessel list's field names renames them and keeps every value.A line your SAA re-points by an update (U) at a CIN that is on no CSN under its own master bill (360) — customs' record shows no CSN on that bill carrying it. A line re-pointed at a house PCIN from a CSN on another bill was refused 360 twice (Chennai, October 2026), with the line's own PAN and with the CSN filer's. Quote the CSN customs holds on the bill instead.The declaration's amendment type is not U (master.decRef.amdType): on an SAA it is U — the manifest is being changed — or D; S belongs on each line and container the SAA adds, never on the declaration. The two SAAs on record that put S there were both refused with no error code at all, the declaration block the one block customs did not stamp.Who files is not a PAN: a submitter, authorised representative, sea carrier or consolidator code such as XXXXXXXXX or AUTHORIZED — a template's value, not yours.

Shown as warnings — worth a look before you send:

Totals that look like they count only your amendment (90, 89): an SAA adding two lines numbered 103 and 104 that declares a line total of 2 has most likely written the size of the amendment where the manifest's total goes — the total is the whole manifest's after the change. A warning, not an error, because one real case gives the same numbers: the second SAA of a drop-and-re-add sent separately. The count of what customs holds settles it.

A line you add under a number in use (307) when only ICEGATE's public SAM/IGM enquiry shows it: that enquiry is asked by rotation and line number and does not say whose manifest the line is on — and it numbers lines by their IGM line, which on some calls differs from the manifest's own line numbers, so the line it shows may be a different one.

A container total above the count (89) — an empty being repositioned can sit on the vessel's list with no line.

Added containers numbered as if customs held a different count than your total says — say the total gives 1,069 held but the added boxes start at 1,067. One of the two is wrong: the total (89) or the numbers (394). The count of customs' manifest says which; for an SAA that only adds lines, type one bill already on the manifest to start it.

A line added above your own line total — line 542 with a total of 535 needs seven numbers out of use. That happens (deleted lines; customs has accepted a manifest numbered 1–8 and then 52–107), but check the total.

A party code with no code type. A consignee, consignor or notify code needs its type beside it (IEC, PAN, GSN…); every real manifest on file sends one. SCMTR names the type the code's shape suggests.

An added box that disagrees with itself — one weight, package count, load status or seal on its line (or lines, added up, for a box two lines share), another on the vessel's container list.

A file name that disagrees with the file — say job 1545 in the name, 1309 inside.

A line your SAA removes declaring that it quotes nothing (previous declaration N, no prior reference) while customs holds it quoting a PCIN or MCIN: a removal states the line as customs holds it — Y and the CIN your SAM quotes. The removal of such a line with no CIN was refused 724; one declared N has not been seen answered. SCMTR asks customs' record which kind of CIN the line quotes; the CIN itself never comes back to the page.

A line you add quoting a CSN's CIN under the other consolidation indicator — SCMTR asks customs' record what the CIN is: a straight CSN's own PCIN is quoted by an S line, a consolidation's own MCIN by a C line. Make this line S (or C) sets it. No refusal names the shape, so it is a warning.

A container your SAA changes on a line it updates, left off the vessel list in the file — customs presumably keeps the vessel list's row as it holds it (no reply on file says), so a changed weight or count there may stay as it was; every amendment on file restates such boxes on the vessel list (U).

A line whose quoted CIN your SAA changes by an update (U) — ICES Advisory 38/2026 (Q2) calls that prohibited in place; the line is dropped and filed again. The replies seen named no code for the change as such.

An amendment type the guide does not list — A on a line, its containers or the vessel list. Each record says S (add), U (modify) or D (delete). SCMTR reads A as S (an addition), so if customs already holds the line, that is shown as an error — set U if you meant to change it.

A container on the vessel list with no amendment type — every row of an amendment's vessel list says S, U or D. When the file removes that box from its line, it is D, and Mark it removed (D) sets it.

A line you remove whose container the vessel list in your file does not remove — if no other line carries it, add it there with D under the vessel's sequence number for it (from your SAM); the count says whether another line does.

When a check cannot run — ICEGATE did not answer, the count needs one master B/L already on the SAM, or it is another filer's manifest — the top of the page says which check is missing instead of showing all clear.

Drop the refusals of the same vessel call beside it (or keep them here) and the line total, the lines customs holds and the container total customs refused are checked too.

Will customs re-check the lines I did not change?

Not known. One real amendment (September 2026) was refused with 233 on 114 lines it had not changed; either customs re-checks every CSN-referencing line on any amendment, or the file that was actually uploaded re-sent them. A file built here names only the lines you touched, so the second cause cannot arise from it — but nothing here promises an acceptance. See Customs refused my manifest.

Related

Working with a shipping line filingMy console's house bills are not on the line's manifest — the forwarder's side of the same request, and what the SAA may carryChecking a manifest against ICEGATEBill of Entry and the IGM — what an SAA is, from the importer's sideICES Advisory 38/2026: the six FAQs — the drop-and-re-add procedure, the flags, and what moved from the CSN to the SAMChennai customs' SCMTR help desk — where a refused SAA's Unique ID goes at ChennaiManifest field reference

This page is for information. Customs decides what it accepts — confirm anything that matters with customs or ICEGATE.