什么是符合性证书（CoC）？
31 3 月 2026
2026 Q2 Amazon.fr 库存规划 | 法国Pre-Amazon存储胜过FBA费用
4 4 月 2026
FLEX. Logistics
我们为欧洲的在线零售商提供物流服务：亚马逊 FBA 准备、处理 FBA 移除订单、转发至履行中心——包括 FBA 和供应商发货。
自 2021 年分阶段推出以来，ICS2 重新塑造了货物进入欧盟的方式。第 3 阶段——迄今范围最广——将海运、内陆水运和公路运输全面纳入范围，完成了欧盟海关当局旨在构建的监管架构。对于物流运营商、经纪人和进口商而言，这一最终阶段不仅仅增加了新的申报义务。它暴露了许多供应链中早已存在的问题：海关数据在各方之间所有权、共享和治理的方式。
ENS 拒绝率正在上升。申报正在被标记、延误或拒绝——不是因为货物有问题，而是因为其背后的数据不完整、归属错误或提交太晚。了解这种情况发生的原因，以及谁真正负责修复它，现在已成为欧洲跨境贸易中最紧迫的操作问题之一。
ICS2 第 3 阶段实际改变了什么——以及为什么它现在如此重要
ICS2（进口控制系统 2）是欧盟改革后的抵达前安全与安保申报制度。它取代了旧的 ICS 系统，并引入了根本不同的逻辑：不再依赖每票货物单一的综合申报，而是 ICS2 采用多申报模式，不同方——承运人、货运代理和海关代表——可各自将自己的数据集提交到共享的 ENS（入境摘要申报）中。
ICS2 第 3 阶段，于 2024 年全面投入运营，将这一框架扩展至公路运输和海运，这些领域此前采用遗留或过渡性安排运作。其实践意义重大。
范围已扩大——暴露风险也随之增加
随着公路运输现已完全纳入范围，大量此前在颗粒度较低的抵达前制度下处理的欧盟目的地货运现在必须遵守完整的 ENS 申报要求。这意味着更多参与方、更多数据接触点，以及更多信息落入裂缝的机会。
多申报模式引入新的复杂性
在 ICS2 下，承运人和货运代理可为同一票货物提交单独的数据集。这是设计意图——但前提是这些数据集彼此一致。当不一致时，ICS2 系统会标记该申报，随后会出现拒绝或风险评估查询。
预装载和预抵达时间窗口不可协商
ICS2 执行严格的时间要求。对于空运，PLACI（预装载提前货物信息）必须在装载开始前提交——意味着数据义务在货物实际移动前就开始。对于公路运输，ENS 必须至少在抵达欧盟边境前一小时提交。对于海运，时间窗口根据航程长度而异，但对于深海运输可能延长至 24 小时或更长。所有运输方式的原则相同：数据必须在货物之前抵达海关。
ENS 拒绝率作为治理 KPI
大多数物流团队被动跟踪 ENS 拒绝——当货物延误且有人开始打电话时才显现出来。这是一个问题。ENS 拒绝率需要被视为前瞻性的治理 KPI，而不是回顾性的事件报告。
原因很简单：高的 ENS 拒绝率是系统性数据质量问题的症状，而不是一系列孤立的错误。如果您的拒绝率高于 2–3%，您几乎肯定在数据收集、验证和传输方式上存在结构性问题——而这个问题正在以延误、修改费用和监管暴露的形式让您付出代价。
健康的拒绝率是什么样的
欧盟没有官方的 ENS 拒绝率基准，但与 FLEX. 合作的经验丰富的海关团队设定了内部目标，使标准贸易航线的拒绝率保持在 1.5% 以下。超过 5% 的拒绝率是红旗，应触发全面数据流审计，而 1.5% 到 5% 之间的任何情况都需要针对最高频错误类型进行针对性审查。这种区分很重要：中段比率指向具体、可修复的问题，而高于 5% 的比率通常表明整个数据收集过程需要从头重新构建。
ENS 拒绝的最常见原因
在 ICS2 第 3 阶段下，运营商遇到的最常见问题分为五类：收货人/发货人数据不正确或缺失（尤其是当进口商详细信息由承运人填写而非在源头验证时）；商品描述错误，其中模糊语言未能通过 ICS2 的安全筛查阈值；实际申报人与申报方之间的 EORI 号码不匹配；预抵达或预装载窗口关闭后提交的迟交申报；以及在多申报模式下承运人申报和代理申报信息冲突的数据集不一致。每一种都可以追溯到特定的交接失败。
将拒绝数据转化为行动
将 ENS 拒绝作为 KPI 跟踪的治理价值在于能够细分错误类型、将其分配给责任方，并随着时间跟踪改进。一个结构良好的拒绝日志应捕获货物参考号、ICS2 系统发出的拒绝代码、触发拒绝的数据字段以及负责该字段的当事方。最后一列是最重要的：如果没有明确的当事方归属，拒绝数据只会告诉您出了问题，但不知道谁需要修复它。有了它，您就有了结构化问责对话的基础——以及可衡量的改进周期，而不是反复救火。
字段所有权：大多数团队忽略的根本原因
询问任何物流经理谁负责 ENS 申报中收货人的 EORI 号码，您会根据询问对象得到不同答案——经纪人、承运人或进口商。这种模糊性不是沟通失败。它是治理失败，是 ICS2 第 3 阶段下 ENS 拒绝的主要驱动因素之一。字段所有权意味着为 ENS 申报中的每个数据字段明确、书面地分配供应链中特定方的责任。这听起来显而易见。在实践中，它几乎从未以 ICS2 要求的精确度发生。
为什么模糊性会造成错误——而不是冗余
当多方认为他们共享某个数据字段的责任时，结果很少是双重检查。通常是带有不一致值的重复，或者更糟的是，相互假设对方已处理它。ICS2 多申报模型旨在允许协作申报——但协作只有在各方确切知道他们拥有什么时才有效。在实践中，没有明确边界的共享所有权会反复产生相同的失败模式：
- 重复提交且值冲突 —— 两方为同一字段提交不同数据
- 相互假设缺口 —— 各方相信对方已验证信息
- 没有明确的纠正路径 —— 当拒绝发生时，没人知道谁应该修复它
- 连锁延误 —— 单个无主字段会拖延整个申报
构建字段所有权矩阵
字段所有权矩阵是一个结构化文档，将每个 ENS 数据字段映射到负责提供、验证和申报它的当事方。至少应涵盖以下分配：
- 发货人/出口商数据 —— 进口商或出口商的海关团队
- 收货人数据 —— 进口商
- 商品描述和 HS 代码 —— 海关经纪人或货运代理
- 运输和路线数据 —— 承运人
- EORI 号码 —— 各方负责自己的；由经纪人验证
- 提交时机 —— 承运人（预装载）和经纪人（预抵达）
矩阵不必复杂。它需要被同意、签字确认，并嵌入到运营工作流程中——而不是存放在共享驱动器中被遗忘。
您的字段所有权已损坏的常见迹象
大多数团队直到货物被扣留才意识到他们的字段所有权模型已失败。但警告迹象出现得更早，并遵循可识别的模式，一旦您知道要寻找什么，就很难错过：
- 同一字段反复拒绝 —— 源数据从未在源头纠正
- 最后一刻数据请求 —— 进口商详细信息在订舱确认后被追逐
- 冲突申报 —— 承运人和经纪人数据在路线或收货人上不一致
- 没有升级路径 —— 当字段无法及时验证时，团队不确定联系谁
当这些模式中任何一种持续出现时，问题就是结构性的。修复它需要治理干预，而不仅仅是向相关方发送提醒邮件。
FLEX. 在实践中如何处理字段所有权
在 FLEX. Logistique，字段所有权不被视为一次性设置练习。它被纳入每个新客户的入职流程，并在贸易航线、供应商或承运人发生变化时进行审查。链中的每一方都会收到他们拥有字段的书面分解，包括明确截止日期和定义的升级路径。该方法基于四个运营原则：
- 完整字段归属 —— 每个 ENS 字段仅分配给一个责任方
- 入职整合 —— 在第一票货物移动前达成所有权协议，而不是之后
- 定期审查周期 —— 每当航线、供应商或承运人发生变化时重新审查分配
- 可追溯问责 —— 每个拒绝可追溯到字段，每个字段可追溯到当事方
当存在这种可追溯性时，改进变得可衡量。没有它，同样的错误会无限重复。
进口商–经纪人–承运人交接：数据出错的地方
ENS 数据质量中最危险的时刻是交接。这是数据从一方转移到另一方的时候——从进口商到经纪人，从经纪人到承运人，或从承运人返回海关系统——也是最有可能引入、重复或完全丢失错误的地方。
在 ICS2 第 3 阶段下，交接问题因公路运输通常涉及多个分包商，以及海运可能涉及复杂的多式联运段而加剧，每个段都有自己的数据义务。
进口商的角色比大多数人假设的更大
许多进口商将海关申报视为完全交给经纪人的服务。在 ICS2 下，这不再是一种可行的姿态。进口商是 ENS 数据重要部分的真相来源——特别是收货人信息、商品细节和 EORI 号码。如果源头数据错误，没有经纪人能在下游修复它而不返回进口商——这需要时间，而时间正是预抵达窗口不允许的。
进口商需要在货物订舱时建立验证和提供 ENS 就绪数据的内部流程，而不是货物在运输中之后。
经纪人的协调责任
海关经纪人在 ENS 数据流中占据中心位置。他们从进口商接收数据，与承运人协调运输细节，并将申报提交到 ICS2 系统。这使得经纪人成为 ENS 流程的自然所有者。一个运作良好的经纪人关系包括：
- 来自进口商的数据提供明确 SLA（例如，在预抵达窗口打开前至少 24 小时提供完整货物数据）
- 申报前的验证检查点，经纪人将缺失或不一致字段标记回源头
- 当数据在申报截止日期前无法确认时的书面升级路径
ICS2 第 3 阶段下的承运人义务
承运人不是 ENS 流程中的被动参与者。在 ICS2 下，他们承担运输层面数据的直接申报义务——特别是空运的 PLACI 要求，以及公路和海运的预抵达要求。当承运人数据与经纪人申报数据冲突时，ICS2 系统会标记不一致。
承运人的责任是提交准确、及时的运输数据，并实时沟通任何影响 ENS 的路线变更或分包安排。在实践中，这需要与货运代理或海关经纪人签订数据共享协议，指定承运人将提供什么数据、以什么格式以及何时提供。
构建 ICS2 就绪的数据治理框架
修复 ENS 拒绝率不是技术问题。它是治理问题，技术可以支持它。最有效地管理 ICS2 第 3 阶段的公司已经构建了解决人员、流程和系统——按此顺序——的框架。正确实现欧盟进口合规从人员和流程开始，而不是软件。
步骤一：审计您当前的拒绝概况
在改变任何事情之前，了解您正在处理什么。拉取您过去 90 天的 ENS 申报，并按错误类型、数据字段和责任方细分拒绝。该审计几乎总是会浮现少量反复出现的错误——通常是三到五个字段类型——这些占您拒绝的大多数。系统性地修复这些将对您的整体拒绝率产生不成比例的影响。
步骤二：正式化交接协议
记录数据从进口商到经纪人再到承运人的确切移动过程。指定格式、截止日期和升级路径。将交接协议作为您与每一方的商业协议的一部分——而不仅仅是内部标准操作程序。当延误或错误发生时，该协议为您提供了问责和快速纠正的明确基础。
步骤三：监控、报告和迭代
没有测量，治理框架会衰退。为 ENS 拒绝率设定每月审查节奏，按贸易航线、承运人和错误类型细分。与链中所有各方共享数据。当一方的数据质量改善时，予以承认。当恶化时，及早处理——而不是在货物卡在边境之后。
您的 ENS 数据就是您的海关策略。以此方式对待它
ICS2 第 3 阶段让一件事无可否认：海关合规不再是后台职能。您 ENS 数据的质量、字段所有权模型的清晰度，以及进口商–经纪人–承运人交接的效率，直接影响您可靠且有竞争力地将货物运入欧盟的能力。
ENS 拒绝率是治理 KPI。字段所有权是运营纪律。而进口商、经纪人和承运人之间的交接协议是您欧盟市场准入所依赖的基础设施。
在 FLEX. Logistique，我们与进口商和供应链运营商合作，构建正是这种海关数据治理——从字段所有权矩阵到拒绝率监控，从经纪人协调到所有运输模式下的全面 ICS2 合规支持。如果您的 ENS 拒绝率高于应有水平，或者您的数据交接仍在非正式协议上运行，现在是修复基础的正确时机。
准备好让您的 ICS2 合规得到控制了吗？ 与 FLEX. 团队联系，让我们从审计您当前的 ENS 数据流开始。
