ERP、CRM 數字永遠對不起來？Data Contract 要管理的是資料口徑，不只是資料格式

月底開經營會議，業務說本月成交 120 筆，財務系統卻只有 113 筆，行銷儀表板還顯示 126 筆。三個部門都認為自己的報表正確，但可能各自使用不同的日期、訂單狀態、取消條件與重複計算規則。Data Contract（資料契約）的價值，是把這些長期藏在口頭與程式碼裡的假設，寫成資料提供者與使用者共同確認、能夠檢驗的規則。

專題編輯：Renee Kuo｜數據分析與成長編輯

一、Data Contract 到底在約定什麼？

資料契約是資料生產者（Producer）與資料使用者（Consumer）之間，對資料的結構、意義、品質、交付條件與責任所建立的共同規格。Open Data Contract Standard（ODCS）以開放規範形式描述 Schema、資料品質、服務條件、團隊與角色等部分，提供跨系統與跨組織的一致表達方式。來源一

「契約」在這裡主要是資料工程與治理術語，不代表單靠一份 YAML 檔案就產生法律上可執行的雙方合約。法律責任、個資處理與服務採購仍須依具體契約、權限與法規另外確認。來源二

資料契約常被和 API Contract 混淆。API 契約著重某個介面如何呼叫、需要哪些參數、回傳什麼資料及錯誤；Data Contract 更關心資料本身的欄位語義、品質、刷新時間、來源責任與使用範圍。即使企業每天只交換 CSV 檔案，仍然可以建立資料契約，不一定要先有 API。

二、真正需要契約的，是「同名不同義」的欄位

以訂單金額為例，營業單位的 sales_amount 可能指含稅訂單總額，財務使用的 recognized_revenue 則可能指依會計政策認列的收入。兩者就算都叫「營收」，也不能直接比較。另一個常見問題是訂單建立日期與付款日期：同一筆訂單可能分別落在不同月份，導致每月績效看似互相矛盾。

企業因此要先回答五件事：這個指標的業務定義是什麼、誰是權威資料源、何時算有效紀錄、允許哪些例外、品質異常由誰修復。若尚未對齊這五件事，再多 AI 報表都可能只是把不一致的數字呈現得更漂亮。

三、實務上至少包含六種規則

第一是欄位結構，包括欄位名稱、型別、是否允許空值、唯一鍵與版次。第二是業務語義，說明金額是含稅或未稅、幣別、匯率基準、訂單狀態及有效日期。第三是品質門檻，例如重複鍵必須為 0、必填欄位不得缺漏、金額需符合合理範圍。第四是更新時效，定義每天何時應完成同步，以及延遲時如何通報。第五是責任分工，明確標示資料提供者、使用者及異常處理人。第六是變更管理，確認欄位更名、停用或口徑調整時，哪些下游系統會受影響。

ODCS 的 Schema 定義允許表達資料物件與屬性，並把資料模型和品質規則結合；以下範本是面向台灣中小企業的工作表格式，不宣稱直接符合 ODCS 所有正式欄位。來源三

四、可直接使用的「訂單資料契約」範本

表中資料集名稱、欄位與狀態均為虛構示例；正式企業應自行確認狀態完整性，尤其是部分退款、跨期沖銷、分期付款與外幣換算，不能直接把示例規則套用於真正帳務。

進一步建議為每一個欄位補上業務定義與版本，例如 net_amount_twd 是否扣除折扣、運費、退款與折讓，究竟以建立單日、付款日或入帳日計算。這些口徑比欄位英文名稱更重要。當客戶問「這個月到底做了多少生意」，財務認列與業務接單本來就可能合法呈現不同數字，契約應說明差異，而不是強迫所有報表得出同一數值。

五、把 Data Contract 變成真正會阻擋錯誤的測試

單純把資料契約寫成文件，仍不足以防止污染資料流入 Dashboard。至少應建立五種自動化檢查：必填欄位完整性、主鍵唯一性、合法狀態與型別、資料更新時效、與權威來源對帳。若其中一項出現異常，應有 ACCEPT、REVIEW、EXCLUDED 或其他明確狀態，不能默默丟棄不符合預期的資料。

例如每晚同步訂單資料時，若主鍵重複，應停止將這批資料直接更新正式績效報表，並輸出 quality_issues.csv 讓負責人核對；若是日期欄位無法解析，也應保留原始值與錯誤原因。數據清理不只是「把錯誤修掉」，而是讓每次修正都有追蹤紀錄與可逆性。

另一個必備機制是 Schema 變更審查。假設 ERP 增加 discount_type 欄位，是否會破壞下游不一定，得看消費者容不容許新增欄位、報表是否依欄位順序讀取，以及既有計算邏輯。企業不能簡單宣稱「新增欄位一定向後相容」，應在正式上線前跑契約測試與真實消費者情境測試。

六、30 天試點，不必從整座資料倉儲改起

第一週選一張最常造成爭議的表，例如訂單明細，訪談財務與業務 Owner，確認指標定義與權威來源。第二週產出資料字典與初版契約，標示欄位、時效、品質條件、版本與異常處理人。第三週加入自動化檢查與例外紀錄，從來源資料和報表資料做逐筆對帳。第四週觀察一輪真實的資料變更或同步，記錄錯誤是否被提早發現，以及部門是否能在合理時間內完成修復。

這個 30 天安排是建議的試點結構，實際時程依資料品質與系統權限而定。測量指標可包含口徑爭議次數、對帳差異筆數、異常發現時間、資料重工時數，以及報表發布前待確認事項數量。沒有驗證紀錄，不能直接宣稱導入契約已改善營收或節省多少時間。

企業缺的通常不是另一張視覺化報表，而是一套能讓大家說明「這個數字從哪裡來、代表什麼、何時可信」的共同規則。 Data Contract 正是將這個問題落到文件、測試與責任的起點。

延伸閱讀與來源

1. Open Data Contract Standard（ODCS）官方文件。
2. Data Contract Specification，與 ODCS 的關係及遷移說明。
3. ODCS Schema 文件。
4. 天地人既有文章：API 契約是什麼？。

本文資料欄位與流程為教學示例，非真實客戶資料或法定帳務準則。主圖為原創生成資料契約概念圖，非真實資料庫產品畫面。

可下載工作範本

下載訂單資料契約工作表（ZIP）。範本為教學示例，採用前請填入經核准的真實資料。

相關閱讀

延伸閱讀：企業併購後，兩套客戶名單與產品編碼對不起來？AI 如何協助資料整併與核對