多货币订阅开票：匹配的四舍五入规则

为什么订阅发票会在不同系统间漂移

一个常见的头疼问题：网页结账显示一个总额，移动端显示略微不同的总额，会计导出又是第三个数字。每个系统都在做“合理”的数学运算，但方法不相同。

订阅会放大这个问题，因为你不断重复同样的计算。小差异会在续费时累积，在有人中途升级导致的分摊、抵扣与退款、失败支付后的重试扣款，以及计费期开始或结束的部分期间时尤为明显。

漂移通常始于一些微小的、在可视阶段不可见的选择：何时四舍五入（按行或最后总计）、使用哪个税基（净额还是含税毛额）、如何处理有 0 位或 3 位小数的货币、以及使用哪个 FX 汇率（哪个时间戳、哪个来源、什么精度）。如果网页在每一行都四舍五入到 2 位小数，而移动端只在最终总额四舍五入，即使输入相同也会产生 0.01 的差异。

目标很无聊但很重要：同一张发票在任何地方、任何时候都应产生相同的总额。这能让客户放心、减少客服工单，并在审计时站得住脚。

“保持一致”意味着对于给定的发票 ID 与版本：

• 货币与小数位规则在 web、移动与导出间一致。
• 税务方法一致（包括税是按行四舍五入还是按发票四舍五入）。
• 四舍五入与余数处理是固定且可重复的。
• 使用的任何 FX 汇率都被钉在发票上（汇率、精度与生效时间）。

示例：客户在月中将 EUR 19.99 升级到 EUR 29.99，产生分摊费用，随后因停机获得小额抵扣。如果一套系统对每个分摊行四舍五入，而另一套只在最终总额四舍五入，导出的发票可能会与客户看到的不一致，尽管每个数字看起来都“够接近”。

基础知识：货币、小数位、净额-税-毛额

在争论 FX 汇率或税务四舍五入规则之前，先把基础锁定好。如果这些不清楚，发票就会在你的 web、移动和会计导出间发生漂移。

每条发票行和发票总额应该明确携带三项金额：净额（未税）、税额、毛额（净额 + 税）。选择其中之一作为存储与计算的事实来源，然后在所有地方用同一方式推导其他两项。很多团队会存净额与税额，然后计算毛额为净额 + 税，因为这样便于审计和退款。

明确标注每个数字对应的货币。团队常混淆三种不同的概念：

• 发票货币：打印在发票上并用于总额的法定货币。
• 客户展示货币：当有人在界面浏览套餐时显示的货币。
• 结算货币：支付处理方结算到你银行账户的货币。

它们可以相同，但也可以不同。如果你的发票是 EUR 而卡在 USD 结算，发票仍应在 EUR 中保持一致，即便银行入账不同。

接下来，把钱当作小单位的整数对待（例如以分为单位）。以浮点数存 9.99 是产生 9.989999 类问题的常见方式，尤其在添加税、折扣、分摊或多项商品时。存 999（分）并记录货币代码，只在展示时格式化。

最后，决定你的定价税模式：

• 税外价（Tax-exclusive）：价格为净价，在其上加税。
• 含税价（Tax-inclusive）：价格已含税，需从中推算出净额。

一个具体检查：标为 10.00（含税，20% VAT）的套餐应在 web 和移动端生成相同的小单位毛额存储值，然后用统一规则推导净额与税额。

FX 汇率：差异通常从这里开始

外汇差异常在税与四舍五入规则之前就产生。两个系统都可能“正确”，却因为使用了不同的来源、不同的时间戳或不同的精度而不一致。

汇率提供商很少完全一致：有的提供中间价，有的包含点差。有的每分钟更新，有的每小时或每日更新。即便是同一个提供商，一端把汇率四舍五入到 4 位小数，而另一端保持 8 位小数以上，也会在把订阅金额与税相乘时改变总额。

最重要的决定是你的汇率时间戳意味着什么。如果你以 EUR 开具发票，但客户以 USD 支付，你是在发票开具时锁定汇率，还是在抓取付款时锁定？两者都常见，但在 web、移动与会计导出间混用会保证出现不匹配。

一旦选定规则，就把你使用的精确汇率存到发票上。不要在以后用“当前”汇率重新计算，即使你能查到历史汇率。提供商修正、时区差异和小的精度变化会让旧发票在导出或重新生成 PDF 时漂移。

一个简单例子：你在 23:59 开具发票，但付款在 00:02 成功。那些时间戳常落在提供商的不同“日”上，因此基于日表的汇率可能产生不同数字。

决定并记录这些 FX 细节：

• 提供商与报价类型（中间价或包含手续费）
• 时间戳规则（开具时间或捕获时间）及时区
• 汇率存储精度（例如 8 位小数）
• 四舍五入点（对换算后的行项四舍五入还是仅对最终总额四舍五入）

需要预先处理的特殊情况：零小数货币（如 JPY）、高精度汇率，以及退款。退款通常应重用原发票存储的 FX 汇率，否则退款金额可能与客户预期及会计导出不一致。

一个仍能工作的最小发票数据模型

如果你希望发票在 web、移动和会计导出间匹配，你的数据模型必须存储结果，而不仅仅是输入。目标很简单：同一张发票应在任何地方以相同的小单位呈现，即使数月之后也是如此。

一小组实体通常就够了：

• Subscription：customer_id、plan_id、billing_currency、billing_interval、next_renewal_at、status
• Invoice：invoice_id、customer_id、subscription_id、issued_at、period_start、period_end、status（draft/final）、currency、fx_rate_id（或 provider）、fx_rate_value、rounding_mode、totals（net_minor、tax_minor、gross_minor）
• Invoice_line：invoice_id、description、quantity、unit_price_minor、line_net_minor、line_tax_minor、line_gross_minor、tax_rate_id（或 tax_code）
• Payment：invoice_id、paid_at、amount_minor、currency、provider、provider_payment_id、status

关键规则：金额字段应为小单位的整数。既存单价也存计算后的行项总额，这能防止以后用不同的四舍五入规则或不同的 FX 来源重新计算并产生差异。

FX 需在发票上捕获，而不是推断。即便你有共享的 FX 表，发票也应保存最终化时使用的确切 fx_rate_value（以及其来源），这样导出可以重现相同数字。

当一张发票可能包含多种税率或属地（例如混合商品、欧盟 VAT + 当地税、或基于地址的税率在一张发票内变化）时，你才需要单独的税拆分表。然后为每个税率存一行，记录 taxable_base_minor 与 tax_amount_minor。

最后，把已最终化的发票视为不可变。快照计算值并在发票成为 final 时保存，切勿在订阅变更后重新计算旧发票的总额。这个选择能消除大多数“为什么分角变了？”的 bug。

选择一个四舍五入策略并坚持它

四舍五入不是数学细节，而是产品规则。如果你的网页采用一种方式，移动端另一种，会计导出第三种，即便输入相同也会得到不同的总额。

常见的三种策略，以及它们在哪一步“锁定”小单位不同：

• 按单元四舍五入：对每个单价在数量乘前（或折扣、税后）四舍五入。
• 按行四舍五入：计算整行后再四舍五入一次。
• 对发票总额四舍五入：对所有行保持高精度，最后只对发票总额四舍五入。

对于订阅，默认采用按行四舍五入通常较好。它对客户可预测（每行看起来正确）、便于审计（你能解释每行总额），并且在续费时稳定。对单元四舍五入在数量变化或在 UI 显示单价时会漂移。仅在发票总额四舍五入常常会导致“为什么这些行加起来不等于总额？”的工单，因为可见的行合计可能与显示的总额不一致。

经典的“分角问题”在于许多小项或分数税率时会显现。例如：20 行每行产生 0.004 的余数。按行四舍五入时，这些余数可能累计成 0.08，与仅在最终四舍五入相比存在差异。使用 FX 换算时，这类微小余数更常见，并可能随时间在导出与营收报表中累积。

无论你选哪种，一定要让它决定性且可复现：

• 使用相同的精度规则（货币小数位、税的小数位、FX 精度）。
• 在相同的步骤应用四舍五入（单元、行或总额），并保持顺序一致。
• 使用相同的舍入规则（例如 half-up 或 half-even），在所有地方一致。

如果你同时开发网页和移动账单流程，把四舍五入规则写成可测试的规范，而不是只在 UI 中体现。

逐步：以可重复的方式计算总额

要让 web、移动和会计导出显示相同数字，把计算当作一道菜谱来对待。关键思想是：用高精度计算，但只在发票货币中以整数（小单位）存储与求和。

可重复的计算步骤

1. 从每条行项的净额高精度值开始。在乘以数量、应用折扣、以及（如需）转换货币时保留额外小数。然后按选定的规则把它四舍五入成发票货币的小单位，并把该整数存为行净额。

2. 从已存的行净额计算税额（或在允许按税率分组的规则下从税组小计计算）。应用相同的四舍五入规则并以小单位整数存税额。系统在此处常常发生漂移：一端在税前四舍五入，另一端在税后四舍五入。

3. 每行毛额按（已存净额 + 已存税额）计算。发票总额为已存小单位的求和。不要为了展示而从浮点值重新计算总额。展示和导出应读取已存的整数并进行格式化。

4. 如果当地规则需要发票级别的税总额，你可能需要分配余数。例如：三行每行税额为 0.01 时总和是 0.03，但发票级别四舍五入要求 0.02。决定一个确定性的决胜规则（例如从应税金额最大的行开始加或减 1 个小单位，然后按行 id 稳定排序）。把调整存为受影响行的小税额修正，这样每个系统都能复现它。

5. 锁定发票。在完成所有四舍五入与余数分配后，把发票当作不可变。若订阅价格后来变更，生成新发票或抵扣单，但不要重写旧数字。

一个具体检查：如果 EUR 9.99 的套餐适用 19% VAT，你的已存可能是净额 999 分、税额 190 分、毛额 1189 分。每个客户端都应从这些已存整数渲染出 11.89 EUR，而不是在前端实时重新计算 VAT。

税额四舍五入：按行 vs 按发票与余数分配

税额四舍五入是正确数学变成不匹配发票的地方。本质问题很简单：更早的四舍五入会改变最终和。

如果你对每条行项（或每个数量）先四舍五入再求和，可能会得到与对发票汇总未四舍五入而最终再四舍五入不同的结果。行数越多，差距越大，尤其当小数位与 FX 换算已生成小数时。

具体例子（2 位小数）：两行应税金额各为 0.05，税率 10%。未四舍五入时每行税为 0.005。如果按行四舍五入，每行变为 0.01，总税为 0.02。如果在发票级别四舍五入，总应税 0.10，税为 0.01。两者都有道理，但结果不一致。

当既要展示每行税额，又需要发票总额完全匹配时，请以确定性方式分配四舍五入余数：

• 计算每行未四舍五入的税额，然后对每行向下舍入。
• 求和这些向下舍入后的税额，并与目标税额（发票级别四舍五入后的总税）比较。
• 把剩余的小单位按行的小数部分从大到小分配。
• 在并列时一致性地破局（例如按行位置，随后按稳定的行 id）。
• 切勿根据 UI 排序来决定分配顺序。

当会计在导出时需要按产品、税率或属地对行进行分组时，导出仍可能漂移。为避免这种情况，首先在每个必需的组内分配余数，然后验证各组总额能滚动汇总成相同的发票税与毛额。

如果会计需要按税率或属地拆分税额，但 UI 只显示一个税总额，也请同时存储拆分明细（按税率或属地的应税基与税额加上审计友好的分配规则）。UI 可以只显示一个总额，而导出带有详细分桶同时不改变发票总额。

应在一开始就决定的边缘情况

大多数发票不匹配发生在角落里。提前决定规则，这些就不会成为惊喜。

零小数货币需要特别小心。JPY 与 KRW 没有小单位，任何假定“分”的步骤都会悄悄造成差异。决定你是在每行四舍五入、税层面四舍五入还是仅在最终总额四舍五入，并确保每个客户端使用相同的货币设置。

跨境 VAT 或 GST 可能基于客户位置与你接受的证据（账单地址、IP、税号）改变税率。难点不在于税率本身，而在于你何时锁定税率。选择一个时间点（结账、发票开具日或服务期开始）并坚持它。

分摊是分数乘法的温床。月中升级会产生诸如按日计算 9.3333... 的数值。决定你是先对净额分摊、先对毛额分摊，还是先按服务期基数计算，然后再由此计算其他项。改变步骤顺序会改变最后一分。

把这些规则写下来，让它们不会随着时间漂移：

• 零小数货币处理：四舍五入方法与何时适用。
• 基于地点的税：用哪些字段决定税率以及何时冻结这些字段。
• 分摊数学：基准（日、秒或固定 30 天月）与四舍五入点。
• 折扣与抵扣：是否减少应税基，以及是按行应用还是在发票级别应用。
• 退款对称性：退款应重现原始行金额与税额，而不是用今日汇率重新计算。

退款是最后的陷阱。如果原始发票有一个 0.01 的余数分配给某行，你的退款也应精确反向该分配。否则客户会看到一个总额，而你的账本导出又是另一个数字。

导致发票不匹配的常见错误

大多数发票不匹配并非由“复杂数学”引起，而是来自系统不同部分做出的小、不一致选择。

一个大问题是以浮点数存钱。像 19.99 这样的值在许多系统中不能被精确表示，因此在求和行项、应用折扣或计算税时会出现微小误差。把金额存为小单位整数，并记录货币代码与小数位规模。

另一个常见问题是在导出时重新计算 FX。客户基于某一特定时间与率付款。如果你的会计导出拉取“今天”的汇率，即使每一步都是正确的，你也会得到不同的总额。把发票当作快照：存存 FX 汇率、换算后的金额以及四舍五入结果。

四舍五入差异也会在 UI 与后端在不同阶段四舍五入时出现。例如后端可能对每行税额四舍五入，而网页 UI 只在总额上四舍五入。两者都看起来合理，但不会匹配。

五个老问题解释了大多数差距：

• 使用浮点数表示价格、税、折扣或 FX 换算
• 在导出时重新计算 FX 而不使用发票中存储的值
• 在 UI 与后端不同地方用不同方式四舍五入税额
• 在同一张发票中混用含税价与不含税价逻辑
• 让移动端自己实现算法而不是呈现后端已存的总额

一个简单且有效的修复办法是：在后端计算一次、存好整张发票快照，然后让 web 与移动端精确呈现这些已存数字。

保持发票一致的快速检查表

当你的 web、移动与会计导出数字不一致时，通常不是数学问题，而是存储与四舍五入的问题。

遵循原则：客户端应显示发票存储的数值，而不是重新计算。后端应为唯一事实来源，所有通道都读取相同的已保存值。

防止大多数不匹配的五项检查

• 把每条行金额存为小单位整数，且发票总额等于已存行小单位的和。不要让 web 或移动端从单价重新计算总额。
• 保存你使用的确切 FX 汇率（以及使用时间）。如果你重新生成发票，重用已存的汇率，不要用更新后的汇率。
• 写下一条四舍五入规则（在哪一步四舍五入以及如何四舍五入），并在后端计算、移动端渲染、PDF 生成与会计导出中强制执行它。
• 使税务核对可证明：已保存的税额总和（按行或按发票，取决于你选的方式）每次都必须等于发票税额总和。
• 运行往返测试：导出发票数据，然后再导入，确认总额与税额完全匹配，包括小单位。

别忘了退款与抵扣

退款与抵扣应镜像原始发票的四舍五入结果。如果原始发票按行四舍五入，退款也应以同样方式进行，并使用相同的货币精度与存储 FX 汇率。否则小额余数会出现并随时间累积。

一种实用的执行方式是为每张发票存储清晰的计算快照：货币、小数位精度、四舍五入模式、FX 汇率与时间戳，以及最终化的行小单位。

示例：一张在 web、移动和导出都一致的发票

下面是一张在各处保持一致的示例发票。

假设发票以 EUR（2 位小数）开具，VAT 为 20%，客户以 USD 支付。后端存储了一个 FX 快照：1 EUR = 1.0857 USD。

Net total (EUR) = 26.99

VAT 20% (EUR) = 5.40（因为 26.99 x 0.20 = 5.398，四舍五入为 5.40）

Gross total (EUR) = 32.39

现在后端从已存的 EUR 总额与 FX 快照推导出收费货币的金额：

• Gross (USD) = 32.39 x 1.0857 = 35.17
• Net (USD) = 26.99 x 1.0857 = 29.30
• VAT (USD) = 5.40 x 1.0857 = 5.86

如果你也存储了按行转换后的 USD 金额，那么在对每行换算后四舍五入并求和时通常会出现 0.01 的差异。这正是发票常常漂移的地方。

使其决定性：对每行进行换算并四舍五入，然后如果按行求和与已固定的毛额 USD 总额不一致，按固定顺序（例如按 line_id 升序）分配多出或少出的分角，直到按行之和等于已确定的毛额 USD 总额。

Web 与移动端应显示后端已存的行总额、税总额、FX 汇率与毛额，而不是重新计算。会计导出应同时发出相同的已存数字以及 FX 快照（汇率、时间戳或来源），以便账本与客户看到的一致。

一个实用的下一步是把计算实现为一个共享服务，输出单一的发票快照（行项、税项、总额、FX、四舍五入调整），让每个通道都从中渲染。如果你在 Koder.ai (koder.ai) 上构建这些流程，把快照模型放在中心可以帮助 web、移动和导出保持一致，因为它们都能读取相同的已保存数值。