電商訂單有 API 自動匯入 ERP，LINE 和 Email 的訂單呢？
晚上十一點，做烘焙原料批發的張老闆還在辦公室。蝦皮店鋪今天的 37 張訂單早就自動匯入 ERP，出貨單都印好了——這段流程他兩年前就搞定了，訂單拋轉系統設好，基本不用管。
他在忙的是另一疊：LINE 裡二十幾條叫貨訊息、Email 附件裡三張 PDF 訂購單，還有傳真機吐出來的兩張手寫單，其中一張的「5」看起來像「6」。這些訂單，一筆一筆，都要靠他自己打進同一套 ERP。
同一家公司、同一套系統，為什麼「訂單匯入 ERP」這件事，一半全自動、一半純手工？這篇文章把這個問題拆開來講：先認真回答電商訂單怎麼拋轉，再回答那個網路上幾乎沒人回答的問題——LINE 和 Email 的訂單怎麼辦。
先把舊問題答好：電商訂單匯入 ERP 的三種方式
如果你 Google「訂單匯入 ERP」或「訂單拋轉」，找到的內容幾乎都在講電商平台，而且方法就三種。
**第一種：Excel 匯出、匯入。**從平台後台匯出訂單報表，整理欄位後用 ERP 的批次匯入功能進系統。零串接成本，但每天要人手動操作，欄位格式對不上就得先在 Excel 裡加工。單量小的時候堪用，單量大了就變成每天固定的苦工。
**第二種：API 串接。**平台開放介面，讓 ERP 直接抓訂單。像鼎新 A1 的雲端電商訂單模組主打各平台訂單一鍵匯入、庫存同步；TMS ERP 的串接列表則涵蓋蝦皮、momo、SHOPLINE、91APP、Shopify 等主流平台，訂單依排程自動進系統。
不過 API 串接有個常被忽略的細節：不是你想串就能串。以蝦皮為例，Shopee 官方的 Open API 說明寫明 API 只開放給商城賣家與第三方系統商（例如 ERP 供應商）；momo 則沒有公開的開發者平台，串接要透過供應商後台申請、綁定系統商的 IP 來做。所以多數中小賣家實際上是「透過 ERP 廠商」間接串接，而不是自己寫程式。
**第三種：中台／拋轉系統。**在平台與 ERP 之間加一層專門的訂單整合系統，統一收單、轉格式、再拋進 ERP。適合同時經營五、六個通路的賣家，連沒開放 API 的平台也能用半自動方式處理。
| Excel 匯出匯入 | API 串接 | 中台／拋轉系統 | |
|---|---|---|---|
| 自動化程度 | 低（每天人工操作） | 高（排程自動抓單） | 高 |
| 建置成本 | 幾乎為零 | 依 ERP 方案而定 | 中～高 |
| 前提條件 | ERP 支援批次匯入 | 平台有開放 API 且你符合資格 | 通路多、單量大才划算 |
| 適合誰 | 單一平台、日單量少 | 主流平台賣家 | 多通路賣家 |
到這裡，電商訂單的問題其實已經被市場解得很好了。真正的問題在下一段。
這三種方法有一個共同前提：訂單是結構化資料
Excel 也好、API 也好、中台也好，它們能運作，是因為平台訂單天生就是「表格」：品項編號、數量、金額、收件人，每個欄位清清楚楚。所謂拋轉，本質上是欄位對欄位的搬運——搬運可以自動化，因為兩邊的格子早就畫好了。
換句話說，這三種方法解決的是「搬運」問題，不是「理解」問題。它們的能力邊界，就畫在訂單長得像不像表格這件事上。
B2B 批發的現實：你的訂單不長那樣
台灣批發業一年的營業額超過 14 兆元，將近零售業的三倍。但這個體量巨大的產業裡，訂單很少從平台來——B2B 的客戶是餐廳、烘焙坊、經銷商、門市，他們下單的方式是：
- LINE 打一句「明天老樣子，再加兩箱大的」
- LINE 傳一張語音：「喂，幫我留十斤梅花，禮拜四出」
- Email 附一個自家格式的 PDF 或 Excel 訂購單
- 傳真一張手寫單，字跡潦草
- 直接打電話
這不是少數公司的特例。LINE 在台灣有 2,200 萬月活躍用戶，官方帳號開了 340 萬個——比台灣的中小企業總數（171.5 萬家）還多。LINE 早就是台灣做生意的預設通道。而資誠與資策會的中小企業調查顯示，近七成中小企業的數位化程度就停留在 Email、通訊與社群工具這一層——訂單從這些工具進來，再自然不過。
問題是：LINE 沒有「訂單 API」可以串。「明天老樣子」四個字，對 API 來說不是資料，是亂碼。於是這些訂單全部回到人工：讀懂、對品號、查價格、一格一格打進 ERP。這段人力的帳我們在〈業務助理一天 key 單 3 小時，一年燒掉多少錢〉算過——以勞動部薪資調查的數字，批發零售業一個事務支援人員年薪約 51.5 萬元，如果一半工時在搬訂單，這筆帳很具體。
非結構化訂單自動轉入 ERP 的三個技術難題
為什麼這段沒有現成的 API 可買？因為「訊息變訂單」要過三關，每一關都不是規則寫得完的。
**第一關：品名對應。**客戶說「大白」，你的 ERP 裡叫「白玉蘿蔔（大）」；客戶說「老樣子」，指的是他每週固定那七個品項。同一個品項，十個客戶有十種叫法。傳統系統要為每個别名建對照表，但客戶的說法會變，表永遠建不完。
第二關：單位換算。「來三件」的「件」是幾包？A 客戶的一件是 12 包，B 客戶的一件是 24 包。箱、件、斤、公斤、尾，同一個品項對不同客戶可能用不同單位計價，換算邏輯藏在老員工的腦袋裡。
第三關：修改與追加。「剛剛那張單，白蝦改成兩箱就好」——這句話要先找到「剛剛那張單」，再改對品項。訂單不是一次成形的，它在對話裡長大，而對話會被後面湧入的訊息淹沒。
這三關，就是「有 API 的世界」和「沒 API 的世界」之間的鴻溝。
AI 怎麼解這三題：從「搬運」升級到「理解」
大型語言模型（LLM）改變的，是機器第一次能處理「語意」而不只是「格式」。AI 接單的做法是：訊息進來（文字、圖片、語音都行），AI 比對你的品號表、該客戶的歷史訂單與慣用語，把「明天老樣子再加兩箱」翻譯成結構化的訂單草稿——品項、數量、單位、交期填好，沒把握的欄位標記出來，由人確認後寫入 ERP。
三個難題的解法對應是：品名對應靠「客戶專屬詞庫＋歷史訂單比對」，單位換算靠「客戶別的單位對應表」，修改追加靠「AI 把同一張單的多輪對話串起來」。人的角色從逐字打字，變成看一眼、按確認。
效益有多大？McKinsey 的研究提到，導入訂單流程自動化的企業，訂單處理時間可以從兩三天縮到一兩個小時；而人工輸入的錯誤率，業界常引用的人因研究數字是每筆輸入約 1%——一張訂單十幾個欄位、一天幾十張單，錯誤是常態不是意外。
對客戶端來說，最重要的一句話是：他們什麼都不用改。不用裝 App、不用學新系統、不用照你的格式填單——繼續在原本的 LINE 對話裡打那句「老樣子」。改變全部發生在你這一端。這也是 AI 理解訂單和「請客戶改用下單系統」最根本的差別，後者為什麼常常推不動，我們在〈B2B 下單系統做好了，經銷商為什麼不用〉寫得很直白。
誠實說，AI 也有它的邊界。口語訂單天生有歧義，所以人工複核不是選配，是必要設計；如果你的品項大量涉及時價與當日議價，AI 能整理品項和數量，價格仍要人拍板。還有，如果你日單量不到十筆，這套投資大概划不來——請人順手處理可能更便宜。
你需要哪一種？三個判斷題
**第一題：你的訂單從哪裡來？**如果九成以上來自電商平台，用本文前半段的拋轉方案就夠了，不需要 AI。如果 LINE、Email、電話佔了大宗——多數 B2B 批發商是這樣——搬運型工具幫不上忙，你缺的是理解層。
**第二題：日單量多少？**十筆以下，人工還撐得住；三十筆以上，每天花在 key 單的時間已經值得認真算一次帳。
**第三題：你有沒有本錢要求客戶改變？**客戶集中在少數幾家大經銷商、你有談判力，推下單系統可行。客戶多而分散、下單習慣五花八門，那麼唯一不得罪客戶的路，就是讓系統來配合客戶，而不是反過來。
兩邊都有的公司（平台＋LINE 雙軌）也不必二選一：平台訂單走拋轉、非結構化訂單走 AI 理解，最後在 ERP 前匯流成同一條流程。哪一種方法對應哪種訊息型態，可以參考〈客戶用 LINE 下單，訂單怎麼自動進 ERP〉的完整比較。
常見問題
我們的 ERP 比較舊，沒有開放 API，AI 接單還能用嗎？
多數情況可以。AI 接單方案寫入 ERP 的方式不只 API 一種：如果你的系統支援 Excel 或 CSV 批次匯入（台灣主流進銷存幾乎都有），AI 整理好的結構化訂單可以走既有的匯入格式進系統；部分方案也支援直接寫入資料庫或 RPA 代打。重點是你不需要為此換掉用了十年的 ERP。
電商平台訂單和 LINE、Email 訂單，可以在同一套流程裡處理嗎？
可以，而且建議這樣做。平台訂單走現成的 API 或拋轉系統，LINE、Email、傳真訂單由 AI 理解後轉成同樣的結構化格式，兩邊在進 ERP 之前匯流成同一條路。這樣庫存、對帳、出貨都只看一套數字，不會出現「系統一套、LINE 一套」的平行世界。
手寫傳真那麼潦草，AI 真的讀得懂嗎？
比你想像的好，但不是百分之百。AI 會結合你的品號表、該客戶的歷史訂單來推斷潦草字跡最可能的意思，並對沒把握的欄位標記出來交給人確認——而不是硬猜。實務上的合理預期是：大部分例行訂單自動完成，最潦草、最模糊的少數訂單由人複核，整體時間仍遠低於全人工。
想知道 AI 讀不讀得懂你們家的訂單？最快的方法是直接試：預約 demo，帶一張你們家最亂的訂單截圖來，看 AI 當場把它變成一張乾淨的 ERP 訂單。