要用 AI 安全分析應收賬款賬齡，先按會計規則計算及核對，再提供獲批最少彙總或假名化資料。AI 只描述集中度、變動及異常，不判斷可收回性、壞賬準備、客戶風險、追收次序或會計處理。財務負責政策及結論，私隱或保安負責人批准資料流向。

按AI 受控流程限制輸入及核實輸出，不讓模型充當總賬、計算系統或審批人。

關鍵要點

先固定報告日、總賬範圍、貨幣政策、到期日規則及賬齡邊界。

在模型以外計算逾期日數和分組，並測試每個邊界值。

移除姓名、聯絡資料、銀行資料、自由文字和其他非必要欄位。

核對來源、轉換資料、各組、異常項目和 AI 輸入的金額。

把模型發現寫成待調查問題，不把相關性寫成客戶行為原因。

所有結論均須財務及私隱責任人覆核。

用 AI 安全分析應收賬款賬齡，責任在誰？

有用的產出是一份覆核包，而不是自動作出的信貸決定。覆核包應包含已凍結的快照身份、一張已核對的分組表、有紀錄的資料質素異常、一小組描述性觀察，以及一份交給獲授權覆核人的問題清單。

讓四個層次保持分開：

層次	例子	責任方
來源事實	合成發票 `INV-SYN-104` 未清金額為 4,200	財務系統負責人
確定性衍生	在報告日逾期 37 日	已批准的計算
描述性觀察	31–60 日組別較上一期快照上升	分析員覆核
業務決定	是否聯絡客戶或調整撥備	獲授權財務人員

前兩層經核實之後，模型可以協助草擬第三層。它不得補作欠缺的到期日，不得從自由文字推斷爭議，亦不得越界進入決定層。如需先進行較廣泛的試算表流程，請參閱 AI 試算表分析指南。

應收賬款資料怎樣才可信？

第 1 步：凍結快照和會計規則

匯出任何資料之前，先寫一個簡短的控制標頭：

報告主體和總賬；
快照 ID 和擷取時間戳；
報告日期和時區；
納入的帳戶類型和排除的結餘；
本位幣和外幣換算規則；
未清金額的定義；
到期日的優先次序；
未分配收款、貸項通知單、有爭議發票和付款計劃的處理方式；
已批准的賬齡區間界線；以及
政策負責人和版本。

這可防止一段流暢的敘述掩蓋互不相容的輸入。如果總賬已結賬、匯率已改變或採用了不同的到期日規則，9 月 6 日產生的賬齡表便不能隨便與 8 月 31 日那份比較。

IFRS 9 討論了用於貿易應收款的撥備矩陣，並以逾期日數對應的比率作說明。［1］但這並不代表一套通用的分組或比率便適用於你的主體。具決定作用的，仍是適用的報告框架、政策、重要性和專業判斷。

第 2 步：訂明必要欄位

先由欄位規格開始，而不是匯出整本總賬。一張最小的工作表可以包括：

欄位	用途	核驗
`invoice_id`	穩定的資料列身份	快照內唯一
`customer_token`	不用姓名亦能連結重複結餘	假名化並控制存取
`invoice_date`	時間背景	有效日期，且不遲於擷取時間
`due_date`	計算逾期日數	有效，或清楚標示欠缺
`open_amount`	仍未收回的金額	屬數值，並與總賬對應
`currency`	防止不同貨幣混合加總	已批准的貨幣代碼
`credit_or_payment_status`	說明已納入的調整	受控取值
`dispute_flag`	保留已知的流程狀態	由來源系統產生，絕不推斷

除非已批准的用途確實需要，否則不要匯出電郵地址、電話號碼、郵寄地址、銀行資料、稅務識別號碼、帳戶備註、追收往來或完整的發票描述。AI 私隱風險指南提供了較全面的輸入分類問題。

如果來源表格不一致，先按有紀錄的規則修正，然後才分析。試算表清理流程有助組織這項工作，但每個被改動的值，仍須有可追溯的出處或負責人決定。

第 3 步：最少化、彙總或假名化

資料最少化要問：就所述目的而言，每個欄位、每一列是否都必要？ICO 的指引亦說明，假名化可以降低風險，但只要額外資料能把代碼重新對應到某人，這些資料仍屬個人資料。［2］［3］把這份對照表另行保護，不要放進 AI 輸入。

選擇能回答問題、但暴露最少的呈現方式：

只需觀察組合變動時，只用各組總額。
只有在需要分析集中程度時，才加入假名化的客戶代碼。
只有在調查計算或流程異常時，才加入發票層面的資料列。
以獲授權來源流程產生的受控標記，取代自由文字。
在考慮使用已批准的正式資料之前，先以合成資料列設計和測試提示。

彙總並不自動等於匿名。一個只包含一位可識別客戶、一種罕見貨幣和一個精確金額的組別，仍可能暴露身份。檢查小組別、不尋常的組合以及與其他資料連結的可能性。不要聲稱只刪去姓名便令資料集變得安全。

第 4 步：確定性計算賬齡分組

以試算表公式、SQL 查詢或經審查的程式計算 days_past_due 和 bucket。語言模型不應成為作為紀錄依據的計算工具。

就一項簡單的政策而言：

days_past_due = max(0, reporting_date - effective_due_date)
bucket = current | 1-30 | 31-60 | 61-90 | 91+

實際規則可能更複雜。欠缺的到期日、非工作日、貸項通知單、有爭議的結餘、分期付款計劃、重新開啟的發票和時區截點，都需要明確的處理方式。為每條被拒絕或未解決的資料列編配一個異常代碼，而不是把它強行歸入最接近的組別。

測試確切的界線：0、1、30、31、60、61、90 和 91 日。亦要測試負數未清金額、零結餘、欠缺貨幣、重複的發票 ID，以及剛好在截點入賬的付款。資料驗證清單有助把這些情況變成可重複的控制。

分析並覆核已核對的結果

第 5 步：使用 AI 前完成核對

控制表至少證明：

來源未清總額 = 轉換後總額 + 已記錄排除項
轉換後總額 = 所有賬齡組 + 未解決異常
AI 輸入總額 = 已審批的轉換或彙總總額
當前快照客戶數 = 互不重疊客戶組數量之和

無獲批換算便按貨幣核對，不混加美元、歐元、人民幣；金額及發票數比例分開。等式失敗即停，查重複連接、隱藏篩選、舊匯出、正負號、貸項、取整、截點過賬，記錄處理並從凍結來源重跑，不讓模型解釋差額。

第 6 步：限制 AI 的描述工作

提供控制資料、欄位字典、核實表及嚴格輸出格式：

只用已核對表描述重要賬齡變動、集中度及資料質素異常。
每項觀察引用資料列或彙總 ID；不得推斷逾期原因、可收回性、
信用風險、預期損失、不當行為或追收動作。
缺證據時寫「沒有支持」。
返回觀察、檢查及覆核問題。

要求列出計算輸入，在模型外重算總數、比例及變動。

按 NIST 生成式 AI 全生命週期風險管理，治理輸入、量度錯誤、保存原始輸出，由負責人覆核。［4］

第 7 步：覆核異常而不虛構原因

「61–90 日組上升 18%」可重算；「客戶因經濟不確定而延遲付款」不能由賬齡表證明。以紀錄表保留其他解釋及處理責任：

觀察	證據	確定性檢查	其他解釋	負責人決定
集中度上升	彙總 `A-07`	重算比例	客戶合併有變	待財務覆核
最舊賬齡組下降	快照比較	核對變動	撇賬或收款	查總賬事件
到期日缺失集中	異常 `E-03`	按來源計數	匯入對應缺陷	指定系統負責人

把已知爭議與推斷爭議分開，把過賬異常與客戶事件分開。模型只可提出問題；來源系統及授權人員才可回答。

第 8 步：審批、保留及安全重跑

最終覆核包記錄來源快照、計算版本、核對結果、已審批輸入、政策要求的模型或工具設定、原始輸出、審核修訂、未解決事項、批准結論和保留或刪除要求。快照、政策、欄位、提示、工具或計算有變，舊審批失效。

財務批會計定義及結論，私隱或保安負責人批路徑及保護措施，系統負責人修擷取缺陷。按政策刪臨時匯出及對照；彙總與評論仍可能敏感，須限制存取。

常見錯誤有哪些？

完整賬冊上載：改用彙總或假名化欄位。
讓 AI 計算賬齡或補作到期日：改用已測試的確定性規則。
未核對月份比較：先固定定義、逐快照核對。
把觀察到的變化寫成原因：改成覆核問題。
混幣：分開報告或按獲批規則換算。
隱藏拒絕列：保留異常組並清楚處理。
把流暢敘述當作財務審批：要求具名財務及私隱決定。

總結

固定快照、政策及範圍。
輸入前先最少化、彙總或假名化。
用確定性邏輯計算分組並測試邊界。
核對來源、轉換資料、各組、異常及 AI 輸入。
AI 只輸出有引用的描述性觀察和覆核問題。
可收回性、準備、追收及會計決定由專業人員負責。

常見問題

可把完整賬冊上載 AI 嗎？

預設不行。先分類、查合約及政策、刪非必要欄位，用獲批環境。優先已核對彙總或合成資料；可識別資料須經私隱及保安審批。

客戶編號是匿名資料嗎？

通常不是。可連回客戶即屬假名化；對照表分隔保護，並評估其他欄位的間接識別風險。

AI 應否計算逾期日數？

不應。須有確定性截點、到期日、貨幣、貸項及異常規則；AI 只描述核實結果，不作計算記錄系統。

AI 可建議預期信用損失比率嗎？

不可。準備取決於準則、歷史證據、前瞻資料、機構政策、控制及專業判斷；賬齡敘述非減值模型。

爭議發票應如何處理？

使用來源系統產生的爭議標記及獲批政策。不可根據備註或付款行為讓 AI 猜測爭議。需要時另行報告爭議結餘。

分組與總賬不一致呢？

立即停止。檢查篩選、重複、匯率、貸項、截點過賬、排除列、正負號及取整，記錄原因後從凍結來源重跑。

AI 可決定先聯絡哪些客戶嗎？

不可。合約、爭議、客戶關係、脆弱情況、法律限制及機構政策都可能影響決定，賬齡表不能完整證明這些條件。

應多久重跑一次分析？

採用財務和營運批准的頻率。每個新快照均是新輸入，須重新驗證及核對；政策、欄位、工具或計算變動時不可沿用舊審核。

**免責聲明：**本文非會計、審計、法律、私隱或追收建議。須遵循準則、合約、政策及合資格專業判斷。

來源

IFRS Foundation, IFRS 9 Financial Instruments: https://www.ifrs.org/issued-standards/list-of-standards/ifrs-9-financial-instruments/
UK Information Commissioner's Office, Pseudonymisation: https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/anonymisation/pseudonymisation/
UK Information Commissioner's Office, Security and data minimisation in AI: https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/how-should-we-assess-security-and-data-minimisation-in-ai/
National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1): https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 2026 年 9 月 6 日。

如何用 AI 安全分析應收賬款賬齡：分組、核對與覆核