香港電商 ERP 對接 Shopify 選型指南（2026 實戰版）

選 ERP 對接 Shopify，先定清楚三件事：主數據主權歸誰、庫存與訂單的同步頻率要求、以及跨境多幣種多實體的會計結構。技術上再決定用原生連接器、iPaaS，還是自建中介層。本文拆解香港及亞太企業的選型框架與落地細節。

為什麼香港電商的 ERP 對接比歐美複雜？

香港市場的特殊性不在規模，而在結構。一間典型的香港零售或品牌商，往往同時營運：實體門市（POS）、Shopify 官網、HKTVmall / 天貓 / Lazada / Shopee 等平台店、以及面向內地或東南亞的跨境渠道。每一條渠道都有自己的庫存承諾、價格策略與結算週期。

根據香港政府統計處的零售業銷貨額統計，網上銷售只佔整體零售業銷貨價值約 2% 的水平，遠低於內地及英美市場——這代表大部分香港企業的 ERP 是「以門市與批發為中心」設計的，電商只是後來加上去的一條支線。對接時最大的矛盾往往不是 API，而是 ERP 的主數據模型根本沒預留電商需要的欄位（變體屬性、SEO 內容、渠道專屬價目表）。

另一層複雜度來自跨境。Shopify 官方資料顯示，Shopify Markets 支援單一店舖處理多市場的貨幣、稅務與網域設定；但 ERP 端能否對應同一法人實體下的多幣種應收、或多法人實體之間的內部轉撥，差異極大。先搞清楚你的公司架構（香港控股 + 新加坡或馬來西亞倉儲 + 台灣在地公司），再去看 ERP 的多實體能力，順序不要倒轉。

先回答五條問題，才看產品

做選型前，建議把以下五項寫成白紙黑字的需求基線。沒有這份基線，任何 demo 都會看起來很好。

1. 主數據主權：SKU、價格、庫存的「真相來源」（system of record）在 ERP 還是 Shopify？大多數零售與分銷業務應該是 ERP；純 DTC 新品牌則可能反過來。
2. 同步延遲容忍度：庫存是否需要近即時（秒級）？還是每 15 分鐘批次足夠？秒級同步的成本可能是批次的數倍。
3. 訂單生命週期的分界：Shopify 負責到哪一步（付款、風控、履行觸發），ERP 從哪一步接手（撿貨、發票、退換貨、會計入賬）。
4. 多實體與多幣種：是否需要跨港、新、台、澳多法人合併報表？外幣重估與轉撥定價由誰處理？
5. 峰值負載：雙十一、聖誕、週年慶的每分鐘訂單峰值是多少？這直接決定你要不要排隊機制。

我們在為一間香港多品牌餐飲集團做會員與電商整合時，最後花最多時間的不是寫 API，而是把三個品牌各自的「套餐 SKU」在 ERP 中重新建模，讓 Shopify 的 bundle 能映射到可盤點的實體物料。先談數據模型，後談工具，是省錢的唯一方法。

四條對接路線的真實成本與取捨

路線一：ERP 原生 / 官方連接器

SAP Business One、Oracle NetSuite、Microsoft Dynamics 365 Business Central 都有官方或認證夥伴提供的 Shopify 連接器。Microsoft Learn 的文件指出 Dynamics 365 Business Central 內建 Shopify Connector，可同步產品、客戶、訂單與庫存，屬於開箱即用的範疇。

適合：業務流程標準、SKU 結構乾淨、單一市場為主。 代價：欄位映射彈性有限。一旦你有渠道專屬價目表、複雜的促銷組合或自訂履行邏輯，連接器往往要靠額外擴充開發，反而比自建更貴。

路線二：iPaaS 中介平台

Celigo、Boomi、Workato、Make 一類平台提供預建流程 + 低代碼編排。Celigo 公開的 integrator.io 產品文件說明其針對 NetSuite–Shopify 提供預建 integration app，包含訂單、履行、退款、庫存等流程模板。

適合：多系統（ERP + WMS + 3PL + CRM + 客服）需要編排、團隊有 ops 人力但缺後端工程師。 代價：按連接數或任務量計費，訂單量上去後成本會線性甚至超線性增長；除錯時你在看別人的黑盒。

路線三：自建中介層（middleware）

用 Node.js / Python 服務 + 訊息佇列（SQS、RabbitMQ）+ 自有資料庫，承接 Shopify webhook 與 ERP API。

適合：訂單量大、邏輯特殊、需要把多個 Shopify 店舖與多個市場收斂成單一管道。 代價：你要自己負責重試、冪等、監控、值班。沒有長期維運團隊就不要走這條路。

路線四：雲原生 ERP 直接取代

若現有 ERP 是十年以上的本地部署系統且沒有可用 API，有時換 ERP（NetSuite、Business Central、Odoo）比硬接更划算。Odoo 官方文件說明其提供 Shopify 連接模組與開放的 XML-RPC / JSON-RPC API，對中小型業務的總持有成本相對友善。

代價：ERP 遷移是財務與營運專案，不是 IT 專案。預算與時程通常是整合專案的數倍。

Shopify 端的技術限制，你必須先知道

選型會被 Shopify 的 API 行為直接約束。根據 Shopify 開發者文件：

• GraphQL Admin API 採計算成本制，標準方案每秒回復 100 點、桶容量 1,000 點；Shopify Plus 享有 10 倍額度。REST Admin API 則以每秒請求數計（標準 2 req/s、Plus 20 req/s）。
• Webhook 重試機制：Shopify 文件說明若你的端點未在限定時間內回 2xx，Shopify 會在 48 小時內重試 19 次，之後刪除該訂閱。也就是說，你的接收端必須在數秒內回應並把工作丟進佇列，不能同步呼叫 ERP。
• Bulk Operations 適合初始化與夜間對賬，不適合即時同步。

接收端的最小正確寫法大概是這樣：

1// Express：先驗簽 → 立即回 200 → 丟佇列
2import crypto from 'crypto';
3
4app.post('/webhooks/orders-create',
5  express.raw({ type: 'application/json' }),
6  async (req, res) => {
7    const hmac = req.get('X-Shopify-Hmac-Sha256');
8    const digest = crypto
9      .createHmac('sha256', process.env.SHOPIFY_WEBHOOK_SECRET)
10      .update(req.body)
11      .digest('base64');
12
13    if (!crypto.timingSafeEqual(Buffer.from(digest), Buffer.from(hmac))) {
14      return res.status(401).send('invalid hmac');
15    }
16
17    // 冪等鍵：同一 webhook 重送不可重複入賬
18    const eventId = req.get('X-Shopify-Event-Id');
19    await queue.enqueue('erp.order.sync', {
20      eventId,
21      payload: JSON.parse(req.body.toString()),
22    });
23
24    res.status(200).send('ok'); // 必須在幾秒內回應
25  });

庫存回寫則建議用 GraphQL 批次變更，減少點數消耗：

1mutation SetOnHand($input: InventorySetOnHandQuantitiesInput!) {
2  inventorySetOnHandQuantities(input: $input) {
3    inventoryAdjustmentGroup { createdAt reason }
4    userErrors { field message }
5  }
6}

1# 檢查目前點數餘額（throttleStatus 在每次回應的 extensions 中）
2curl -s https://your-shop.myshopify.com/admin/api/2025-10/graphql.json \
3  -H "X-Shopify-Access-Token: $TOKEN" \
4  -H "Content-Type: application/json" \
5  -d '{"query":"{ shop { name } }"}' | jq '.extensions.cost.throttleStatus'

跨境營運：香港作為亞太整合樞紐的實際優勢

對歐美品牌而言，把 ERP–Shopify 整合的營運中心放在亞太，不是為了便宜，而是為了「時區覆蓋 + 在地規則知識」。

• 時區：香港、新加坡、台北與澳洲東岸合起來，可覆蓋歐洲開市到美西收市之間的大部分時段。對於需要在雙十一或黑五期間盯著訂單佇列的團隊，這是實打實的值班成本結構。
• 在地支付與物流：香港常見 PayMe、FPS、八達通；台灣有超商取貨付款（CVS COD）；東南亞 COD 比例仍高。根據 Worldpay 的《Global Payments Report》，亞太地區數位錢包在電商交易中的佔比明顯高於北美與歐洲。這些支付方式的對賬邏輯必須在 ERP 裡建模，不是 Shopify 端設定一下就算完。
• 稅務與申報：新加坡 GST、澳洲 GST、台灣統一發票、歐盟 IOSS——每一項都影響你的訂單欄位設計。統一發票尤其典型：發票號碼必須由在地加值中心配號，ERP 必須持有該號碼，Shopify 只能顯示。
• 資料合規：香港《個人資料（私隱）條例》對跨境資料轉移有其指引，私隱專員公署亦就跨境轉移發出建議範本條款。整合設計時要決定顧客個資複製到哪些系統、保存多久。

AI 能幫到哪裡，不能幫到哪裡

2026 年的現實是：LLM 已經可以顯著壓縮整合專案的部分工作量，但壓縮的位置可能和你想的不一樣。

實際有效的用法

• 欄位映射草稿：把 ERP 的 item master schema 與 Shopify 的 ProductVariant schema 一起餵給模型，產出初版映射表與轉換規則，再由人工修正。省的是機械勞動。
• 錯誤分類與值班輔助：把同步失敗日誌交給模型做歸類（「這 80% 是同一個稅碼缺失」），比人工翻 log 快。
• 對賬異常說明：自動把「Shopify 收款 vs ERP 入賬」的差異生成可讀摘要給財務。
• 測試資料生成：產生涵蓋邊界情況的訂單樣本（部分退款、多次出貨、混合幣種）。

不該交給 AI 的部分

• 財務入賬規則與稅務判斷——錯一次的成本遠高於省下的時間。
• 冪等與重試邏輯的最終設計。
• 任何涉及個資的 payload 直接貼進公共模型。要用就用有資料處理協議的企業版本或自託管模型。

怎樣寫一份能比價的 RFP？

供應商報價差三倍，通常不是因為能力差三倍，而是因為需求寫得太模糊。建議把以下項目明確寫進 RFP：

1. 同步對象清單：產品、變體、庫存、價格（含渠道價目表）、客戶、訂單、出貨、退款、發票、會計分錄——逐項標明方向（ERP→Shopify / Shopify→ERP / 雙向）與頻率。
2. 冪等與重試規範：明確要求供應商說明如何處理 webhook 重送、ERP 超時、部分成功。
3. 對賬機制：每日自動對賬報表的定義（訂單數、金額、庫存差異），以及差異的處理流程。
4. 監控與告警：佇列積壓、同步失敗率、API 點數耗盡的告警門檻與通知渠道。
5. 峰值測試：要求在 UAT 階段做一次等同歷史峰值 2 倍的壓測。
6. 交付物與擁有權：原始碼、文件、環境、API 憑證歸屬。這一條最常被忽略，也最常在換供應商時變成談判籌碼。
7. 維運責任矩陣：誰負責 Shopify API 版本升級（Shopify 的 Admin API 版本每季發布、支援期約一年）、誰負責 ERP patch 後的回歸測試。

落地節奏：分階段，不要大爆炸

第 0 階段 — 數據清理（常被低估） 清 SKU、統一單位、處理重複客戶、決定哪些歷史訂單要遷移。如果 ERP 裡有三千個無效 SKU，先刪再接。

第 1 階段 — 單向只讀 先做 ERP → Shopify 的產品與庫存推送，觀察兩週。此階段風險最低，但能暴露 80% 的數據模型問題。

第 2 階段 — 訂單下行 Shopify → ERP 訂單寫入，但先不自動入賬，由財務人工覆核一段時間。

第 3 階段 — 履行與退款閉環 出貨回寫追蹤號、退款與退貨同步。這一段的邊界情況最多：部分退款、換貨、跨倉拆單。

第 4 階段 — 多市場擴展 再加第二、第三個市場或店舖，並在此時驗證多幣種與多實體邏輯。

每一階段都保留回滾路徑。最實用的做法是保留一個「手動補單」工具，讓營運團隊在同步失敗時可以不求人地修正單筆訂單。

常見失敗模式

• 用 Shopify 做庫存真相來源，但門市在 ERP 出貨：超賣幾乎必然發生。要嘛統一到 ERP，要嘛在 Shopify 保留安全庫存緩衝。
• 同步呼叫 ERP：webhook 端點直接等 ERP 回應，ERP 一慢就觸發 Shopify 重試，造成重複訂單。
• 沒有冪等鍵：同一張訂單入賬兩次，財務月結時才發現。
• 忽略 API 版本淘汰：Shopify Admin API 每季發新版、舊版約一年後停用，沒有升級流程的整合遲早靜默失效。
• 把促銷邏輯寫死在中介層：行銷每改一次規則就要發版，團隊會繞過系統手動操作，數據從此不可信。

怎樣判斷供應商是否真的做過

問這幾條問題，答得出來的通常有實戰經驗：

• 你如何處理 Shopify webhook 的亂序到達（order/updated 先於 order/create）？
• 多幣種訂單在 ERP 的匯率用交易日還是結算日？誰決定？
• 當 ERP 在月結鎖賬期間拒絕寫入，你的佇列如何處理？
• 你的對賬報表怎樣定義「差異」？能否示範一份實際輸出（可去識別化）？
• Shopify Plus 與標準方案在你的架構下，限流策略有何不同？

選型的本質不是挑最強的工具，而是挑一套你的團隊在三年後仍然維護得起的架構。把數據模型談清楚、把責任界線寫清楚，剩下的工具選擇往往會自己浮現。

Branch8 總部設於香港，並在新加坡、台灣、越南、馬來西亞、印尼、菲律賓與澳洲設有交付團隊，長期處理 Shopify Plus 與 SAP Business One、NetSuite、Business Central、Odoo 的跨境整合與維運。如果你正在評估 ERP 對接路線，歡迎與我們預約一次技術評估會議，我們會先看你的數據模型，再談工具。

Sources

• Shopify — Admin API Documentation
• Shopify — Webhooks Overview
• Microsoft Learn — Dynamics 365 Business Central Shopify Connector
• Oracle NetSuite — SuiteCloud Platform
• SAP — SAP Business One
• Odoo — Official Documentation
• 香港政府統計處 — Census and Statistics Department
• 香港個人資料私隱專員公署 — PCPD