Data Reconciliation
数据大屏与ERP、Excel数字不一致，怎么定位差异
数据大屏与 ERP、Excel 的数字对不上时，先让双方使用同一统计范围、权限和数据快照，再沿“源记录 → 数据加工 → 接口响应 → 页面显示”逐段复算，找到第一个出现差异的位置。只比较两个总数，通常无法判断是数据少了、重复计算了、筛选条件不同，还是某一层仍在显示旧结果。
阅读目录6 个章节
本文面向已经出现数字差异的业务、数据和开发人员，给出一套可以协作执行的排查建议。如果尚未确定指标应该怎样计算，可先整理经营驾驶舱指标口径表；这里重点讨论口径明确后，怎样追到造成差异的具体记录和处理步骤。
先让两个结果处在同一组条件下
“同一天查看”不代表用了同一批数据。先保留两个结果的截图、查询条件、查看角色、导出时间及数据最后成功更新信息，再选一组可复算的记录。这里的数据快照，是指用于本次比较的同一批、在比较期间不再变化的数据，或双方都能重现的同一截止点。
左右滚动表格，查看完整对照内容。
| 先核对什么 | 容易产生的差异 | 本次比较应固定什么 |
|---|---|---|
| 时间范围 | 一边按下单时间，一边按审核时间；自然日与业务日不同；时区或结束时刻不同。 | 时间字段、时区、起止边界及截止点。建议明确记录“开始时刻包含、结束时刻不包含”等实际规则。 |
| 业务范围 | 是否包含取消、退款、草稿、测试数据；组织和产品筛选不同。 | 同一指标版本、组织范围、业务状态与筛选条件，暂不在排查中途换口径。 |
| 访问权限 | 管理员看全公司，部门账号只看本部门；导出权限与页面权限不同。 | 在已授权条件下比较等价的数据范围，记录实际使用的角色及组织，避免直接用两个权限不同的账号比总数。 |
| 更新批次 | Excel 已改动但未保存；源系统已有新记录，而同步任务或模型仍是上一批。 | 源文件版本、数据截止时间、同步或刷新任务结果。区分“任务结束时间”和“业务数据更新到哪里”。 |
| 统计粒度与单位 | 订单数被当成商品明细行数；元与万元混用；先逐行四舍五入再合计。 | 一条记录代表什么，采用计数、去重计数还是求和，以及换算和舍入发生在哪一步。 |
如果条件确实不同，应先把差异解释清楚，再决定是否需要统一口径。不能仅因为其中一个结果来自 ERP 或 Excel，就默认它一定是正确基准。
教学样例：3 行有效明细，为什么只有 2 个订单？
以下四行是专为本文编写的虚构教学数据，不是客户数据或泓珊科技项目成果。四行属于同一个演示组织和同一统计日，订单号在该组织内唯一。本例按下单时间划定统计日，读取同一快照中的订单状态；只统计“已确认”订单，排除“已取消”。行金额不涉及税费、退款或币种换算。
左右滚动表格，查看完整对照内容。
| 订单号 | 明细行号 | 订单状态 | 行金额（元） |
|---|---|---|---|
| DEMO-001 | 01 | 已确认 | 120 |
| DEMO-001 | 02 | 已确认 | 80 |
| DEMO-002 | 01 | 已确认 | 150 |
| DEMO-003 | 01 | 已取消 | 50 |
按本例约定，筛选后有 3 行有效明细、2 个不同的有效订单，行金额合计为 120 + 80 + 150 = 350 元。如果 ERP 的“订单总数”是 2，而大屏显示 3，应先查大屏取数是否在明细表上直接计数。3 本身可以是正确的“订单明细行数”，但不是本例定义的“订单总数”。
再看金额：DEMO-001 的订单头总额为 200 元，DEMO-002 为 150 元。如果把订单头关联到明细后，再对重复出现的订单头总额求和，就会得到 200 + 200 + 150 = 550 元。差异出在关联后的统计粒度；本例应选择按行金额求和，或先保留每个订单的一条订单头记录再求和。
不要把“加一个去重”作为通用修复。订单号是否跨组织重复、同一订单是否允许分期记录、状态变化怎样处理，都需要按真实数据结构确认。先确定唯一标识和统计对象，再调整计算。
沿数据经过的环节，找第一次不一致的位置
针对一小组差异订单，记录每个环节的输入版本、筛选条件、记录数、订单标识和金额。相邻两层如果结果不同，要先判断这种变化是否符合已确认规则；例如订单展开为明细后行数增加可以是正常现象，增加后仍被当成订单数才是问题。
左右滚动表格，查看完整对照内容。
| 环节 | 具体检查 | 怎样缩小问题范围 |
|---|---|---|
| 1. 源记录 | 在同一快照中核对订单号、明细行号、时间和状态；把一边有、另一边没有的记录单独列出。 | 源记录集合已经不同，先查来源、导出范围或截止点；不要直接修改页面公式来追平总数。 |
| 2. 加工步骤 | 逐步检查读取、类型转换、筛选、关联、去重与聚合后的记录。保留订单粒度和明细粒度的区别。 | 找到第一次出现漏记录、重复记录或不符合约定的金额变化的步骤，检查该步骤的键、规则与异常处理。 |
| 3. 接口响应 | 按页面实际使用的组织、角色、时间和筛选参数核对响应；确认字段含义、分页和汇总方式。 | 加工结果正确、响应不符时，查接口过滤、参数、序列化和缓存版本。不能默认响应中的 total 就是业务订单总数。 |
| 4. 页面显示 | 比较原始响应与卡片、图表、明细和导出的取值，核对字段绑定、二次汇总、单位、舍入与隐藏筛选。 | 接口结果正确而显示错误，优先查页面配置与计算；如果只有某个角色或某个筛选下异常，就固定该组合继续复现。 |
| 5. 更新链路 | 核对源更新、同步任务、模型或聚合结果、接口缓存及页面显示各自的版本和成功状态。 | 各层在同一旧快照下能算对，但线上结果仍不一致时，确认哪一层没有取得目标批次，而不是只重复刷新浏览器。 |
对前面的教学样例，如果加工后的订单汇总为 2，接口也返回 2，而卡片显示 3，就把检查重点放到页面字段绑定或二次计算；如果加工阶段已经把订单头金额汇总为 550 元，页面即使忠实显示接口，也仍需回到关联与聚合步骤修复。
遇到这几种现象，还应看哪里？
每个部门都显示相同的数
先确认部门筛选是否真正作用到数据，关联字段和数据类型是否匹配，关系是否按预期传播筛选。以 Power BI 为例，微软的关系排查文档建议查看表或矩阵中的查询结果，并核对关系、基数、激活状态和筛选方向；它还列出“每个分组出现相同值”可能与关系缺失或筛选未传播有关。不要把全公司的总值相同误判为每个部门都有相同业绩。参考：Power BI 关系排查。
Excel 看起来正常，导入或刷新后却不一样
保留出错步骤和错误信息，检查最近是否改了表名、列名、表头或数据类型，再核对哪些行被转换成空值、错误或被筛除。Microsoft 的 Power Query 文档说明，源表或列名变更会影响查询步骤，类型变更也可能造成错误或意外结果。不要直接把转换失败的值全部补成 0 后就认定数据正确。参考：Power Query 数据源错误处理。
点击刷新后，数字仍然是旧的
确认刷新的是哪一层。以 Power BI 的导入模式为例，刷新视觉对象读取的是已经导入语义模型的数据；要获得源数据的新变化，需要模型完成相应的数据刷新。模型更新完成后，已打开报表中的视觉对象也可能需要再次刷新。检查刷新历史与本次数据截止点，比单看“刚刚刷新”更能说明数据是否到位。参考：Power BI 数据刷新类型。
以上产品行为只用于说明排查位置。自建数据大屏采用接口、数据库或文件同步时，应查看实际项目的更新链路，不套用某个 BI 产品的按钮、许可配额或刷新机制。
修复后，怎样证明差异已经解决？
修复验收要留下“为什么错、改了哪里、按同一输入重算后是什么结果”。先回放原先出错的快照，再补一组未参与修复的新记录；总数相同还不够，应同时核对记录集合和明细，避免漏一条与多一条刚好抵消。
- 原问题可复现，也能解释。保留修复前的错误结果、差异记录、原因与修改位置。本例可以明确记录“把明细行数用作订单数”或“关联后重复汇总订单头金额”。
- 相同输入可复算。在相同口径、快照、权限和筛选下，保存源明细、计算过程、接口结果与页面结果；教学样例应得到 2 个有效订单、3 行有效明细和 350 元。
- 边界条件仍符合约定。补查取消记录、重复标识、空值、跨时间边界和金额精度；计数按约定精确匹配，舍入或采样差异应事先规定，不能用临时放宽的误差掩盖问题。
- 下游引用没有遗漏。核对同一指标的总览卡片、趋势图、明细、导出和其他引用页；不同角色按各自应有的数据范围检查，不要求无权限的角色看到全量数据。
- 后续刷新能维持结果。在下一次实际更新完成后，复查数据截止点、错误状态和同一批核对项，确认修复没有只改变某一张静态截图。
完成定位后，可把原因、版本、受影响页面、责任人和复算证据写回指标治理与数据血缘验收矩阵。如果需要改变指标定义，而不是修正错误实现，应先通过指标口径评审确认新旧规则与生效范围。
需要一起排查时，先准备哪些资料？
先准备两个不一致结果及其查询条件、一组脱敏的差异记录、当前指标规则，以及数据更新时间或失败信息。资料不必覆盖整个系统，能重现一个具体差异就有助于判断下一步需要业务负责人、数据人员还是页面开发人员参与。
可结合BI 大屏与数据接入服务说明现有系统、使用者和受影响页面，再通过项目联系页沟通排查范围。需要参考展示结构时，可查看企业经营驾驶舱方案案例；本文教学样例不来自该方案。