多幣種賬戶，為什麼不能只顯示一個總餘額？
從美元、歐元和一個人民幣估值出發，理解原幣餘額、凍結、可用資金、換匯分錄與對賬。
賬戶裡有 100 美元和 50 歐元，可以說自己有“150”嗎？當然可以寫出這個數字，但它沒有一個共同單位，也不能直接說明能完成哪一筆付款。
多幣種產品看起來是在餘額旁邊多放幾個國旗，真正難的是把“持有什麼”“能花多少”和“摺合多少”講清楚。下面用假設的預存資金賬戶討論產品與賬務設計，不包含授信或透支。
三個問題，應該有三個答案
已入賬餘額回答賬戶記了多少錢；凍結或佔用回答其中多少暫時不能使用；可用餘額回答當前能用於新操作的資金。
| 幣種 | 已入賬餘額 | 已佔用 | 可用餘額 |
|---|---|---|---|
| USD | 100.00 | 30.00 | 70.00 |
| EUR | 50.00 | 0.00 | 50.00 |
在這個簡化模型中，可用 = 已入賬 − 佔用。真實產品若還有待入賬資金、準備金、授信或其他限制，應另外定義，不能機械套用一個公式。
使用者付一筆 80 USD 的訂單時，看到“美元餘額 100”會以為足夠，看到“可用 70，另有 30 佔用”才知道現在發生了什麼。
總資產可以估值，但不能替代原幣
繼續假設 1 USD = 7.20 CNY、1 EUR = 8.00 CNY。上面的已入賬資金合計估值為 1,120 CNY，可用資金合計估值則是 904 CNY。這裡忽略換匯費用，匯率也不是實時數據。
這兩個數字都能幫助理解規模，但 904 CNY 的估值並不意味著可以直接發起任意幣種的同額付款。能否自動換匯、兌換路徑、最低金額、費用和限額，還需要看賬戶的實際能力。
因此我會保留每個原幣餘額，在彙總旁註明估值幣種、匯率時間和計算範圍。展示“總資產”時，不要悄悄把凍結資金也說成可用資金。
金額要帶著單位進入系統
一個可靠的金額對象至少包含金額和幣種。幣種不能靠頁面當前選項猜測，也不能在查詢或回調裡丟失。
不能一律按兩位小數處理：JPY 通常按零位小數表示，USD 通常為兩位，但具體 API 的最小單位與例外仍須核對。匯率、費用計算和展示還可能各有不同精度。
內部用精確十進制或按明確幣種規則換算的整數最小單位，避免二進制浮點直接累計資金。每一步在哪個精度舍入、餘數怎樣歸屬，都應能復現。
換匯是一組關聯動作
假設一次兌換減少 100 USD、增加 92 EUR。它不應該只是把餘額字段從一個數字改成另一個數字，也不能直接把 −100 與 +92 相加，宣稱分錄不平。
需要分別記錄美元側和歐元側的資金變化，通過換匯訂單、報價和相應的清算或橋接科目關聯；每個幣種按賬本模型保持可核查的平衡。手續費使用自己的幣種和分錄，業務估值與會計本位幣處理另行約定。
當一側已經確認、另一側結果未知時，先進入對應的處理中或待核對狀態。不能為了讓頁面看著完整，就提前增加另一幣種的可用餘額。衝正也應保留原記錄，通過關聯的逆向記錄修正。
對賬必須回到每一種幣
原始交易、授權佔用、最終入賬、手續費和退款可能是多條記錄，時間也可能不同。對賬需要先按幣種、賬戶和提供方引用匹配，再解釋跨幣種關係。
退款關聯原交易，部分退款累計檢查上限，重複通知只處理一次。外部超時保留未知，之後用查詢和報告收斂；頁面上一個綠色勾號不能替代賬本確認。
如果總估值剛好相同，也不能據此說所有原幣都對平了。美元短缺和歐元多記，可能在某個匯率下互相抵消，卻依然是兩項真實錯誤。
界面簡潔，解釋要完整
我希望默認界面只突出幾個有用的信息：每幣種可用餘額、佔用、待處理事項，以及帶時間的總估值。點擊後再展開對應交易、費用和換匯記錄。
這背後需要清楚的數據層次：提供方原始結果、內部資金與狀態模型、對外接口、頁面展示。原幣金額、字符串標識和關聯引用要沿鏈路保留，不能為了“統一展示”提前壓成一個總數。