
歐洲 Seller Fulfilled Prime:非歐盟品牌能否通過資格審核,需要甚麼物流配置?
26 5 月 2026
為何銷往歐洲的美國品牌在歐盟新海關規則後重新評估 DDP Incoterms
26 5 月 2026

FLEX. Logistics
我們為歐洲的網上零售商提供物流服務:Amazon FBA 預備、處理 FBA 移除訂單、轉運至履行中心 — 包括 FBA 及 Vendor 貨運。
一家英國品牌從波蘭的 3PL 倉庫將貨物運送至德國、法國和荷蘭的消費者。每個包裹都會跨越消費國邊境。每筆銷售都會在買家的成員國觸發增值稅義務。若沒有協調的報告結構,該品牌將面臨多達 27 個獨立的國家增值稅登記 — 或單一、妥善管理的非聯盟 OSS 登記,將整個報告負擔合併為一份在單一歐盟國家提交的季度申報表。
波蘭於 2026 年 5 月正式引入 UC147 法案,轉化歐盟理事會指令 2025/516 第 2 條及第 4 條(ViDA 方案),加嚴了非歐盟賣家必須遵守的規則。本文解釋了有哪些改變、誰擁有哪些義務,以及您的履行設定必須捕捉哪些營運數據,以從第一天開始讓歐盟範圍的 B2C 增值稅合規變得易於管理。
ViDA 轉化實際上為非歐盟賣家帶來哪些改變
ViDA 方案並非新增稅項,而是對現有增值稅義務在歐盟成員國之間如何分配、報告及執行的結構性優化。對於未在任何歐盟國家設立固定營業場所的非設立賣家而言,最重要的改變集中在三個範疇。
首先,之前容許部分賣家採用原產國增值稅稅率的每年 10,000 歐元門檻已獲澄清。UC147 法案明確指出,從外國或多國 3PL 節點發貨的銷售不計入此門檻計算。實際上,使用德國或波蘭等歐洲集中履行樞紐的非歐盟賣家,幾乎肯定已超過門檻,必須對每筆 B2C 銷售採用目的地國增值稅稅率。
其次,稅務時點規則已獲統一。增值稅責任的發生時間現時與確認發貨事件掛鉤 — 即包裹離開倉庫的時刻 — 而非付款日期或訂單確認時間。這令發貨國家對應成為合規關鍵數據欄位,而非僅是物流指標。
第三,平台視為供應商制度已擴展至涵蓋透過數碼市場處理的若干跨境 B2B 交易,在指定情況下將增值稅收取責任轉移至平台。對於直接面向消費者的網店,並無此類轉移。賣家仍需全面承擔責任。
非聯盟 OSS 登記途徑
未在歐盟設立營業場所的非歐盟賣家,可在其選擇的任何成員國登記非聯盟 OSS 方案。波蘭及愛爾蘭因行政便利而成為常用入門點。一經登記,賣家只需提交一份季度增值稅申報表,即涵蓋所有向歐盟消費者作出的 B2C 銷售,並對每筆交易採用買家所在國的增值稅稅率。
UC147 法案移除了一項歷史障礙:之前在非聯盟 OSS 配置時須提供網站 URL 的要求,已在波蘭轉化版本中取消。這減低了經營多個店面或無頭商務架構的賣家在入門時的摩擦。登記本身需要有效的 EORI 號碼、業務身份證明文件,以及若干成員國要求的指定稅務代表。在提交前,請向合資格的歐盟稅務顧問確認最新要求。
未進行 OSS 登記會如何
若未進行非聯盟 OSS 登記,從歐盟倉庫發出 B2C 包裹的非歐盟賣家仍無法豁免增值稅義務。無論賣家有否登記收取增值稅,義務依然存在。各成員國可透過市場平台數據共享協議、海關進口記錄及承運商清單審核等方式,向未登記賣家追討。
實際後果是分散風險:每宗銷售的目的地國均可能成為執法司法管轄區。追溯登記、補交申報及相關利息,可能在問題浮現前已於多個稅期累積。對於使用單一樞紐提供泛歐 B2C 履行服務的賣家,發貨量與已登記增值稅報告之間的差距,可在承運商數據中很早便顯現。於首件包裹發貨前登記,才是唯一具營運可行性的立場。
發貨事件作為您的增值稅稅務時點
根據 ViDA 方案引入的統一規則,遠距離銷售的增值稅稅務時點為確認發貨事件。這是包裹交給承運商並建立追蹤記錄的時刻。對於使用歐洲履行樞紐的非歐盟賣家,這意味著倉庫管理系統必須在發貨確切時刻記錄發貨國家、目的地國家、適用增值稅稅率及交易價值 — 而非在月底追溯重建。
運行自動化庫存追蹤及即時發貨國家對應的履行合作夥伴,可為每張出庫訂單自動產生此數據欄位。若欠缺該自動化,賣家通常須從承運商發票及訂單匯出檔案中重建發貨記錄 — 此過程容易引入對賬錯誤,並在 OSS 季度申報中造成缺口。稅務時點首先是數據問題,其次才是稅務問題。

視為供應商規則:市場平台銷售與自家網店
視為供應商制度是 ViDA 框架中非歐盟賣家最常被誤解的元素之一。根據擴展後的規則,在若干跨境銷售中促進交易的網上市場平台會被視為供應商。平台會向買家收取增值稅,並向相關稅務機關繳付,而底層賣家則收取淨額付款,無需就該交易承擔增值稅責任。
這適用於市場平台促進交易且賣家未在歐盟設立的 B2C 銷售。對於使用主要面向歐盟平台的賣家,其 B2C 交易量中相當大一部分可能已由平台的視為供應商義務涵蓋 — 即賣家自身的 OSS 申報應排除這些交易,以避免重複報告。
關鍵區別在於銷售渠道。透過自家直接面向消費者的網店、品牌網站或任何無市場平台中介的渠道進行的銷售,不存在視為供應商轉移。每宗此類交易均為您的增值稅義務,必須在 OSS 登記下報告,並需要一份與正確目的地國稅率掛鉤的清晰發貨記錄。同時經營市場平台及 DTC 渠道的賣家,需要在訂單層面(而非報告階段)將這兩個流程分隔的數據架構。
您的數據堆疊必須捕捉的資料
對於從歐盟履行節點發出的每張 B2C 訂單,您的系統必須記錄:發貨倉庫國家、買家送貨國家、該國家及產品類別的適用增值稅稅率、交易價值(不含增值稅),以及銷售所透過的渠道。此數據集是您 OSS 季度申報表的基礎。
若您的 3PL 合作夥伴從多個倉庫位置提供泛歐 B2C 及 B2B 履行,則發貨國家欄位必須在個別訂單層面分配 — 而非從預設樞紐假設。一名將庫存分散於德國及波蘭節點的賣家,可能因庫存可用性而從其中任一位置發貨同一 SKU。每一次發貨來源均會產生不同的稅務時點記錄,並可能就同一目的地國產生不同的增值稅稅率計算。
數據架構在何處崩潰
最常見的故障模式是訂單管理系統與倉庫管理系統之間的不匹配。訂單系統記錄銷售渠道及買家國家。倉庫系統記錄發貨位置及承運商交接。若這兩個系統沒有在履行交接後仍然有效的共同訂單識別碼,則稅務記錄中便會欠缺發貨國家欄位。
第二個故障點是產品類別對應。增值稅稅率不僅因目的地國而異,亦因產品類型而異。在同一出庫流程中同時運送食品補充劑、電子產品及服裝的賣家,必須對同一包裹中的不同 SKU 應用不同稅率。若產品類別未在發貨前於訂單數據中對應正確的增值稅稅率,OSS 申報便會出現系統性錯誤,並於每個季度申報中累積。在數據架構階段解決此問題,遠較審計後才更正便宜得多。

實際責任歸屬圖:誰申報什麼
對於進行歐盟範圍 B2C 業務的非歐盟賣家,增值稅義務歸屬分為三個參與者。市場平台就平台促成的銷售承擔視為供應商義務,並向各成員國提交自身增值稅申報。賣家就所有直接網店銷售承擔 OSS 義務,並在其 OSS 登記國家提交單一季度申報。履行合作夥伴則負責數據捕捉層 — 於每張出庫訂單發貨時刻記錄發貨國家、目的地國家及交易價值。
當此責任歸屬圖在業務開始前已清晰,每個參與者均清楚知道自己負責產生及保留哪些數據欄位。若未清晰,賣家通常會在首個 OSS 申報期發現差距,屆時季度申報無法與承運商記錄對賬,因為發貨國家欄位從未被系統性捕捉。在入門時而非申報時建立責任歸屬圖,是決定合規是否易於管理或僅為被動反應的營運控制點。
推出後才浮現的隱藏合規缺口
大多數進入歐盟市場的非歐盟賣家,均專注於海關清關、進口增值稅及初步產品登記。持續的 B2C 增值稅合規層 — 特別是 OSS 季度申報 — 往往被視為業務運行後才由會計師處理的行政後續事項。此假設會造成三個特定缺口,在推出後變得昂貴才可彌補。
第一個缺口是追溯發貨數據。若倉庫管理系統未從第一天起便配置為將發貨國家設為必填欄位,賣家便須從承運商清單中重建此數據,而清單未必按訂單參考整理。對於每週發出數百張訂單至多個歐盟目的地的賣家,此重建可能需時數週,且仍可能產生不完整記錄。
第二個缺口是稅率變動風險。歐盟成員國會定期調整特定產品類別的增值稅稅率。若訂單系統中的產品對稅率對應為靜態,且未在成員國改變稅率時更新,賣家可能向買家少收增值稅,並在受影響期間的 OSS 申報中少報。責任始終由賣家承擔,無論結帳時收取了多少。
第三個缺口是 B2B 例外邊界。OSS 僅涵蓋 B2C 銷售。若賣家的歐盟客戶群包括提供有效增值稅號碼的商業買家,則該等交易必須從 OSS 申報中排除,並按反向收取規則處理。若履行系統未在訂單層面標示已登記增值稅的買家,便會將 B2B 及 B2C 交易混入同一數據匯出,須在每個季度申報前手動分隔。
OSS 登記清單
- 確認不存在會要求進行標準增值稅登記而非非聯盟 OSS 的固定歐盟營業場所
- 在登記前取得有效的 EORI 號碼 — 海關所需,且 OSS 入門時通常亦需要
- 根據行政便利性及顧問可用性,選擇 OSS 登記成員國
- 確認您所選登記國家是否需要本地稅務代表
- 對應所有活躍銷售渠道,並確認哪些由市場平台促成,哪些為直接網店銷售
- 確認您 OSS 登記國家的申報日曆及季度截止日期時間表
履行數據準備清單
- 確認倉庫管理系統已在訂單層面捕捉發貨國家欄位,而非從預設樞紐假設
- 將每個活躍 SKU 對應至每個目的地國及產品類別的正確增值稅稅率
- 在訂單管理系統與倉庫管理系統之間建立共通訂單識別碼,並確保其在履行交接後仍然有效
- 在結帳時配置買家增值稅號碼捕捉,以標示 B2B 訂單作反向收取排除
- 確認履行合作夥伴可按訂單參考、目的地國家及發貨日期,為每個季度期間匯出發貨記錄
- 在首個正式申報期前,以樣本 OSS 申報測試數據匯出
首張歐盟包裹發貨前必須鎖定的流程
營運次序至關重要。若非歐盟賣家在完成 OSS 登記前便選擇歐洲履行樞紐,便有風險在未具備有效報告結構的情況下發出應課稅 B2C 包裹。正確次序是平行進行並在首張出庫貨物前匯聚的兩個軌道。
在稅務軌道上:聘請歐盟增值稅顧問確認您的登記類別、選擇 OSS 成員國,並啟動登記程序。OSS 登記可能需時數週,視乎成員國及您的文件是否齊全。切勿等到貨物到達倉庫才開始此程序。
在履行軌道上:與您的 3PL 合作夥伴合作,配置倉庫管理系統以捕捉發貨國家、產品類別增值稅對應及 B2B 訂單標示。確認您的訂單管理平台與履行系統之間的整合,能在訂單層面傳遞所有所需稅務時點欄位。若您的設定使用 API 整合,請在上線前端到端測試數據流程。
在渠道軌道上:審核每個活躍銷售渠道,以確定是否適用市場平台視為供應商規則。對於不適用的每個渠道,確認 OSS 申報將包括該等交易,且該渠道的數據饋送已連接到履行發貨記錄。匯聚點是一個單一、可對賬的數據集,涵蓋每張 B2C 發貨、每個目的地國家及每項適用增值稅稅率 — 無需手動重建即可用於首份季度 OSS 申報。
多節點履行與發貨國家複雜性
將庫存分散至兩個或以上歐盟倉庫位置的賣家 — 例如以波蘭為主要樞紐、德國為次要緩衝 — 會面對額外的發貨國家複雜性。同一 SKU 可能視乎庫存水平、承運商截單時間或送貨承諾要求,而從其中任一位置發貨。每一次發貨來源均為獨立的稅務時點記錄,並可能就同一目的地國產生不同的增值稅處理。
這並非理論上的邊緣情況。圍繞多節點建立的泛歐履行基礎設施,正是專為縮短全洲送貨時間及降低承運商成本而設計。但這要求倉庫管理系統在訂單層面動態分配發貨國家欄位,而非在產品層面靜態分配。假設所有發貨均來自單一樞紐的 OSS 申報,會在第二個倉庫節點上線的瞬間產生系統性錯誤的申報。在擴展至第二個位置前配置多節點發貨的數據架構,才是正確的營運次序。

門檻規則
從外國或多國 3PL 節點發貨的銷售不計入每年 10,000 歐元門檻計算。使用集中歐盟樞紐的非歐盟賣家,應假設從第一筆銷售起,每筆 B2C 交易均適用目的地國增值稅稅率。
稅務時點規則
增值稅稅務時點為確認發貨事件 — 即包裹離開倉庫並建立承運商追蹤記錄的時刻。此欄位必須在發貨時自動捕捉,而非從月底承運商發票或訂單匯出中追溯重建。
渠道分隔規則
受視為供應商制度涵蓋的市場平台促成銷售,必須從您的 OSS 申報中排除。直接網店銷售必須包括在內。在同一數據匯出中混合這兩個流程,會產生系統性錯誤的季度申報,並於每個報告期中累積。
首件歐盟包裹發貨前必須鎖定的三件事
包括波蘭 UC147 法案在內的 ViDA 轉化,並無為非歐盟賣家創造新稅項,而是澄清及收緊已適用的規則。對於使用歐洲履行樞紐為全洲 B2C 客戶提供服務的英國、美國或香港品牌而言,實際效果是合規基礎設施必須在首件包裹發貨前便已就位 — 而非在首份季度申報截止日期後才被動組裝。
三項決定決定您的 OSS 合規是易於管理還是脆弱。首先,在倉庫入門同時(而非之後)確認您的登記類別並啟動非聯盟 OSS 登記。其次,配置您的履行數據架構,以在每張出庫貨物的訂單層面捕捉發貨國家、目的地國家、產品增值稅類別及渠道類型。第三,建立清晰的責任歸屬圖:市場平台就平台銷售處理視為供應商義務;您的 OSS 登記涵蓋直接網店銷售;您的履行合作夥伴的發貨記錄是兩者的來源數據。
將增值稅合規服務視為稅務申報練習而非數據及營運紀律的賣家,一致地遇到同一個問題:季度申報無法準確提交,因為底層發貨數據從未被系統性捕捉。解決方案是架構性而非行政性的,且在正式上線前實施遠較在現有業務中追溯修改容易得多。

若您正在規劃歐盟範圍 B2C 履行,並需要一個倉庫合作夥伴,其系統能在發貨時自動捕捉發貨國家、目的地國家及訂單渠道數據,請聯絡 FLEX. 團隊,了解我們的歐洲履行基礎設施如何支援您的 OSS 合規數據要求。
請向合資格的歐盟稅務顧問確認您特定的增值稅登記義務及申報要求。FLEX. 提供營運及數據層 — 準確的發貨記錄、多節點庫存追蹤,以及歐盟範圍的 B2C 訂單履行 — 讓您的稅務顧問的工作變得可行。



