SCMTR JSON upload

This screen used to be called "Open a SCMTR file". It is the same screen: the name changed because "SCMTR file" read as a file belonging to this website, when it means any file from a customs filing under the Sea Cargo Manifest and Transhipment Regulations.

You have a JSON file and a question about it: is this filing going to be rejected, what does this acknowledgement actually say, what is in this manifest. Upload it. The platform reads it against the real schema, the mandatory-field rules for its reporting event and customs' full error list — which is a different thing from describing it in words, and the only one of the two that can tell you about your file.

Where it is, and what it takes

Sign in and go to CSN filing. SCMTR JSON upload is the drop target at the top of the page, beside New filing: drop a file on it, or click it to choose one. You do not go to another page first — the file opens from where you dropped it. (The checker also has a page of its own, /declarations/inspect, which takes the same files.)

It takes an uploaded .json file. There is no paste box, and pasting the contents of a filing into a chat — including into this platform's assistant — gets you a description of the format, never a verdict on your file.It works out what you gave it. A CSN declaration, an ICEGATE acknowledgement, a structural-failure response, a whole SAM / SDM, or a transhipper's or custodian's inland message — each opens in the right view. You do not have to tell it which.Nothing is filed. A CSN is never added to your filings unless you import it, and nothing is sent to customs.An acknowledgement for a filing you sent from SCMTR is recorded. Dropped on the CSN filing page, an _ACK file is matched to the filing it answers, and the outcome — accepted with its CSN, or rejected with its errors — is set on that filing straight away and explained against what was actually sent, with the one button that fixes it. An acknowledgement for a draft you filed on ICEGATE yourself is explained but not recorded: use Record a filing made elsewhere, with the file you filed beside it, so what goes on record is what customs received. If it could answer more than one of your filings you are asked which, and nothing is recorded until you pick. If it answers none of them — a partner's filing, or one made somewhere else — it is not refused: it opens in the checker and is explained there instead. (On the checker's own page an acknowledgement is only explained, and recorded when you click Record this outcome.)Any of the files a filing produces is fine: …_DEC.json, …_DECSigned.json, …_ACK.json or …_SFL.json. If you are unsure which you are holding, that is itself a reason to upload it — the file name is decoded for you in Reading an acknowledgement.A file that is not yours to file is still readable here. A CFS or a transhipper sending you their own message — F_CUCHE01_ST_… or F_TRCHE01_AR_… — is a normal thing to be handed and a hard thing to read. It opens like anything else.

Checking a file without an account

You do not need to sign in to find out whether a file would be refused. Open scmtr.io/check and drop the .json file on it — a CSN, an acknowledgement or a structural-failure response. You get the verdict straight away: how many problems customs would refuse, how many things are merely worth a look, the first problem in full — what it is, where it sits in the filing and how to fix it — and what each of the others says, grouped, with how often it occurs. The file is checked on our server and, since 17 September 2026, kept for two years like every file uploaded to SCMTR — privately, under no account since you are not signed in, never sold or used to train AI, and deleted whenever you ask. The page says so beside the drop target.

Already filed it? Under a checked CSN, each master bill links to BL tracking, which reads ICEGATE's own public record for that bill — export CSNs included — so you can see whether customs has issued the CSN, with no account.

A signed file and your DSC. A _DECSigned file carries the public half of your certificate and a signature over that file's exact contents — not your DSC's private key, which never leaves your token. Nothing in the file can sign anything else, here or anywhere. The page checks the signature the way ICEGATE does and keeps the certificate's serial number and thumbprint behind Certificate details.

To see which line each finding is on and fix it, sign in (it is free — there is no separate sign-up; the same buttons create your account). If you press the button to continue, the file is held for thirty minutes so it opens in the checker as soon as you are in — you do not drop it twice. The held copy is deleted when it opens, or after the thirty minutes if it never does; the file itself is kept for two years, like any file you check. If you are already signed in, /check takes you straight to the full checker. A SAM / SDM is not sent anywhere from /check: sign in and open it under Shipping line filing instead.

Checking a file by e-mail

Where it is switched on, the same check works by e-mail: send the .json files as attachments to the checking address shown on your CSN filing page and in Settings, from the address you sign in with, and the full check comes back as a reply. A CSN and its acknowledgement sent together are read together; an acknowledgement's report names the filing it answers; ICEGATE's refusals that arrive as e-mail with no file can be forwarded too; and your own checking address lets a forwarding rule send ICEGATE's replies in automatically. All of it — limits, what the button opens, and why a reply might not come — is in Checking files by e-mail.

Fix it here, or keep it here

When a checked CSN has problems, Fix in the editor copies it into a draft of your own and opens the form on the first problem. When it has none, Keep it here does the same without the jump. Either way you can download a corrected file at any time with Download JSON and file it however you usually do. If problems are still outstanding, Download and Copy ask first — they name what customs would refuse and offer Show me what to fix before Download anyway — and the Email this file button under a checked file says the same in the message it sends, so nobody receives a file believing it is filable when it is not. When ICEGATE answers a file you filed yourself, bring that file and its acknowledgement back through Record a filing made elsewhere on the CSN filing page (a filing sent with Sign & upload takes its acknowledgement on the CSN filing page's drop instead), so the CSN number and the outcome sit on the filing and an amendment later can be built from it. The job number and control number in the draft are new ones — see the note under the button for why.

Can I e-mail the file I checked?

Yes, if you are signed in. Email sits beside the result, and sends the file you dropped — under the name you dropped it as — with what the check found, to whoever needs to see it: the console agent whose CSN it is, the line you are reconciling against, the customer who sent it to be looked over.

The message says what it is. A file checked here has been nowhere near customs on your account, so nothing in it claims a verdict and there is no customs tracking link on it. Everything else works as it does for a filing — a "View online" page of its own that you can withdraw, the same recipient book, the same daily limits. See Sending a CSN to others.

What you get back, by file

A declaration — rendered in full, and checked against the field rules for its reporting event. Findings are listed in two tiers — red for what customs refuses and Sign & upload blocks on, amber for what is merely unusual and blocks nothing — and each one jumps to the field or the row it belongs to. A filing can read Valid and still carry a row of amber. See What the app's checks mean. An export (SCX) also gets the checklist "What customs checks on an export" — eight lines, each clear or naming what is wrong, drawn from the same red and amber findings; see exports: filing an SCX. On a filing carrying several master bills the record opens as a table, one row per consignment, and a problem in the list opens the row it sits in. If the file's own name disagrees with the identifiers inside it, the screen says which parts differ and what the name built from the file would be. If any character in the file is not plain text, a notice lists each one by line and column with the field it sits in and what to type instead — the line is the one ICEGATE's "File is not UTF-8 encoded" email names, though the email's "position" appears to count bytes from the start of the file rather than characters along the line; it is red when a character could not be read at all, because then the file is not UTF-8 and ICEGATE refuses it. If the job number and date look already used, a notice says so before any field. It appears when a bill of lading is dated after the job date, or when your organisation already sent a transmission here under the same sender ID, control number and job date. These are the files ICEGATE refuses by e-mail with "Header validation failed … The Control Number has already been processed" — see Reading an acknowledgement and It says the job number and date look already used at the end of this page. The VCN is also checked against the calls customs lists for the ship — see Is the VCN on this file the right call? below.A file that is not SCMTR JSON at all — told what it is rather than "not valid JSON". An IGM in the old flat-file format (the HREC… header line and <consoligm> sections ICES took before SCMTR — one was dropped here on 2026-09-23) is named as such, with what replaces it: a SACHM22 CSN or a SACHM23 SAM, both JSON, from your own software. A JSON file with a comma or bracket missing gets the line and column of the fault and the text around it, so the place can be found in the software that wrote the file — the parser's own message gives only a character count from the start of the file.An acknowledgement — read out error by error against customs' published code table, so each code arrives with what it means and what to change rather than as a number. For one of your own filings, the outcome is recorded against it as well (see above).A structural-failure response — the same, for a file customs refused before business validation.A SAM / SDM — opens as a searchable, editable table of its lines. See Working with a shipping line filing.A transhipper or custodian message (TRCHE01, CUCHE01) — read out block by block with every field named and explained from ICEGATE's own guide, and the reporting event spelled out (SF as stuffing report, ASR as allowed-for-shipment request, and so on). Read-only: neither message is yours to file, so there is nothing to validate or send. Keep one and it is offered back next time under Files you kept. See Reading a transhipper or custodian file.

What does this field mean? Every label explains itself

Every label in the opened filing carries a small ?. Hover it with a mouse, or tap it on a phone, and it tells you what the field is in plain words, the key it has in the JSON file (so you can find the same value in the file you uploaded), whether the reporting event treats it as mandatory or optional, and — where the screen has re-formatted a value — the wire format the file actually carries (dates as YYYYMMDD, times as THH:MM, a PAN with its PAN: prefix). Block headings have the same: what "Packages & measures" or "Location & customs" is for, and its key in the file.

The same explanations sit on the table view's column headings, on the badges (the reporting event, Valid, the two finding counts, Signed, Read-only), on an acknowledgement's terms (CSN, MCIN/PCIN, the transmission id, an error code, how confident the match to your filing is), and on the four kinds of file beneath the drop target — each of those tells you what the document is and how its filename usually ends. Tips open on hover, on keyboard focus, or on a click that pins them open; on a phone they open as a sheet from the bottom of the screen.

Where is this bill now? Track it from the filing

A filing with several master bills opens as a table, and every master row carries a track icon that opens the public customs lookup for that bill at the filing's port of reporting — what ICEGATE holds against it right now. A filing with one master has the same lookup as Track at customs in the header of its own page. See Tracking your cargo.

Is the VCN on this file the right call?

Filers report ICEGATE accepting a CSN on last voyage's VCN. As far as we can see it does not check, when a CSN is filed, that the VCN is the ship's current call. So a declaration opened here can have its VCN checked against the calls customs lists for its ship, the same way the platform checks its own filings before they are signed. It is a live question to ICEGATE, so it is asked when you ask: press Check the VCN with ICEGATE, and the line fills in within a few seconds. When you are amending, deleting or filing the CSN from the same page, it is the first of the three steps Check with ICEGATE answers — the call, then whether customs holds the CSN, then what you can do. If customs has been asked about that ship in the last fifteen minutes, that answer is reused; if customs does not answer in time, the line uses the last answer on record and says when it was.

Amber: customs lists a different call of this ship at your port. This is what last voyage's VCN looks like. Customs' list covers sixty days either side of today, so the ship's previous call has usually dropped off it, and what is left is the current call beside a number customs does not list. The line names the call customs does list. The same tone is used when customs has stopped listing a call it listed before, and when the VCN is a call at a different port from the file's port of reporting.Amber: the VCN may be an earlier call of this ship. A ship that calls at your port every week or two keeps last voyage's call on customs' list, so that VCN is listed and looks fine. What gives it away is the file's own date: the call it names had arrived before the file was made, and customs lists a later call of the same ship at the same port that is nearer that date. The line names both, because a filing made after the ship berthed rightly names the call that has arrived — if that is your file, the VCN is right. This rule rests on one live enquiry (September 2026), in which a frequent caller had five calls at the same port inside customs' answer, so last voyage's call was still listed; it has not been tested against a refusal. Expect it to be amber harmlessly on a weekly feeder whose CSN was filed a few days after berthing, once the next call is nearer the file's date than the one that arrived — compare the arrival notice before changing anything.Against the cargo's own arrival. An import's file also gets the Arrival card under this line — the day the line gives for the master bill, with its countdown, asked as soon as the file is checked. Once you have pressed Check the VCN with ICEGATE, the card says whether the VCN's call fits that day, and names the call that does when it does not (see When will it arrive?). The line's day is a better guide than the file's own date: it is the day the cargo itself arrives.Neutral: customs does not list the VCN yet, or lists no call at your port yet. That is often timing — customs may not have issued the call — and a number customs has not listed is not a number it refuses.Neutral: the file is older than customs' list. A file dated before the first day customs' answer covers cannot be judged: the call it named has left the list, and the ship's next call at the same port would look exactly like the amber case. The line says so rather than warning.Green: the VCN is a call customs lists for this ship, on an answer no more than fifteen minutes old. On an older answer the line keeps the fact and drops the reassurance.

It is a warning, never a refusal: nothing is filed from this page, and only ICEGATE decides whether it accepts a VCN. What to do about an amber line depends on the file. On an unsigned file, correct the VCN before it is signed and sent. On a signed one that customs has already accepted, an amendment is not the fix: ICES Advisory 37/2026 (18 September 2026) says a CSN amendment can change anything except the VCN and rotation number. Raise it with the shipping line and your jurisdictional customs officer, and do it before another party's CSN on the same master B/L is accepted if you can, because customs' error list has a refusal for changing a CSN linked to another (320), though none has been seen on a reply yet — the line's manifest no longer does, since the same advisory, but it narrows what is left. Either way, confirm the VCN with the shipping line or its agent first. See The vessel call number (VCN), start to finish.

The container numbers are checked too, as on every filing: a number that fails its check digit is listed in amber, and a house bill's container missing from its master bill in red. Neither check can tell whether a correctly formed number is the right box — only the shipping line's manifest shows that, and it is usually on customs' record only near arrival.

Does customs hold this version of the file?

A CSN dropped here without its acknowledgement gets one more line: Does customs hold this version of the file?, with a Check with customs button. Nothing is sent to customs until you press it — a large consolidation is dozens of lookups, and most people drop a file only to read its field checks. Pressed, it reads ICEGATE's public enquiry — the same one the tracker and the customs-record check use — for a filing by this file's submitter on every master bill of lading in the file, six at a time, and compares what customs holds with what the file says. A seventeen-bill file is three lookups; the count climbs as each lands, and the bills already answered appear while the rest are asked. Above them sits one line for the whole file — CSN 1454036 of 10/09/2026 · 17 bills asked · 14 identical · 3 held differently at customs — and the bills that need reading come first; the ones customs holds exactly as the file has them fold away behind their number. The answer shows the time it was checked; Check again opens two minutes later, because asking sooner returns the same answer. Every bill links to its own page on BL tracking.

Green — customs holds this version. A filing by your PAN is on record for the bill, and every value the record carries agrees with the file: the ports, the cargo type and movement, the transhipper, the weights, the packages and every container. The line names the filing date and the CIN. It says nothing about the parties or the goods description, because the public record does not publish them.Amber — customs holds a different version. A filing by your PAN is on record and it does not say what this file says. The line lists what differs, disagreements first — and the dates say which kind of difference it is. Customs' record carries the date of the latest version it accepted, not of the original; so when that date is after the file's, the line says so plainly: customs accepted an amendment or a re-filing on 10/09/2026, the day after this file was made — this file is the version from before that. That is the ordinary case for a file kept from the day it was filed: a line agent's seventeen-bill CSN had three bills held differently, and all three were the corrections an amendment made the next day (a destination moved from a Nhava Sheva CFS to a Mundra one, and a bill reclassified as transhipment). Where the file is dated after customs' copy, the line reads it the other way — an amendment not yet accepted, or a draft made after filing. Beside each coded value the line says what the code means — Mundra (INMUN1) — a location under it, Transhipment — so a moved destination reads as one rather than as two strings.Grey — a filing like this one is on record, but not this transmission. The values agree, but the record's transmission id belongs to a different acknowledgement we hold, or customs filed its copy before this file was made — this file is a copy of a CSN that was already filed.

Customs taking its copy days after the file's date is normal, not a warning. A file's date is when it was made; it is signed and uploaded when you get to it. Two files in our samples were made on 5 September and uploaded on 9 September, and their own ACK answers exactly the filing customs holds. The check shows both dates side by side and holds nothing against the gap.

Every answer shows your file beside customs' record. Each value ICEGATE's public record carries is laid out in plain words — vessel and voyage, the master B/L, each container, each house B/L — with your file's value, customs' value, and one word for the result: Same, Same, rounded (customs keeps weights to two decimals), Different, Blank in your file or Not with ICEGATE. Differences open first; the values that agree are one click away.

Grey — nothing on record by your PAN. The public record lists accepted filings only, so the file was refused, never sent, or filed under another port or bill date — or, measured once, the bill is in the gap after an accepted update amendment, when the record went blank for a while (see an accepted amendment can empty the record). The line says whether anyone else — the shipping line, another forwarder — has filed on the bill. What to do about it is the next section.

It is read from a public page, for every master bill in the file — a shipping line's CSN for a whole vessel has two hundred — six at a time, with a Stop button while it runs. It stops at the first three bills that need your attention (held differently at customs, another upload, or not on customs' record), because those are what you fix first, and if customs holds none of the first six it stops there: the CSN is not filed or not accepted yet. Every bill customs confirmed is remembered for twelve hours, so after you fix the file and check again, only the bills that changed are asked — and the check carries on from where it stopped. If you look many files up in a short time it pauses and says so; wait a few minutes and press Check again. And for a file checked here it decides nothing: only the acknowledgement does. A file uploaded with its acknowledgement does not ask, because the acknowledgement has already answered. (A filing sent from SCMTR is read off the same record under stricter conditions — the transmission id, a single filing on the bill, the cargo agreeing — and can turn accepted from it; see After you file.)

BL tracking shows one thing and my file says another — which is right?

Both, usually. BL tracking shows what customs holds now; your file is what you sent then. If you amended after filing — or customs holds a re-filing — the two differ exactly where the amendment changed something, and the file is the older of the two. Drop the file on the tracking result (Is this what you sent?) or on the checker and press Check with customs: it lays every bill in the file beside the record, names the date customs accepted the later version, and lists what changed. The tracking page's own green line — all filings on record agree with each other — compares the filings customs holds against one another (your CSN against the line's manifest), not against your file; the two are different questions, and the checker answers the second.

It says "Customs' record holds no filing by" my PAN — what does that mean?

It is a grey notice, not an error and not a refusal. It means that when customs' public enquiry was asked about this file's master bill of lading, at this file's port of reporting, for this file's event (arrival or departure), it listed no accepted filing under the PAN this file was filed by. It is not a decision on the file.

The sentence after it comes in two versions, and they say different things:

"Nobody has filed on this bill at this port yet." Customs lists no accepted filing on this master bill number at this port for this event, by anyone and on any bill date — not the shipping line, not another forwarder. A different bill date on your file is therefore not the explanation here; the enquiry lists every date it holds for the number."Other parties have filed on this bill." Somebody else's accepted filing is there — their PAN is listed underneath as Also on record for this bill — and yours is not. That is usually the shipping line. A different port or bill date on your file can explain this one.

Why your filing is not listed. Go through these in order; the first two answer most cases.

It was never sent. A draft that was saved, downloaded or signed but never uploaded to ICEGATE is not filed.It was sent and refused. A refusal never appears on the public record — only in the acknowledgement file ICEGATE returns, or in its email. If you have the _ACK file, check it here together with the filing, and it will say which.It was sent and not yet accepted. Nothing is listed until customs accepts it. How soon an accepted filing appears in the enquiry has not been measured.The file does not say what was filed. The question is asked with the master B/L number, port of reporting and arrival-or-departure exactly as this file carries them. A master number written differently from the filed one — a carrier prefix added or dropped, a house bill number in the master field — the wrong port of reporting, or an arrival where a departure was filed, asks about a different bill. Look the bill up on BL tracking with the details from the acknowledgement to be sure.It was amended a moment ago. Measured once: the record went blank for a while straight after an accepted update amendment (see an accepted amendment can empty the record).

What to do next.

You hold an acknowledgement that says accepted, with a CSN number. The acknowledgement is customs' answer and it stands; for a file checked here, the public enquiry decides nothing (a filing sent from SCMTR is a different matter — its acceptance is read off that same record, under conditions After you file sets out). Record it on the filing and do not file the same bill again — a second filing on bills customs holds is refused as a duplicate (122/123). To change it, amend it; or, before the shipping line's manifest, delete it first — the route ICES Advisory 38/2026 opens, on which read deleting does not free the bill of lading before relying on it.The acknowledgement says rejected. Fix what it names and file again — see Why customs rejects a filing.It was never sent. The CSN still has to be filed for this bill. If the notice also said nobody has filed, no shipping line's filing stands in your way yet.You do not know whether it was sent. Find the acknowledgement first — check the filing's status here, and the mailbox ICEGATE sends your acknowledgements to — before filing anything again.

Upload the acknowledgement and the filing it answers

This is the step people skip, and it is where most of the value is.

An acknowledgement names positions in a document it does not contain — a path and an error code, with no cargo in sight. On its own you get the errors; paired with the declaration they refer to, every error is anchored onto the block, row and field it actually names, which is the difference between "error 122 at some path" and seeing the bill of lading it is complaining about.

So upload the acknowledgement, then use Upload the CSN this answers to add the declaration — the file whose name ends in _DEC or _DECSigned. Never upload only the declaration when the file you are actually holding is an acknowledgement.

Which file is it asking me for?

The screen names it before asking: The CSN this answers is named F_SACHM22_SCE_…_DEC — all six parts of the name, each with how sure it is. A part is read off the acknowledgement's own name where ICEGATE kept it (ICEGATE names its reply after the file it answers), recovered from the acknowledgement's body where the file was renamed on its way through a mailbox, and shown as a gap where it cannot be recovered at all. The job number on a rejection is the usual gap, and five known parts still narrow a folder of near-identical names down to one or two files.

A CSN that is not the one the acknowledgement answers is refused, not warned about. Every error would otherwise be anchored onto blocks customs never saw, sending you to fix a field that was fine. The refusal says which identifiers disagree — sender, control number, job number, or the two file names themselves.

"But this is my consignment." Usually it is. The commonest way to hold two files that will not pair is to have filed, been refused, corrected and filed again: the second message is the one customs answered, the first is the CSN still in your folder, and both describe the same containers. Where the screen can see that — a master bill of lading in common, and every disagreement about which transmission rather than about the cargo — it says so, and names both job numbers so you know which of the two files to go and find. See One consignment, several transmissions.

If the filing was sent from SCMTR and you are already on it, none of this is needed: drop the acknowledgement onto the filing itself and it is recorded and explained there. A filing you filed on ICEGATE yourself is recorded through Record a filing made elsewhere with the file you filed — see After you file.

Why the assistant will not read your JSON for you

Ask the assistant on this site to check, validate or review a filing and it will send you here instead. That is deliberate, and it is not a limitation worth working around.

The assistant answers from prose — reference pages about the message and the regulation. It cannot see your file, and a confident verdict produced from prose about a document whose rejection costs you a day is worse than no verdict. The inspector parses the actual file against the actual rules. One is a description of the format; the other is an answer about your file.

What the assistant is good for is the question underneath: what error 122 means, why a filing gets rejected for a container count, which reporting event you should be filing, what a field is asking for. Ask it those and it answers from the same reference material published at Reference and Help. Ask it "is this file correct" and the honest answer is: upload it.

Related

Red versus amber, and why something is one rather than the other: What the app's checks meanWhat the three files are and how to read a verdict: Reading an acknowledgement from customsWhat each rejection code means: Why customs rejects a filing and ICEGATE error codesOpening a carrier's manifest: Working with a shipping line filingRecording a filing made in other software, and every other route into the app: Using SCMTR

It says the job number and date look already used

Two things put that notice above the fields, before anything else is checked, because ICEGATE refuses either by e-mail as "Header validation failed … The Control Number has already been processed" without reading a field:

Your organisation already sent a transmission under this sender ID, control number and job date. If that transmission was accepted or is still waiting for its answer, a refile has to carry a new control number, and Refile gives it one. If it was refused, the number is free again — a refusal does not use it up — and Refile keeps it.A bill of lading is dated after the job date. Customs reads that as a job that cannot yet exist.

The notice is a warning, not a refusal: the file can still be downloaded. Whether ICEGATE also compares the job number itself against earlier ones is not settled by anything on record, so a refile that keeps its job number may still draw the e-mail — see Reading an acknowledgement.