做跨境平台的，财务月底对账被汇率坑过的，估计不少。订单是上周下的，客户这周才付款，财务顺手按今天的汇率入账，月底一结，差出几千块，说不清是赚是亏。退款更麻烦：客户三个月前用奈拉付的钱，现在退，按哪个汇率？按原来的，客户觉得少拿了；按今天的，公司账上多一笔莫名其妙的损益。这事儿跟技术多牛没关系，纯粹是规则没定清楚。
一、先把「记账汇率」固定下来
一笔跨境订单至少有四个时点：下单、支付、退款、结算。每个时点用哪条汇率，得白纸黑字写下来。
我们的做法是：前端展示用实时参考价，加一句「以支付时汇率为准」的提示；支付成功那一刻，把当时的汇率、来源、时间戳一起写进订单表。这条就是「交易汇率」，后面退款、对账、开票全以它为准，不重算。
别小看这一条。很多系统出问题，就是因为退款时又去查了一次实时汇率。
二、汇率是一条带时间的记录，不是普通的数字
表里至少要有这些字段：
| 字段 | 说明 |
|---|---|
| 源 | 央行 / 商业银行 / 支付渠道 / 人工 |
| 币种对 | USD/CNY、USD/NGN…… |
| 买入/卖出价 | 别只存中间价 |
| 生效时间 | 精确到秒，统一 UTC |
| 抓取时间 | 和生效时间分开存 |
| 是否人工覆盖 | 谁改的、什么时候、为什么 |
汇率服务要有缓存，TTL 按币种分。主流币种几分钟刷一次，小币种一天一次就够。接口挂了要有降级：先用本地缓存最后一条，超过阈值告警，再不行走人工审批的兜底价。最忌讳的是接口一挂，下单直接报错。
三、四个场景，四套规则
- 报价：展示价 = 基准价 × (1 + 加点率)。加点按币种、按渠道配，别写死一个 2%。
- 收款：以支付渠道回传的实际结算金额为准，和订单金额的差额进「汇兑损益」科目。
- 退款：默认按原交易汇率退，配置项允许按当日汇率，但退款单上要标明用了哪条。
- 结算与账务：月底对未清余额做重估，重估差额单独挂账，不动原始交易记录。
四、几个常见的坑
- 金额用浮点数存。汇率一乘，0.1+0.2 变成 0.30000000000000004，对账永远差几分钱。老老实实用最小货币单位的整数存。
- 退款按当日汇率重算。客户明明付了 100 美金，退回来 98，投诉电话就打过来了。
- 所有支付渠道共用一个汇率。渠道成本不一样，该分的账分不开。
- 手工改汇率不留痕。出了事查不到是谁、什么时候、为什么改的。
- 时区没统一。美国团队按纽约时间算，深圳财务按北京时间算，跨月那天的单子永远对不上。
五、多国市场得允许并存两套价格
尼日利亚奈拉、巴西雷亚尔、塞拉利昂利昂这些货币，官方牌价和实际能换到的价经常差一截。系统里最好让「官方价」和「结算价」两条并存，前端展示用哪条、财务入账用哪条、差额进哪个科目，全做成配置，别在代码里写 if-else。香港、新加坡的客户一般用中间价加银行点差，逻辑相对干净，但同一套模型也得能覆盖。
六、实际实施顺序
- 先拉财务和业务，把每类交易用哪条汇率列成一张表，签字确认。
- 再搭汇率服务，接一两个源，配好缓存和降级。
- 然后把快照字段加进订单、退款、结算三张表。
- 最后做对账报表和月末重估。
顺序反了，先接 API 再想规则，后面改起来要付出很大代价。
这套东西技术上不难，难在规则。我们给香港、新加坡、尼日利亚的客户搭过几套，模板是现成的。你们要是正在理这块，把现在的币种清单和对账流程发过来，我们帮着看看哪一步最容易漏。
