DEV Community: iCustoms

The NCTS and CDS Workflow That Survives Pre-Lodgement

iCustoms — Mon, 21 Sep 2026 07:26:19 +0000

Pre-lodgement RoRo journeys are unforgiving. The Goods Movement Reference will refuse the pairing if either declaration is missing. Sequencing matters.

Step one: classify the movement

Direct clearance or transit? The answer picks the primary system. The UK NCTS vs CDS guide has the decision framing in one image.

Step two: file the transit declaration first

For transit journeys, NCTS goes in early so the movement reference is live.

Step three: file the CDS entry

Direct clearance leg or destination clearance gets its own CDS entry.

Step four: bind them under the GMR

The Goods Movement Reference is where both records meet. Both must be valid at the moment of creation.

Step five: monitor discharge and clearance separately

Discharge closes NCTS. Clearance closes CDS. Two events, two evidence trails.

Ready to run this without duplicating data entry? Watch a demo.

Building an NCTS Transit Declaration: The Workflow

iCustoms — Fri, 18 Sep 2026 07:19:30 +0000

How should the workflow run?

The workflow runs in stages that mirror the NCTS5 data model. Skipping stages introduces validation errors. Repeating the same stage order across all filers produces consistent, low-rejection output.

Stage 1: Access and readiness

Confirm Government Gateway credentials, EORI, user permissions, and software version. Validate that the software uses the NCTS5 data model.

Stage 2: Consignment mapping

Map the load into consignment, house consignment and goods item layers. Every commercial invoice becomes a house consignment. This NCTS Phase 5 filing guide walks through the mapping in operational terms.

Stage 3: Commodity coding

Populate a six-digit HS code for every goods item. Descriptions never substitute for codes.

Stage 4: Route and offices

Confirm office of departure, offices of transit where applicable, and office of destination. Check that the route falls within the guarantee's binding conditions.

Stage 5: Guarantee and IE015

Attach the guarantee reference and access code. Submit IE015 to the office of departure.

Stage 6: TAD and release

Once validated, the office issues the MRN and generates the TAD. The document travels physically with the goods and is presented at each transit office.

Want to see the entire workflow inside one platform? Watch a demo.

Building a Clean EU Transit Workflow End to End

iCustoms — Thu, 17 Sep 2026 07:25:51 +0000

Think of an EU transit movement as a small state machine. Every state has entry conditions and exit conditions. Miss an exit condition and the movement stalls with a guarantee locked behind it.

The four states that matter

Declared, Released, In transit, Discharged.

The transit discharge process walks through what each transition needs and why the last one is the one most operators underestimate.

State: Declared

Data is validated locally, guarantee cover confirmed, declaration lodged at the office of departure.

State: Released

MRN issued, TAD printed, driver dispatched. Do not overwrite the record. From here it becomes the reconciliation anchor.

State: In transit

Border-crossing notifications are received at each office of transit. Alert on any missing notification within a defined window.

State: Discharged

Arrival notification, unloading remarks and discharge message. Only at this point can the guarantee be marked released internally.

Instrumentation

Every transition is a metric. Time to release, time to first transit notification, time to discharge, age of open MRNs. Miss the last two and you are flying blind.

Run declarations, guarantee tracking and discharge in one system. Watch a demo.

Building a Pre-Boarding Workflow for GB to EU Trailers

iCustoms — Wed, 16 Sep 2026 07:49:39 +0000

The workflow in four gates

A trailer becomes ready to board only when four gates pass in order: export declaration lodged, transit MRN issued, import declaration pre-lodged, and safety and security reference attached. Anything less is an incomplete GMR.

Gate-by-gate logic

Gate one closes when CDS accepts the export declaration and returns a valid MRN. Gate two closes when NCTS Phase 5 issues the transit MRN and the departure office releases the movement. Gate three closes when the EU-side import declaration is pre-lodged. Gate four closes when the safety and security data — embedded or separate — carries a valid reference. Full sequencing is documented in this 2026 UK transit customs handbook.

Where the workflow breaks

Most rejections come from parallel steps started too early. Filing a GMR before the transit MRN exists produces a stub reference that fails at the port. The fix is a strict gate order and a single owner per GMR.

FAQ

Should the driver ever hold a paper backup?
The MRN barcode on the TAD is the operational document; a driver-side copy is common practice.

Can gates run in parallel?
Some can, but the GMR should not be committed until every gate has closed.

See the whole workflow in one screen. Watch a demo with iCustoms.

Designing an NCTS Phase 5 Declaration Workflow That Does Not Break at the Border

iCustoms — Tue, 15 Sep 2026 07:50:05 +0000

Workflow shape

Phase 5's rejection pattern is upstream by design. A workflow that validates house consignment structure, commodity codes, GRN state and party EORIs before IE015 leaves your system is cheaper than one that reacts to IE056 after submission.

Checkpoints

Manifest ingestion → build consignment and house consignment tree.
Line normalisation → force six-digit HS codes.
Guarantee check → confirm GRN, access code, EORI and available balance.
Party validation → verify EORI shape and status.
Optional safety and security → only when the full dataset is present. The end-to-end sequence is captured in the iCustoms NCTS Phase 5 declaration process guide.

Retries and dead letters

Route IE055 and IE056 into a queue with the field pointer parsed. IE051 is a policy decision by the office of departure, not a retry candidate — surface it to a human.

Ship it

Watch a demo to see how the workflow behaves under real traffic.

The Modern TSS Declaration Workflow With AI in the Loop

iCustoms — Mon, 14 Sep 2026 07:37:47 +0000

The old flow

A broker receives PDFs. They re-key fields into TSS. They pick a commodity code. They validate mentally. They submit. Errors surface as rejections and get chased manually.

The AI-in-the-loop flow

Documents land in the workflow queue. Extraction reads invoices, packing lists, and transport documents. The validation engine checks format, consistency, and TSS constraints. Classification proposes a code with alternatives. The reuse layer flags known lines. The broker reviews, corrects low-confidence fields, and submits.

Why "in the loop" matters

A person still owns risk decisions, procedure choice, and communication. This is the reallocation model at the centre of the what AI can and cannot do in TSS piece.

Handling low confidence

Route below-threshold fields to a review queue. Do not silently accept. Every override enters the audit trail with reason and reviewer.

Handling peaks

Supplementary declaration deadlines create surge weeks. Design the queue for horizontal parallelism and pre-warm the review team. This is where AI pays back its licence.

Handling first-time products

Skip auto-reuse. Send to a specialist. Create a fresh product record with attributes for future recognition.

What success looks like

Fewer rejections. Faster median declaration time. Stable staff numbers absorbing higher volumes. A clean audit trail on every submission.

Design your own workflow with us. Watch a demo.

Building a Multi-Client TSS Declaration Workflow

iCustoms — Fri, 11 Sep 2026 06:51:45 +0000

The workflow shape that scales

A declaration workflow that scales across clients looks less like a form and more like a pipeline: ingest → validate → enrich from client product master → assemble → submit → route response.

Ingest with source discipline

Client invoices arrive in varying formats. The ingest layer normalises them against the client's written data specification. This upstream discipline is the difference between a review workflow and a re-key workflow.

Enrich per client, not globally

Commodity codes, standard descriptions, supplier records, and route templates live per client. Cross-contamination is the failure mode most single-trader systems produce when pushed into multi-trader use. The scaling TSS declarations breakdown lists per-client reference data as a core requirement.

Validate before submission

Client EORI, UKIMS position, item count under 99, description quality, origin documentation. Rejections after submission cost far more than pre-checks in front of it.

Route responses back to context

Every response — acceptance, rejection, amendment request — should return to a queue tagged with the client and the source document, not to a shared inbox.

Observe by client

Dashboards need per-client cycle times, rejection rates, and month-end multiples. Aggregate views hide the accounts costing you the most.

See this workflow running in a live multi-client environment. Watch a demo.

Designing the TSS Submission Workflow Around Your Data

iCustoms — Thu, 10 Sep 2026 09:08:56 +0000

The workflow decides the outcome

A TSS integration succeeds when the workflow around it fits the way declarations actually arrive. That means designing for uneven load, exceptions and human review before you finalise the code path.

Model the tenth of the month

Supplementary declarations concentrate on a monthly deadline. A workflow that handles average load but not peak load will collapse when it matters most. Size the queue for peak, not average. The portal to API decision guide explains why peak handling is the deciding metric for many organisations.

Split lanes by movement type

Standard goods take one lane, controlled goods take another, and exceptions have a manual review path. Trying to run all traffic through one queue removes the operational advantages hybrid gives you.

Keep humans in the loop where it matters

Automated does not mean unsupervised. Route exceptions and rejections to a queue a person owns, with an SLA that fits the declaration deadline.

Make retries observable

If a rejection retries silently and fails again, nothing improves. Every retry event needs a log, a status and a threshold at which a human is paged.

Instrument every stage

Time-to-submit, time-to-response, rejection rate by field, retry rate by cause. These numbers tell you where the workflow is weakest.

See a full TSS submission workflow with queue design and exception handling. Watch a demo.

Designing a Reliable TSS Declaration Workflow

iCustoms — Wed, 09 Sep 2026 07:43:01 +0000

A dependable TSS pipeline looks the same across most stacks.

Stage 1: Ingest

Pick up supplier invoices, packing lists and transport documents from email, SFTP or a shared drive. Normalise into a single schema before anything else runs.

Stage 2: Enrich

Look up party data, commodity codes and licences from your master data. If the tool cannot reach your ERP, half the value is gone. For a broader map of the workflow, this TSS software workflow reference is useful.

Stage 3: Validate

Commodity code exists, currency and digit count are correct, document codes reconcile with tariff requirements, mass and package counts agree with the invoice.

Stage 4: Submit

Programmatic submission with idempotent retries and clear correlation IDs back to the source document.

Stage 5: Handle exceptions

Failures route to the right person with enough context to fix them, not just a raw error code.

Stage 6: Audit

Every step, every change, every submission timestamped and exportable.

Map this workflow against iCustoms. Watch a demo.

Modelling a Declaration-to-GMR Workflow

iCustoms — Tue, 08 Sep 2026 07:20:42 +0000

Stages as states

Treat the movement as a state machine.

declarations_created
mrns_issued
gmr_built
checked_in
embarked
inspection_resolved ## Transitions

Each transition depends on the previous state. gmr_built cannot occur without at least one mrn_issued on the load. checked_in cannot occur without a valid GMR whose vehicle and trailer match the physical unit at the barrier.

Ownership of each transition

Trader or intermediary produces declarations that trigger MRN issue.
Haulier drives gmr_built (either automated via TSS or manual via GVMS).
Carrier verifies at checked_in and notifies HMRC at embarked. You can compare that ownership model against the source in this declaration-to-GMR walkthrough.

Mutability window

The gmr_built state remains mutable until the boarding barcode scan triggers the checked_in to embarked transition. That is the update window your ops tooling should expose.

Failure surface

Most operational failures live at two transitions: MRN issued to GMR built (late or wrong-format references) and GMR built to checked in (vehicle and trailer mismatches).

Build ops workflows that surface these state changes automatically. Watch a demo.

ENS Workflow Design for Northern Ireland Freight Teams

iCustoms — Mon, 07 Sep 2026 08:11:57 +0000

The workflow problem

Teams that treat ENS as customs work miss the deadline. ENS binds to the transport booking, not the customs paperwork window.

Recommended workflow

Booking created in the TMS.
Consignment data pulled into the ENS builder.
XI EORI validated at booking, not at submission.
Description matched against the approved product library.
ENS submitted through ICS2.
Movement Reference stored against the booking.
Customs route selected (simplified, internal market, full).
Supplementary declarations auto-generated where simplified. The full workflow is walked through in the Windsor Framework ENS reference.

Split of responsibility

Trader: master data, descriptions, EORI check.
Carrier: legal ownership of ENS.
Forwarder: submission and ICS2 response handling.

Corrections

Corrections applied only to downstream customs declarations create mismatch flags. Apply at the ENS source and cascade forward.

Design ENS workflows that hold up under audit — Watch a demo.

The 12-Step Workflow Behind a Valid TSS Declaration

iCustoms — Fri, 04 Sep 2026 06:59:42 +0000

Why a Workflow Beats a Checklist

A checklist tells you what. A workflow tells you what and in what order, so the same team gets the same result every day.

The 12 Steps

Confirm the declaration type.
Gather invoice, packing list and transport document.
Pull party details from records.
Process each goods line separately.
Confirm commodity code currency and digit count.
Read the Tariff Requirements section and note document codes.
Retrieve or write the approved product description.
Reconcile weights, package counts and values against documents.
Confirm origin and hold evidence for preference claims.
Attach certificate references for controlled goods.
Verify scheme authorisation validity for the movement date.
Run the completeness and consistency check. ## Where It Usually Breaks

Steps 5, 6 and 8. Codes drift, the Tariff Requirements section gets skipped, and reconciliation is treated as a formality. The TSS submission data checklist explains why each step exists.

What to Automate First

Extraction of invoice and packing list fields, then validation of the joined dataset. Submission comes last, and only against clean data.

Automate the boring 12 without losing the guardrails. Watch a demo.