同一批业务记录，数据库合计 1.01，报表明细相加却是 1.02。两边都显示两位小数，也都没有重复记录，差异仍可能出现。把容差改大、再让模型解释为“正常误差”，会掩盖真正的计算规则分歧。金额验收需要证明每一步如何保留精度、何时舍入，以及余差归到哪里。
先冻结计算契约，而不只是字段类型
为每个金额指标记录币种、计量单位、业务状态、事实粒度、输入精度、计算精度、舍入位置、舍入方式与输出精度。单价、汇率、比例和已经结算的金额可能需要不同精度；不能因为最终展示到分，就把所有中间字段都缩成两位。本文讨论工程计算约定，不替代具体财务或税务制度。
智能问数的语义层应引用这份契约，而不是让模型每次决定先 round 还是先 sum。若用户问的是已经入账的金额，应以相应已确认事实为依据，不能偷偷按当前单价和规则重算历史。若问的是模拟分摊或测算值，则应明确标注计算版本和假设，不能和真实收付记录混用。
金额偏差还有多表关联的原因。可先检查多表关联的基数与金额守恒，确认每个事实只贡献一次，再排查精度。本篇聚焦在事实集合已经正确的条件下，数值表示、计算顺序和传输如何改变结果。把两个层次分开，才能避免用舍入规则修补重复累计。
十进制类型解决表示问题，但精度仍需设计
PostgreSQL 17 文档将 numeric 与 decimal 视为等价类型，并建议在需要精确存储和计算的金额场景使用 numeric，而不是近似的浮点类型。[1] 但声明 numeric(p,s) 仍有边界：p 是总有效位数，s 是小数位数；超过声明小数位的输入会被舍入，整数部分超出允许范围会报错。
因此，原始单价若需要四位小数，却在第一张落地表就存入两位小数列，后续改成高精度字段也无法恢复已丢失的信息。应沿来源、暂存、加工、指标、API 和展示逐层检查类型，特别注意隐式转换。用十进制处理后的数值再转成二进制浮点，在下一步又可能引入近似表示。
整数最小单位也是一种选择，例如确定以分结算的金额可用整数保存，但必须同时知道币种和单位，并检查累计范围。它并不自动适合需要更细精度的单价、比例或汇率。换算到最小单位也有舍入规则；不能用“全部乘一百”代替业务契约，更不能直接相加不同币种金额。
逐行舍入与汇总舍入不是同一个指标
以下为构造算例，采用“就近舍入，正好居中时远离零”，不是任何行业的默认制度。三行未舍入金额均为 0.335。逐行保留两位得到 0.34、0.34、0.34，合计 1.02；先相加得到 1.005，再保留两位得到 1.01。两种算法差 0.01，原因是舍入不满足这种交换关系。
若契约要求累计已经逐行结算的金额，应汇总那些结算结果；若要求对原始金额先累计再结算，就保留原始精度到规定节点。不能为了让报表总计等于屏幕上已经格式化的明细，就擅自改变总计口径。界面可以同时说明“按原始值汇总后舍入”，或者展示明确的舍入调整项。
舍入方式也要对齐。Python Decimal 默认上下文采用 ROUND_HALF_EVEN，而 PostgreSQL numeric 在居中时远离零。[1][2] 对精确十进制 1.005 保留两位，前者为 1.00，后者对应的方式为 1.01；对 -1.005 则分别为 -1.00 与 -1.01。负数退款必须进入测试，不能仅凭正数样本判断一致。
在 Python 中可用 Decimal('1.005') 从十进制文本构造，再用 quantize 显式指定目标精度与舍入方式。[2] 不应先转 float 再期待 Decimal 恢复最初输入意图。小数运算也受上下文有效位数约束，特别是除法与大数乘法；“用了 Decimal”不等于中间计算永不舍入。
分摊余差要有确定归属和可复现顺序
构造另一例：把 1.00 元平均分给三个对象，各自保留到分。简单得到三个 0.33，总和只有 0.99。一个可选规则是先按最小单位计算各份基础额，再把剩余单位按约定顺序分配；在本例中得到 0.34、0.33、0.33。多出来的一分不是凭空产生，而是原总额中尚未分配的部分。
对于非负总额与非负权重，可设计最大余数法：先按权重计算理想份额，向下取到最小单位，统计剩余单位，再按小数余数从大到小补足。相同余数用稳定业务键打破平局，并保存规则版本。不能依赖数据库未声明的返回顺序，否则重复运行时同一分钱可能落到不同对象。
该方案有明确前提。负金额、混合正负权重、零分母、上限和不允许分摊的对象，需要另外定义，不能直接套用上述正数规则。退款可以按原分摊结果追溯冲回，也可以采用其他已批准方案，但必须避免用已经变化的新权重重算旧交易，导致原账与冲回无法对应。
验收既检查分摊总额等于输入总额，也检查对象资格、单项约束与稳定性。对同一组业务键改变输入排列，结果应保持一致；相同输入与规则版本重复执行，应得到相同对象金额。分摊只是分析归属，不应被描述成每个对象真实发生的独立付款。
空值、传输与展示是另外三道边界
PostgreSQL 的 sum 汇总非空输入，没有输入行时返回 null 而非零。[3] 因此，缺失金额、没有符合条件的记录和真实零金额应分别建模。可同时返回事实数、非空金额数和总额；只有业务定义明确允许时，才把空结果转成零。否则系统可能把数据尚未到达解释为没有收入。
跨服务传输需要明确精度契约。可以传带币种与单位的整数最小金额，或经过规范的十进制字符串，由接收方按十进制解析。不能仅因为 JSON 字面量看起来正常，就假定所有客户端都保持同样精度。对大型金额和较长小数，加入往返测试：数据库输出、API 编解码、客户端读取后，再按约定恢复并比较。
展示层的千分位、两位小数和万元换算，应与实际计算分开。不要把格式化字符串再作为下一层汇总的来源。向模型提供的结果应包含单位、精度、口径版本与缺失说明，模型负责解释结果，不负责重新心算一套总额。若需要追加计算，应调用同一受控计算路径。
用分层对账定位差异，不用统一容差掩盖
建立小而明确的回归集合：正常小数、居中值、负数退款、极小金额、大额边界、空集、部分空值、三等分以及零权重。每例保留原始输入、精确中间值、舍入节点、预期输出和规则版本。本文的舍入算例已用 Python 十进制运算核对，但没有运行数据库性能测试，也没有据此声明生产系统通过。
把控制总额按同一事实范围独立计算，再依次比较原始事实、加工结果、分摊结果、API 返回与最终显示。发现差异先找第一个发生变化的阶段：输入解析改变值，属于接入问题；分摊合计不守恒，属于算法问题；只有显示变化，则检查格式化和单位。这样能避免直接在最终查询上不断加 round。
容差必须服务于已批准规则。已结算整数分且同范围的对账，可要求精确相等；含换算和多节点舍入的指标，应明确每类调整与可接受边界，不设置一个适用于所有金额的百分比。若规则未定义，应输出“未认证口径”或暂停该指标的正式回答，而不是把差额自动归零。
交付物应包含可读的金额计算契约、跨语言一致性用例、差额明细与异常处置路径。下一次调整舍入方式或分摊规则时，把它作为指标版本变更处理，并评估是否需要重算历史。金额可信来自一条可重复的计算链，不来自答案最后显示了两个小数位。