1. 案例一頁摘要（30 秒速讀版）
這不是一個「要不要」的決策案例，而是一件行政管理處財務部財會課會計組每天都要做的例行工作：把 POS 日結、支付平台明細、銀行入帳三份報表兜在一起，確認錢有沒有真的進來、進來的金額對不對。2026-07-18（六）這天，13 種支付工具、158 筆交易，人工要花約 2.5 小時逐筆核對；用 Codex／ChatGPT 上傳三份資料＋1 份規則表，5 分鐘就能跑出一份差異清單。這個 demo 的重點不是训练你做財務分析判斷，而是示範「有明確規則的例行核對工作，怎麼用 AI 一次做完」——成品是一張核對表／差異清單，不是決策 memo。資料裡刻意埋了 3 個真異常，其餘所有看起來「對不上」的地方，全部都能用手續費與入帳天數規則完全解釋，這正是本案要考驗你的地方：分得清楚「正常的時間差」跟「真的出問題」。
2. 情境背景與量化錨點
情境：每逢週末假日隔天，會計組都要把前一天的營收做三方對帳：POS 日結表（門市端）、支付平台交易明細（金流端）、銀行入帳明細（銀行端）。三份資料口徑不同——POS 是「賣了多少」、平台明細是「金流商收了多少、要收多少手續費」、銀行入帳是「錢實際進帳戶多少、哪一天進」——三者之間本來就會因為手續費與入帳天數（T+N）產生「正常的落差」，會計組的工作就是把這些正常落差濾掉，抓出真正異常的部分。
量化錨點：
| 錨點 | 數字 | 資料來源 |
|---|---|---|
| ① 支付工具種類 | 13 種（現金、VISA、Master、JCB、聯名卡、LINE Pay、街口支付、Apple Pay、悠遊付、台灣Pay、全盈+PAY、icash Pay、禮券） | G6-4a 規則表 |
| ② 當日交易筆數 | 支付交易明細（G6-5）共 158 筆；POS 日結（G6-4）共 157 筆（155 筆正向交易＋2 筆退貨沖帳負數列） | G6-4、G6-5 |
| ③ 人工 vs. Codex 作業時間 | 人工逐筆核對約 2.5 小時／天 → Codex／ChatGPT 上傳四份檔案，約 5 分鐘產出差異清單 | 投影片錨點（會計組工時估算） |
| ④ 真異常數量 | 全部差異中，只有 3 筆是真的需要查核的異常，其餘均可用規則表完全解釋 | 綜合三方資料比對結果（見第 6 節） |
3. 資料檔清單與每檔重點欄位說明
| 檔案 | 重點欄位 | 這份資料能回答什麼 |
|---|---|---|
G6-4_POS日結業績_20260718.csv/.md | 交易序號、時間、樓層、櫃位、支付方式、金額_元 | 門市當天實際刷出去的每一筆交易；157 筆（155 正向＋2 退貨沖帳）。 |
G6-5_支付交易明細_20260718.csv/.md | 平台、平台交易序號、對應POS序號、金額_元、手續費_元、預計入帳日 | 支付平台／收單機構端看到的每一筆交易與對應手續費、預計何時入帳；158 筆。 |
G6-6_銀行入帳明細_20260719.csv/.md | 入帳日、摘要、入帳金額_元、對應平台 | 銀行帳戶實際收到多少錢、哪一天收到；每個支付工具一筆彙總入帳，共 13 列＋1 筆無法對應來源的入款。 |
G6-4a_支付工具規則表.md | 支付工具、費率、入帳天數（T+N） | 判斷「明細金額 − 手續費 = 銀行入帳金額」是否成立、入帳日期是否合理的唯一依據——這是整個對帳作業的判準來源，不是background資料。 |
4. 完整 Work Brief（與投影片一字不差）
「請完成《0718 營收三方對帳差異清單》： 1. 只用 G6-4、G6-5、G6-6 三份檔案與 G6-4a 規則表。 2. 依支付工具逐筆比對 POS、交易明細與銀行入帳。 3. 依規則排除手續費與入帳天數造成的正常差異。 4. 列出真異常：金額、櫃位、可能原因、建議查核動作。 5. 輸出差異總表＋3 行主管摘要；不得編造資料。」
5. 20 分鐘上機流程指引
0–5 分：交代 Brief
本段重點：
- 這個 demo 跟前面幾個不一樣，不是要你做判斷、下決策，是要示範一件會計組每天都要做的例行工作，怎麼用 AI 5 分鐘做完原本 2.5 小時的事。
- 先讀規則表：G6-4a 規則表不是背景資料，是這次對帳的「法規依據」——沒有先讀規則表，AI 會把所有 T+1、T+2 的正常入帳時間差全部誤判成異常，做出一份錯誤百出的差異清單。
- 範圍限定：只能用 G6-4、G6-5、G6-6、G6-4a 這 4 份，不得編造資料、不得假設沒給的手續費或費率。
檢查點：是否把模擬數字當真實財務資料
- 這份資料是課程模擬資料，交易序號、金額、銀行摘要均為虛構，數字經過設計不代表任何真實交易。請注意：這不是台茂真實的營收數字，是為了教學設計的模擬資料，用途僅限於練習「三方對帳」的方法，不可外流當成真實財務資訊看待。
5–14 分：執行比對
本段重點：
- 先把 4 份檔案（含規則表）一次上傳，再下指令，不要分批問。
- 提問方式建議：「不要問『這些資料有沒有問題』，要問『請用 G6-4a 的費率與入帳天數規則，逐支付工具核對 G6-5 明細金額扣除手續費後，是否等於 G6-6 對應平台的銀行入帳金額；入帳日期是否符合 T+N；再核對 G6-4 與 G6-5 逐支付工具的筆數與金額是否一致，列出無法用規則解釋的差異』。」
- 留意 AI 有沒有把「LINE Pay 的入帳日是 07-20（T+2），現在還沒到」直接當成「這筆錢不見了」的異常——這是本段最常見的翻車點（詳見第 7 節）。
檢查點：是否把 T+1／T+2 的正常時間差誤報成異常
- 好答案的樣子：AI（或你）的輸出裡，對每個支付工具都先確認「入帳金額 = 明細金額 − 手續費」「入帳日 = 交易日 + N」兩件事都成立，才判定為正常；只有真的兩邊都對不上的，才放進異常清單。
- 你做出的「異常清單」，應該恰好是這 3 筆：
1. 5F 美食街 F12 櫃：LINE Pay 明細有一筆 12,800 元，POS 沒有對應紀錄（漏登）； 2. 3F A31 櫃：VISA 退貨 6,450 元，POS 沖帳了兩次（兩筆 -6,450），但支付平台只有一筆退款； 3. 銀行入帳出現一筆 45,000 元，找不到對應的支付平台或交易來源。
14–20 分：主管修正
成品：差異總表＋3 行主管摘要
本段重點：
- 完成差異清單初稿後，試著回答以下主管視角的追問：
1. 「這份清單裡有沒有把 LINE Pay、街口支付這種 T+2 的項目誤判成異常？回頭再檢查一次。」 2. 「45,000 元這筆不明入款，你打算怎麼查？找誰查？」——這是核心追問，要把「發現異常」升級成「有負責人、有下一步」的查核動作，而不是列完清單就結束。
- 把「建議查核動作」寫具體：例如「請財會課會計組同仁調閱銀行往來對帳單原始憑證，並比對是否為其他部門（如招商押金、廣告款）誤入本帳戶；如 3 個工作天內無法釐清來源，簽報財會課主管並知會銀行往來窗口」，而不是籠統寫「進一步確認」。
好答案長什麼樣：
- 差異總表：每個支付工具一列，欄位至少含「明細金額合計、手續費合計、應入帳金額、銀行實際入帳金額、入帳日是否相符、判定（正常/異常）」；
- 3 行主管摘要（例如）：「0718 全館 13 種支付工具、158 筆交易對帳完成，僅 3 筆真異常：F12 櫃 12,800 元漏登 POS、A31 櫃退貨 6,450 元重複沖帳、銀行有 45,000 元不明入款待查。其餘差異均為手續費與入帳天數造成的正常落差，已逐筆核對相符。建議：F12 補登 POS、A31 沖銷多餘一筆退貨、45,000 元由會計組 3 日內查明來源並簽報。」
- 每個異常都有「金額、櫃位（或位置）、可能原因、建議查核動作」四個欄位，不能只列金額。
6. 埋梗解答（做完再對答案）做完再看
(a) 全平台勾稽總表（逐一驗算，供你核對自己的答案）
驗算公式：銀行入帳金額_元 = G6-5 明細金額合計_元 − 手續費合計_元；入帳日 = 交易日（2026-07-18）+ G6-4a 規則表天數。
| 支付工具 | 費率 | 入帳天數 | 明細筆數 | 明細金額合計 | 手續費合計 | 應入帳金額 | 應入帳日 | 銀行實際入帳金額 | 銀行實際入帳日 | 判定 |
|---|---|---|---|---|---|---|---|---|---|---|
| 現金 | 0% | T+0 | 25 | 31,390 | 0 | 31,390 | 07-18 | 31,390 | 07-18 | 正常 |
| 禮券 | 0% | T+0 | 3 | 6,920 | 0 | 6,920 | 07-18 | 6,920 | 07-18 | 正常 |
| VISA | 1.55% | T+1 | 22 | 113,050 | 1,854 | 111,196 | 07-19 | 111,196 | 07-19 | 正常（＊金額本身已含隱藏異常，見(c)） |
| Master | 1.55% | T+1 | 15 | 50,340 | 781 | 49,559 | 07-19 | 49,559 | 07-19 | 正常 |
| JCB | 1.65% | T+1 | 8 | 26,780 | 441 | 26,339 | 07-19 | 26,339 | 07-19 | 正常 |
| 聯名卡 | 1.50% | T+1 | 10 | 26,890 | 403 | 26,487 | 07-19 | 26,487 | 07-19 | 正常 |
| Apple Pay | 1.55% | T+1 | 10 | 19,500 | 302 | 19,198 | 07-19 | 19,198 | 07-19 | 正常 |
| 台灣Pay | 1.00% | T+1 | 7 | 6,910 | 68 | 6,842 | 07-19 | 6,842 | 07-19 | 正常 |
| LINE Pay | 2.20% | T+2 | 23 | 37,810 | 831 | 36,979 | 07-20 | 36,979 | 07-20 | 正常（＊筆數本身已含異常，見(b)） |
| 街口支付 | 2.00% | T+2 | 15 | 12,220 | 243 | 11,977 | 07-20 | 11,977 | 07-20 | 正常 |
| 悠遊付 | 1.80% | T+2 | 8 | 6,970 | 125 | 6,845 | 07-20 | 6,845 | 07-20 | 正常 |
| 全盈+PAY | 1.80% | T+2 | 6 | 4,320 | 78 | 4,242 | 07-20 | 4,242 | 07-20 | 正常 |
| icash Pay | 1.80% | T+2 | 6 | 5,140 | 92 | 5,048 | 07-20 | 5,048 | 07-20 | 正常 |
| 合計 | 158 | 348,240 | 5,218 | 343,022 | 343,022 | 13 平台金額全部相符 | ||||
| 不明入款 | — | — | — | — | — | — | — | 45,000 | 07-19 | 異常③ |
驗算結論：13 個支付工具「明細金額合計 − 手續費合計」與銀行實際入帳金額逐一相符，入帳日也全部符合 T+N 規則——單看這張總表，13 個平台看起來「全部正常」。但這正是本案要考驗你的地方：VISA 的「正常」是假象。銀行是照著支付平台明細（G6-5）把錢清算入帳的，而 G6-5 的 VISA 明細裡，本來就已經內含了 A31 櫃重複沖帳造成的異常（見 (c)）——銀行端只是忠實反映了「已經出錯的明細」，所以「明細 vs 銀行」這條線永遠對得上，真正的異常必須回頭比對「POS vs 明細」才抓得到，這也是 Brief 第 2 條要求「依支付工具逐筆比對 POS、交易明細與銀行入帳」三方都要比、不能只比後兩方的原因。
(b) 異常① F12 漏登：筆數比對就能抓到
G6-4（POS）與 G6-5（明細）逐支付工具核對筆數：LINE Pay 在 POS 只有 22 筆，明細卻有 23 筆，差 1 筆。往下查這 1 筆多出來的明細：LINE Pay、金額 12,800 元、對應 POS 序號欄位是空白——代表這筆交易平台端收到了錢，但 POS 沒有留下對應紀錄。經查證屬於 5F 美食街 F12 櫃（此欄位無法單純從 G6-5 的欄位看出，需會計組向 5F 樓管與 F12 商家調閱當日收據 / POS 交易紀錄後才能鎖定，這也是 Brief 第 4 點要求「建議查核動作」的原因——不是所有異常都能只靠三份報表比對出答案，有些需要人工介入現場查證）。建議查核動作：請 F12 櫃位負責人確認當日是否漏刷 POS，補登 157 → 158 筆，並請 5F 樓管複核。
(c) 異常② A31 重複沖帳：筆數比對抓不到，要看金額
G6-4 與 G6-5 的 VISA 筆數都是 22 筆，完全一致——如果只做「筆數比對」，VISA 會被判定為完全正常，這正是陷阱所在。往下比對「金額」：POS 端 VISA 金額合計為 106,600 元，明細端 VISA 金額合計為 113,050 元，兩者相差 6,450 元。追查明細，發現 3F A31 櫃原始銷售 6,450 元（VISA，POS 序號 P0038）之後有一筆退貨；但 POS 端這筆退貨被沖帳了 兩次（P0047、P0123 各一筆 -6,450 元），而支付平台明細只看到 一筆退款 -6,450 元——POS 多沖了一筆不存在的退貨，等於少計了 6,450 元的當日淨業績。
VISA 筆數為什麼「剛好」還是 22 對 22？ 因為 6F D05 有一筆 38,700 元的大額 VISA 消費（POS 序號 P0040，屬正常交易，非異常），支付平台因單筆請款金額較大，將這筆拆成 2 筆入帳明細（21,000 元＋17,700 元，加總與 POS 相符，屬正常批次拆帳，不列入異常）——這筆「明細多 1 筆」的正常拆帳，恰好抵掉了「A31 重複退貨造成 POS 多 1 筆」的異常，兩個各自獨立、性質完全不同的原因疊加後，讓 VISA 的總筆數表面上維持一致。這正是本案要教的核心教訓：筆數比對只能抓出「總數對不上」的異常（如 F12），完全抓不出「筆數剛好被別的正常原因抵銷掉」的異常（如 A31）——一定要逐支付工具、逐金額比對，不能只看總數或只看筆數。 建議查核動作：請會計組同仁沖銷 A31 櫃多出的一筆 -6,450 元 POS 退貨紀錄，並請 3F 專櫃複核退貨僅發生一次。
(d) 異常③ 銀行不明入款：三份資料都對不到，必須另案查證
銀行入帳明細中有一筆 2026-07-19 入帳 45,000 元、摘要「跨行匯入-未標明用途」，對應平台欄位空白。核對 G6-5 全部 158 筆明細金額與任何組合，均找不到能兜出 45,000 元（或扣手續費後兜出 45,000 元）的合理對應——這筆錢不屬於當日任何一種支付工具的營收清算，可能是其他部門款項（如招商押金、廣告合作款、保證金）誤入本對帳戶，也可能是銀行作業錯帳。建議查核動作：由財會課會計組於 3 個工作天內調閱銀行往來明細原始憑證，並發函／致電銀行往來窗口確認匯款人與用途；同時排查招商、工務等其他部門近期是否有應收款項尚未入帳；若逾期無法釐清來源，簽報財會課主管，並比照公司「不明款項處理原則」列管。
7. 常見翻車點與修正方法
| 翻車點 | 症狀 | 修正提示 |
|---|---|---|
| 沒看規則表就開始比對 | AI 直接比較 G6-5 金額與 G6-6 入帳金額，發現「幾乎每個平台都對不上」，整批誤判成異常 | 「Brief 第 3 條說了要『依規則排除手續費與入帳天數造成的正常差異』——你有沒有先把 G6-4a 讀進去，讓 AI 知道 VISA 要扣 1.55% 手續費、隔天才入帳？沒有規則表，AI 是用『金額完全相等』的標準在比對，當然全部都不合格。」 |
| 把 T+2 還沒入帳當成錢不見了 | LINE Pay、街口等 T+2 項目在 07-19 的銀行明細裡「還沒出現」，AI 直接列為異常 | 「LINE Pay 的規則是 T+2，交易日 07-18，入帳日應該是 07-20——銀行明細檔名雖然叫 20260719，但裡面本來就會涵蓋到 07-20 才入帳的項目，你要先查這筆到底『入帳日還沒到』還是『真的沒入帳』，不要看到日期沒對齊就喊異常。」 |
| 只做筆數比對，漏掉 A31 重複沖帳 | 發現 POS 157 筆、明細 158 筆，只解釋了 F12 這 1 筆差異就收工，沒有逐支付工具核對金額 | 「你解釋了『筆數』的 1 筆落差，但 Brief 第 2 條要你『逐支付工具』比對——VISA 的筆數明明對得上（22 對 22），你有沒有進一步比對 VISA 的『金額』？筆數對不代表金額對，這是本案故意設計的陷阱，你要抓出來。」 |
| 對 45,000 不明入款只寫「待查」就結案 | 異常清單裡 45,000 元那一列的「建議查核動作」寫「進一步確認」或空白 | 「『進一步確認』是誰要確認？什麼時候確認完？Brief 第 4 條要你列出『建議查核動作』，不是『備註』——請你重寫成有負責單位、有時限、有下一步的具體動作，例如『財會課 3 日內調閱銀行憑證並聯繫銀行窗口』。」 |
| 編造沒有的手續費或費率 | AI 自己假設某個支付工具的費率或入帳天數（因為規則表沒明講的細節），而非老實標示「規則表未列此情形」 | 「Brief 第 5 條說『不得編造資料』——如果規則表沒寫的東西，AI 不能自己腦補一個費率出來湊,要嘛回頭問你有沒有漏給資料，要嘛就老實在輸出裡標示『此項規則未提供，無法判定』，不能自己掰一個數字讓報表看起來很完整。」 |
8. 延伸練習
用「明細金額扣手續費」反推銀行入帳金額，練習不依賴 AI 也能徒手驗算
時間允許時，建議你任選 2–3 個支付工具（建議挑 VISA 與 LINE Pay，因為這兩個工具內含隱藏異常），徒手（用計算機即可，不透過 AI）驗算：
- 從
G6-5_支付交易明細_20260718.csv篩出該支付工具全部列，加總金額與手續費； - 套用
G6-4a_支付工具規則表.md的費率，確認「明細金額合計 × 費率」約等於明細中的「手續費合計」（可能有 1 元內的四捨五入差異）； - 用「明細金額合計 − 手續費合計」比對
G6-6_銀行入帳明細_20260719.csv對應列的入帳金額，確認完全一致； - 再回頭比對
G6-4_POS日結業績_20260718.csv同一支付工具的筆數與金額，看能不能自己發現 VISA「筆數對、金額不對」的異常。
目的：實際體驗一次「AI 輸出的差異清單，自己也能徒手驗算出一部分」，建立對 AI 分析結果的查核能力，而不是照單全收——這正呼應第 6 節埋梗解答 (c) 的核心教訓：光看總表、總筆數容易被騙，真正的核對功夫在「逐項、逐金額」的細節裡。