Do You Need to Reconfigure Your TMS for ICS2?

Yes, if you file Entry Summary Declaration (ENS) data yourself, or if your carrier pulls shipment data straight out of your TMS, you have config work to do. Three fields need attention almost every time: goods description, EORI numbers on both the consignor and consignee side, and HS code precision. If a 3PL files on your behalf using its own master data, your exposure is lower, but you are still legally responsible for the accuracy of the data you supply, even when someone else pushes the button.

What changed in ICS2 version 3 that affects your TMS?

Version 2 messaging is gone. ICS2 version 3 became mandatory across all transport modes on the 3rd of February 2026, which means any integration, EDI mapping, or API call still built on the old schema is now rejected outright at the ICS2 Common Repository. The practical change inside version 3 is stricter validation on fields you probably haven't touched in years:

• Goods description fields must be specific and meaningful; broad commodity labels get rejected.
• Consignee and consignor party data must meet the new v3 completeness standard.
• Routing and transport data has to reflect the real shipment, not a template-filled placeholder.

And there's no cushion left on the transport-mode side either. With the final road and rail derogations gone, the temporary derogations that let some member states delay enforcement have ended, with no remaining grace period, and ICS1 no longer accepted for shipments that fall under ICS2. If your TMS still has an ICS1 fallback path configured for any lane, archive it. It's dead weight that can silently misroute a filing.

Who actually owns ENS data, you or your carrier?

Legally, the carrier is usually on the hook for filing, but you own the data quality, and that's where shippers get caught out. Under the Union Customs Code, the importer, consignee, or any person able to present the goods may file instead of or in addition to the carrier, which is exactly why "the forwarder handles it" isn't a full answer to the compliance question. Here's the part that trips up ops leads: filing responsibility and commercial consequence are not the same thing. If your goods description is vague or your party data is incomplete, the commercial consequence falls on the business that owns the cargo, not just the filer. Your carrier eats an administrative penalty. You eat the stopped truck, the missed delivery window, and the customer call. Build a one-page matrix by lane and carrier: who files master-level data, who files house-level, and who in your org is the named data owner when a filing bounces. If you can't answer "who fixes a rejected goods description on lane X by Tuesday" in one sentence, you don't have an SOP, you have a hope.

What is the stop words list, and how do you audit your goods description templates?

Stop words are goods description terms the European Commission has flagged as too vague to be useful for risk screening, and an updated list took effect in 2026 that adds to what was already banned. As one customs source puts it, stop words and phrases are terms the European Commission has identified as too vague, generic, or ambiguous to serve any meaningful purpose in a goods description field. Generic entries like "machine parts," "electronics," "clothing," or "general cargo" are already rejected outright, and the May 2026 update adds a further nine terms to the prohibited list. This is where manufacturer-scale shippers get hurt the most. For manufacturers with high-volume, recurring shipments, a single prohibited term used across hundreds of ENS filings becomes a systematic failure the moment the new list takes effect. If "parts" or "accessories" sits in a reused product master description, you're not looking at one bounced shipment, you're looking at every shipment on that SKU, that lane, starting the same day. Run this audit at the master-data level, not shipment by shipment:

1. Pull the last 90 days of ENS rejections from your TMS or your carrier's reporting portal.
2. Cross-check every recurring goods description template against the published CIRCABC stop words list.
3. Fix the description at the product master record, not inside individual shipment records, so the correction propagates forward automatically.
4. Re-check templated or auto-populated fields specifically, since systems that auto-populate goods descriptions from product codes or historical entries are a common source of stop word violations.

What is ICS2 "multiple filing," and do you need to configure for it yet?

Multiple filing lets different supply chain parties, say your carrier and your own operation, each submit a portion of the ENS data instead of one party holding the whole record. By the end of 2026, ICS2 is expected to support multiple ENS filings for a single shipment, letting different parties in the supply chain, such as the carrier and the importer, submit their portion of the required data separately. This isn't fully live everywhere yet; it's already standard for air and most maritime movements, and road is catching up through 2026. Don't build speculative mapping for this today. Instead, ask your TMS or EDI provider one direct question: is multiple filing shipped for your transport modes, or still roadmap? Get the answer in writing, because the anticipated multiple filing rollout will require each contributing party to own and validate their portion of the record, and that's a mapping change you want scheduled, not discovered mid-quarter.

How do you test ENS submissions before a real shipment gets stuck at the border?

Run a dry-run on a known-good lane before you roll any template change company-wide, using a test or sandbox EORI where your provider supports one. The risk of skipping this step is concrete, not theoretical: version 2 filings can no longer be patched. Any ENS declarations lodged using ICS2 version 2 prior to February 3, 2026 cannot be amended after that date using the legacy message format, and these declarations must be invalidated and re-lodged using version 3 messaging standards. That means a bad template deployed to production doesn't get a quiet fix, it gets a full re-file, with the delay and re-scoring that comes with it. Treat every goods-description or EORI mapping change the way you'd treat a rate table change: one lane, one carrier, confirm the ENS clears clean, then push wider.

Which TMS and customs-data layers handle this natively vs. need manual workarounds?

This splits roughly into two camps, and it matters for how much config work lands on your desk versus your forwarder's.

Don't take any vendor's marketing page as proof of ICS2 v3 readiness. Ask for the exact field mapping document, lane by lane, mode by mode. If a vendor can't produce one, that's your answer.

Your copy-paste checklist

• Data owner matrix: one row per lane/carrier combo, naming who files what and who fixes rejections.
• Stop-word audit cadence: quarterly minimum, immediately after any CIRCABC list update.
• Test-filing cadence: every template or mapping change goes through one known-good lane before company-wide rollout.

Put these three items in your SOP doc this week, not next quarter. The deadlines already passed. What's left is cleanup, and cleanup is cheaper before a shipment sits at the border than after.