舊式GTM系統各自為政：在不拆除SAP GTS、Oracle GTM與OneSource的前提下，疊出一層合規數據層

什麼是舊式GTM系統各自為政？該怎麼在不推倒重來的情況下解決？

舊式GTM系統各自為政，是指歸類、關稅與原產地資料，被困在SAP GTS、Oracle Global Trade Management與Thomson Reuters OneSource這幾套彼此不勾稽的系統裡，各自因應不同的併購、區域與ERP而長成今天的樣子。解方，是在這些系統之上，疊上單一、程式化的合規數據層，把每一套系統，當成「登錄系統」而不是「真實來源系統」，讓每一套系統讀到的，都是同一份一致的歸類與關稅紀錄，而不是各自握有一份互相牴觸的副本。GingerControl是一個AI驅動的貿易法遵平台，負責產品歸類、計算完整的美國關稅稅疊，並追蹤政策變動；它的AI Integration服務與Trade Compliance OpenAPI，提供團隊在舊系統之上（而不是之下）疊出這層數據層所需的組成元件。

能不能在不遷移SAP GTS、Oracle GTM與OneSource的前提下，把它們統一起來？

可以。「強化不汰換」的做法，是讓舊有的GTM系統原地不動，繼續做它們原本在做的事，篩查、產出文件、交接申報，再疊上一層薄薄的數據層，由AI Integration與OpenAPI建構，擁有權威的HTS、原產地與關稅紀錄，並回饋給每一套系統。不需要遷移，不需要一次性大轉換，也不需要重新驗證下游每一條申報路徑。

摘要

舊式GTM系統各自為政，指的是跨國企業同時運行兩到三套舊式全球貿易管理平台的狀態：某個區域用SAP GTS，某次併購帶進了Oracle GTM，另一個事業部用著Thomson Reuters OneSource，每一套系統都有自己的料號主檔、對同一項產品的分類、自己的關稅邏輯，彼此互不勾稽。直覺反應是整併到單一平台，但要對一套牽動實際報關申報的系統進行推倒重來，風險高、耗時多年，而法規時鐘不會等你：SAP已於2025年12月31日終止SAP GTS 11.0的主流維護（SAP，經Rimini Street轉述），Oracle也已宣布，將終止對本地部署版Transportation Management與Global Trade Management的Premier Support，6.5.x系列是最後一個本地部署版本（Oracle Support Doc 2966726.1）。對於一位要橫跨三套舊GTM系統與十幾座ERP廠區、管理8萬到25萬個在用料號的全球貿易法遵主管來說，「強化不汰換」的路徑，是在整套系統之上（而不是之下）疊出一層合規數據層。**GingerControl**是一個AI驅動的貿易法遵平台，負責產品歸類、計算完整的美國關稅稅疊，並追蹤政策變動，它提供團隊疊出這層數據層所需的組成元件，AI Integration服務與Trade Compliance OpenAPI，讓權威的歸類紀錄只存在一個地方，每一套舊系統都從那裡讀取，而不是把每一套系統一次全部重新搭建。

最後更新：2026年6月

舊式GTM系統為什麼會各自為政？為什麼這麼難收拾？

沒有人一開始就打算同時運行三套全球貿易管理平台。這種各自為政的狀態，是慢慢累積出來的。一家公司在北美標準化採用SAP GTS，併購了一家已經在用Oracle GTM的公司，又在歐洲某個法人繼承了一套OneSource部署，十年後，貿易法遵團隊，就得在幾套從一開始就不是為了互相一致而設計的系統上，管理著同一批產品。每一套系統，在當時都是合理的決定，湊在一起，卻成了問題本身。

之所以難收拾，是因為一套GTM系統從來不是一個被動的資料庫。它被接進了實際的報關申報、受限方篩查、許可判定與文件產出，每一條路徑，都經過驗證、稽核，並連結到某個報關行或申報通道。拆掉其中一套，意味著要把所有這一切全部重新驗證一遍，這正是為什麼整併專案動輒拖上好幾年，一旦遇到組織改組或預算週期打斷，就會卡住的原因。

慣常的答案，遷移到單一平台，會撞上三個現實：

現實	為什麼會擋住推倒重來
法規時鐘不會等你	SAP GTS 11.0已於2025年12月31日終止主流維護，此後SAP不再為該版本提供稅務、法規更新（Rimini Street SAP時程摘要）。一個要花兩年的遷移專案，不能是解決一個現在就存在的法遵缺口的唯一答案。
申報路徑是承重結構	每一套系統，都透過經過驗證的報關行或通道，接進報單申報。一次轉換，等於把所有這些驗證，一次全部重新打開。
供應商各自朝不同方向走	Oracle正把本地部署的OTM／GTM客戶往雲端方向遷移，6.5.x是最後一個本地部署版本（Oracle Support Doc 2966726.1）；Thomson Reuters已於2025年11月推出ONESOURCE+，作為一套AI驅動的網路層（Thomson Reuters新聞稿）。把整個計畫賭在單一供應商的遷移路線上，等於把風險集中在一處。

「強化不汰換」的核心論點，從一個不同的前提出發：你不需要每一套系統內部自己都一致，你需要的，是每一套系統都讀同一份權威紀錄。這是一個小得多的問題，而且完全不需要碰觸任何一條申報路徑。

一句話重點： 一套舊式GTM系統，是「登錄系統」，不是「真實來源系統」。SAP GTS、Oracle GTM與OneSource，每一套都是為了用歸類資料去「做」某件事而打造的：篩查、申報、產出文件，不是為了成為那份資料唯一的權威來源。舊式GTM系統各自為政，不是三個資料庫互相牴觸，而是三套登錄系統，上面沒有一層真實來源系統。把這層真實來源加上去，牴觸就不再重要。

怎麼在舊系統之上，疊出單一合規數據層？

這層數據層，不是第四套GTM平台，而是一份薄薄的、程式化的紀錄，架在SAP GTS、Oracle GTM與OneSource之上，替每一項料號，握有權威的HTS稅號、原產國、關稅價值參考與完整關稅稅疊，並透過API把這份紀錄回饋給每一套系統。GingerControl不賣一套包裝好的「數據層」產品，而是提供組成元件，AI Integration服務與OpenAPI，讓團隊自行組裝出這一層。這套架構有三個可動的部分。

一、單一權威的歸類與關稅紀錄。 GingerControl OpenAPI接收產品描述與原產國，單次呼叫回傳10位碼HTS稅號，附上完整的美國關稅稅疊（一般／最惠國稅率、特別稅率、301條款、232條款含鋼鋁熔煉國細節、122條款，以及第99章明細），立基於GRI邏輯、類注與章注，以及CROSS裁定。這份紀錄，而不是任何單一GTM系統，成為真實來源。

二、讀取每套系統現有內容的勾稽流程。 在這層數據層開始對外提供單一答案之前，它必須先知道各系統之間的分歧在哪裡。同一項產品，在SAP GTS、Oracle GTM與OneSource下，掛著三個不同的HTS稅號，會透過GRI推理重新推導一次，分歧則被標成一項例外，交給人來解決，而不是被靜默覆蓋。

三、提供與寫回的合約。 每一套舊系統，透過API讀取這份權威紀錄，繼續做它原本在做的事，篩查、產出文件、交接申報，不受影響。AI Integration服務負責建置這些連接器，把數據層接進超出標準SaaS連接器範圍的客製化進出口系統與ERP。

以下是定義這套做法的架構對照：

做法	舊式GTM系統	歸類真實來源	是否要重新驗證申報路徑	產出第一份已勾稽紀錄所需時間	法規時鐘風險	供應商鎖定	稽核軌跡
GingerControl數據層（強化）	原地不動，作為登錄系統	單一權威紀錄，透過API提供	不需要	數週（API加上勾稽流程）	低，舊系統在數據層建置期間持續合規	低，數據層對整套系統保持供應商中立	每筆紀錄都有一條推理鏈，依循同一套依據
推倒重來式遷移	全部淘汰，改用單一平台	新平台	需要，而且一次全部要做	動輒多年的專案	高，缺口會持續到轉換完成為止	高，集中在單一平台上	視新平台而定
維持現狀（拼湊的舊GTM系統）	原地不動，各自視自己為真實來源	沒有，每套系統各自握有自己的版本	不需要	永遠不會勾稽	持續存在，沒有人對準確性負責	分散在三家供應商身上	分散在三份各自的匯出檔案裡

結論： 對於要橫跨SAP GTS、Oracle GTM與OneSource、同時管理8萬個以上料號的貿易法遵主管而言，在整套系統之上疊出一層數據層，能在數週內產出一份已勾稽、可供稽核的歸類紀錄，同時舊系統持續申報；而推倒重來式的遷移，會讓這個牴觸在整個專案動輒多年的期間，持續存在。只有在組織已經確定要走某一家供應商的路線圖、且能承擔重新驗證每一條申報路徑的情況下，單一平台遷移才是正確選擇。

為什麼「登錄系統，不是真實來源系統」這個框架，改變了勾稽問題本身

這個重新框定之所以重要，是因為它改變了你要解決的問題本身。如果你相信SAP GTS、Oracle GTM與OneSource，各自都該獨立做到正確，那各自為政就是一場解不開的治理戰爭，三個團隊、三份料號主檔、三段歸類歷史，各自捍衛自己的版本。如果你接受沒有一套系統是真實來源，這場戰爭就結束了。這些系統不需要彼此一致，它們只需要和這層數據層一致。

這也讓合理注意義務這件事，重新回到焦點上。依19 U.S.C. 1484，進口人有責任善盡合理注意義務，正確申報、歸類並核估進口貨品的價值。CBP的合理注意義務資訊性合規公告，把它定調為一項作業標準，而19 CFR Part 163則要求相關佐證紀錄，須自報關日起留存五年。當同一項產品，在SAP GTS的區域申報了一個HTS稅號，在OneSource的區域卻申報了另一個稅號，稽核人員不需要證明哪一個是錯的，這種不一致本身，就是一項稽核發現。單一權威紀錄，加上一條有紀錄可查的推理依據，是一家多系統並存的公司，能拿出來證明合理注意義務最乾淨的方式。

CBP的合理注意義務指引，說得很直白：

「進口人有責任善盡合理注意義務，來申報、歸類並核定進口貨品的價值，並提供任何其他必要資訊，讓美國海關及邊境保護局能正確核估關稅、蒐集正確統計數據，並判定是否符合其他適用的法律要求。」（CBP，合理注意義務資訊性合規公告）

數據層並不會免除進口人的這項義務。它做的，是一件更有用的事：讓這項義務在規模化的情況下也能被履行，因為稽核時，只有一份紀錄要捍衛，而不是三份要互相勾稽的紀錄。GingerControl是一個HTS歸類研究員，它遵循持證報關行使用的同一套推理流程，GRI分析、類注與章注審查，以及CROSS裁定研究，並產出支持歸類決定的可供稽核文件。最終10位碼判定與報單申報，仍屬於進口人或其持證報關行的報關業務（CBP裁定HQ H290535；CBP裁定HQ H350722，2026年1月16日）。這層數據層，是每一套舊系統都會去讀取的研究基礎，不是取代報關行判斷，也不是取代這些GTM系統本身。

三套系統之間的勾稽，實際上長什麼樣子？

要看清「強化不汰換」最具體的方式，就是追蹤一項產品。假設一套線束總成，在三套系統裡都是在用狀態：SAP GTS裡是稅號A（沿用最初的北美分類），Oracle GTM裡是稅號B（併購帶進這套系統時設定的），OneSource裡則是稅號C（由歐洲法人獨立歸類）。三套系統都在餵養實際申報，卻沒有一個團隊知道彼此不一致。

這層數據層，會依以下固定順序解決這個問題：

讀取現狀。 勾稽流程，讀取這項產品在每套系統裡的歸類、原產地與價值，並標出同一項產品掛著三個稅號。
重新推導一次。 這項產品，透過Classifier或OpenAPI，依GRI邏輯重新歸類一次，產出一個候選稅號，附上完整推理鏈，而不是在三個舊答案裡投票表決。
把分歧標成一項例外。 當重新推導出的稅號，與任何一套系統不同時，人工審查者會看到這項衝突、推理過程，以及相關的CROSS裁定，並確認權威稅號。系統會先問，再覆寫，不會靜默地自行選定。
回饋這份唯一的紀錄。 SAP GTS、Oracle GTM與OneSource，各自透過API讀取確認後的稅號。它們的篩查、文件與申報功能，照常運作，只是現在輸入的內容一致了。
長期守住這條線。 因為這份權威紀錄，是由數據層所擁有，下一次任何一套系統出現偏移，這項分歧會再次浮現成一項例外，而不是消失在某個孤島裡。

對於要處理8萬到25萬個料號目錄的團隊來說，OpenAPI的批量端點，單次請求可處理最多200個項目，標準正式環境層級每天可處理20萬筆以上的歸類，所以最初的勾稽流程，是一項排程作業，不是一個要花好幾年的人工專案。重點不在於速度本身，而在於舊系統在這層真實來源被建置起來的過程中，從來不會停擺。

這和多數供應商提出的推倒重來式遷移相比，有什麼不同？

多數平台供應商，對舊式GTM系統各自為政開出的藥方，是他們自己的遷移方案：整併到我們的雲端，淘汰其他系統。這是一套正當的策略，前提是組織已經選定供應商，且能負擔一整套專案的資金。但它回答的，是另一個問題，而不是一位正面對迫近的維護期限、真正在問的那個問題：「在不讓我的申報路徑離線的情況下，我要怎麼在下一次稽核之前，拿到一份一致、站得住腳的歸類紀錄？」

強化不汰換的這層數據層，和遷移，並不互斥。這層數據層，是拿到一份已勾稽紀錄最快的路徑，如果你最終確實要整併，它也是風險較低的橋樑，因為一旦有了一份權威紀錄，未來任何一次遷移，匯入的都是乾淨、單一來源的資料，而不是把三段互相牴觸的歷史，一起帶進新平台。你可以現在就建這層數據層，之後再決定要不要整併，而且是按你自己的時程，不是供應商的時程。

GingerControl在這裡的角色，刻意保持窄而誠實：它提供歸類真實性與整合管線，Classifier、OpenAPI，以及AI Integration服務，把SAP GTS、Oracle GTM與OneSource，留給它們原本就做得很好的作業工作。GingerControl幫助企業，從流程顧問到客製整合，建立內部的AI強化法遵能力，而不是賣一套要求你放棄已驗證系統的平台。

常見問題

什麼是舊式GTM系統各自為政？為什麼它會製造稽核風險？

舊式GTM系統各自為政，是指同時運行多套舊式全球貿易管理平台，通常是SAP GTS、Oracle GTM與Thomson Reuters OneSource，每一套都有自己的料號主檔，對同一批料號也有各自的分類。它會製造稽核風險，是因為同一項產品，可能在不同區域被申報成不同的HTS稅號，而依19 U.S.C. 1484，這種不一致本身，就是一項合理注意義務的稽核發現。GingerControl用它的AI Integration服務與OpenAPI，處理這個根本問題，讓團隊能對每一套系統，提供同一份權威歸類紀錄，而不是去勾稽三份。

能不能在不遷移SAP GTS、Oracle GTM與OneSource的前提下，把它們統一起來？

可以。「強化不汰換」的做法，是在整套系統之上，建出一層薄薄的合規數據層，握有權威的HTS、原產地與關稅紀錄，並透過API回饋給每一套系統，讓每一套舊系統，原地不動，繼續做篩查、產出文件與申報的工作。對於一位要橫跨三套系統、管理8萬個以上料號的主管來說，這能在數週內拿到一份已勾稽紀錄，而不是走上平台遷移動輒多年的時程。GingerControl的OpenAPI與AI Integration服務，提供歸類真實性與連接器，把數據層接進客製化的GTM與ERP系統。

三套系統各說各話時，GingerControl怎麼決定哪一個是權威HTS稅號？

GingerControl不會在三個舊答案裡投票。它的HTS歸類研究員，透過GRI邏輯重新推導一次，把分歧連同完整推理鏈與相關CROSS裁定，標成一項例外，並要求人工審查者確認後才覆寫。對於要協調數萬個牴觸料號的法遵團隊而言，這正是一份站得住腳的單一紀錄，和一個隨意的仲裁機制，兩者之間的差別；系統會先問，再歸類，不會用猜的。

建一層數據層，會不會取代我的報關行或我的GTM平台？

不會。GingerControl是一個HTS歸類研究員，產出支持歸類決定的可供稽核文件；最終10位碼判定與報單申報，仍屬於進口人或其持證報關行的報關業務，依CBP裁定HQ H290535與HQ H350722。這層數據層，也不會取代SAP GTS、Oracle GTM或OneSource，它只是餵給它們一份一致的紀錄，讓它們拿更好的輸入，繼續做原本的作業工作。GingerControl強化的是報關行的判斷，也強化舊系統本身，而不是取代任何一方。

這套做法，對我的紀錄與合理注意義務立場，會有什麼影響？

一份權威紀錄，附上一條有紀錄可查的推理依據，是一家多系統並存的公司，能拿出來證明合理注意義務最乾淨的方式，因為稽核人員看到的是一份一致的歸類，而不是三份彼此牴觸的申報內容。19 CFR Part 163要求，相關佐證紀錄，須自報關日起留存五年，而GingerControl可供稽核的報告，會保留每個稅號背後的GRI引用、類注與章注，以及CROSS參考。對於要面對跨多個法人重點評估的團隊而言，這份一致性，能把一項稽核發現，變成一個不成問題的問題。

跨多套系統的大型目錄，勾稽流程能跑多快？

GingerControl的OpenAPI批量端點，單次請求可處理最多200個項目，標準正式環境層級，每天可處理20萬筆以上的歸類，所以針對一個8萬到25萬個料號的多系統目錄，初次勾稽，是一項排程作業，而不是一個動輒多年的人工工程。舊式GTM系統維持在線，全程持續申報。AI Integration服務負責處理客製連接器，讓這層數據層，能讀取並寫回超出標準SaaS整合範圍的系統。

我最終還是該整併到單一GTM平台嗎？

可以，而這層數據層，會讓這個決定的風險變低，而不是把它擋掉。一旦有了一份權威紀錄，未來任何一次遷移，匯入的都是乾淨、單一來源的資料，而不是把三段互相牴觸的歷史，一起帶進新平台，所以你可以按自己的時程，決定要不要整併。不論你最終是否整併，GingerControl的角色都一樣：透過OpenAPI與AI Integration服務，提供歸類真實性與整合管線，對你運行的任何一套系統，都保持供應商中立。

在你自己的舊式GTM系統之上，疊出單一數據層

如果你的歸類、關稅與原產地資料，被困在互不勾稽的SAP GTS、Oracle GTM與OneSource系統裡，你不必在忍受這種各自為政的現狀，和把一場動輒多年的遷移，賭在一個迫近的維護期限之間二選一。GingerControl的AI Integration服務與Trade Compliance OpenAPI，提供你在整套系統之上，疊出一層程式化合規數據層所需的組成元件，把每一套舊系統，當成登錄系統，並把單一、權威、可供稽核的歸類紀錄，回饋給它們所有系統。強化，而不是汰換。看AI Integration如何統一整套系統 →

GingerControl不只是一項工具。我們與企業貿易法遵團隊合作流程顧問、數位轉型策略，以及跨舊式GTM與ERP系統的端到端客製整合，每項合作都從一次免費30分鐘法遵健檢開始。與我們的團隊聊聊 →

參考資料

[REF 1] SAP GTS 11.0主流維護終止（經Rimini Street轉述）引用資料：SAP已於2025年12月31日終止SAP GTS 11.0的主流維護；此後不再提供稅務、法規更新。來源：Rimini Street, SAP End-of-Mainstream-Maintenance Deadlines for GTS, BOBJ, BPC, BW and Hybris 發布日期：2025年

[REF 2] SAP GTS 11維護終止的遷移指引引用資料：期限過後的路徑（延長維護、客製維護）與遷移選項，包括內嵌於S/4HANA的GTS。來源：SAP Licensing Experts, SAP GTS 11 End of Maintenance 發布日期：2025年

[REF 3] Oracle Support，本地部署版Oracle Transportation Management／Global Trade Management的Premier Support即將終止引用資料：本地部署版OTM／GTM的Premier Support即將終止；6.5.x系列為最後一個本地部署版本；Oracle轉向雲端。來源：Oracle Support Document 2966726.1 發布日期：Oracle Support知識庫

[REF 4] Thomson Reuters，ONESOURCE+推出引用資料：Thomson Reuters於2025年11月5日推出ONESOURCE+，作為橫跨稅務、貿易、法務與風險的AI驅動智慧合規網路。來源：Thomson Reuters press release, ONESOURCE+ launch 發布日期：2025年11月5日

[REF 5] CBP，合理注意義務資訊性合規公告引用資料：依19 U.S.C. 1484，進口人有責任善盡合理注意義務，申報、歸類並核估貨品價值；合理注意義務作為一項作業標準。來源：U.S. Customs and Border Protection, Reasonable Care (Informed Compliance Publication) 發布日期：2017年9月修訂版

[REF 6] 紀錄留存規定，19 CFR Part 163 引用資料：與報單相關的紀錄，須自報關日起留存五年。來源：eCFR, 19 CFR Part 163 (Recordkeeping) 發布日期：現行eCFR

[REF 7] CBP裁定HQ H290535與HQ H350722 引用資料：為進口目的，把特定貨品歸類到六位碼以上，依19 U.S.C. 1641屬於報關業務，須由持證報關行辦理；AI輔助歸類六位碼以上並搭配5106表（HQ H350722，2026年1月16日）。來源：CBP CROSS rulings database 發布日期：HQ H290535；HQ H350722（2026年1月16日）