ICS2 in Practice: What LSPs Shipping into the EU Need to Fix

For a long time, ICS2 lived in the “future compliance” bucket for most logistics providers. It started with postal and express air, then expanded to general air cargo. For many ocean-focused LSPs, it felt distant.

That phase is over.

ICS2 Release 3 is now fully extended to maritime, road, rail and inland waterways.
Legacy ICS1 routes are being phased out.
And critically, European Commission guidance is pushing all operators to the current ENS message version (v3) by 3 February 2026.

In other words: ICS2 is no longer a project for your customs team in 2027. It is a data-quality and process issue that can delay containers next month if you get it wrong.

This post focuses on what actually changes for LSPs:

What ICS2 means in practice for ocean, road, and rail into the EU
Where filings usually fail (and how that shows up operationally)
What you should put in place before February 2026 so ICS2 becomes a planning topic, not a fire drill

What ICS2 Actually Changes for LSPs

You don’t need a legal treatise to work with ICS2. The important changes for an LSP are structural.

1. All modes are now in scope

ICS2 is the EU’s upgraded pre-arrival safety and security system (Entry Summary Declaration/ENS). It replaces and extends the old ICS1 regime.

The roll-out has been staged:

Release 1 – postal and express air consignments
Release 2 – general air cargo
Release 3 – maritime, inland waterways, road, and rail, plus multi-modal flows

As of late 2025:

Any movement into or via the EU, Norway, Switzerland or Northern Ireland is covered, irrespective of mode.
For LSPs, that means ICS2 now sits behind a large share of your ocean and cross-border road/rail flows—not just air.

2. More granular, house-level data

ICS1 was built around fairly high-level carrier data. ICS2 expects richer, more granular information:

More detailed goods descriptions (no more “parts”, “general cargo”, “equipment” as a catch-all)
Wider and stricter use of HS codes
More complete and validated party information (shipper, consignee, EORI where needed)

Crucially, ICS2 supports (and increasingly expects) house-level ENS filings. That means:

Carriers submit master-level data (voyage, master B/L, high-level cargo info)
Forwarders, NVOCCs and consolidators are expected to file or feed house-level data for their part of the shipment

If you treat ENS purely as “the carrier’s job”, ICS2 will shine a light on the gaps between what you know and what the master filing contains.

3. Earlier and more structured timing

ICS2 cares not only about what you file, but when you file it.

Depending on the mode and route, some data now needs to be submitted:

Before loading (for certain air and maritime flows)
Or before arrival (for others)

For an LSP, this moves data collection and validation upstream:

You can’t wait until after a shipment is fully built and documents are final to clean up descriptions and HS codes
Data must be ready and structured in time for the relevant ENS cut-off

Where We Are Now: Release 3 and the February 2026 Pivot

ICS2 Release 3 has been rolling out for maritime, inland waterways, road, and rail through 2024 and 2025. The transitional “deployment windows” are closing.

In practical terms, as of late 2025:

Maritime and inland carriers are expected to be live on ICS2
House-level filers (forwarders, NVOCCs) have had their deployment window and are moving into “business as usual”
Road and rail carriers are also under ICS2 for cross-border EU traffic

On top of that, the Commission has issued clear guidance:

All economic operators should migrate to the current ICS2 ENS message version (v3) by 3 February 2026.

After that date, older message versions will be progressively switched off. For LSPs, that date is a hard psychological line:

If your ICS2 processes are still based on “old habits” or legacy message formats after early February, you should assume less tolerance for inconsistencies.
Customs, carriers, and platforms will increasingly focus on v3 as the only supported way forward.

You do not need to implement a new IT project before that exact date. But you do want your organisation to answer, calmly and clearly:

“Who files what for ICS2 on our EU-bound flows?”
“How do we collect and validate the data ICS2 expects?”
“What happens internally when an ENS message is rejected or questioned?”

Who Files What: Carriers, Forwarders, and Shippers Under ICS2

One of the biggest pain points today is not the regulation itself, but confusion about roles. ICS2 makes that confusion more costly.

Carrier level – master data

For ocean, rail, road, and inland waterway, carriers are responsible for the master ENS:

Transport details (voyage, vessel, train, truck, route)
Master-level cargo information (total pieces, weight, high-level consignments)

They must ensure their ICS2 connection works and that master data is sent on time.

House-level filers – the LSP layer

Forwarders, NVOCCs, consolidators, and logistics intermediaries:

Hold the house-level data: actual shipper/consignee, detailed goods description, HS, packages, etc.
Can file ENS segments directly or provide that data systematically to carriers or service providers for inclusion

ICS2’s “multiple filing” concept is designed for this:

Each party with knowledge of a part of the shipment submits their segment
ICS2 composes a complete picture

For many LSPs, that means moving from “we send a PDF or email to the carrier” to:

A structured data feed
Or direct ICS2 house-level filing via a provider or interface

Shippers and cargo owners – the data origin

Shippers are not off the hook either. ICS2 indirectly forces:

Better goods descriptions (meaningful, specific)
More consistent HS classifications
Accurate and complete party data

If your customers’ commercial data is weak, your ENS filings will be weak—and ICS2 will push back. For many LSPs, this is where process work is most needed: upgrading what you require from shippers at booking time.

The Data That Will Hurt You: Typical ICS2 Failure Points

ICS2 problems rarely start with exotic edge cases. In most forwarder discussions, the same issues appear again and again.

1. Vague or non-compliant goods descriptions

Descriptions like:

“Parts”
“General cargo”
“Machinery”
“Equipment”

are increasingly unacceptable on their own. Customs wants plain-language, specific descriptions that give a real sense of the goods.

Practical impact:

ENS messages with vague descriptions may be rejected or flagged
You end up rewriting descriptions under time pressure—often with incomplete input

2. Incomplete or inconsistent HS codes

Common patterns:

Missing HS where it is required for certain goods
Wrong number of digits (e.g. 4 instead of the expected 6 or more)
Systematic use of a “generic” HS code for a whole product family

ICS2 is part of a trend toward better alignment between security filings, customs declarations, and what’s actually in the box. If your HS data is consistently off, it increases the likelihood of:

Questions
Holds
Inspection risk

3. Missing or incorrect party data

Typical issues:

Shipper or consignee name and address not matching any registration
Missing or incorrect EORI numbers for EU trading partners
Incomplete data for intermediate parties (e.g. notify, buyer, seller where relevant)

This is where poor master data maintenance shows up. If ICS2 can’t connect the dots, it slows things down.

4. Late or mismatched house-level data

Even if your data is “good enough” on content, timing and alignment can cause issues:

House-level data arrives after the master ENS has already been lodged
Quantities, weights, or parties don’t match between carrier and LSP segments
Multiple filings contradict each other

In a world where ICS2 expects a coherent picture before loading or arrival, these mismatches generate extra work and delay.

5. No internal owner for ENS exceptions

Finally, many LSPs simply lack a clear process for when ICS2 pushes back:

Who monitors ICS2 responses (directly or via carrier/provider)?
Who is responsible for fixing a rejected or “do not load” message?
What is the internal SLA for resolving issues?

Without that, problems sit in inboxes or carrier portals while the shipment clock keeps ticking.

What ICS2 Mistakes Look Like in Real Life

On paper, ICS2 is about “safety and security risk management”. In practice, for an LSP, mistakes look like:

ENS rejection
- Messages bounced back due to missing or non-compliant data
- Staff re-keying and resubmitting under time pressure
Pre-loading or pre-arrival blocks
- For certain routes, ICS2 risk analysis can trigger “do not load” until data is fixed
- For maritime and road/rail, this translates into missed vessels or delayed border crossings
Holds and inspections on arrival
- Inconsistent or incomplete data increases the chance of physical inspections
- That means days of extra dwell and unplanned storage
Costs and noise
- Storage, handling, and administrative overhead
- Last-minute calls to shippers: “we urgently need a better description / HS / EORI”

In other words: ICS2 failures don’t feel like a compliance memo. They feel like operational friction and cost, often with the LSP in the middle.

A Practical ICS2 Readiness Checklist for LSPs

You don’t need a separate ICS2 “project team” to make progress. You do need some deliberate housekeeping. Here’s a pragmatic checklist.

1. Map your ICS2 roles by lane and customer

For each major EU-bound lane and customer:

Are you acting as a house-level filer (directly or via a provider)?
Or are you relying on carriers to file everything based on your data?

Write this down. ICS2 multiple filing only works if each party knows what they’re responsible for.

2. Confirm your EORI and connection route

Make sure:

Your EORI registrations are valid and up to date
You know how your ICS2 filings are technically submitted:
- Your own system integration
- A third-party filing service
- A carrier portal or EU web interface

If you’re using a mix of methods, understand which customers/lanes go through which route.

3. Standardise the data you collect from shippers

Look at your booking templates and SOPs. Do they force the data ICS2 expects?

At minimum, consider making mandatory:

Clear, specific goods descriptions
HS code at the required level for your flows
Full party details, including EORI where applicable

The earlier you capture quality data, the less “ENS firefighting” you’ll do later.

4. Align expectations with carriers and partners

With your main carriers and service providers, clarify:

Who files which messages (master vs house)
What cut-off times apply for your data to be included
How discrepancies will be handled:
- Who has the “final say” if your house data conflicts with master data?
- How you will be informed when something is rejected or queried

Getting this in writing (even as a simple process document) avoids a lot of finger-pointing when something goes wrong.

5. Build a simple ENS exception workflow

You don’t need a complex ticketing system to start. You do need:

A clear owner (or team) for ICS2/ENS issues
A basic workflow:
- Monitor responses (directly or via providers/carriers)
- Classify issues (missing data, wrong format, risk flag)
- Fix them within a defined timeframe

Even a lightweight process can significantly reduce the time shipments sit waiting for corrected filings.

6. Use your visibility and data layer, not separate spreadsheets

ENS data doesn’t have to live in a separate universe.

If you already have:

A TMS
A visibility platform
A central data hub

make sure:

The same shipment record that drives operations also drives ICS2 data
Updates to HS codes, descriptions, or parties are reflected everywhere, not just in a local spreadsheet
ICS2 errors trigger updates at the source, not just patch-work fixes on a single message

That way, you’re improving your overall data quality, not just “feeding the ICS2 machine”.

How Visibility and Event Data Make ICS2 Easier to Live With

ICS2 is one more example of a broader theme: when data is scattered, slow, and inconsistent, it becomes a bottleneck.

Event-based visibility and ICS2 aren’t the same thing, but they benefit from the same foundation:

A B/L- and container-centric record for each shipment
Consistent party, product, and routing data in one place
Frequent updates that reflect what actually happens in the network

If your visibility backbone (whether TRADLINX or another platform) is the single source of truth for:

Who is shipping what
Under which HS and description
On which routing and carrier

then:

ICS2 filings can be generated or supported from those records
ENS issues become one more type of exception in an existing monitoring process
You can align what you tell customs with what you tell your customers

The more your operational systems are joined up, the less ICS2 feels like an extra compliance layer—and the more it feels like a natural extension of good data hygiene.

Turning ICS2 into a Planning Topic, Not a Panic Topic

By early 2026, ICS2 will simply be “how things work” for any shipment into or via the EU. The days of treating it as an air-cargo-only pilot are already behind us.

For LSPs, success won’t be about memorising annexes. It will come from:

Clarity on who files what, by lane and customer
Better data collection from shippers at booking stage
Simple but robust exception handling for rejected or flagged ENS messages
A shared data backbone that keeps ICS2, operations, and customer communication in sync

The February 2026 push to ENS v3 is a useful internal deadline. If you can answer the basic ICS2 questions with confidence by then, you’ll be in a position to treat ICS2 as one more managed constraint, not a last-minute surprise that derails sailings.

ICS2 in Practice: What LSPs Shipping into the EU Need to Fix