If a carrier, postal operator, merchant, or customs-facing intermediary explicitly says your shipment has an ICS2, ENS, Entry Summary Declaration, or ICS2-linked EAD data problem, the issue is about advance EU safety and security information used before or at entry.
That does not automatically mean the ordinary import declaration was rejected, customs finally refused the goods, the shipment was detained or seized, duty or VAT is unpaid, or the package failed customs clearance.
The first practical question is: who controls the ENS filing or response for this shipment? In many customer-facing cases, the sender or merchant is being asked to provide accurate shipment facts to a carrier or filing operator. Supplying the facts is not the same as being authorized to amend or re-file the ENS.
How to tell whether this is actually an ICS2 or ENS problem
Use this page only when the shipment-facing evidence names the safety/security object. Strong entry signals include:
ICS2;ENSorEntry Summary Declaration;EADwhen the operator clearly ties it to EU/ICS2 advance-data requirements;- an ICS2 validation error, incomplete ENS, or ENS rejection;
- an ICS2 additional-information request or referral;
- an ICS2 High Risk Cargo and Mail screening request;
- an ICS2 Do Not Load instruction; or
- a carrier message saying transport or dispatch is blocked because required ICS2/ENS data is missing or incorrect.
A generic message such as “stuck in customs,” “customs processing,” “documents required,” “clearance delay,” or “shipment not moving” is not enough. Without a named ICS2/ENS/EAD safety-security object, use Package Stuck in Customs or the more specific customs owner that matches the evidence.
This distinction matters because ICS2 is an advance safety/security filing and risk-analysis layer. It is not, by itself, the ordinary import declaration or the process that releases goods into free circulation.
Who controls the filing, and who only supplies data
The European Commission says the carrier bringing goods into the EU is generally responsible for lodging the ENS. When the carrier does not hold all legally required particulars, another supply-chain participant that holds those particulars can have a filing role under the applicable single- or multiple-filing arrangement.
That does not make every sender or recipient an ENS filer.
| Actor | Typical role in this problem | What not to assume |
|---|---|---|
| Carrier | Often the main ENS filing actor and the party that turns missing data into an operational customer request | The carrier is not automatically the source of every underlying product, seller, buyer, or commercial fact |
| Person filing / declarant | Receives or controls filing-specific notifications and the authorized ENS response or amendment path | The person filing is not automatically the sender or recipient |
| Supplementary or house-level filer | May submit part of the required data where the filing model supports multiple filings | Holding one data element does not make that actor responsible for every ENS field |
| Sender / seller / merchant | Often holds the truthful item, seller, buyer, description, value, or other shipment facts the filer needs | Providing facts does not automatically authorize that party to amend the ENS |
| Recipient / consignee | May hold relevant information in some arrangements and may receive a relayed carrier request | Being the addressee does not automatically make the recipient the ENS filer |
| Customs authority | Performs the safety/security risk analysis and can issue requests or controls through the ICS2 process | Customs risk analysis is not the same object as ordinary import release |
| Import broker or import declarant | May control a separate later import-entry, representation, or clearance process | A later broker/import role does not retroactively turn the ENS into the import declaration |
The core rule is:
The person who possesses the correct factual information is not automatically the person authorized to amend, re-file, or answer the ENS.
Do not tell an ordinary recipient to sign in to an ICS2 trader interface merely because the parcel is addressed to them. If the message does not identify who is filing, ask the verified carrier or intermediary who is the person filing/declarant for this shipment and whether they need data from you or action by the filer.
Read the exact message as an evidence object
| Message or object | What it confirms | What it does not confirm | Next actor |
|---|---|---|---|
| Named request for missing or corrected ICS2/ENS data | A shipment-specific safety/security data dependency exists in that operator's workflow | Formal customs detention, seizure, or final refusal | Carrier/intermediary first; provide truthful facts only if requested, while the filing actor handles the ENS action |
| ENS validation error, rejected ENS, or ENS not complete | The filing or data state failed an applicable validation/completeness step | Final refusal of the goods | Person filing/declarant or the operator controlling the filing |
| Additional-information referral | Customs risk analysis requires additional information through the relevant filing actor | Seizure | Declarant/person filing; carrier is informed where applicable |
| HRCM screening request | A distinct higher-risk screening branch has been triggered in an applicable ICS2 risk-assessment context | A generic ENS rejection or automatic seizure | Declarant/person filing and carrier under the applicable control process |
| Do Not Load | A distinct instruction not to load the goods applies in the relevant ICS2 context | A universal result of every ICS2 error or a synonym for “ENS rejected” | Carrier and person filing; follow the official control process and do not attempt to bypass it |
| Carrier origin or pre-dispatch hold | The carrier has stopped its own transport/dispatch workflow pending required data or compliance action | Formal customs detention | Carrier plus the person who can supply the missing facts; the ENS filer performs the filing action |
| Complete/accepted ENS or assessment complete | The safety/security filing or assessment reached that stated state | Ordinary import clearance, duty/tax settlement, release into free circulation, or final delivery eligibility | Continue with the next controlling customs or carrier process rather than treating the shipment as customs-cleared |
If the ENS is rejected or not complete
An ENS rejection, lifecycle validation error, or incomplete-ENS state is a filing/data problem. Current EU guidance and national customs implementation material show that insufficient or unclear data can lead to rejection, an amendment request, or additional-information handling before risk analysis is complete.
Do not translate that into “customs rejected my goods.” A separate authoritative customs or enforcement decision would be needed to establish refused entry, detention, seizure, return, disposal, or another final disposition.
If the carrier asks you to correct factual shipment data, provide the accurate facts through its verified channel. Do not invent a different product description, change an HS code merely to get past the control, understate value, disguise origin, or convert a commercial shipment into another category.
If the real problem is now a known product-description, HS-code, origin, quantity, value, invoice, or source-record mismatch, switch to Customs Declaration, HS Code, Value, or Invoice Mismatch. That page owns the source-record and correction problem; this page owns only the named ICS2/ENS safety-security state.
If you received an additional-information referral
An ICS2 additional-information referral is not the same thing as a seizure.
In the Commission's operational model, customs can request additional information during risk analysis from the declarant, with the carrier notified when it is a different actor. The risk analysis then continues when the requested information is supplied.
For an ordinary shipment customer, the safest action is not to guess which ICS2 field to amend. Ask the verified carrier or intermediary:
- What exact ICS2/ENS request was received?
- Who is the person filing or declarant?
- Which factual information is missing or needs clarification?
- Do you need me to supply facts, or is the required action entirely with the filer?
- What later message will show that the response was accepted or the risk-assessment state changed?
If the request instead becomes a sensitive ID, tax-number, invoice, proof-of-payment, or document-verification task, use Customs or Carrier Asks for ID, Tax Number, Invoice, or Proof.
HRCM and Do Not Load are separate controls
Do not collapse every serious-looking ICS2 message into “ENS rejected.”
A High Risk Cargo and Mail (HRCM) screening request is a separate risk-control branch used in applicable ICS2 contexts. A Do Not Load (DNL) request is stronger still: it instructs the relevant carrier/filer not to load the goods in the applicable scenario.
Neither label should be guessed from a generic delay. If the carrier only says “awaiting information” or “shipment on hold,” do not upgrade that wording to HRCM or DNL.
If DNL is explicitly named, do not advise the sender to route around the filer, change the declaration to make the message disappear, or use another transport path to defeat the control. The next step belongs to the carrier/person filing and the official customs process.
A carrier origin hold is not customs detention
A shipment can be stopped before dispatch because the carrier does not have the advance data it requires for its ICS2 workflow. That is an operator-controlled transport/compliance hold.
It is not, without separate authority evidence, formal customs detention.
This is important when a customer sees language such as “held at origin,” “cannot be transported,” or “missing electronic data.” First identify whether the shipment has even reached an authority-controlled customs stage. A carrier can prevent transport while waiting for data without customs having physically detained the goods.
If a later authoritative record explicitly says the goods are detained, seized, refused entry, stored, returned, abandoned, or disposed of, the primary owner has changed. Use Customs Clearance Failed or Package Became Undeliverable for the verified failed-clearance/disposition path rather than treating the later state as merely an ICS2 data error.
Why a complete ENS does not mean customs cleared
A complete or accepted ENS proves only the safety/security state that the relevant system actually reports. It does not by itself prove:
- an ordinary import declaration was accepted;
- duties, VAT, or other charges are settled;
- goods were released into free circulation;
- an import broker has completed a later customs procedure;
- no physical or regulatory control remains; or
- the carrier can deliver the shipment.
The systems can interact without becoming the same legal or operational object.
For example, the current NCTS Phase 6 architecture can, in participating road/rail implementations, carry complete ENS safety/security particulars with a transit declaration. NCTS remains a transit system, and the combined route does not prove ordinary import clearance or release.
If the shipment has moved on to a broker, formal-entry, representation, or power-of-attorney dependency, use Customs Broker, Formal Entry, or Power of Attorney.
If the remaining issue is a duty, tax, brokerage, or release-payment request, use Customs Fee, Duty, Tax, Brokerage, or Release Payment Request. Payment is a separate object from the ENS safety/security filing.
Carrier-specific examples show the problem can reach customers
The EU-wide meaning comes from government sources. Carrier and postal examples show only how a named ICS2 dependency can surface in a particular customer workflow.
Royal Mail international: Royal Mail describes ENS as a carrier-to-customs safety/security declaration and collects Electronic Advance Data from senders. Its sender guidance warns that items missing mandatory advance-data fields can be delayed or returned. This is a Royal Mail workflow, not a universal carrier status rule.
UPS Supply Chain Solutions: UPS SCS says that when its business/freight customers provide insufficient ICS2 data it will make a commercially reasonable effort to contact them; if the shipper does not respond, the shipment can be held at origin until the requirements are received. That is a UPS SCS operational hold, not a general UPS small-parcel rule and not formal customs detention.
DHL eCommerce Poland: In its documented 2026 business flow for Ireland and Northern Ireland, DHL eCommerce Poland says the carrier makes the ICS2 declaration for those shipments and missing or incorrect required data can prevent transport. This is a division- and corridor-specific example, not a global DHL rule.
These examples support one narrow conclusion: an ICS2/ENS data dependency can be made visible to a sender or business customer. They do not create a cross-carrier rule that every operator uses the same status text or always holds a shipment in the same way.
When this is actually another customs problem
Switch owners when a different evidence object becomes primary:
- No named ICS2/ENS/EAD object; only an unresolved customs hold or delay: Package Stuck in Customs.
- Known HS code, description, origin, quantity, value, invoice, or source-record mismatch: Customs Declaration, HS Code, Value, or Invoice Mismatch.
- Sensitive ID, tax-number, invoice, or proof request: Customs or Carrier Asks for ID, Tax Number, Invoice, or Proof.
- Broker, formal-entry, importer-filer, representation, or power-of-attorney dependency: Customs Broker, Formal Entry, or Power of Attorney.
- Duty, tax, brokerage, payer, payment-route, or release-payment question: Customs Fee, Duty, Tax, Brokerage, or Release Payment Request.
- Authoritative failed clearance, refused entry, storage, return, abandonment, disposal, detention, or seizure state: Customs Clearance Failed or Package Became Undeliverable.
- Only the responsible actor remains unclear: Who Should I Contact About a Package?.
A question about the EU's separate temporary €3 low-value customs-duty rule is also outside this page. Use EU €3 Customs Duty on Low-Value E-Commerce Imports for that duty rule instead of treating it as an ICS2 problem.
What to do next
- Keep the exact wording of the message. Record whether it names ICS2, ENS, Entry Summary Declaration, EAD, an additional-information request, HRCM, DNL, or a carrier data block. Do not replace the actual wording with “customs rejected it.”
- Identify the message source. Use the carrier, postal operator, merchant, broker, or intermediary's verified account, app, website, or case channel rather than contact details copied from an unsolicited message.
- Ask who controls the ENS filing. The useful question is not “Who owns the parcel?” but “Who is the person filing/declarant, and who is authorized to correct or answer this ENS state?”
- Supply only truthful requested facts. If the operator needs product, seller, buyer, description, code, value, weight, or other shipment facts from you, provide the real information through the verified route. Do not change facts to obtain a preferred result.
- Let the authorized filing actor perform the ENS action. Do not self-file, amend, or use a trader portal unless the verified process actually identifies you as the responsible economic operator or authorized filing actor.
- Wait for the next specific evidence state. “Data sent” does not prove the ENS was accepted. “ENS accepted” does not prove customs clearance. “Assessment complete” does not prove duty settlement or delivery eligibility.
- Change pages when the evidence changes. Once payment, import-entry correction, document verification, detention, seizure, failed clearance, return, or another object becomes primary, follow that owner instead of forcing every later problem back into ICS2.
If you are genuinely the responsible economic operator/person filing and need filing-system support, use the European Commission ICS2 FAQ, which directs ENS filing questions to the relevant national ICS2 service desk and explains the trader-facing filing environment. That is an economic-operator route, not a default instruction for ordinary parcel recipients.
Protect private shipment and customs data
Do not upload to 11Tracking:
- full tracking or booking references;
- home or business addresses;
- EORI or other tax/import identifiers;
- commercial invoices or payment records;
- private carrier or merchant messages;
- customs notices or filing screenshots;
- ENS filing data;
- passwords, one-time codes, account credentials, or access tokens.
11Tracking can explain what a named evidence object means and help identify the responsible actor. It cannot access ICS2, STI, or STP; file or amend an ENS; contact a carrier or customs authority for you; release cargo; remove a control; override a Do Not Load instruction; correct an import declaration; or guarantee transport, customs clearance, or delivery.