什麼是符合性證書（CoC）？
31 3 月 2026
2026 Q2 Amazon.fr 庫存規劃 | 法國Pre-Amazon存儲勝過FBA費用
4 4 月 2026
FLEX. Logistics
我們為歐洲的網上零售商提供物流服務：Amazon FBA 準備、處理 FBA 移除訂單、轉運至履行中心 — 包括 FBA 及 Vendor 貨件。
自 2021 年分階段推出以來，ICS2 已徹底改變貨物進入歐洲聯盟的方式。第 3 階段 — 至今最具規模的一次 — 將海運、內陸水運及道路運輸全面納入範圍，完成歐盟海關當局致力建立的監管架構。對於物流營運商、報關行及進口商而言，這最後階段不僅增加新的申報義務，更暴露了許多供應鏈中早已存在的問題：海關數據在各方之間的擁有權、共享及管治方式。
ENS 拒絕率正在上升。申報被標記、延誤或拒絕 — 不是因為貨物有問題，而是因為背後的數據不完整、歸屬錯誤或提交太遲。了解為何會發生此事，以及誰真正負責修復，已成為歐洲跨境貿易中最迫切的營運問題之一。
ICS2 第 3 階段實際上改變了什麼 — 以及為何現在如此重要
ICS2（Import Control System 2）是歐盟改革後的到達前安全及保安申報制度。它取代了舊有的 ICS 系統，並引入了根本不同的邏輯：不再依賴每票貨物單一的綜合申報，而是採用多重申報模式，不同各方 — 承運人、貨運代理及海關代表 — 可各自將自己的數據集提交至共享的 ENS（Entry Summary Declaration）。
ICS2 第 3 階段，於 2024 年全面投入運作，將此框架延伸至道路運輸及海運，這些行業以往在舊有或過渡安排下運作。實際影響十分重大。
範圍已擴大 — 暴露風險亦隨之增加
隨著道路運輸現已全面納入範圍，大量以往在較不詳細的到達前制度下處理的歐盟目的地貨運，現在必須遵守完整的 ENS 申報要求。這意味著更多參與者、更多數據接觸點，以及更多資訊可能遺漏的機會。
多重申報模式帶來新的複雜性
在 ICS2 下，承運人及貨運代理可就同一票貨物提交獨立的數據集。這是設計使然 — 但前提是數據集彼此一致。當不一致時，ICS2 系統會標記申報，隨之而來的是拒絕或風險評估查詢。
預先裝載及到達前時段不容妥協
ICS2 強制執行嚴格的時限。對於空運，PLACI（Pre-Loading Advance Cargo Information）必須在裝載開始前提交 — 意味著數據義務在貨物實際移動前已開始。對於道路運輸，ENS 必須至少在抵達歐盟邊境前一小時提交。對於海運，時段視乎航程長短而定，但深海貨運可延長至 24 小時或以上。所有運輸模式原則相同：數據必須在貨物到達前抵達海關。
ENS 拒絕率作為管治關鍵績效指標
大部分物流團隊只被動追蹤 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 流程的自然擁有者。一個運作良好的報關行關係包括：
- 清晰的進口商數據提供服務水平協議（例如至少在到達前時段開啟前 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 數據流程開始。
