昨天確認了多筆支出的新增、編輯與刪除，今天把焦點放在付款人。朋友一起出門，不一定每筆都由同一個人付錢，可能小明付晚餐、小美買咖啡、阿哲付車資。最後需要整理的，是每個人已經拿出多少錢，以及原本應該負擔多少。

今天先釐清三個數字。已代墊，是替這本帳中的支出先付出去的金額；應分攤，是根據參與名單與分攤規則計算的消費負擔；淨額則是已代墊減掉應分攤。淨額為正，代表應該收回差額；為負，代表還需要補款；等於零，才是剛好平衡。

目前每筆支出仍然只有一位付款人。「不同人代墊」指的是不同筆支出可以由不同人付款，不代表已支援同一筆消費由兩個人共同付款。先把範圍說清楚，文章才不會把目前的功能寫得比實際更多。

我先用原本的三筆範例核對。晚餐 1,200 元由小明代墊，三人均分；咖啡 280 元由小美代墊，只有小明和小美參與；車資 350 元由阿哲代墊，三人分攤。三人的應分攤金額分別是 657、657、516 元，已代墊則是 1,200、280、350 元。

兩者相減，小明應收回 543 元，小美還需付 377 元，阿哲還需付 166 元。因此，雖然三個人都先付過錢，最後仍然只有小明收款。這也提醒我，不能只看誰有付款，就認為他不需要再付了。

接著在瀏覽器裡，把晚餐的付款人從小明改成小美，保留原金額與參與者。儲存後，總額仍是 1,830 元，三人的應分攤也仍然是 657、657、516 元。改變的是小明的已代墊變成零，小美累計代墊 1,480 元，阿哲維持 350 元。

新的付款清單是小明付小美 657 元，阿哲付小美 166 元，小美收回 823 元。這個案例確認，更換付款人只改變誰先拿出錢，不應該改變誰吃了多少、誰參與了哪些消費。

之後把晚餐付款人改回小明，結果也回到原本的小明應收 543 元、小美應付 377 元、阿哲應付 166 元。還原操作能幫助確認，程式沒有把新舊付款人的代墊金額重複累加。

另一個情境是，代墊者沒有參與消費。我把咖啡改由阿哲付款，但參與者仍然只有小明與小美。畫面保留兩人各分攤 140 元，沒有因為阿哲付款，就把他自動加入咖啡的分攤名單。

此時阿哲合計代墊 630 元，原本應分攤的 516 元不變，所以他從需要補款的人，變成應收回 114 元的人。小明仍應收 543 元，小美則需付 657 元。最後的清單是小美付小明 543 元，再付阿哲 114 元。

這個結果也說明，結算清單整理的是整本帳的淨額，不一定逐筆照原本的消費關係還錢。只要最後每個人的應收應付正確結清，就不必把每一筆代墊都拆開處理。不過，今天沒有證明轉帳筆數在所有情況下都是最少，因此不把它稱為保證最佳的方案。

我也測試了取消更換付款人。在咖啡表單中把阿哲改成小美，但按下取消，回到帳本後仍由阿哲代墊，結算維持不變。表單裡尚未儲存的選擇，不應該提前改掉原帳目。

計算模組部分，今天共執行八項案例，全部通過。除了上述情境，還包含全部由同一人代墊、三人各付 300 元後剛好平衡、已代墊仍需補款、同一人多筆付款累計，以及反轉支出順序後結果保持一致。

例如兩筆三人均分的支出，小明先付 600 元，小美先付 60 元，總共 660 元，每人應負擔 220 元。小美雖然已經付了 60 元，仍需補上 160 元；阿哲需付 220 元，小明收回 380 元。這個例子比單純說「付款人也要分攤」更容易理解。

每個測試都核對了代墊合計與分攤合計是否等於消費總額，以及淨額加總是否為零，也模擬按照付款清單交付後，各人的差額是否全部歸零。三人各付 300 元的案例則確認，所有人平衡時不會產生多餘的轉帳。

瀏覽器完成五個檢查點：原始帳目、晚餐更換付款人、還原付款人、咖啡改由未參與者代墊，以及取消更換付款人。其餘案例是在計算模組中驗證，沒有把它們全部寫成已經操作過的畫面測試。

第十一天完成了既有不同人代墊功能的驗證，沒有修改產品程式，也沒有提交或發布新版。目前仍只在當前頁面保存帳目，尚未涵蓋同筆多人付款、實際轉帳或所有裝置的完整測試。

今天最大的收穫，是更清楚地分開「誰付了錢」和「誰應該負擔」。和 AI 討論分帳時，把已代墊、應分攤與淨額逐一列出來，就能用具體數字確認它有沒有把角色混在一起。下一天會聚焦每筆支出的參與者，檢查沒有喝咖啡的人，是否真的不會被算進那筆費用。