CFS filing

If you run a CFS, an ICD or a terminal — or move export cargo inland under your own TP bond — your SCMTR reports are not a CSN. A custodian files CUCHE01 (registered as ACU): the stuffing report (SF), its cancellation (SFCN), the stripping report (ST), and the vehicle's departure time (DT) and arrival time (AT). A transhipper files TRCHE01 (registered as ATP): the allowed-for-shipment request (ASR), the inland departure (DP) and the arrival (AR). Many CFSs hold both registrations on one ICEGATE ID.

CFS filing — the pill of that name in the header for an organisation whose business type is CFS, ICD or terminal operator (Settings → Workspace), and a link on the CSN filing page for everyone else — makes, checks and signs these reports. This page covers how.

How do I file a stuffing report?

Press Container stuffed. The report opens laid out for a stuffing: your yard (filled from your last report), the job number (the next free one, already filled), the container, and the shipping bills stuffed into it. Type the container number, its size, the seal and the time it was stuffed and sealed (Now fills the present minute, in Indian time), then for each shipping bill its PCIN, number and date, and the package numbers that went into this box. The package count and the container's total are worked out from the ranges.

Customs refuses a second container on one stuffing report (CCB15), so a stuffing report holds one. For the next box of the same bills press Next container of the same bills: a new report opens with the bills and their PCINs carried over and each bill's package numbers continuing where this box stopped — packages 1 to 5 in the first, 6 to 10 in the second, as ICES Advisory 41/2026 sets it out.

What is checked as I type?

Every field of a custodian's report, against ICEGATE's own JSON Schema for it — the schema embedded in the CIM Custodian guide, which is what ICEGATE's first-level validation runs before anyone reads the file: what it requires, how long each value may be, the smallest and largest numbers, and the form of each code and date. The transhipper's reports are checked against their guide's tables, since no schema was published for them. And every business rule customs has published a refusal code for, on the reports the code is published for, that the file alone decides:

one container per stuffing report (CCB15), and a stuffing report with no PCIN (CDB04); party type C on a stuffing report (LCB03), ATP on a transhipper's (LCB04);on a stuffing report, a package range that runs backwards (CDB10); one PCIN per ASR, and none missing (CDB05); a container listed twice on a stuffing report, an ASR, a DP or an AR (CCM02).

Beside those, amber: one shipping bill marked both full (F) and part (P) — customs publishes CDB19, "Shipment Type is not valid for all records for PCIN", and that it means this is our reading of its words — a report with no container, a count that disagrees with its range (CDB15), the same packages on two lines, a PCIN that is not shaped like one, a container number whose check digit is wrong, a time later than now, a date that is not on the calendar.

Red is what ICEGATE's schema or a published refusal code says outright; amber is worth a look. No report made here has had customs' answer yet, so none of these has been seen refused through SCMTR.io. Each problem names its field, takes you to it in one press, and where the fix is certain — CN for the C ICEGATE's own sample uses, P for a bill that does not start at package 1, a range turned the right way round — fixes it in one press.

Why does it say CN when my old files say C?

ICEGATE's schema for the stuffing, stripping and arrival reports accepts the container type only as CN (or B, W, TE, DPL, CH, BL, BB). The guide's own stuffing sample, and many files written from it, send C — which that schema does not accept. The transhipper's message is the other way: its guide's pattern takes C. CFS filing writes each the way its own message wants, and turns one into the other when a report follows from another.

How do I sign it and send it?

Press Sign with your DSC and save. The scmtr DSC Signer on your computer signs the file with your class 3 DSC — the same signer the CSN uses — and the signed file is saved to your computer under the name ICEGATE reads, F_CUCHE01_SF_<your ICEGATE ID>_<job>_<date>_DECSigned.json. A stuffing, stripping or cancellation report must be signed: ICEGATE's own failure sample is an unsigned stuffing report refused with ERR100, missing required properties (["digSign"]). The custodian guide says every file is signed; the arrival-time schema alone does not demand it, so sign the departure and arrival times too unless ICEGATE has told you otherwise.

Customs takes these reports only through ICEGATE's API utility, with an API key your organisation generates on the ICEGATE portal (ICES Advisory 41/2026). Upload the saved file there. SCMTR.io does not send it for you.

Customs answered — how do I read the reply?

Drop the _ACK or _SFL file on the report, or on the CFS filing page, which lays it on the report with the same job number. An acknowledgement marks each block 00 Successful or with a code; the report shows Customs accepted it — for a stuffing report the officer then approves it container by container (ICES Advisory 41/2026) — or each refusal with ICEGATE's words, the guide's meaning, what to do, and a link to the field it is about — and the field shows it too. A structural failure says which field the schema refused. A departure's reply carries the CIM number; the DT, the AR and the AT quote it, and it carries into the next report only from an accepted reply. A reply whose marks cannot all be read is shown as unclear, never as accepted.

What comes after a stuffing report?

The order is customs' own (ICES Advisory 41/2026): the stuffing report, acknowledged and then approved by the officer container by container; the transhipper's ASR, one per shipping bill; the DP for each vehicle, whose reply gives the CIM number; the custodian's DT when the vehicle leaves; the AR at the next station; and the AT there. Under What comes next, each report offers the one that follows, carried over from it: an ASR with every bill of the stuffing report, a DT with the DP's vehicle, containers and CIM number. Nothing needs typing twice.

Can I check a file my own software made?

Yes. Drop it on the CFS filing page — signed or not, a CUCHE01 or a TRCHE01. Two things are said about it. First, what ICEGATE would make of the file as it arrived: a number written as text, a date in the wrong form, a missing signature — what ICEGATE's own schema checks before anyone reads the file. Then it opens as a report, checked like one made here, and the file saved from it writes each of those right. Anything the file carried that the guides do not name is listed rather than dropped, and old spellings ICEGATE's samples use (documentNumber, equipmentQUC, containerID) are read and written back the schema's way.

Is the transhipper's side as certain as the custodian's?

No, and it is marked Beta for that reason. ICEGATE published JSON Schemas for the custodian's reports, but none for the transhipper's — its guide's tables are the only source, and they contradict themselves in places. So the transhipper's rules are amber, bar the refusal codes customs publishes. The file follows the guide where it differs from the custodian's: a container is C, a shipping bill SB, the event date and the expected arrival are written YYYY-MM-DDTHH:MM, and the expected arrival's key is spelled as the guide prints it, expectedTimeOfArriva.

I am a forwarder and a CFS sent me their file

Then it is not yours to file. Open it on SCMTR JSON upload to read it — see Reading a transhipper or custodian file.

Related

ICES Advisories 41/2026 and 42/2026 — the order and the contents, in customs' wordsEvery field a transhipper or custodian filesWhich error list does my code come from?