系统数字舍入处理方案及跨系统会计金额精准匹配问题问询

核心前提 #

会计场景下的小数运算首先要规避二进制浮点类型的先天误差，所有相关逻辑禁止使用float、double类型做价格计算。 #

具体落地方案 #

1. 统一存储与交互标准 #

• 内部运算全部使用BigDecimal类型实现四则运算，初始化时必须使用字符串构造参数，例如new BigDecimal("19.99")，禁止传入浮点类型参数带入原生精度损失。
• 跨系统交互优先传输「分为单位的长整型（long）」价格，例如19.99元传输为1999，从根源上避免小数解析、传输过程中的精度偏差，展示层再做单位转换即可。

2. 统一舍入规则与运算时序 #

• 舍入规则二选一，双方必须100%对齐：
  • 通用国际会计/银行场景：使用银行家舍入法（四舍六入五成双），对应Java枚举RoundingMode.HALF_EVEN，是IEEE 754标准推荐的默认舍入模式，可降低多次舍入的累积误差。
  • 国内普通会计场景：使用四舍五入，对应Java枚举RoundingMode.HALF_UP，符合国内大众对金额计算的普遍认知。
• 统一舍入时机：约定中间运算步骤统一保留4位小数精度，所有运算（你场景中的15次处理+外部系统的多轮运算）全部执行完成后，再一次性舍入到2位小数（分），避免中间多轮舍入产生累积偏差。

3. 差异规避校验机制 #

• 跨系统传输数据时，同时附带金额的字符串格式值和整型分单位值作为校验位，接收方优先取分单位值做后续计算。
• 优惠分摊、税费计算、折扣计算这类容易产生逻辑差异的模块，要么统一由单方计算后同步结果，要么双方完全对齐运算公式、参数取值逻辑，避免各自实现产生的逻辑差。

不存在普适所有场景的统一舍入规则，只要双方提前约定好完全一致的存储、运算、舍入、交互规则，即可保证最终结果100%匹配。

内容的提问来源于stack exchange，提问作者Diego Alves