Troubleshooting

Symptoms, in the words you would use to describe them.

Signing

I cannot find the Sign on ICEGATE button any more — only Sign & upload

That is the app since 13 September 2026, and nothing is wrong. Sign & upload signs the filing on your own computer with your DSC token, through the scmtr DSC Signer, and sends it — one button, no trip to the portal. The Signer is a signed, free installer offered by the app the moment it finds it missing. The older route — download the file, sign it on ICEGATE's own portal, upload it back — is still there for anyone who cannot install software: the dialog that appears when Sign & Submit finds no Signer offers Sign on ICEGATE beside the download. Full detail is in Signing your filing.

Nothing happens when I press Sign & upload — no certificate dialog appears

Signing needs the scmtr DSC Signer running on your own computer — a web page cannot reach a USB token by itself. Full detail is in Signing your filing.

Check, in order:

Your browser was allowed to reach it. Chrome asks, once, whether scmtr.io may access other apps and services on this device — that is the Signer, and the answer is Allow. Blocked, the platform says so; fix it under the address-bar icon → Site settings → Local network access. Closed without an answer, the platform says that instead — press Check again and choose Allow.The scmtr DSC Signer is installed and running. If it is not installed, the platform says so: a dialog offers the download for your machine and a Check again button — install it, then press that rather than starting the filing again. Once installed it starts with Windows and sits in the notification area; look for the scmtr icon there, or open http://127.0.0.1:13913/health — text means it is running, a connection error means it is not, and the Start menu entry scmtr DSC Signer starts it.It is current. The platform refuses a Signer older than it needs and names both versions — "version 0.1.0, but signing here needs 1.0.0 or newer". Run the current installer over the old one; there is nothing to uninstall first.You are on the real address. The Signer answers scmtr.io and www.scmtr.io and nothing else; there is no dialog to allow a site and nothing to un-block. A preview or staging address is refused however good your token is — open the filing at https://scmtr.io.Your DSC token is plugged in and its driver installed.The same token signs on ICEGATE's own portal. If it does not, the problem is the token, not this filing.

If you cannot install anything, the dialog in step 1 also offers Sign on ICEGATE — download the filing, sign it on ICEGATE's portal, and upload it back. That route needs nothing on your computer.

The Signer is gone every time I restart, and I have to install it again

You should not have to — and if that is what has been happening, it was our defect rather than anything you did. It is fixed in Signer 1.1.1: install that over what you have, and there is nothing to uninstall first.

What went wrong. The installer arranges two ways for the Signer to start when you sign in to Windows: a scheduled task, which also restarts it if it ever stops, and a plain startup entry as the fallback. The task was written asking Windows to run it for every user of the computer, and only an administrator may set that up — so on an ordinary account Windows refused it, silently. The fallback still started the Signer, which is why almost nobody saw anything wrong. But on a machine where antivirus or a "PC cleaner" later removed that fallback — both do this to startup entries routinely — nothing was left to start it, and the Signer really was gone after every restart. To the app that looks exactly like not installed, so installing it again did work. Every morning.

From 1.1.1 the task registers properly, the installer checks it is really there before dropping the fallback, and the Signer inspects its own start-up arrangement every time it runs and puts back whatever has been removed. Where it cannot arrange either, the installer says so on its last screen instead of finishing quietly.

To see where you stand, in a Command Prompt:

"%LocalAppData%\Programs\scmtr DSC Signer\scmtr-sign.exe" -autostart-status

Starts at sign-in: yes means there is nothing to do; anything else prints the reason. The same line is in the tray icon's right-click menu, and since 23 September 2026 the filing form shows a small banner while you are filing if the Signer reports that it will not be there after your next restart — the filing you are working on is unaffected either way. Fuller answer in Do I have to start the Signer every time I restart my computer?.

The app says my Signer is too old

Sign & upload refuses a Signer below the version the app was built against, and tells you both numbers. Download the current installer from the app's download page and run it over the old version: it closes the running copy, replaces it and starts the new one, and there is nothing to uninstall first. Then press Check again in the dialog to carry on with the same filing.

It is asking me which certificate to sign with

More than one usable DSC was found — often a colleague's token left plugged in, or a renewed certificate alongside the one it replaced. Pick the one registered with ICEGATE for the organisation this filing belongs to; where two share a name, the expiry date tells them apart. The one belonging to the person named as the filing's authorised representative is marked, as a guide. The platform will not choose for you, because the wrong certificate is only caught by customs later.

ICEGATE emailed "DSC validation failed … Please use a valid DSC"

Drop the signed file you sent on SCMTR JSON upload, or on https://scmtr.io/check. Its Digital signature (DSC) panel checks the causes a file can show and flags the likely one: a certificate not registered on your ICEGATE ID (often a renewal — signed in, it compares with your organisation's accepted filings), a file re-saved after signing, or an expired, revoked or encryption-only certificate. If you have the token, press Compare with the DSC on this computer as well. Nothing in the cargo data needs to change — fix the cause, sign a fresh copy and re-file with a new control number.

It says my certificate is not valid today

The DSC has expired or has not started yet. Customs rejects a filing signed with an expired certificate, so this is stopped before it is submitted. Renew it with your Certifying Authority, register the new certificate with ICEGATE, then sign again.

The signed file was rejected as not matching

Sign again from a fresh download rather than reusing a file you signed earlier. What gets signed is the exact frozen text of that declaration; an older signature covers older content, and the mismatch is caught deliberately.

I cancelled the PIN dialog and now I am unsure what state I am in

Nothing was sent. Signing again reuses the version that was frozen, rather than creating a second one, as long as nothing about the filing has changed.

Filing

My filing shows "Delivery unconfirmed"

The upload left and no answer came back, so ICEGATE may hold the file or may never have received it. The filing is locked and marked as sent — the safer assumption — with no tracking number claimed. Do not upload it again. The platform keeps reading customs' public record for that master bill and settles it when your filing appears; dropping the emailed acknowledgement on the filing settles it too. If nothing ever arrived, an organisation admin can return it to draft. Full detail in After you file.

It says my filing is being held

Nothing was sent and your signed file is unchanged. Either sends are being paced — thirty a minute across the platform, ten a minute for your organisation — or uploads have stopped completing and sending is paused for about five minutes. Try again shortly.

It says the same file was already sent

A transmission of this filing has already gone and customs has not answered, or has accepted it. The earlier one is named with a link; open it before doing anything else. A refusal is never in the way. If you are certain it never arrived, type a reason of at least ten characters and send it anyway — the reason is kept with the filing.

It says this filing is larger than the platform carries

A signed CSN over 4 MB — roughly eight hundred house bills — is refused before anything is sent, with the size named. A filing that large is unusual: if it is right, download it, sign it with your DSC on ICEGATE's portal and upload it there, and tell us, because we would rather raise the limit than have you work around it.

It says "Filed to ICEGATE's portal, but no tracking id was returned"

The portal took the file and gave back nothing to poll, so the acknowledgement can never arrive here on its own. The filing is locked to prevent a duplicate.

A rejection comes by email to your registered ICEGATE address — watch that mailbox, then open the declaration and use the Status card to record what the email says. An acceptance can now be found without the email: customs' public record lists an accepted filing together with its tracking id, and the platform checks it in the background — if your filing appears there, the id is recovered and the status starts moving on its own. You can also ask on the spot with BL tracking in the header, or ? → Customs lookup. See What customs already holds.

After you file covers this state in full, including what to do when the email does not arrive.

ICEGATE emailed "Header validation failed" — how do I find the error in my CSN?

Read the rest of the sentence before looking inside the file. The wording on record is "Header validation failed for Job no. <n>. The Control Number has already been processed", and it is not about any field of the declaration — so it looks the same whatever the shipment is, a Nepal transit, an ICD move or a plain import. ICEGATE has already processed a file from your sender ID under that job number and job date, and it refuses the numbers, not the contents. Nothing was filed and no acknowledgement is coming for that upload.

The fix is to give the file a job number your sender ID has never used, change it in the header's control number, the job details and the file name, set the job date and header date to today, and only then sign and upload it again. If the earlier use of that number was accepted, do not file again at all — amend the accepted CSN. Where the earlier use usually comes from, and the clue to look for in the file, are in Reading an acknowledgement.

If your email says something else after "Header validation failed", that wording is not on record here — do not assume it means the same thing; send the whole email, the file and its control number to the ICEGATE Helpdesk.

ICEGATE emailed "there was an error in processing your file… please try after some time"

Nothing was filed, and no acknowledgement is coming — this email is sent instead of one, for a file that failed before it became a declaration. So do not sit waiting on the control number it quotes.

It is also the one refusal that names no fault in your file, so do not edit the declaration. Wait a short while, then send the same file again with a new control number and job number — the old control number was received, and reusing it risks "The Control Number has already been processed". If it fails again the same way two or three times, stop retrying and raise it with the ICEGATE Helpdesk quoting the control number, filing date, receiver ID and message ID of each attempt. Full detail, and what the wording does and does not tell you, is in Reading an acknowledgement.

ICEGATE emailed that my file failed UTF-8 encoding validation

Nothing was filed, and no acknowledgement is coming for that upload. The email asks you to correct the content "at line … and position …": somewhere in the file there is a character that is not plain text, and ICEGATE turned the whole file away before reading any of the filing. ICEGATE's own FAQ says a file must be UTF-8 encoded, and every filing on record that customs accepted is plain ASCII throughout.

The email does not say which character it is. The likely sources — our reading, since in the one refusal on record the character itself was never seen — are values pasted from a PDF, Word or an email: a curly apostrophe or quote, a long dash, a non-breaking space, an accented letter, saved by the software that made the file in a Windows encoding instead of UTF-8.

Find it. Drop the file on SCMTR JSON upload on the CSN filing page: it lists every character that is not plain text by line and column, with the field it sits in and what to type instead. Match it to the email by the line: the email's "position" appears to count bytes from the start of the file, not characters along the line.Retype the value by hand where the file was made, rather than pasting it again.Create the file again and sign it again. Never edit a signed file — one changed byte breaks the signature.Re-file with a new control number.

A filing made here should not meet this: typing or pasting into any field converts those characters to plain text as you go, and a value that arrived another way — an imported file, the address book — is flagged before you sign. Full detail, including how to find the character in Notepad++ without the app, is in Reading an acknowledgement.

ICEGATE emailed "your filing was failed due to some error" naming a field and a length

Nothing was filed, and no acknowledgement is coming for that control number. After Errors in file: the email lists each problem as the offending value, a colon, and the rule it broke — for example "…:Consignee Street Address should be only characters and should not be more than length 70".

Despite the wording, count the characters before looking for anything else. In the one refusal of this kind on record, the value held nothing but letters, digits and spaces and was 74 characters long — it was the length that failed.

Search the filing for the quoted value. The list does not say which house bill it is on, and the same address is often on two parties (a notify party "same as consignee") or on several house bills. Every copy has to be fixed.Shorten it to the limit. For an address, the city, state and PIN code have fields of their own, so a city repeated at the end of the street line can usually go.Re-file with a new control number.

The app now catches this before you file: a value longer than its field's published maximum is a red issue in the checklist, on the review step and on SCMTR JSON upload, however it got there — typed, picked from the address book, or brought in with an uploaded file — naming the limit and how many characters to remove. See Reading an acknowledgement.

My filing says "Submitted" and nothing has happened for hours

Since 22 September 2026 a fresh filing sent from here is resolved from customs' own record: the platform reads ICEGATE's public enquiry for every waiting filing about every fifteen minutes, and when it names your transmission and agrees with what was sent, the CSN number and date are recorded and the filing turns accepted on its own. So a filing still submitted hours later usually means one of three things: customs has not answered yet (commonly minutes, sometimes much longer); customs refused it — a refusal never appears on the public record and reaches you only in the emailed _ACK, so check the registered mailbox; or the filing is an amendment or a deletion, which are never settled from the record and wait for the _ACK regardless. Past a day, treat it as an outcome to record by hand — see After you file.

Before assuming something is wrong with your filing, consider that it may not be your filing at all. ICEGATE's acknowledgement generation has stalled service-wide before, for days at a time, with every filer at every agent waiting on the same queue. The tell is that it is not just you: nothing is coming back for any of your filings, and the trade groups you are in are saying the same thing. Your submission is unaffected — it was accepted and queued, the answer is simply not being produced yet — and there is nothing to resend. Resubmitting during a stall risks a duplicate filing, which is a far worse problem than waiting.

Once the service recovers, drop the acknowledgement ICEGATE emails onto the filing, which records and explains it in one step — or read the outcome off ICEGATE's portal and record it on the declaration's Status card.

ICEGATE emailed me the acknowledgement, but the filing here still says "Submitted"

The platform never saw it — an acknowledgement goes to your mailbox, not to us, and a rejection reaches the filing no other way (an acceptance is usually read off customs' record first, but the file is still the one to keep). Drop the attached file (the one whose name ends in _ACK) onto the filing: ⋯ → Upload ACK on its row, the Status card on its page, or SCMTR JSON upload on the CSN filing page, which finds the filing from the file. The status and details are set from it and every error is explained against what was sent, with where to fix it. A reply that came back the next day is named for the day ICEGATE answered, not the day you filed; that is normal and it is still accepted, because the check is on what the file carries, not its name. If it says the file is for job N, it is another filing's — open that job and drop it there. If the filing was already accepted from customs' record, an acknowledgement that agrees is kept and becomes the transmission's own answer; one dropped twice says the outcome is already recorded, and there is nothing to do. See After you file.

It refused my acknowledgement and said the two files are not the same filing

On SCMTR JSON upload, the CSN you added is not the one the acknowledgement answers, and the refusal names which identifiers disagree. The screen spells out the name of the file it needs, part by part — pick that one from the folder. On a filing's own page the same refusal means the acknowledgement is for a different job, which it names.

ICEGATE rejected the file on upload

That is a rejection of the file, before customs saw it — usually structure rather than content. The reason is shown; your draft is untouched and can be corrected and re-signed.

It was rejected for the file name

If the reason mentions the file name — "Invalid SCMTR File Name format" — nothing is wrong with what you declared. ICEGATE reads the filing's message type, event, sender, job number and date straight out of the name, and it refuses any name that does not have exactly those seven parts.

This only reaches you on the Sign on ICEGATE route — the one offered when the Signer cannot be installed — where the file passes through your hands. The usual cause is renaming it, and the usual accidental cause is downloading it twice so your browser saved the second copy as … (1).json. Fetch a clean copy and sign that one, leaving the name exactly as the platform issued it. Filename convention in Every reference number, who issues it, and when has the full shape.

Customs rejected it and I want to try again

A rejected fresh filing unlocks automatically. Correct it and file again — it is still the same declaration, and no CSN was ever granted, so there is nothing to amend against.

The form

The checklist says a field is required and I do not have a value for it

Some entries are recommended, not required — they say so, and they do not block submission. Customs has accepted filings without them.

If it is genuinely required and you have no value, the usual cause is that an optional block was started by accident: filling any field inside a block switches on all of that block's mandatory fields. Clearing the whole block puts it back to untouched.

I set an amendment flag on a block and now it demands a dozen other fields

Same cause. Setting a flag on a block "starts" it. If the block has no data, leave the flag blank.

The Amendment field is asking for a value on a row I just added

New and duplicated rows arrive with the flag blank on purpose, so you choose rather than inheriting a wrong answer. A row that did not exist in the accepted filing is a supplementary addition.

The review asks for an authorised representative PAN and no step ever offered me one

That value comes from your organisation's profile, not from the filing — Settings → the filing profile. If it is blank or malformed there, it is blank or malformed on every declaration started since.

Fill in Settings → Authorised representative PAN with a bare ten-character PAN (AAAAA0000A, never PAN:AAAAA0000A), or set the submitter code to your PAN and let it fill itself. Existing drafts keep whatever they were created with, so correct the field on the draft too — it is on the master bill step, in the folded Filed by section.

I pasted a bill of lading and the discharge port is not the right one

Check the port shown on the panel before you press the button: it is displayed as code and name (INPAV1 — PIPAVAV) precisely so it can be checked against the bill in your hand. Any value it offers can be edited afterwards on the step that owns it.

I pasted a bill of lading and it filled almost nothing

Three usual causes. The copy did not include the text — some carrier PDFs draw their values as graphics, and a copy of those pages yields captions only; paste the pages that select as text, or type the few fields by hand. The bill was already filled in — a paste never overwrites what you have typed, and says "already filled, left alone" against each such value; the panel lists every value either way, with the step it sits on, so you can see where it went. Most of it landed on the house bill step — the parties, the goods and the packing are all on Your house bill, which comes after the master bill and its containers, so the master screen after a paste looks much emptier than the filing actually is.

Take the paste anyway even when it has nothing left to fill: that is exactly what a second bill looks like, and pasting both is what produces the disagreement list and identifies the consolidator.

The paste named the ship but the vessel field is still empty

That is deliberate, and it is now one press rather than a retype. A bill of lading writes MAERSK CAMEROUN/629W; the message wants a seven-digit IMO and the VCN customs issued for that call, and neither is on the document. So the paste hands the name to the ship finder above and searches it for you — pick the hull from the results and the IMO is written for you. If no ship comes back, the finder offers Enter this ship's details by hand right there.

Customs rejected my filing with error 122 or 123

122 is MC-MBL Details Already Exists and 123 is HC-HBL Details Already Exists, the same at house level. Customs already holds a cargo declaration for that bill of lading, so a second one is refused. Three different situations produce this pair, and they need opposite responses:

Your own earlier filing. The usual case. The app checks as you type the bill number on the wizard's master bill step and names the job if it finds one. To change what was declared, amend that filing rather than filing again.Another party has filed — the shipping line or another forwarder — and the master bill is now closed to a fresh CSN from you. If theirs is a CSN, an amendment of yours may be refused too (320 in customs' list, not yet seen on a reply); if it is only the line's manifest, your accepted CSN can still be amended (ICES Advisory 37/2026). Check customs' accepted-filings record before assuming otherwise; "they haven't filed yet" is worth one lookup rather than trust.You deleted a filing and are re-filing the corrected one. Measured once, on 6 September 2026: a deletion acknowledged, and the fresh filing refused with this pair all the same — it cost that filer their cut-off. 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 without a mismatch, so this cause should be history; no re-file after a deletion has yet been seen accepted from customs' side to show that it is. If you meet it, see Deleting does not free the bill of lading for what to do — and send us the acknowledgement, because a refusal after the advisory is news.

In every case, check whether the filing can still be amended (see below) before spending another submission.

One case on record cuts the other way, and the filer's own account explains it. A CSN was accepted, then amended to a new transhipper PAN and bond (accepted at 20:13). About five minutes later the filer looked the bill up on ICEGATE's public enquiry and it showed nothing — the record was blank. So they sent the original file again as a fresh CSN, with a new job number and the corrected PAN and bond, and at 20:27 it was accepted as a second CSN with a new PCIN. Two other filers' fresh filings on bills customs still held came back 122/123 — one after a deletion, one after a vessel substitution (both before ICES Advisory 38/2026). Read together: 122/123 is "customs holds this bill from you"; when the record is empty a fresh filing goes through, but as a new CSN and a new PCIN, which the CFS and transporter then have to be told. So before you re-enter a bill, look it up with SCMTR JSON upload (it asks customs' record): a listed bill draws 122/123 and wants an amendment; a blank one takes a fresh filing. And if an accepted amendment is followed by a blank record, treat the amendment as not on record until the enquiry shows it — measured once, September 2026.

Customs rejected it for an invalid country code and the code we entered is correct

The usual one is 44 Invalid Buyer Country Code on a filing whose consignee country reads US, or 43 on a shipper's — both genuine two-letter ISO codes, both refused. Four things to check, and the first two answer most of it:

What the file says, not what the form said. Country codes are two characters; the trade writes them three (USA, IND, CHN). Open the declaration and read the field.Which bill the error names. The master and each house bill carry their own consignee, and the acknowledgement points at one of them. Filling the house in does not fill the master in.The party's identity code. On an arrival filing the consignee is the Indian importer, and every code type customs accepts bar a passport (PPT) is an Indian registration — a foreign country against an Indian PAN or IEC is the contradiction being refused. Check the shipper and consignee are not the wrong way round on that bill.A leftover state code. Subdivision codes are Indian states only; a foreign party carries its province as a name with the code left blank.

Upload the declaration and the acknowledgement together on SCMTR JSON upload. Each error is marked on the block it names, in the filing itself, with the value that is actually in the file quoted beside it — which settles "but we entered US" in one look. Full detail, including what to do when the consignee genuinely is foreign, is in Why customs rejects a filing.

My export was rejected with 159, "Incorrect Cin Type in MC" — I did put S for the shipping bill

S says the bill refers to one shipping bill; 159 says it did not name which. A straight export bill — one shipping bill under one B/L — has to carry that shipping bill's PCIN in the previous reference, with the CIN type set to PCIN. The shipping bill number is not the PCIN and is not on the bill of lading: fetch the PCIN from ICEGATE's PCIN download enquiry for export (Services → Enquiries → ICEGATE Enquiry Service). In the guided export steps the field is PCIN of the shipping bill, on the first screen, and the filing cannot go out without it.

My export was rejected with 383 and 384 — a CIN "referred multiple times"

One PCIN appears twice in the filing. The usual way: a consolidation whose master names a PCIN that one of its lines also names, or two lines carrying the same one. Each PCIN goes on exactly one line, and a consolidation's master names none at all — customs issues that master its own MCIN when it accepts. Take the PCIN off the master, give every shipping bill its own line with its own PCIN, and check no two lines match. The two codes arrive together because one is reported against the master and the other against the line. Neither is in any published code list; this reading is from refusals seen in September 2026.

My export was rejected with 286, "Invalid Destination Port Code" — the port code is a real one

It is real, and it is Indian. On an export the destination is the foreign port the cargo is discharged at, and so is the port of receipt; the Indian port you load at belongs in the first port of entry and the port of acceptance. The message guide's own wording ("the last port from which the goods leave India") points the other way, which is why this catches people — customs refused it in September 2026 and the exports it accepted name the foreign port. If you fix only the destination and leave the Indian port as the port of receipt, the next refusal is 365.

My export was rejected with 239 and 381 on one line — but the containers are on the master

On an export every line under the B/L lists its own containers, even though the master already carries the full list. 239 is a line with no equipment at all; 381 comes with it because containerised cargo needs at least one container of type CN on that line. In the guided steps, open the shipping bill's line, tick the containers its cargo is in under "Which containers is shipping bill … in?", and type that line's share of the packages and weight in each.

My export was rejected with 709 — the package totals look right to me

709 compares the packages on the bill with the packages on its items, and the usual cause is an item whose package count was left blank — a blank adds nothing, so the items come up short of the total however right the total is. Give every item its count. The neighbouring codes are the same arithmetic elsewhere: 221 is the bill against its containers, 225 a master against the lines under it. 709 is in no published code list; this reading is from a refusal seen in September 2026 and customs' own wording, Total Pckg Mismatch in Transport Doc and Transport Item.

My export was rejected with 053 — I never typed a negative weight

053 is worded Net Weight Can Not Be -Ve, and a net weight of zero draws it too. The field is optional: leave it empty, or give the real net weight. The published list writes the code 53; a reply prints 053. Seen on a real export refusal in September 2026.

My export was rejected with 225 — the master's packages and the lines' do not match

225 is Pckg in MC Does Not Match With Total Pckg in HC Ref: the master bill's package count is not the sum of the lines under it. On a consolidation each shipping-bill line carries its own packages and the master carries the total — add the lines up and correct whichever side is wrong against the bill of lading. The guided steps add the master up from the lines for you. 221 is the same sum one level down (a bill against its own containers) and 709 a bill against its items.

The shipping line says its manifest was refused with 237 because of my CSN's load status

237 is Load Status Not Match With Referred Load Status of CSN. The line's departure manifest declares the same container as your CSN, and customs compares them on seven points — total packages, number of containers, and each container's type, number, size, load status and shipper-owned flag (232 to 238). Weight is not one of the seven. Agree with the line which status is right for that box — FCL, LCL or EMP, meaning how full it is — and whoever is wrong amends. On every export customs has been seen to accept, every container is FCL; what a container shared between two shipping bills should say on an export is not published anywhere, so for a shared box ask the line before you file.

My export was rejected with 161, 148 or 149 — something about the CIN

All three are about the PCIN (or MCIN) a bill quotes. 161 Incorrect Cin_Type in HC — the type on a line is wrong: a line that refers to one shipping bill (S) quotes a PCIN. 148 and 149 Incorrect Cin_Type+Cin_No on the master or a line — the number is not one customs holds: re-copy it from the let-export shipping bill or ICEGATE's PCIN enquiry, all twenty characters, year then PC. We have not seen any of the three on a real refusal; this is read from customs' published wording and its own table of which CIN each kind of bill quotes. The one that has been seen is their master-level sibling 159, above.

Continue is greyed out and I can't go on to the house bill (or the next step)

Continue stays dark until nothing on the step is still required, on an import filing as on an export one. Where to look, in order:

Just above the button. Anything the step is waiting for that has no field on the screen is listed there in words — on the master bill page this is most often the VCN: "Pick this filing's VCN — press Use on one of the calls listed under the ship." The ship has to be picked first: until it is, the finder says "Search and pick the vessel above to continue".Red fields on the page, including inside a section that is folded away behind its summary line — open it. A required field is marked in red once you have been on the step.The count of what is still outstanding, which says how many required fields are left and on which step.

The button is also briefly unavailable while the draft is saving. If none of these explains it, report it through Feedback with the step's name — a dark button with nothing said is a fault.

Continue is greyed out on the export steps and nothing on the screen is red

Look just above the button. Some findings have no field on the screen to point at — a shipping bill line with no containers ticked is the common one, because the problem is the absence of a row — and those are now listed above Continue in words, with the code customs would answer with. Before 2026-09-20 the button went dark and said nothing. If the list names a PCIN used twice, the other copy may be on a different line or on the master: the message says where.

I got an email saying another filer disagrees with my CSN

That email means the other party on your master bill — usually the shipping line — has filed their own CSN, customs accepted it, and on the fields customs cross-checks (packages, container counts, and each box's number, type, size and load status) their figures differ from yours. The platform found this on customs' own public record and mailed you because the window to fix it closes when the disagreement bites: the shipping line's manifest is checked against both filings, and once the other CSN stands against yours customs' error list has a refusal for amending yours (320, not yet seen on a reply — a risk, so amend early). Since ICES Advisory 38/2026 customs says the container ISO code is validated on the line's manifest only; whether a size-code difference between two CSNs still draws a refusal has not been seen either way since, so fix yours if it is wrong.

Open the declaration the email links to and compare the listed values. If yours are wrong, amend now — the other party typically files 2 to 4 days after you, so the window is short. If theirs are wrong, tell them; their filing is the one that has to change. The email is sent once per disagreement, not on a schedule, and the same finding stays visible on the declaration page. See What customs already holds.

Why can't I amend or delete my filing any more?

If customs refused it with 320: another party — the shipping line or another forwarder — has filed its own CSN against the same master bill of lading, and customs accepted it. Your CSN is now linked to theirs, and customs' error list has 320 for changing it. No reply carrying 320 has been seen yet, so the app warns of it on the filing's page and still lets you file; if the refusal does come, a wrong declaration has to be settled with the shipping line and your jurisdictional customs officer. There is no notice and no grace period — the risk starts with somebody else's action, so amend before theirs lands if you can.

If only File a deletion is gone: the shipping line's manifest (SAM) covers your bill. Since ICES Advisory 37/2026 (18 September 2026) that no longer closes your CSN to amendment — file the amendment, then give the line the amended CSN and MCIN/PCIN so it can file a matching manifest amendment (SAA); once Sea Entry Inwards is granted, both need the jurisdictional customs officer's approval. A deletion after the manifest is the officer's to carry out, not yours to file. (Until 19 September 2026 the app treated the manifest like another party's CSN and withdrew both actions; that rule was an inference no ICEGATE refusal ever confirmed.)

The filing's page tells you which case you are in and whose filing caused it. The practical lesson is unchanged: amend the day you notice something wrong, not the week after.

I can't file a new CSN for this master B/L at all

Same cause as above, and here it is firmer than for amendments: once another party's CSN for a master bill of lading is accepted, that master is closed to a brand-new CSN from you. Once the line's manifest covers it, a fresh CSN is not the route either: ICES Advisory 37/2026 has the CSN filed before the manifest, and has the line add missing house bills by amending its manifest (SAA) — ask the line.

The app checks before you get far. The wizard says so on the master bill step, an imported JSON file says so before you build a draft on it, and a submission that would be refused is stopped rather than spent from your monthly allowance.

Note this is not the shipping line doing anything wrong, and their filing is not a conflict with yours. Both of you file against the same master B/L by design — you for the house cargo, they for the master. Theirs is simply also your deadline.

My broker cannot file the Bill of Entry — "THIS IS NOT A VALID IGM"

Your CSN is almost certainly not the problem, and neither is the carrier's manifest being visible on ICEGATE while this happens.

A Bill of Entry is checked against the Import General Manifest, which is raised at the port around the vessel's call. SCMTR filings are accepted days or weeks earlier and live in a separate record — which is why the same shipment can be plainly visible on ICEGATE's New SAM/IGM enquiry and absent from the older Sea Arrival Manifest one. The BoE reads the older one's source, so "visible in the new, missing from the old" and the BoE refusal are one fact, not two.

Look the master bill up under ? → Customs lookup (or BL tracking in the header) and read the carrier's filing: an empty inward date means the vessel has not been granted entry inward, and an empty IGM line means the consignment has not been mapped onto a manifest line yet. Either way the wait is upstream of the Bill of Entry. If the carrier lodged the manifest as an SAA amendment, it may be waiting on an officer's approval — that, and the rest of what to check before escalating, is in When the Bill of Entry cannot find the manifest.

Where is my container? The filing doesn't say

Customs and the carrier answer different questions, and a filing's page carries both under Where this shipment is. The manifest status says whether your bill of lading reached the carrier's arrival manifest — that is about paperwork. Only the shipping line can say where the box physically is, so there is a link out to their own tracking, with your container or bill number already filled in where the carrier's site accepts it in a link, and copied ready to paste where it does not.

If we do not recognise the carrier yet, the link goes to a general tracking site that covers more of them, with your number copied. That gap closes as more filings come through.

The paste did not fill the weight

If your bill prints pounds, the weight is refused on purpose — number and unit together. A CSN carries KGS or MTS only, and a pound figure with its unit dropped would be read as kilograms. Convert it and type it in.

Fetch from ICEGATE found nothing

The arrival manifest may not be filed yet — a CSN is often filed in parallel with it, so a "not found" early on is normal rather than an error. Fill in what you have and try again later.

The form disagrees with ICEGATE's manifest and I think the form is right

Submit anyway. The comparison is a warning, not a gate; it exists so a disagreement is a decision you made rather than one you missed. What differs is listed before you decide.

The load status is greyed out and I cannot change it

That container is on more than one house bill, so it is a shared box and the status is not a choice — two shippers in one container means neither has a full load, and the field is filled in as LCL and locked. It names the other house bill it is shared with.

To change it, change the sharing: remove the box from the other bill, or give this one a different container number. Once only one bill is on the box the field is editable again.

The load status filled itself in as FCL and I need LCL

You can change it. A container on one house bill only is assumed to be a full load, because that is what a bill with a box to itself almost always is — but a genuinely part-full container is a real case, and changing it is expected. Change it on the master bill's container row and the house bill follows; a house bill never changes the master for you, and one that disagrees with its master gets an amber note on both, with one click on the master to take its status across.

It says the last digit of my container number is wrong

Container numbers carry a check digit calculated from the ten characters before it, and yours do not agree — usually a misread or a transposed pair. The message tells you what the last digit should be, so compare it with the box or the shipping line's paperwork.

If the number is right, keep it: the warning does not block filing, and equipment that is not a standard ISO container (shipper-owned boxes, trailers, breakbulk) legitimately fails the check.

Is there a limit on how many house bills I can file under one master — six, or some other number?

No. Neither the official MIG Field Table nor the CSN message schema caps the number of house consignments (houseCargoDec) under a master, and real accepted filings prove it in practice — we hold accepted CSNs with 7, 8, 12 and 16 house bills under a single master. The only numeric bound anywhere near a house bill is on its own serial number (subLineNo), which runs 1–9999 — that is a field limit, not a count of how many houses a master can carry.

If a filing tool or portal refuses a master past a small number of house bills, that is a limitation of that tool, not an ICEGATE rule.

Where do I add containers to the master consignment?

On the master bill step — one row per box, as printed on the master bill of lading: number, size and seal. Each house bill then ticks the master's containers it is in and gives its own share of packages and weight in each; a box two house bills tick is shared, and is LCL on both bills and — unless you choose otherwise — FCL on the master. The master row's packages and weight are added up from the house bills' shares, unless you type the master bill's own printed figures, which are then checked against the shares.

On a master bill filed on its own, with no house bill under it, the master's rows are the whole filing, and packages and weight are typed there.

If a draft from before this layout has a container on a house bill that the master does not list, the house bill step says so and offers to add it to the master in one click — customs refuses a house container the master does not carry (error 105).

The summary says fewer containers than the rows I entered

It counts distinct boxes. Two house bills carrying the same container number are one container, which is what goes on the filing and what customs expects to see. If you meant two different boxes, check the numbers: they are identical, and identical numbers are what "shared" means.

Declarations

"Amend this filing" is not there

It appears only on an ACCEPTED declaration. A FILED_UNTRACKED filing has to be recorded as accepted first, with its CSN — in the recording form the band at the top of its page offers while the outcome is awaited, or, for an org admin, under Change this CSN's status by hand.

Clicking Amend took me to someone else's half-finished draft

One amendment draft exists per filing, so two people cannot build rival amendments against one CSN. You were handed the one that already exists. An org admin can start their own anyway, or discard the abandoned one to free the slot.

I imported a JSON and the CSN is missing from it

Deliberately. An imported file might be a template rather than a record of this filing, so the CSN and the transmission identifiers are stripped on the way in. If the filing really was accepted, drop its acknowledgement on the page, or record the CSN under Change this CSN's status by hand (org admins).

A draft I did not create is on my declarations list

Everything in your organisation is visible to your organisation. Only the creator or an org admin can delete a draft.

Access

It says you have sent as many sign-in emails as you can today

A ceiling on the platform's outgoing mail for the day, not anything about your address. Sign in with Google or Microsoft instead — neither sends an e-mail — or ask for a link again tomorrow.

I signed in but I have no organisation

You signed up without an invitation and one is being created, or your invitation was sent to a different email address than the one you signed in with. Check the address on the invitation.

I cannot see the Admin section

It is for platform staff. Organisation administration — members, invitations, settings — is under Settings, not Admin.

Someone from support was in my account

Support staff can act on your behalf to help, and it is recorded. The session itself — when it started, when it ended, and which staff member ran it — is written to the audit log against that staff member. What was done during it is recorded on your account, since the platform is operating as you at that point, and the session's times make those actions distinguishable from your own. A banner is shown to your organisation for the whole time a session is open. See "What is recorded when support staff act on my behalf?" in Using the app.

The vessel search cannot find my ship

Three things cause this, in rough order of likelihood.

The name is spelled differently on the bill of lading than in the records. Carriers write vessel names inconsistently — abbreviations, missing prefixes, an extra roman numeral. Try the IMO number instead; the same box accepts it, and it is usually printed alongside the vessel name on the bill of lading or on the carrier's booking confirmation.

The ship is new, or rarely calls at Indian ports. Vessel names are learned from ships broadcasting their identity in Indian waters and from public reference data, so a vessel making its first call may not be known yet. The IMO number always works.

The vessel has no IMO number. Barges, coastal and inland vessels and much smaller craft do not have one, and the declaration has a code for exactly this case: transport means type 11, non-IMO vessel, with the ship's name in trnsprtMeansId instead of a number.

You should not have to work that out for yourself. When a ship register holds a hull under the name you typed but publishes no IMO for it, the search says so — naming the ship with its flag and MMSI — and offers File this as a non-IMO vessel, which sets the type to 11 and fills the name. That is a different result from "no ship found": it means your spelling was right and there is no number to find. Entering the details by hand is still there if you prefer it. See Finding the ship you are filing for.

One caveat: a register publishing no IMO is not always proof the ship has none — some flag administrations do not publish theirs. If your bill of lading or booking confirmation shows an IMO number, use it and file as type 10.

The search found several ships with the same name

That is the expected answer, not a fault. A ship's name is not a unique identifier: names are transferred between hulls when ships are sold or rechartered, and several vessels can carry the same name at the same time.

Pick the one whose port and arrival date match your bill of lading. If none of them match, none of them is your ship — check the IMO number instead. A ship customs lists no call for at any Indian port within two months either side of when it was last asked is a strong sign it is not the one you are filing for; a ship with calls elsewhere but none at your port yet is usually timing — its VCN for your arrival may not be issued yet. See When does a VCN exist at all?.

The VCN on my draft is not in the ship's list any more

The ship step, the review step, the full form and the moment before signing all compare the VCN on the filing against the calls customs lists for the ship, and each says when customs was asked. Once the filing has gone, its own page carries the same comparison for as long as the filing can still be amended — read from customs' latest answer as the platform already holds it, with Check now to ask again. A notice that the VCN is no longer among the calls customs lists means an earlier answer from customs had listed that call and the latest one does not. That is the strongest sign the check can give that the call has been replaced — a vessel substituted near the ETA is what filers report behind it — but what changed is customs' list, not your filing: nothing on the draft has been altered, and nothing stops you signing.

What to do depends on what the carrier did:

Same ship, a different call. The notice names the calls customs lists now, at your port first. Open the ship step and pick the right one with Use; the conveyance reference takes that call's VCN; if the port of reporting was still your organisation's default, it follows the call's port too, and the panel lists everything it filled.A different ship. If the carrier's revised arrival notice names another vessel, the IMO number has changed as well as the VCN. On the ship step, search for the new ship by name and choose it; its calls come back with it, and you pick the call from those.The arrival notice still names this VCN. Keep it. The enquiry is not the last word — customs decides on the filing, not on what its public enquiry lists — and the notice never blocks signing. If the answer and the arrival notice disagree close to the ETA, ask the carrier.You changed the number but not the ship. This is the shape the mistake usually takes: the new VCN gets copied off the revised arrival notice and the hull is left as it was. Nothing here says "you have changed one of two" in those words, but the tell is there. The check is keyed to the ship your filing names, so a new call typed under the old hull comes back as a number customs has not listed for this ship — and where customs does list calls for that old hull at your port, they are named beside yours and signing pauses to show you. Where this platform has already seen that VCN under a different hull, the review step and the full form say so outright: customs has listed that number under IMO …, not this ship. When the carrier substitutes the vessel, change the ship first — search the new hull by name, or use The ship has changed — find the new one — and pick the call from the ones that come back with it. Both fields move together, because a different hull is a different IMO number and a different call.Not sure it is current? Check again asks customs now, one request per click.

The substitution is what filers report; the late VCN is what the rotation dates customs returns show — 2 to 19 days ahead of arrival on the six calls observed on 7 September 2026. See I prepared the filing early for what each answer does and does not prove.

I got an email saying customs no longer lists my vessel call — what do I do?

The whole picture — why a VCN goes out of date, everything the platform checks, and what it will never do — is on When the ship changes.

Read it, then check the arrival notice. Nothing has been changed, filed or refused, and this is not a decision from customs — so it is not an emergency. But do not file it for tomorrow either. This email only goes to a filing that has already gone to customs, and if that filing has been accepted, fewer routes are open to fix it once the shipping line's manifest is filed against the same master bill of lading, and none from your side once another party's CSN is. Neither has a date on it, and both arrive with no notice.

What the email means. Your filing names one call of one ship. The platform keeps reading customs' list of calls for that ship, and the call your filing names is not on it any more. It only writes to you — and only badges the row on your CSN filing list — once customs has said that on two separate answers, hours apart, so what you have is not one odd answer from a gateway having a bad morning. (The notices inside the filing itself are quicker: the ship step, the filing's page and the pause before signing read customs' latest answer and will say it on one. They describe and never act, which is why they are allowed to.) If customs answers nothing about every ship at once, that is read as a bad moment at customs rather than as news; it is recorded against those ships, so nothing is concluded from that answer anywhere — no notice, no badge, no pause and no mail — until customs answers properly again. The most likely explanation is the one filers report: the carrier substituted the vessel near the ETA, which changes the IMO number and the VCN together.

What it does not mean. Nothing on your filing has been changed — the VCN you chose is still the VCN on it, and the platform never rewrites it. Nothing has been filed, amended or withdrawn on your behalf. Customs has not refused anything: this is its public enquiry about a ship, not a decision about your declaration, and the two are separate. You only get this email for a filing that has already gone to customs; a draft gets a badge on your CSN filing list and a notice when you open it instead.

Three things to check, in this order.

The carrier's latest arrival notice. Does it still name that ship and that VCN? If a revised notice names a different vessel, the substitution is confirmed and the notice carries the numbers you need.The line or its agent. They applied for the VCN, so they know whether the call was replaced, and with what. Worth one message if the arrival notice is not recent.Check now, on the filing's page. It asks customs again on the spot rather than reading the last answer, and shows what customs lists for that ship at your port now.

Then, depending on the filing.

A draft — where what you saw was the badge or the on-open notice rather than an email. Nothing has been sent, so there is nothing to correct at customs. Open the ship step: pick the current call with Use, or, if the hull itself changed, search the new ship by name and pick its call. Then file as normal.Accepted, with a CSN. An amendment will not fix it: ICES Advisory 37/2026 (18 September
says anything in a CSN can be amended except the VCN and rotation number. Raise it with the shipping line and your jurisdictional customs officer, and do it now — see The ship changed after customs accepted my CSN. (Until 19 September 2026 the notice offered Amend on Vessel details for this; it no longer does.)
Filed but not auto-tracked. Record what ICEGATE emailed you first — dropping the _ACK file onto the filing does it, and an acceptance sent from here is often read off customs' record before the email comes — so the filing's page can say what is still open to you; the VCN itself is the shipping line's and the officer's to settle, as above.Sent and still awaiting customs' answer. Wait for it. A filing under consideration cannot be amended. If customs refuses it, Refile reopens the same job as a fresh attempt — the same job number, a new transmission number, and nothing sent until you sign it again — and where the refusal points at the voyage it opens on Vessel details, with customs' current calls beside the field. Pick the one you want with Use: the platform never puts a call on your filing for you.

If the arrival notice still names the call customs has dropped, keep what you have and ask the carrier. Customs decides on the filing, not on what its enquiry lists, and a filing is never blocked by this check.

The other voyage email is the good-news one — Customs now lists a call for …. It goes to a draft that was saved with a ship but no VCN, the first time customs' list carries a call for that ship at your port that was not on record when you last worked on the job. It says customs lists one rather than that the port has issued one, because the list is what was read; where customs gives the rotation's registration date, the email quotes that as the day the port registered the rotation. Nothing has been filled in for you: open the job and pick the call with Use — on the ship step in the guided filing, or under Vessel details in the full form — if it is the one your arrival notice names.

I got an email saying my ship's expected arrival moved

It means customs' list of calls for your ship now gives a different expected arrival day for the call your filing names than it did when you last worked on the ship and the call. The email quotes both days — the new one and the one it moved from — the row on your CSN filing list says Arrival moved, and the filing's page shows the same beside the voyage reference, as ETA 14/09/2026 (moved from 12/09/2026 on 10/09/2026). You get one email per move, for a draft or a filing already sent.

There is nothing to amend. The CSN carries no arrival date, and the call — the VCN — is the same call it was. Nothing on your filing has been changed, and nothing has been sent to customs.

What is worth doing:

Tell whoever is waiting on the cargo. The public BL tracking page shows the expected arrival for the call a CSN on the bill names, and the day it moved from, until the ship is in, wherever the platform already holds that ship's calls — so the BL tracking link is the thing to send your customer.If the move is large, ask the carrier why. A slip of a day or two is ordinary. A long one can be the start of a reworked sailing — a roll or a substitution — and that would change your filing, because it changes the ship and the call. The carrier's revised arrival notice settles it.

How much this proves: the day is the port's record of the call, a day with no time, not the shipping line's schedule. And as of September 2026 nobody has yet seen customs revise an expected arrival day at all — the email exists to find out whether it does — so an email from it is new evidence, and no email is no sign the ship is on time. See Why did I get an email saying my ship's arrival moved?

Customs has no call for my ship yet

The check gives two different answers here, and they mean different things.

Customs lists no call for the ship at your port, but has calls at other ports. Usually timing. The port issues a VCN when the line applies for that call, and filers report that it is sometimes not on ICEGATE until under ten days before the ETA — so a filing prepared early can be prepared before its VCN exists. Leave the conveyance reference as it is, come back nearer the ETA and press Check again. If the line's arrival notice already carries the VCN, type it in: the check will report it as one customs has not listed, which does not make it incorrect, and it never blocks signing. Do not put the carrier's voyage number in its place — it is not a VCN, and it is on the checklist for a 700 refusal.

Customs listed no calls for the ship at all. A stronger signal. No call at any Indian port within two months either side of the day customs was asked is a strong sign this is not your ship: check the IMO number against the bill of lading or the carrier's booking confirmation, and search by name if it differs. If it is the right hull and simply early — a ship making its first call at an Indian port, weeks out — the advice is the same as above: check again nearer the ETA.

Either way the check itself is not a fault, and it does not stop you filing. An entry, exit or domestic-movement filing does need a conveyance reference, so if the ETA is close and customs still lists no call, ask the carrier for the VCN from its arrival notice rather than waiting.

I was refused on the voyage and the new VCN does not exist yet

Go to the carrier, rather than waiting for customs' list to catch up.

First the reassurance: the refusal consumed nothing. No CSN was issued, nothing is held against your master bill of lading, and the job is intact — so a day spent getting the right number costs you nothing at customs. Nor is filing it blank a way round the wait: on an arrival, a departure or a domestic movement the conveyance reference is mandatory, and the filing is held before it goes.

Then, in this order:

Ask the line's agent for the VCN off the arrival notice. It is the same number customs' enquiry will eventually list, and it reaches you first. Type it in. The check will report it as one customs has not listed, which does not make it wrong and does not block signing.If the agent has no number either, the port has not registered the call, and nobody can file the right one — the shipping line included. That is the one comfort in it: the line's own accepted filing is what closes a fresh CSN to you, and it is waiting on the same number you are.Check again nearer the ETA. Filers report the VCN sometimes not being on ICEGATE until under ten days before the ETA, and the rotation dates customs returns ran 2 to 19 days ahead of arrival on the six calls observed on 7 September 2026.

Two things not to do. Do not re-file on the old call to be seen to have filed — it costs another attempt and stops no clock. And do not invent a number, or put the carrier's own voyage number in the field: a number customs does not recognise as the call is exactly what the voyage codes 20 and 24, and the voyage step of the checklist for a 700, are there to catch, so you would be trading one refusal for another.

The carrier won't confirm a VCN or a cutoff, and the days I was told to expect one by have passed

You are probably not out of time — the day count you were given is very likely not a rule that exists anywhere, and it is worth separating that from the real question underneath it, which is whether the line is behind.

There is no published CSN cutoff measured in days before ETA. CBIC's own table of who files what and when puts the CSN at "before departure from the last port of call" — the same point set for the carrier's own arrival manifest — and nowhere turns that into a number of hours or days. The 5-day figures that circulate are informal practice, not a rule, and in the numbers actually observed the thing that closes your window is not a date at all: it is the line's own filing being accepted, which measured on real bills landed one to three days before the vessel was granted entry inward — see Is there a deadline for the CSN itself?. So a quoted cutoff passing does not by itself mean the window has shut; check what customs already holds against the master bill before assuming either way.

A VCN not showing up is not, by itself, evidence the carrier is at fault. The port only issues one once the line applies for that specific call, and filers report it sometimes not reaching ICEGATE until under ten days before the ETA — see When does a VCN exist at all?. What is a fair thing to press the line on is not "why is it not on ICEGATE" but "have you actually applied to the port for this call" — that step is genuinely theirs, and nobody else's filing can substitute for it.

What to do while you wait, in order:

Keep the rest of the draft finished. A CSN with the vessel and conveyance reference blank is an ordinary saved draft, not a broken one — the guided steps offer "The port has not issued a VCN for this call yet — continue without it" so the rest of the filing is not held up; see Where do I get the VCN, and is the one I picked still right?.Let the platform watch for it rather than re-checking by hand. Once a draft names a ship with an IMO number, the background reading asks customs' own VCN enquiry for that hull on its own and emails you Customs now lists a call for … the first time a call appears at your port — see What the background reading writes to you about.Do not type the carrier's voyage number, or invent one, to stop waiting. A voyage number is not a VCN and is exactly what a 700 refusal checks for; see I was refused on the voyage and the new VCN does not exist yet above if that has already happened once.Put the request to the carrier in writing, with a date on it. Since ICES Advisory 37/2026, the VCN and rotation number are the one thing a CSN can never carry in an amendment — if the vessel is later substituted, that is not something you can fix from your side at all, only the carrier and your jurisdictional customs officer can; see The ship changed after customs accepted my CSN. That is the real reason to keep pressing for a firm number rather than filing on a guess to beat a clock that, on the evidence above, is not the one actually running.

I e-mailed a file to the checking address and nothing came back

The commonest reasons, in order: it was sent from an address that has no SCMTR account, or from one your mail provider does not vouch for; it was attached to a reply to an earlier report, which goes to a person rather than being checked; it went through a forwarding rule to the shared address rather than to your own checking address; or you have sent thirty files today. Each is explained, with what to do, in Checking files by e-mail. The mailbox is read about once a minute, so give it a few minutes first.

My forwarding rule to my checking address does nothing

Gmail forwards nothing until the destination confirms it — look for a report titled "Confirm your forwarding rule" and use Gmail's code or link in it. Microsoft 365 often blocks automatic forwarding outside your organisation unless an administrator allows it. And the rule must point at your own checking address from Settings, not the shared one, which cannot tell a forwarded message is yours. See Checking files by e-mail.

The page reloaded by itself while I was filling in a filing

That is SCMTR updating, and it is working as intended. New versions are released often, and a page that was loaded before one shipped can no longer talk to the server. Rather than leave you pressing a button that quietly does nothing, the page reloads itself onto the new version and puts your work back — the same values, the same step, the same bill you were editing. A short note at the foot of the step says so.

Nothing is lost and nothing was filed. Carry on from where you were and press the button again.

It said "Server Action was not found on the server"

Same cause, older behaviour: SCMTR was updated while your page was open. Reload the page and carry on. Anything you had typed on a saved filing is still there.

If you see this message now, tell support — the version you are on should be reloading itself instead of showing it.

It reloaded, and now it says my entries could not be kept

Rare, and it means the browser refused to hold your work across the reload — usually private browsing, or storage that is full or blocked for this site.

Your entries are still on the screen in front of you. Copy anything you do not want to type again, then reload the page. If it keeps happening, try an ordinary (non-private) window.

I dropped a file to check and the page reloaded, then checked it again

Same thing, on SCMTR JSON upload and the free check at /check. A tab loaded before an update cannot reach the server, so instead of saying something went wrong, the page reloads itself onto the new version with your file kept and checks it again — you do not have to choose the file a second time. The result you see is from the new version. Nothing about the file is kept beyond that: the copy the reload carried is discarded the moment it has been checked.

If instead it says SCMTR was updated while this page was open, the reload could not carry the file — usually private browsing, or a file too large for the browser to hold across a reload. Reload the page yourself and drop the file again. Nothing is wrong with the file, and nothing was checked or kept.

I was signing when it reloaded — did my filing go through?

No. A submission interrupted this way never reached customs.

The request is refused before it is processed, so there is no partial filing, no tracking number and no duplicate to clean up. Your declaration is still a draft. Press Sign & upload again and sign again — the earlier signature was never used. On the Sign-on-ICEGATE route, download the file again before signing it.

If you want to be certain before re-submitting, open your declarations list: an interrupted submission leaves the filing exactly as it was, with no submitted version and no tracking id against it.