--- title: "用 AI 建立結算系統前應確定的 7 項政策" locale: zh-hant category: how_to category_name: "操作教學" translation_status: reviewed license: cc_by author: "injoys" source_url: https://injoys.com/en/articles/seven-policies-before-building-ai-settlement-system published_at: 2026-07-27T00:58:06+09:00 --- # 用 AI 建立結算系統前應確定的 7 項政策 > 結算並非只是從銷售額中扣除手續費的計算功能，而是管控銷售款項歸屬、支付條件、退款、稅務與失敗處理的財務營運體系。在交由 AI 實作前，應由人員先行確定從結算基準日到稽核日誌的 7 項政策。 ## Key Points - 銷售款項並非平台可自由運用的營運資金，而應作為與支付給賣家等對象的義務相關聯之受限制資金加以管理。 - 應將訂單狀態與結算狀態分開，並把確認收貨、退款、爭議與支付失敗分別記錄於帳簿中。 - 並非一律要對個人賣家預扣 3.3% 的稅款，而應依所得的法律性質與賣家身分判斷。 - 即使使用 PG 或第三方託管服務，結算週期、手續費、暫緩、負餘額結轉與稅務政策仍須由平台決定。 - AI 產生的結算程式碼，應經過會計總帳核對、防止重複支付、權限控管與專家審查後，才能投入營運。 結算不只是單純的減法功能。它是一套帳簿系統，用來確認各筆訂單的權利與義務、區分平台應保管或支付的資金，並追蹤退款、爭議、稅務及匯款失敗等情況。 生成式 AI 可以協助撰寫程式碼與測試，但不能成為結算政策的責任主體。如果政策有所缺漏，AI 可能會建立看似合理的預設值或遺漏例外情況，其結果可能導致超額支付、重複支付、稅務錯誤或流動性事故。 ## 從 2024 年 티몬·위메프 事件中確認的原則 2024 年 티몬 與 위메프 發生大規模銷售款項未結算事件，顯示結算延遲可能對賣家與消費者造成多麼嚴重的連鎖損害。然而，不應只以結算週期過長這一項因素斷定事件原因。資金運用、流動性、治理結構與內部控制等多項因素都必須一併檢視。 營運者應汲取的核心教訓十分明確。 - 不要將尚未支付的銷售款項視為公司可以自由使用的現金。 - 結算週期越長，暴露於單次故障或流動性不足風險的未支付餘額就越大。 - 每日核對銷售款項餘額與實際保管資金。 - 向賣家透明公開結算條件與延遲原因。 - 分別確認相關法令、合約結構與 PG 服務範圍。 銷售款項的法律歸屬與保護方式可能會依交易結構而有所不同。因此，日常應始終保持這是「他人的錢」的警覺，但實際的會計與法律處理仍應依合約及現行法令判斷。 ## 實作前必須確定的 7 項結算政策 ### 1. 結算基準日與支付週期 首先應定義訂單何時成為可結算狀態。如果只以訂單日或付款日為基準，配送前可取消與可退貨的金額也可能被納入支付對象。 一般商品交易可設計以下流程。 1. 付款核准 2. 配送完成 3. 確認購買，或約定期間屆滿後自動確認 4. 檢查退貨、爭議及異常交易 5. 確定結算對象 6. 納入支付批次 7. 完成匯款與核對 必須決定的項目如下。 - 商品、數位內容、服務等各交易類型的結算基準事件 - 自動確認購買前的期間及起算時間點 - 每日、每週或每月的支付週期 - 週末與國定假日的處理方式 - 結算截止時間及截止後交易歸屬的批次 - 最低支付金額及小額餘額是否遞延 - 是否允許依賣家等級採用不同週期 - 確認是否超過法令或合約所定支付期限的程序 可結算日與實際支付日必須分開。例如，`eligible_at` 是符合支付條件的時間，`scheduled_payout_at` 是納入支付批次的時間，而 `paid_at` 則是確認匯款成功的時間。 ### 2. 手續費計算與結算明細表 如果只向賣家顯示最終支付金額，將難以驗算，並會增加詢問與爭議。因此，必須同時提供訂單單位明細與各期間合計。 | 明細項目 | 說明 | |---|---| | 交易總額 | 商品價格、選項價格、運費等合約所定銷售額的構成 | | 折扣負擔額 | 平台、賣家及合作夥伴各自負擔的折扣 | | 取消與退款金額 | 全額及部分退款與運費調整 | | 平台手續費 | 手續費率、定額手續費及是否課稅 | | 付款相關費用 | 標示 PG 費用是另行扣除還是包含於手續費中 | | 稅務調整 | 加值稅標示、預扣稅等適用項目 | | 其他調整 | 補償金、廣告費、罰款等具有合約依據的調整 | | 最終支付金額 | 反映所有加減項目後的預計匯款金額 | 手續費政策也必須明確說明計算基準。應決定以折扣前售價或折扣後付款金額何者為基準、是否包含運費與加值稅，以及部分退款時如何退回手續費。 金額最好不要使用浮點數資料型別計算。若是韓元這類最小貨幣單位為整數的情況，應以整數儲存；若需處理外幣或小數運算，則應使用定點數資料型別及各幣別的四捨五入規則。 ### 3. 退款與負數結算 已向賣家支付款項的訂單，之後仍可能發生退款。此時應將退款金額與可退還的手續費記錄於調整帳簿，並從下次支付金額中扣除。 例如，本次預計結算金額為 30 萬韓元，而先前訂單的退款相關扣除額為 40 萬韓元，可按以下方式處理。 - 本次支付金額：0 韓元 - 未回收餘額：負 10 萬韓元 - 遞延至下次結算的金額：扣除 10 萬韓元 政策中需包含以下項目。 - 部分退款時商品價格、運費與手續費的分攤方式 - 負數餘額的遞延期間與抵銷順序 - 向長期沒有銷售的賣家追討款項的方法 - 設置保證金或支付準備金的合約依據 - 賣家退出前確認未清償義務的程序 - 取消退款或爭議結果變更時進行沖銷分錄的方式 不要覆寫既有交易記錄，而應將原始交易與調整交易相互連結。如此才能重現哪一筆退款變更了哪一筆結算。 ### 4. 暫緩支付與解除 不應一律中止整個賣家帳戶的支付，而應能依訂單、金額或原因分別暫緩支付。常見的暫緩原因如下。 - 消費者爭議或退貨處理中 - 疑似自我交易、帳戶遭竊或異常付款 - 賣家本人、企業或帳戶驗證失敗 - 法院、調查機關或相關機構提出合法要求 - 未提交合約所要求的結算文件 每筆暫緩記錄都應儲存對象金額、原因代碼、依據資料、開始時間、審查期限、負責人及解除條件。賣家介面應在可公開範圍內顯示暫緩金額與原因、所需措施及諮詢管道。 為避免營運者任意重複暫緩支付，最好分離建立與解除的權限，並對大額暫緩支付的解除採用雙重核准。 ### 5. 銷售款項分離管理與 PG、託管結構 如果將未支付的銷售款項與公司營運資金視為相同的可用現金管理，流動性不足便可能立即演變成未結算。至少在內部帳簿與帳戶運作上，應明確區分銷售款項相關資金與營運資金，並每日核對餘額。 然而，僅僅設立獨立帳戶，並不代表法律上的破產隔離或完整資金保護會自動成立。信託、存放、支付保證等保護方式的效力與義務，必須依適用法令及合約結構進行檢視。 依平台在付款及支付流程中扮演的角色，可能涉及依《電子金融交易法》登記為電子支付結算代理業者等問題。並非所有平台都同樣需要登記為 PG，也不會僅因計算結算資料就必然成為登記對象。應根據實際收取、保管、移轉資金的方式及合約關係判斷。 初期平台可以考慮使用已登記 PG 所提供的付款、託管或按賣家分拆結算服務。然而，即使使用 PG，以下責任也不會消失。 - 決定哪些訂單應在何時傳送為支付對象 - 計算手續費與調整金額 - 管理退款與負數餘額遞延 - 驗證賣家資訊與帳戶 - 核對 PG 結果與內部帳簿 - 應對故障與支付失敗 託管義務與例外也會依交易類型及付款方式等因素而異，因此必須確認《電子商務法》及其下位規定。 ### 6. 預扣稅、加值稅與憑證 「個人賣家一律扣除 3.3%」並不是正確的規則。3.3% 通常是所得稅 3% 與個人地方所得稅 0.3% 的合稱，適用於營業所得。實際是否預扣稅款，不只取決於賣家是否完成事業登記，也會依所得性質、合約關係、支付項目及例外規定而有所不同。 在註冊與簽約階段應取得以下資訊。 - 個人、個人事業者、法人等賣家類型 - 是否為境內外居民或法人 - 應稅、免稅、簡易課稅等稅務狀態 - 事業登記號碼、居民登記號碼等法定申報所需資訊 - 所得性質與支付原因 - 稅務發票、計算書或預扣稅收據等所需憑證 也不應一概認為對事業者賣家「永遠不扣除任何稅款，支付 100%」。如果合約約定扣除平台手續費，就必須區分交易總額、手續費、加值稅與實際匯款金額。對於平台所提供仲介服務的手續費，稅務發票的開立主體與時間點，也應依合約及稅法上的供應關係確定。 預扣稅通常適用在支付日所屬月份的次月 10 日前申報及繳納的制度，但可能存在例外或期限變更，因此應確認實際申報時點的規定。與其將稅務規則固定寫入程式碼，不如採用具有適用起始日與結束日的版本化政策管理，會更加安全。 ### 7. 支付失敗、結算管理後台與稽核日誌 即使支付已正常建立，也可能因帳戶錯誤、戶名不符、交易限制、銀行維護或 PG 故障而失敗。不要只將失敗標示為「未支付」，而應細分狀態與重新處理規則。 建議的狀態範例如下。 - `scheduled`：預約支付 - `submitted`：已向銀行或 PG 傳送請求 - `processing`：外部機構處理中 - `paid`：確認成功 - `failed_retryable`：可重試的失敗 - `failed_final`：需要修改資訊等處理的最終失敗 - `reversed`：成功後取消或退回 重試時必須使用可識別同一筆支付的冪等性金鑰。如果將回應延遲誤判為失敗而再次匯款，可能發生重複支付，因此應先透過外部交易編號查詢既有請求的結果。 稽核日誌應保留以下內容。 - 行為人及使用的營運者帳戶 - 執行時間與存取位置等安全資訊 - 變更前後的值 - 暫緩、解除及手動調整的原因 - 核准者與執行者 - 相關訂單、結算批次與外部交易編號 - 失敗代碼與重試紀錄 稽核日誌應受到保護，避免一般營運者修改或刪除；個人資料與金融資訊則應適用最少蒐集、存取控制、加密及保存期限政策。 ## 結算資料模型的最低組成 與其先讓 AI 製作介面，不如先定義以下帳簿。 | 資料物件 | 作用 | |---|---| | 訂單帳簿 | 記錄訂單、付款、配送及確認購買狀態 | | 結算項目 | 記錄各訂單總額、手續費、稅款、調整金額及歸屬賣家 | | 調整帳簿 | 記錄退款、補償、罰款及手動調整 | | 暫緩帳簿 | 記錄暫緩金額、原因、期限及解除紀錄 | | 結算批次 | 特定期間與賣家的支付對象集合 | | 支付帳簿 | 記錄匯款請求、成功或失敗及外部交易編號 | | 稅務帳簿 | 記錄預扣稅及憑證開立、申報狀態 | | 稽核日誌 | 記錄營運者與系統的所有重要變更 | 每本帳簿都應包含幣別、政策版本、建立時間及原始交易連結金鑰。不能只因訂單狀態改變，就在無提示的情況下變更過往的結算金額。 ## 必須維持的控制規則 結算系統應自動檢查以下不變條件。 - 一個結算項目只能且必須連結至一名賣家與一筆原始交易。 - 不得使用相同支付金鑰匯款兩次。 - 已支付金額、未支付金額、暫緩金額及調整金額的合計必須與帳簿一致。 - 手動調整必須有原因及核准者。 - 已關帳的結算不得修改，應透過沖銷分錄與新的調整修正。 - 每日調查內部銷售款項相關餘額與 PG、銀行餘額之間的差異。 - 稅款與手續費計算必須記錄所套用的政策版本。 ## 提供給 AI 的政策規格範例 按照以下方式將需求結構化，可以減少遺漏。 > 將訂單狀態與結算狀態分開設計。實作各交易類型的確認購買條件、每週三支付批次、假日處理、手續費基準、部分退款分攤、負數餘額遞延、逐筆支付暫緩、預扣稅政策版本、支付冪等性金鑰，以及不可變更的稽核日誌。金額應以整數或定點數處理。所有手動調整都必須經過雙重核准並附上原因。實作前，請將最低支付金額、自動確認購買期間、長期負數餘額追討、暫緩期限、重試次數等尚未確定的政策列成問題清單。 不要只要求 AI 提供程式碼，也應一併要求以下產出。 - 狀態轉換圖與例外清單 - 資料庫結構描述與限制條件 - 權限與核准體系 - 正常情況、邊界值、故障及重複請求測試 - 每日核對報告格式 - 故障復原與手動處理程序 - 個人資料與金融資訊保護檢查表 ## 上線前檢查表 - [ ] 已將各交易類型的結算基準日文件化。 - [ ] 賣家可以按訂單單位驗算結算明細。 - [ ] 已通過部分退款與負數餘額遞延測試。 - [ ] 已定義暫緩原因、期限及解除權限。 - [ ] 已區分銷售款項相關資金與營運資金的管理標準。 - [ ] 已與專業人士確認是否涉及 PG、託管及電子金融業。 - [ ] 已檢視各賣家及所得類型的稅務處理。 - [ ] 已完成防止重複支付及失敗重試測試。 - [ ] 可每日核對銀行、PG 與內部帳簿。 - [ ] 營運者的手動變更會保留在稽核日誌中。 - [ ] 結算故障時已有賣家通知與詢問處理程序。 ## 結論 安全結算系統的起點不是 AI 提示詞，而是明確的政策與彼此分離的帳簿。AI 應作為將已確定規則轉換為程式碼、測試與文件的工具；資金保管結構及電子金融、稅務判斷，則必須與 PG、會計與稅務專家及法律專家共同驗證。 ## FAQ ### 結算功能只要從銷售金額中扣除手續費即可嗎？ 不是。結算包含確認收貨、部分退款、暫緩支付、負數餘額結轉、稅金、匯款失敗、防止重複支付及帳簿核對。不僅需要計算公式，還需要狀態轉換與資金控管。 ### 結算基準日一定必須是確認收貨日嗎？ 無法對所有交易一律套用單一標準。實體商品可採用確認收貨或自動確認，但服務、數位內容、預約商品的履約完成條件各不相同。應依交易類型一併訂定基準事件，以及法定與契約約定的付款期限。 ### 結算週期總是越短越好嗎？ 較短的週期可減少未支付餘額與賣家的現金負擔，但也必須考量退貨、異常交易及營運成本。與其以風險為由不必要地延長週期，更重要的是依交易特性設定最低限度的驗證期間與可預期的付款日。 ### 使用 PG 後，平台就不需要制定結算政策嗎？ 不是。PG 可以提供付款、資金轉交、第三方保管或分帳支付功能，但哪些訂單應於何時付款、手續費與退款金額如何計算，以及暫緩向誰付款，均取決於平台政策。 ### 對個人賣家都必須預扣 3.3% 嗎？ 不是。3.3% 通常是營業所得預扣稅與個人地方所得稅合計的說法。是否預扣及適用稅率，不僅須依賣家的登記形式，還應根據所得性質、契約關係、是否為居民及例外規定判斷。 ### 將銷售款項存放於獨立帳戶就完全安全嗎？ 獨立帳戶是區分營運資金與銷售款項的基本控管措施，但其本身並不保證破產隔離或法律保障。應依契約及現行法規，確認信託、存管、付款保證等必要的保障方式，以及帳戶的法律性質。 ### 負數結算應如何記錄？ 將已付款訂單的退款金額記錄為單獨的調整交易，並從下一筆付款金額中扣除。若扣除金額大於預計付款金額，則付款金額應設為 0 韓元，剩餘餘額結轉至下一期結算。不得刪除原始交易或覆寫過去的結算單。 ### 若匯款請求沒有回應，可以立即重新請求嗎？ 不可以。第一次請求可能實際上已成功，只是回應遺失。應對同一筆付款使用冪等鍵與外部交易編號，並先向 PG 或銀行查詢既有處理結果後再重試，才能防止重複支付。 ### AI 產生的結算程式碼可以直接投入營運嗎？ 不建議。必須測試狀態轉換、帳簿一致性、並行處理、重複請求、部分退款、故障復原及權限控管。電子金融與稅務事項也應依實際業務架構接受專業人士審查。 ## Sources - [電子金融交易法](https://www.law.go.kr/법령/전자금융거래법) - [電子商務等消費者保護相關法律](https://www.law.go.kr/법령/전자상거래등에서의소비자보호에관한법률) - [所得稅法](https://www.law.go.kr/법령/소득세법) - [地方稅法](https://www.law.go.kr/법령/지방세법) - [加值稅法](https://www.law.go.kr/법령/부가가치세법) ## Images ![連結商店、結算、安全與驗證環節的 AI 自動化流程圖](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzI4NCwicHVyIjoiYmxvYl9pZCJ9fQ==--327ce77d86d637d351158c65c70ddfacddacae1e/ai-ed29586c.webp) ![連結安全防護、政策流程、資金保管庫、銀行與伺服器的AI結算系統](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzI5MCwicHVyIjoiYmxvYl9pZCJ9fQ==--128e8c8dd212c1da8f86663e5bcd292ceb74aec1/ai-1bda19eb.webp)