如何將HTS稅則分類整合進你的ERP系統

為什麼多數ERP系統無法自行完成產品歸類？

SAP、Oracle與NetSuite這類ERP系統，把稅則代碼儲存為靜態欄位，本身不會套用解釋準則、參照CROSS裁定，也無法解決歸類上的疑義。內建的貿易合規模組（SAP GTS、Oracle GTM）提供的是紀錄保存與申報工作流程，但仰賴外部已經判定好的歸類結果。歸類邏輯本身，必須來自一套理解GRI方法論、部類注、章注與法律先例的專用引擎。

---

---

ERP整合為什麼對貿易合規這麼重要

超過九成的大型進口商，以SAP、Oracle或NetSuite作為核心ERP平台。SAP單一系統就佔全球ERP市場約24%的份額，Oracle ERP Cloud與NetSuite合計再佔15%到20%。這些系統存放著驅動關務歸類決定的產品資料、採購單與供應商資訊。

然而在多數組織裡，HTS歸類作業完全發生在ERP系統之外。合規分析人員把產品清單匯出成試算表，用獨立工具或人工查詢完成歸類，再把結果一筆筆輸回ERP的產品主檔。這種脫節會產生三個系統性問題:

資料重複輸入的錯誤。 手動謄寫10碼HTS代碼，本質上就容易出錯。單一數字打錯位，例如把8471.30.0100打成8471.30.0150，就可能讓適用稅率相差好幾個百分點。產業調查一致顯示，貿易合規流程中的人工輸入錯誤率落在2%到5%之間，規模一大，這些錯誤就會累積成可觀的稅額誤差。

斷裂的稽核軌跡。 19 USC 1484的合理注意義務標準，要求進口商證明歸類決定是怎麼做出來的。當歸類推理留在一個系統、HTS代碼卻存在ERP裡，兩者之間就沒有可串連的文件紀錄。在CBP重點評估過程中，稽核人員會要求檢視每個代碼背後的判定邏輯，而「合規分析人員查了一下就打進去了」不是站得住腳的答案。

過時的歸類結果。 沒有整合的情況下，重新歸類就得靠有人記得要重新匯出、重新歸類、再重新匯入。當USITC修訂HTS代碼、Section 301或232的調整改變適用稅率，或是上游的產品規格異動時，ERP裡的代碼就會逐漸與現實脫節。整合後的系統，能在產品資料異動時自動觸發重新歸類。

「歸類的最終責任在於進口商。海關要求進口商在歸類貨品時善盡合理注意義務。」出自CBP歸類合規指引

用自己的流程量測整合ROI：記錄前後的輸入與複核時間，計入建置及維護成本，並統計修正工作。沒有共同基準確定通常的省時比例或回本期限。團隊可先用GingerLite評估Researcher，再決定整合。

---

整合架構有哪些模式？

把HTS歸類引擎接到ERP系統，主要有四種做法。該選哪一種，取決於你的ERP平台、IT資源、歸類量與合規需求。

GingerControl的REST API適用上述四種做法：它就是透過HTTPS傳送的一般JSON，搭配X-Api-Key標頭。如果你不想自己建置並維護連接器，可以改用依專案建置的GingerOS：以唯讀方式讀取你的ERP與PLM，分階段連接，只在你核准的地方寫回。沒有現成的連接器，也不搬移主檔資料。

整合架構流程

任何ERP的HTS稅則分類整合，核心資料流都遵循同一套模式:

ERP系統                       歸類引擎                        ERP系統
───────────                   ─────────────────────              ───────────
產品建立／更新          ──►  API請求
                              {
                                "description": "material, function,
                                  composition ...",
                                "country_of_origin": "CN"
                              }
                                        │
                              歸類邏輯
                              （GRI分析、CROSS裁定、
                               部類注／章注）
                                        │
                              API回應
                              {
                                "hts_code": "8471.30.0100",
                                "tariffs": {
                                  "general_rate": "Free", ...
                                }
                              }                          ──►  更新產品主檔:
                                                              - HTS代碼欄位
                                                              - 稅率欄位
                                                              - 歸類日期
                                                              - 推理文件（GingerOS）
                                                              - 稽核紀錄

GingerControl的API回傳結構化JSON，能直接對應ERP欄位：HTS代碼及其美國各層關稅（一般與特別稅率，以及每一條第99章項目，包括Section 301與232），拆分編碼的產品則會拆成各個組成部分回傳。API手冊沒有記載推理鏈或信心分數；在GingerOS裡，推理過程、引用的CROSS裁定與核准紀錄，會與每個代碼一併保存。

---

如何把歸類作業對接SAP、Oracle或NetSuite？

每個主要ERP平台的擴充機制、欄位結構與貿易合規模組都不同。以下是美國進口商最常使用的三種ERP系統的平台專屬指引。

SAP S/4HANA + SAP GTS

SAP GTS是大型進口商中最常見的貿易合規模組，負責處理報關申報、許可證判定與合規篩查，但仰賴外部填入的商品代碼。整合點在物料主檔的外貿分頁，商品代碼（HTS號碼）就存放在那裡。

整合做法： 使用SAP Cloud Platform Integration（CPI）建立iFlow，在物料主檔建立或更新時觸發。iFlow把SAP物料欄位（MAKTX描述、WRKST基本材料、MATKL物料群組）對應到GingerControl的API請求，處理回應內容，再把HTS代碼寫回物料主檔的STAWN欄位（商品代碼），同時更新GTS合規文件。

SAP的資料對應：

SAP欄位（MAKT/MARA/MARC）      →  GingerControl API請求
─────────────────────              ──────────────────────────
MAKTX（物料說明）              →  description
WRKST（基本材料）              →  description（附加）
MATKL（物料群組）              →  description（附加）
HERKL（原產國）                →  country_of_origin

GingerControl API回應          →  SAP欄位（MARC/STAWN）
──────────────────────────         ─────────────────────
hts_code                       →  STAWN（商品代碼）
tariffs.general_rate           →  自訂欄位／GTS文件
tariffs（第99章項目）          →  自訂欄位／GTS文件
（你的iFlow執行日期）          →  歸類日期欄位

Oracle ERP Cloud + Oracle GTM

Oracle GTM提供貿易合規工作流程管理，包括受限方篩查、出口許可證管理與報關文件準備。和SAP GTS一樣，它會使用歸類資料，但不會自行產生。

整合做法： 使用Oracle Integration Cloud（OIC）建立由料件主檔異動觸發的流程。把Oracle品項屬性對應到歸類API的請求欄位，並將結果寫回品項的貿易合規屬性。Oracle的REST轉接器讓直接呼叫API變得很直觀。

NetSuite

NetSuite沒有內建貿易合規模組，這讓歸類整合反而更單純、也更有彈性。在品項紀錄上建立自訂欄位，用來存放HTS代碼、稅率與歸類日期，再用SuiteScript 2.0的使用者事件腳本，在品項建立或更新時觸發歸類。

SuiteScript整合模式：

// SuiteScript 2.0 - 使用者事件：afterSubmit
// 品項紀錄儲存時，觸發GingerControl歸類

function afterSubmit(context) {
    var item = context.newRecord;
    var description = item.getValue('displayname');
    var material = item.getValue('custitem_material');
    var origin = item.getValue('custitem_country_of_origin');

    // 呼叫GingerControl Classification + Tariff Calculation API
    var response = https.post({
        url: 'https://api.gingercontrol.com/openapi/v1/tariff',
        headers: { 'Content-Type': 'application/json', 'X-Api-Key': apiKey },
        body: JSON.stringify({
            description: description + ', ' + material,
            country_of_origin: origin
        })
    });

    var result = JSON.parse(response.body);

    // 把歸類結果寫回品項紀錄
    record.submitFields({
        type: item.type,
        id: item.id,
        values: {
            'custitem_hts_code': result.hts_code,
            'custitem_duty_rate': result.tariffs ? result.tariffs.general_rate : '',
            'custitem_classification_date': new Date()
        }
    });
}

還沒有ERP，或產品資料分散在好幾份試算表裡？GingerOS照你的流程、用現有的資料運作，有沒有ERP都可以：沒有ERP，我們幫你建立資料儲存環境，並替團隊設計資料流程；資料很亂的話，我們先把資料整理乾淨，再在上面建置AI系統。它能讀取電子郵件、PDF、Excel、掃描文件和照片，但不支援影片。

---

遇到錯誤與例外情況時，該如何處理？

正式上線的整合，必須考慮歸類無法自動完成的各種情境。在ERP整合裡建立完善的錯誤處理機制，能避免靜默失敗導致未歸類的貨物或預設代碼流入生產環境。

需要人工確認的結果。 API回傳的是代碼及其各層關稅，手冊沒有記載信心分數，所以要先決定哪些品項一律送交複核（新的產品系列、複合貨品、高關稅品項），再把這些品項導入合規複核佇列：可以是自訂的ERP工作流程，或發送通知給合規團隊。GingerOS會替你處理這件事：它記錄每個代碼的推理過程，只寫回經人員核准的結果。

需要進一步釐清的疑義。 API是依收到的描述進行歸類，所以從一開始就要把材質、功能與組成寫進描述裡。如果仍缺少資訊，GingerOS會在建議代碼之前先詢問，GingerLite app裡的Classification Researcher處理單一產品時也是如此。

API無法使用。 建立具備指數退避的重試機制。若歸類API暫時無法使用，先把請求排入佇列，等連線恢復後再處理。絕對不要預設採用佔位用的HTS代碼，在19 USC 1592之下，向CBP申報錯誤的代碼帶有裁罰風險。

HTS代碼驗證。 收到歸類結果後，先對照現行USITC稅則驗證回傳的HTS代碼，再寫入ERP。GingerControl的回應內容以現行HTS稅則為基礎，但在ERP層再做一次驗證，能對過時資料提供多一層防護。

例外處理流程總覽：

歸類請求
        │
        ▼
   API可用？──否──► 排入佇列重試（指數退避）
        │
       是
        │
        ▼
   符合自動核准規則？──否──► 導入合規複核佇列
        │
       是
        │
        ▼
   需要進一步釐清？──是──► 從ERP欄位自動解析，
        │                     或交由分析人員處理
       否
        │
        ▼
   驗證HTS代碼
        │
        ▼
   寫入ERP產品主檔+稽核紀錄

---

如何在跨系統之間維持稽核軌跡？

稽核軌跡，是HTS稅則分類ERP整合最重要的產出，重要程度甚至超過HTS代碼本身。在CBP重點評估過程中，稽核人員不會只檢查HTS代碼對不對，而是評估進口商在得出這個代碼的過程中，是否善盡了合理注意義務。

整合後的系統，必須維持一條不中斷的文件鏈:

1. 歸類觸發事件，記錄是什麼觸發了歸類（新產品建立、材質異動、定期複查)，並附上時間戳記
2. 輸入資料，把送進歸類API的確切產品資料，連同ERP紀錄一併保存
3. 歸類回應，保存完整的歸類回應及其背後的推理過程：套用的GRI規則、參照的部類注／章注，以及引用的CROSS裁定
4. 決策紀錄，若有人工複核，記錄複核者、複核日期，以及任何覆核決定與理由
5. ERP欄位更新，記錄寫入產品主檔的HTS代碼、日期，以及歸類版本

在GingerOS裡，每個代碼都會與其推理過程、適用規則與支持的先例一併保存，核准後的結果會連同稽核軌跡寫回你的ERP。把這些內容存為ERP紀錄附件，或存進連結式的合規文件資料表，讓完整的歸類歷程都能從產品主檔紀錄直接查閱。

對於每年透過美國海關處理超過4千萬份報單的公司來說，CBP以風險為導向的稽核方式，意味著任何進口商都可能被選中進行重點評估。你的ERP整合所產生的稽核軌跡，就是你最主要的防線。

---

導入時程與批次遷移

實際的導入時程，取決於你的ERP平台、既有IT基礎架構，以及歸類量。

既有型錄的批次遷移。 在正式上線即時歸類之前，你需要先完成既有產品型錄的歸類。API的批次端點接受JSON品項，預設每次呼叫最多120項，每一項都帶有你自己的item_id，並依相同順序回傳結果，附上一段摘要：

POST /openapi/v1/tariff/batch
Content-Type: application/json
X-Api-Key: YOUR_API_KEY

{
  "items": [
    { "item_id": "SKU-001", "description": "Cotton knit short sleeve T-shirt", "country_of_origin": "DE" },
    { "item_id": "SKU-002", "description": "Stainless steel hex bolt, M10 x 50mm", "country_of_origin": "TW" }
  ]
}

如果你的型錄存在試算表、PDF和電子郵件裡，而不是一份乾淨的ERP匯出檔，GingerOS會直接讀取原樣的資料（文字和圖片，不支援影片），以批次方式歸類，並為每個SKU記錄推理過程。

---

常見問題

GingerControl能整合哪些ERP系統？

沒有現成的連接器。GingerOS的連接會依每位客戶、針對你已經在用的系統個別建置：唯讀、分階段連接、只在你核准的地方寫回，也不搬移主檔資料。自行建置整合的團隊，可以從任何能對外發出HTTPS呼叫的系統，呼叫Classification + Tariff Calculation API。

把HTS稅則分類整合進ERP要花多久時間？

一般而言，從探索階段到正式上線，HTS稅則分類的ERP整合大約需要4到8週，實際時間取決於ERP平台複雜度與既有IT基礎架構。以中介軟體為基礎的整合（MuleSoft、Boomi）通常比客製連接器開發更快。由我們建置並維護連接的GingerOS專案，從第一次通話到正式上線通常需要8到16週，並從Prototype Week開始。

整合能否處理產品建立時的即時歸類？

可以。API接受同步REST呼叫，所以ERP的產品建立或更新事件可以直接呼叫它，並把代碼寫回。複合或不明確的產品應導入合規複核佇列；在GingerOS裡，系統會在建議代碼之前先詢問缺少的資訊，而且只寫回經核准的代碼。

當某項歸類需要人工複核時，該怎麼辦？

一套建置完善的整合，會把這些品項導入合規複核佇列，而不是把不確定的代碼直接寫入ERP。API手冊沒有記載信心分數，所以要訂好哪些品項一律需要複核的規則。GingerOS會記錄每個代碼背後的推理過程，只寫回經核准的代碼，複核結果也會記錄下來，成為稽核軌跡的一部分。

整合能否維持符合CBP稽核要求的合理注意義務文件？

可以，前提是推理過程要和代碼一起保存。GingerOS會記錄每個代碼背後的推理過程，包括套用的GRI規則、參照的部類注／章注與引用的CROSS裁定，並把核准後的結果連同稽核軌跡寫回你的ERP；單用API，回傳的只有代碼與各層關稅。這些文件與ERP產品紀錄一併保存時，能支持19 USC 1484的合理注意義務標準。

稅則異動時，該如何處理ERP裡的HTS代碼？

GingerOS會監測新規則，以及你的ERP、PLM和供應商紀錄中的變動，將每個SKU與新規則比對，列出受影響的品項，並把核准後的結果連同稽核軌跡寫回你的ERP。在GingerLite app裡，Compliance Radar會拿新的美國貿易公告比對你的HTS代碼，免費的Policy Briefings也會在美國貿易規則異動時寄電子郵件通知你。

ERP系統自動化HTS歸類的投資報酬如何？

用自己的流程量測整合ROI：記錄前後的輸入與複核時間，計入建置及維護成本，並統計修正工作。沒有共同基準確定通常的省時比例或回本期限。團隊可先用GingerLite評估Researcher，再決定整合。

自動化HTS稅則分類，一定要有ERP嗎？

不用。如果你沒有ERP，我們幫你建立資料儲存環境，並替團隊設計資料流程，再在上面建置GingerOS；如果你的產品資料很亂，我們先把資料整理乾淨。GingerOS能讀取電子郵件、PDF、Excel、掃描文件和照片，但不支援影片。

---

開始你的ERP整合

在歸類工具與ERP系統之間手動重複輸入HTS代碼，是一項合規隱憂，會產生錯誤、破壞稽核軌跡，並浪費分析人員的時間。以API為基礎的歸類整合，能消除這道缺口，在產品異動時自動觸發歸類，並把可供稽核的結果直接寫入ERP紀錄。

你可以用從一通電話開始的Classification + Tariff Calculation API自行建置，或讓GingerOS依專案連接你的ERP：它照你的流程、用現有的資料運作，有沒有ERP都可以，並在任何報價之前，先從Prototype Week開始。聯繫我們的團隊

---

參考資料

1. 19 USC 1484，貨物進口，合理注意義務標準
   引用數據：進口商在歸類決定上須善盡合理注意義務
   來源：19 USC 1484，貨物進口
   發布：成文法規
2. 19 USC 1592，進口交易詐欺、重大過失與過失之裁罰
   引用數據：19 U.S.C. 1592(c)下，過失上限是國內價值與損失關稅、稅金及規費兩倍中的較低者；重大過失為四倍；詐欺最高為國內價值。20%/40%的應稅價值上限僅適用於未影響稅款核定的情況。
   來源：19 USC 1592，詐欺、重大過失與過失之裁罰
   發布：成文法規
3. 美國海關與邊境保護局，貿易優先議題與報單數量
   引用數據：每年處理超過4千萬份報單
   來源：CBP Trade Priority Issues
4. CBP重點評估計畫，以風險為導向的進口商稽核方法
   引用數據：CBP評估進口商合規實務（含歸類作業）的稽核計畫
   來源：CBP Focused Assessment
5. CBP知情合規出版品，歸類指引與GRI適用方式
   引用數據：「歸類的最終責任在於進口商。海關要求進口商在歸類貨品時善盡合理注意義務。」
   來源：CBP Informed Compliance Publications
6. USITC進口關稅稅則，官方HTS稅則與修訂紀錄
   引用數據：超過17，000個稅則行，定期修訂會影響已儲存的HTS代碼
   來源：USITC HTS Information
7. SAP Global Trade Services，貿易合規模組文件
   引用數據：SAP GTS商品代碼管理、物料主檔外貿分頁
   來源：SAP GTS Documentation
8. Oracle Global Trade Management，貿易合規雲端模組
   引用數據：Oracle GTM整合模式、料件主檔貿易合規屬性
   來源：Oracle GTM

Related Articles

• ERP整合用HTS稅則分類API：SAP、Oracle與NetSuite