香港一人電商升級：何時該引入 ERP 而非只靠 Shopify 後台

當訂單量、SKU 數與銷售渠道同時增長，而你每週花在對帳、庫存核對與人手輸單的時間超過 8 小時時，就是引入 ERP 的訊號。單一渠道、SKU 少於 300、只用一個倉的一人電商，Shopify 後台加上幾個應用通常仍然足夠。

先釐清：ERP 解決的問題和 Shopify 後台不一樣

Shopify 後台是一個銷售與履行系統。它管理商品、訂單、客戶、庫存數量、折扣與基本報表,做得相當完整。Shopify 在 2024 年度財報中公布全年 GMV 為 2,923 億美元,支撐這個規模的正是它在訂單流程上的深度。

ERP 則是一個帳務與資源系統。它的核心是總帳(General Ledger)、應收應付、成本會計、採購與多實體合併。ERP 之所以存在,是因為當一盤生意有多個庫存地點、多間公司實體、多種幣別與多條採購鏈時,「訂單資料」和「財務真相」會開始分岔。

這個分岔點,就是決策點。在分岔之前買 ERP,你買到的是一個更慢的 Shopify 後台;在分岔之後才買,你付的是幾個月的人手救火成本與錯誤庫存造成的超賣。

Shopify 後台的實際能力邊界

公平地說,Shopify 原生功能比很多人以為的要遠:

• 多地點庫存:Shopify 原生支援多個 inventory location,並可按地點設定履行優先順序
• Shopify Markets:多國定價、多幣別結帳、稅務地區設定
• B2B on Shopify(Plus 專屬):公司帳戶、分級價目表、淨額付款條件
• Admin GraphQL API:幾乎所有後台物件都可讀寫,是所有整合的基礎

它明確做不到的:

• 沒有總帳、沒有試算表、不能出資產負債表
• 沒有採購訂單(PO)與供應商應付帳款管理
• 沒有落地成本(landed cost)計算——運費、關稅、報關費無法攤分到 SKU 成本
• 沒有批次/序號追蹤(Plus 亦需外掛)
• 跨多間 Shopify store(例如 HK store + TW store)之間沒有統一庫存與統一財務視圖

七個真正代表「該上 ERP」的訊號

不要用營業額做判斷標準。同樣月流水,賣三款保養品和賣 2,000 個五金零件,複雜度差十倍。用以下訊號:

1. 你在兩個以上系統重複輸入同一筆資料。 訂單在 Shopify、發票在 Xero、庫存在 Google Sheet,而且三者每月至少對不上一次。
2. 你開始持有跨境庫存。 香港倉 + 台灣 3PL + 深圳工廠寄倉,任何一邊缺貨你都不會即時知道。
3. 你需要真實的毛利,而不是「售價減進價」。 海運費、關稅、退貨損耗、平台佣金都要攤回 SKU。
4. 你有兩間以上公司實體。 例如香港公司收單、新加坡公司開發票給歐盟客戶,需要公司間交易(intercompany)與合併報表。
5. 採購變成一個流程,而不是一則 WhatsApp。 有 PO、有部分到貨、有預付訂金、有匯率差。
6. 渠道超過三條。 自家 Shopify、Amazon、蝦皮、Lazada、線下寄賣、批發客——每條渠道的庫存扣減與結算週期都不同。
7. 審計或投資人開始要求資料。 融資盡職調查時,Shopify 報表無法作為財務底稿。

出現 1–2 項,先用整合工具補洞。出現 4 項以上,ERP 的總持有成本通常已低於人手成本。

在買 ERP 之前,先算清楚這三筆帳

人手時間的真實成本

記錄自己連續兩週的行政時間,分類記在以下四項:訂單同步、庫存核對、對帳與開票、報表製作。一人電商最常見的情況是,這四項合計佔每週 10–15 小時。這些時間本來可以用在選品與廣告——ERP 的回報不是「省錢」,是把創辦人的時間換回來。

實施成本遠大於授權費

無論你選 Odoo、Zoho、SAP Business One 還是 Oracle NetSuite,授權費通常只佔第一年總成本的三分之一。主要成本在:

• 科目表(Chart of Accounts)設計與期初餘額匯入
• SKU 主檔清洗——這一步幾乎永遠比預期久
• Shopify ↔ ERP 的雙向同步邏輯與例外處理
• 團隊訓練與並行運行期(parallel run)

Gartner 長期在其 ERP 研究中指出,ERP 專案超支與延期的主因多為資料品質與流程未先梳理,而非軟體本身功能不足。對一人團隊而言,這代表:先清 SKU 主檔,再談選型。

反向成本:過早上線的僵化代價

ERP 的價值來自紀律,但紀律對高速試錯是阻力。如果你還在每月換供應商、改包裝、測新品類,ERP 的主檔維護會拖慢你。這是真實的取捨,不是藉口。

四條升級路線,以及各自適合誰

路線一:Shopify 原生 + 應用堆疊

適合:單一實體、1–2 個庫存地點、SKU 少於 500。

組合通常是 Shopify + Xero 或 QuickBooks + 一個庫存應用 + 一個 3PL 連接器。優點是啟動快、月費可預測、可隨時拆換。缺點是 App 數量一過六個,彼此的同步時序會開始互相踩踏,而且沒有單一真相來源。

路線二:輕量雲 ERP(Odoo、Zoho One、ERPNext)

適合:2–10 人、開始有採購與多倉、預算敏感但需要總帳。

Odoo 的模組化設計讓你可以只開 Inventory + Purchase + Accounting,日後再加 Manufacturing。它有官方 Shopify 連接器,亦有完整的 XML-RPC / JSON-RPC API 可自建同步。ERPNext 則是完全開源、可自架,適合技術背景創辦人。缺點:香港與台灣的本地會計慣例(如台灣電子發票、香港審計格式)通常需要在地夥伴調整。

路線三:區域級 ERP(SAP Business One、Oracle NetSuite)

適合:多法律實體、跨境合併報表、有外部投資人或準備上市。

NetSuite 的 OneWorld 模組原生處理多幣別、多實體與合併,對「香港控股 + 新加坡營運 + 澳洲銷售」這種常見亞太結構很直接。代價是實施週期以季度計,而且一旦上線,流程變更的成本很高。

路線四:不買 ERP,先建整合中台

適合:技術能力強、系統組合特殊、暫時不想被單一供應商綁定。

用 Shopify Admin API + 一個工作流引擎(n8n、Make、或自寫服務)把訂單、庫存、財務資料集中到一個資料倉(BigQuery、Postgres),先取得統一視圖與報表,再決定要不要換核心系統。這條路的風險是:它很容易變成一個沒人維護的內部系統。

技術層面:Shopify 與 ERP 之間該同步什麼

最常見的錯誤是「全部都同步」。實務上只有四條資料流真正重要,而且方向要固定。

ERP → Shopify:商品主檔、價格、庫存可售量(available to sell)。 Shopify → ERP:訂單、退款、付款結算、客戶資料。

庫存必須單向,由 ERP 作為真相來源,否則雙向同步會在高峰期產生競態條件與超賣。

以 Admin GraphQL API 查詢多地點庫存為例:

1query InventoryByLocation($sku: String!) {
2  productVariants(first: 1, query: $sku) {
3    edges {
4      node {
5        sku
6        inventoryItem {
7          id
8          inventoryLevels(first: 10) {
9            edges {
10              node {
11                location { name }
12                quantities(names: ["available", "committed", "on_hand"]) {
13                  name
14                  quantity
15                }
16              }
17            }
18          }
19        }
20      }
21    }
22  }
23}

由 ERP 回寫庫存時,使用 inventorySetQuantities 這類 mutation 設定絕對值,而不是用增減式調整——後者在重送(retry)時會重複扣減。

訂單方向則應該用 webhook 而非輪詢。以 Shopify CLI 在本機測試:

1shopify app generate webhook
2shopify webhook trigger --topic=orders/create --api-version=2025-01 \
3  --address=https://your-middleware.example.com/hooks/orders

必須注意 API 用量限制:根據 Shopify 開發者文件,Admin GraphQL API 採計算成本制,標準商店的補充速率為每秒 100 點、桶容量 2,000 點,Shopify Plus 商店為 10 倍;REST Admin API 標準為每秒 2 次請求。這代表大量歷史資料回填(backfill)必須分批排程,不能在切換當晚一次跑完。

中介層要有的三件事,缺一不可:

1. 冪等鍵(idempotency key)——同一張訂單重送不能產生兩張發票
2. 死信佇列(dead letter queue)——同步失敗的記錄要能重放,不能靜默丟失
3. 每日對帳作業——比對 Shopify 訂單數與 ERP 銷售單數,差異自動報警

跨境營運:為什麼香港團隊的門檻比想像中早到

香港市場本身不大。根據香港政府統計處的零售業銷貨額統計,網上銷售佔整體零售業銷貨價值的比例僅約百分之二至三,遠低於中國內地與英國。這意味著幾乎所有有規模企圖的香港電商,都必須在很早期就跨境——而跨境正是把 Shopify 後台推出能力邊界的主因。

典型的亞太擴張路徑會依序踩到這些線:

• 台灣:電子發票(B2C 需開立雲端發票)與 7-11 / 全家超商取貨付款,兩者都需要與訂單系統對接
• 新加坡:低價值進口貨品的 GST 制度自 2023 年起擴及境外供應商,需要按客戶所在地判斷稅務處理
• 澳洲:A$1,000 以下進口商品的 GST 由境外賣家收取,門檻低、觸發早
• 馬來西亞、印尼、菲律賓:在地支付方式(FPX、QRIS、GCash)與 3PL 的回傳格式各不相同
• 歐盟:IOSS 申報與 €150 門檻

每多一個市場,就多一組稅務規則、一個倉、一套結算週期。Shopify Markets 能處理前台的價格與稅務顯示,但不能處理後台的多實體帳務與跨境成本攤分。這就是分岔點在香港團隊身上來得特別早的原因。

以香港為亞太樞紐的實際優勢在於:時區覆蓋從東京到雪梨只需一個工作日、簡單稅制讓控股結構清晰、而人才可以理解繁中、簡中與英文三套市場邏輯。ERP 選型時應該直接把「未來 24 個月會進哪三個市場」放進需求清單,而不是等進去了才補。

AI 能不能讓你晚一年才上 ERP?

可以延後,但不能取代。

2025 年後普及的 LLM 工作流確實改變了小團隊的行政負載結構。實際可行的用法包括:

• 文件擷取:供應商 PDF 發票、報關單、3PL 對帳單自動轉結構化資料,再寫入會計系統
• 例外分類:同步失敗的訂單由 LLM 先判斷原因(地址格式、稅務代碼、SKU 不存在)並分流
• 查詢介面:用自然語言查「上月台灣渠道毛利最低的十個 SKU」,由模型產生 SQL 查資料倉
• 客服草稿:訂單狀態查詢自動回覆,由人工審核後送出

這些能把「重複輸入」的時間壓下去,所以訊號 1 可以靠 AI 緩解。但訊號 4(多實體)、訊號 3(落地成本)與訊號 7(審計)是結構性問題,不是效率問題——沒有總帳就是沒有總帳,AI 不會憑空生出一套可審計的複式記帳。

合理的做法是:用 AI 把 ERP 上線時間往後推 6–12 個月,同時用這段時間把 SKU 主檔與科目表整理乾淨。這樣當你真的上 ERP 時,資料品質問題已經解決了一半。

一個實務觀察:先清主檔,再談選型

Branch8 曾為一家香港家居用品品牌處理系統升級,其形態相當典型:創辦人兼營運,主站在 Shopify,另有台灣與新加坡兩個市場,加上一個蝦皮店與若干批發客戶。庫存分散在香港自倉與台灣 3PL。

在評估 ERP 之前,我們先做的不是選型,而是主檔盤點。結果發現同一件商品在不同渠道存在三種 SKU 命名法,顏色與尺寸的變體結構在 Shopify 與 3PL 系統中不一致,而部分歷史訂單的成本欄位是空的。

這件事的意義是:如果當時直接把 ERP 連上去,同步邏輯會在第一週就爆炸,而團隊會誤以為是 ERP 選錯了。實務上,主檔清洗、庫存單位統一與科目表設計這三步,應該在任何 ERP 合約簽署之前完成。工具層面,我們通常用 Shopify Admin GraphQL API 搭配一個中介服務處理同步,並在切換前跑至少一個完整月結週期的並行運行。

90 天分階段路線圖

第 1–30 天:盤點與清洗

1. 匯出全部 SKU、庫存地點、供應商與過去 12 個月訂單
2. 統一 SKU 命名規則與計量單位,標記停售品
3. 與會計師確認科目表結構與多實體需求
4. 記錄現行流程的每週人手時數,作為日後基準

第 31–60 天:選型與試點

1. 用真實資料(不是廠商 demo 資料)做概念驗證,至少涵蓋一個跨境訂單與一次退貨
2. 確認 Shopify 連接器是官方維護還是第三方——後者的 API 版本更新風險較高
3. 測試 API 用量在你的訂單高峰下是否足夠

第 61–90 天:並行運行與切換

1. 舊系統與 ERP 同時運行一個完整月結週期,逐項比對
2. 建立每日自動對帳報警
3. 切換日選在銷售淡季,避開雙 11、黑五與農曆新年備貨期
4. 保留舊系統唯讀權限至少六個月

最常見的五個錯誤

• 先簽約、後清資料。成本最高的一個順序錯誤。
• 雙向同步庫存。看似安全,實際製造競態條件。指定一個真相來源。
• 在旺季切換。任何系統切換的前兩週都會有例外訂單,不要讓它們撞上營業額高峰。
• 只評估功能,不評估在地合規。台灣電子發票、澳洲 GST、歐盟 IOSS 這些在 demo 中不會出現。
• 沒有退出計劃。確認你的資料能以標準格式完整匯出,包括歷史交易與附件。

決策清單:現在就能回答的六個問題

1. 我有幾個法律實體?幾個庫存地點?未來 24 個月會變成幾個?
2. 我能不能在五分鐘內說出上個月某個 SKU 的真實落地成本?
3. 我每週花多少小時在重複輸入?
4. 我的 SKU 主檔在所有系統中一致嗎?
5. 如果明天有投資人要三年財務報表,我要花多久準備?
6. 我未來一年會進哪些新市場,各自的稅務與履行要求是什麼?

如果第 1 題的答案是「一個、一個、可能還是一個」,而第 2 題你能回答——留在 Shopify 後台,把錢花在流量上。如果第 1 題有多個實體、第 5 題的答案以週計,ERP 的討論應該從「要不要」變成「哪一套、什麼時候」。

Branch8 在香港、新加坡、台灣、越南、馬來西亞、印尼、菲律賓與澳洲設有交付團隊,協助品牌處理 Shopify Plus、Adobe Commerce 與 SHOPLINE 的系統整合、ERP 對接與跨境營運架構。如果你正在判斷升級時機,歡迎與我們談談你的資料現況與擴張計劃——我們通常會建議從主檔盤點開始,而不是從選型開始。

Sources

• Shopify — Investor Relations
• Shopify Developers — Admin GraphQL API
• Shopify Developers — API Rate Limits
• Shopify Help Center — Locations and Inventory
• Hong Kong Census and Statistics Department
• Odoo — Official Documentation
• Oracle NetSuite — ERP
• Gartner — Information Technology Research