链上扣了 98.5 U，发票上是 100 U——差出来的那 1.5 U，财务最不该先去翻"手续费"那一栏。在稳定币支付里，Gas 是显性成本，归因和兑换价差才是吃掉对账时间的大头。
财务对账的核心不是"金额对不对"，而是"这笔钱对应哪张发票、谁付的、为什么差这么多"。差个一两块，通常不是算错了，是链路里某一环没对齐。
第一站：先看"到账状态"是不是被误判了
链上显示交易成功，不等于财务系统能把它标记为"已付款"。
可能的情况：
你付的是 USDC，供应商系统等的是 USDT。链上确实转了，但供应商的自动收款只认 USDT，这笔 USDC 进了钱包但没有触发"订单已支付"的状态更新，成了挂在账上的"孤儿资金"。
你没填 Memo 或 Tag。交易所或钱包用同一个地址收多个客户的款，Memo 是区分你是谁的唯一标识。没填，钱到了但不知道是谁的，财务得人工去翻链上记录才能认领。
怎么查：
打开区块浏览器，看收款地址——如果是交易所热钱包地址，大概率需要 Memo。
问供应商那边："你们结算系统认这笔交易吗？订单状态有没有自动更新？"
如果没有，财务需要把链上交易哈希和订单号做手工绑定。
完成标准： 供应商确认订单状态已更新为"已付款"，而不是"钱到了但不知道谁的"。
第二站：金额差一分，归因可能跨了三条链
发票上的 100 美元，到你钱包里变成 98.5 美元，中间差的 1.5 美元可能是这三样东西叠加出来的：
| 扣款项 | 金额范围 | 是否在发票里 |
|---|---|---|
| 入金手续费（法币→稳定币） | 0.1%-1.0% | 否，通常不列 |
| 链上 Gas | < $0.01（Solana/L2） | 否 |
| 兑换滑点/价差 | 0.1%-1.0% | 否 |
| 出金手续费（稳定币→法币） | 10-40 bps（成熟市场） | 否 |
关键洞察： 链上 Gas 是整条链路里最不起眼的一笔。Solana 或 L2 网络上每笔转账的链上费用不到 0.01 美元，真正的成本大头在法币进出的两道门——入金和出金环节。如果你把精力花在查 Gas 上，大概率是白忙一场。
怎么查：
找到供应商用的出金服务商（交易所、支付网关），查它的出金费率。
找出金时用的网络和交易对——USDC/USD、USDC/EUR 等，滑点差异很大。
如果供应商走的是"实时兑换"模式，汇率锁定在付款那一刻；如果供应商"先收再换"，中间的汇率波动也可能造成差额。
完成标准： 能把 1.5 美元拆成"0.8 美元出金费 + 0.5 美元滑点 + 0.01 美元 Gas + 0.19 美元未知差异"，未知差异才是需要深挖的部分。
第三站：如果每笔订单都有独立地址，归因自动完成
这是解决"钱到账但不知道是谁"最彻底的办法。
怎么做：
每张发票生成一个独立的收款地址。供应商给你发票时，附一个专属的生成地址。
付款到那个地址，链上一到账，财务系统直接知道这笔钱对应哪张发票——不需要人工匹配。
Stable 的做法更激进： 发票元数据（发票号、买卖双方、金额、到期日）通过哈希算法生成一个确定性 nonce，买方签名付款时用的就是这个 nonce。链上结算时触发的 AuthorizationUsed 事件直接包含这个 nonce，把链上交易和发票绑定在一起，不需要外部对账系统去"猜"。
如果你没有这套工具：
至少做到：付款时在链上交易数据里附上发票号或订单号（部分链支持自定义备注字段）。
用对账工具把链上交易记录拉下来，按时间、金额、地址做匹配。
完成标准： 财务能在一分钟内回答"这笔 98.5 U 的交易对应哪张发票"，而不是花半小时翻钱包记录。
核验收尾
差一笔对不上，别急着翻 Gas 费。按这个顺序排查：
归因查没查？——是不是没填 Memo，或者钱进了供应商的系统但没被认领。
兑换和出金费用查没查？——出金费率、滑点、汇率时间差，这些才是大头。
收款地址是不是独立的？——如果所有人共用一个地址，对账会一直疼下去。
核验渠道： 把链上交易哈希发给供应商，问三个问题：
"这笔钱在你们系统里被认领了吗？对应哪张发票？"
"你们出金用了什么通道，费用多少，汇率锁在哪一刻？"
"我们能不能给每张发票生成独立地址，以后不用再人工对？"
