# 供應商發票例外處理改善提案

> **狀態：`proposed` 真實型參考案例。** 本提案用於企業訪談與真實案件驗證；目前沒有特定企業的流程紀錄、資料存取授權、負責人接受紀錄或成效證據，不得宣稱已被企業接受或已產生效益。

## 提案摘要

本提案處理供應商發票因採購單、收貨紀錄或發票資料不一致，導致應付帳款人員跨 ERP、Email 與試算表反覆查核的常見問題。建議先統一例外分類、責任歸屬與案件狀態，再以確定性規則支援三方核對與重複發票檢查；生成式 AI 僅保留給非標準文件擷取與溝通摘要，不參與付款核准或供應商銀行資料修改。

本次請求的企業決策是：是否同意由應付帳款流程負責人檢視現況假設，並授權使用一批去識別化歷史案件進行唯讀重播。

## 1. 營運問題與預期成果

**主要使用者：**應付帳款專員。

**建議負責人角色：**應付帳款主管或財務營運主管；實際角色為 `missing`。

**流程範圍：**從企業收到供應商發票，到發票具備付款資格並進入付款排程。付款執行、供應商建檔與銀行資料變更不在本提案範圍。

預期成果是縮短發票從收件到可付款的時間，降低人工追蹤與逾期付款，同時不增加重複付款、錯付或未授權付款風險。基線、目標值與計算口徑目前均為 `missing`，須由企業負責人與資料負責人共同確認。

## 2. 現況流程診斷

以下流程均為待驗證的 `proposed` 參考假設。

### 正常路徑

1. 收到電子或紙本發票。
2. 辨識供應商、金額、發票號碼與採購單號。
3. 在 ERP 查詢採購單。
4. 比對收貨紀錄與發票。
5. 完成三方核對。
6. 送交付款審批並排入付款。

### 例外、升級與重工路徑

1. 財務發現找不到採購單、未收貨、金額不符、疑似重複或資料不足。
2. 財務透過 Email 或通訊工具詢問採購人、收貨單位或供應商。
3. 案件等待補件或確認，狀態另行記錄於試算表或個人工作清單。
4. 收到回覆後，財務重新搜尋資料並再次核對。
5. 長時間未回覆或涉及政策判斷時，再人工升級給主管或控制負責人。

待驗證的主要原因包括：例外責任人與回覆期限不明、案件狀態分散、問題發現過晚，以及每次接手都必須重新建立案件脈絡。

## 3. 目標流程

1. 收件時建立唯一案件編號，保存原始發票與來源。
2. 先執行必要欄位、供應商、重複發票及採購單存在性檢查。
3. 可核對案件依確定性規則完成三方比對。
4. 不可核對案件進入單一例外佇列，使用核准的例外類型與原因碼。
5. 每一例外類型指定一個責任角色、回覆期限及升級路徑。
6. 補件後只重新執行受影響的檢查，保留前次結果與完整稽核軌跡。
7. 僅在所有必要檢查及人工核准完成後，標記為具付款資格。

預期移除的工作是重複搜尋、手工同步多份狀態表與無責任人的催辦；預期保留的控制是職責分離、付款核准、供應商資料變更控制及稽核紀錄。

## 4. 介入與 AI 適配決策

第一階段採用流程與責任調整、單一案件狀態、確定性核對規則、例外佇列及 SLA 升級。這些介入比生成式 AI 更適合處理穩定計算、政策控制與權限判斷。

AI 可在後續、且有證據顯示仍有殘餘負擔時評估：

- 從非標準 PDF 或 Email 擷取候選欄位，由人員確認；
- 將自由文字建議分類至已核准的例外類型；
- 摘要案件溝通歷程，供負責人判斷。

AI 不得核准付款、改寫政策門檻、變更供應商銀行資料或自行放行例外。任何持久性操作均須另有授權、稽核、冪等、復原及問責證據。

## 5. 驗證設計與下一個問責行動

### 唯讀重播

在取得合法存取決定與去識別化方式後，抽取最近一個具代表性期間的已結案發票。樣本數由資料量與例外分布決定，不預先虛構固定數量。以原流程結果作為對照，重播新分類與核對邏輯，不寫回 ERP，也不影響付款。

建議衡量：

- 收件至具付款資格的中位時間及高分位時間；
- 一次通過率與各類例外比例；
- 每案人工接觸次數與跨部門等待時間；
- 逾期付款比例；
- 錯誤放行、重複付款及錯付事件；
- 無法分類或必須人工判斷的案件比例。

### 下一個問責行動

**負責人：**實際應付帳款流程負責人，姓名與職務目前為 `missing`。

**所需輸入：**現行 SOP、例外類型、責任分工、去識別化案件紀錄、指標定義與資料存取決定。

**完成條件：**負責人逐項接受或修正現況與目標流程；資料負責人確認可用欄位、期間、品質與使用權限；雙方核准唯讀重播的成功條件。

## 證據台帳

| 主張 | 狀態 | 現有依據 | 限制 |
| --- | --- | --- | --- |
| 發票例外可能造成跨系統查核與等待 | `proposed` | 常見流程的參考假設 | 未經目標企業觀察，不能視為現況事實 |
| 建議的正常、例外、升級與重工路徑符合目標企業 | `missing` | 尚無流程負責人或操作人員確認 | 阻擋現況診斷定案 |
| 統一例外分類與責任歸屬能改善處理時間 | `proposed` | 本提案的改善假設 | 必須以接受的基線及唯讀重播驗證 |
| 企業歷史案件可供使用 | `missing` | 尚無來源、權限、用途及保存決定 | 阻擋真實資料重播 |
| 新流程不增加錯付或重複付款風險 | `unverifiable` | 尚未進行控制測試 | 阻擋試行與效益主張 |
| AI 是第一階段必要介入 | `proposed`（否） | 穩定核對與控制可用流程及確定性軟體處理 | 僅在重播顯示殘餘語言工作時重新評估 |

## 企業審閱與接受紀錄

接受本提案僅代表同意問題邊界、驗證方法與下一步，不代表成效已被證明。

| 項目 | 決定／修正 | 負責人 | 日期 | 證據位置 |
| --- | --- | --- | --- | --- |
| 現況流程 | `missing` | `missing` | `missing` | `missing` |
| 目標流程與責任分工 | `missing` | `missing` | `missing` | `missing` |
| 指標、基線與成功條件 | `missing` | `missing` | `missing` | `missing` |
| 歷史案件存取與去識別化 | `missing` | `missing` | `missing` | `missing` |
| 唯讀重播授權 | `missing` | `missing` | `missing` | `missing` |

## 提案決議

- [ ] 接受並進入唯讀重播準備
- [ ] 修正後再審
- [ ] 不進行

決策理由、限制與後續負責人：`missing`