合并报表 POC 怎么做：测试清单与评估要点

图：合并报表 POC 的做法（贝则科技）

直接回答：合并报表 POC 要测六类场景：数据接入与映射、内部交易对账、抵销规则、合并层级与股权变动、多准则与多币种、报表输出与穿透查询。核心判断是 POC 不是产品演示，而是用集团自己的真实数据跑一遍最难的场景，看对方能不能在不改代码的前提下配出来。关键数字可参照：按贝则集团级项目口径，对账差异率能从 37% 收敛到 1.2%、编制周期从 28 天压缩到 7 天，POC 就该拿这两条作为可验证的假设去测，而不是只看界面。

很多集团的 POC 最后变成了一场加长版的产品演示。厂商来人，用自己准备的干净数据，把抵销、合并、出表演一遍，界面流畅、过程顺畅，评审组点头。三个月后项目进场上线，发现自家数据缺科目映射、内部交易对不上、层级设计和预想的不一样，于是开始返工。

问题不在厂商，在 POC 的设计。演示要证明的是「产品有什么」，POC 要验证的是「这套东西在我的数据上能不能跑通」。两者需要的数据、场景、评分方式完全不同。把 POC 当演示来组织，得到的结论自然只能支撑一个印象，支撑不了一个决策。

合并报表 POC 是指什么

合并报表 POC（概念验证）是指在正式采购或签约前，由集团提供真实或接近真实的数据与场景，候选服务方在限定时间内搭建可运行的原型，跑通从数据接入到合并报表输出的关键链路，并由集团按事先约定的清单逐项验证、记录结论的过程。它的产出不是一套系统，而是一份有证据的可行性判断。

这个定义里有三个要素容易被放松。一是数据要真实，哪怕只取三到五家代表性单位、一个月的量。二是场景要难，挑最复杂的内部交易类型、最深的股权层级、最麻烦的准则差异，而不是挑最容易演示的。三是记录要留痕，每一项测了什么、结果如何、谁确认的，都要写下来，否则 POC 结束后只剩一句「感觉还行」。

POC 与产品演示的差别

差别集中在四个地方：数据是谁的、场景是谁选的、环境是不是临时的、结论能不能复现。演示用厂商的样例数据、厂商选的标准场景、临时环境、结果不可复现；POC 用集团的数据、集团选的难点场景、独立环境、结果可以再跑一遍。

还有一处隐差别：时间。演示通常两小时，POC 通常需要两到四周。时间是筛子，能在两三周内把真实数据跑通的服务方，说明它对这类场景有积累；需要更久的，要么场景确实难，要么团队不熟。这个信号比任何承诺都真实。

六类必测场景清单

清单按合并的实际链路排列，前一环不通过，后面测了也没意义。每一项都要给出可判定的通过标准，不能只写「支持」。

场景	测什么	通过标准
数据接入与映射	异构 ERP 取数、科目映射、手工填报模板	三到五家单位的数据能按统一口径进系统，映射可自行维护
内部交易对账	撮合规则、容差、差异派发与闭环	用一个月全量内部交易跑出对平结果与可分类的差异清单
抵销规则	往来抵销、交易抵销、未实现内部损益还原	抵销分录可配置、可追溯、可复算
合并层级与股权变动	多层持股、增减资、处置、少数股东权益	股权变动当期能正确调整合并范围与权益结构
多准则与多币种	准则差异规则、折算汇率、双套报表	同一套基础数据输出两套准则报表并附差异说明
报表输出与穿透	法定与管理双套报表、勾稽校验、穿透查询	报表能追到明细与凭证，勾稽不符能定位到源头

六项不必全测，但按集团自身约束选出的前三项必须测完。跨国集团的前三项应是多准则、折算、报表输出；制造集团应是数据映射、内部交易对账、未实现损益；股权频繁变动的集团应把层级与股权变动提到前面。选哪三项，反映的是集团对自己痛点的认识是否清楚。

数据准备的三条要求

POC 的效果八成取决于数据准备。首条要求是取代表性单位：不要只取总部和一家最规范的子公司，要取一家规范的、一家数据最乱的、一家境外的、一家内部交易量最大的。四家的组合能把真实问题暴露出来。

第二条是取完整期间：一个完整月度的数据，包含期初余额、本期发生、期末余额，以及当月的内部交易明细。只给余额不给明细，对账环节就测不了；只给一个月不给期初，跨期差异就暴露不出来。

第三条是保留脏数据：不要为了 POC 好看而清洗掉科目不统一、单位名称不一致、金额有尾差的问题。这些正是系统需要处理的部分。把它们洗干净再测，等于把最难的一段屏蔽掉，测出来的结论对上线没有参考价值。

数据准备通常需要一到两周，由集团财务与 IT 共同完成，服务方可以提供模板与字段清单。如果服务方要求集团把数据整理成特定格式才能导入，这本身就是一个需要评估的信号：真实上线时，各单位的数据不会自动变成那个格式。

评分表怎么设计

评分表要在 POC 开始前定好，测完再定容易变成事后追认。结构上分门槛项和加权项两类：门槛项不满足即出局，加权项按权重累加。

类别	项目	判定方式
门槛项	真实数据能否在约定时间内跑通合并	是或否，不通过即终止评估
门槛项	抵销规则能否由集团自行配置	是或否
门槛项	报表能否穿透到明细与凭证	是或否
加权项	配置工作量与上线所需人天	按工时记录折算
加权项	差异处理的完整度与可追溯性	按场景清单打分
加权项	性能与并发填报表现	按测试记录打分
加权项	团队对场景的理解深度	按答辩与提问质量打分

加权项里最值得关注的是「团队对场景的理解深度」，但这一项最难打分。可行的做法是在 POC 结束时安排一次答辩：请服务方解释为什么这样设计抵销规则、遇到某种差异会怎么处理、如果集团新增一类内部交易需要改什么。回答得出的团队，后续实施大概率顺；只会念产品功能的，后续大概率要集团自己补位。

时间与人力怎么安排

一个完整的 POC 通常安排两到四周。头一周做数据准备与环境搭建，中间一到两周做场景配置与测试，最后几天做验证记录与答辩。压缩到一周的 POC 往往只能测接入与出表，测不到对账与抵销的深度。

人力上，集团侧要有一个能拍板的业务负责人、一个熟悉数据的 IT 人员、两到三家参与测试单位的填报人。服务方侧应派出实际会进项目的顾问，而不是只派售前。如果 POC 是售前做的、实施是另一批人，测出来的结论对项目期的参考价值会打折，这一点要在 POC 前问清楚人员安排。

还有一个细节：POC 环境由谁提供。用服务方的环境，集团看不到部署与配置过程；用集团自己的环境，能验证真实的网络、权限与数据安全要求。后者更接近上线状态，但需要 IT 提前准备资源。按 2026 年多数集团的信息安全要求，涉及财务数据的 POC 在集团内网环境进行会更顺畅。

贝则做 POC 的方式

贝则的 POC 通常从一次诊断开始：先看账、梳股权、出场景清单，再由集团确认测哪三项。这一步看起来是额外工作，但它决定了 POC 测的是真问题还是通用功能。参与 POC 的顾问就是后续进项目的人，CSO 解决方案中心 30+ 位顾问，100% 源自四大、埃森哲、IBM，平均从业 15 年以上，做过的场景类型比较齐。

工具侧保持中立。客户已有国际原厂 EPM 产品，就在原产品上做 POC；需要国产化承接，就用磐石合并报表系统配合 BDM 数据管理平台搭原型。这样 POC 的结论比的是方案与团队，而不是被工具绑定。按 2025 年报口径，贝则累计服务 100+ 家集团级客户，其中集团级合并客户 80+ 家，POC 里常见的抵销与对账场景大多有可复用的规则模板，能缩短配置时间。

POC 结束后贝则会出一份验证记录，逐项写明测了什么、结果如何、遗留问题与建议。这份记录在签约后可以直接作为实施方案的输入，避免同一个问题在项目期再讨论一遍。

落地要点

1. POC 开始前定好场景清单、通过标准与评分表，由集团财务负责人签字确认。
2. 数据取代表性单位、完整期间、保留脏数据，不做美化清洗。
3. 门槛项不超过三条，多了等于没有门槛。
4. 要求实际实施团队参与，而不是只由售前完成。
5. 结束时留一份书面验证记录，作为后续实施方案与验收标准的依据。

常见问题

Q：POC 需要多长的周期，两周够吗？

A：两周可以覆盖数据接入与出表，加上一项深度场景，适合结构相对简单的集团。法人多、内部交易大、多准则并行的场景建议三到四周，否则对账与抵销只能测到表面。周期长短不是关键，关键是测试项是否跑完并有记录。

Q：厂商不愿意用我们的真实数据做 POC 怎么办？

A：这本身就是一个需要记录的信号。常见顾虑是数据保密与工作量，前者可以签保密协议、在集团环境内测试解决，后者反映的是投入意愿。若对方坚持只用样例数据，可以退一步：用集团的真实数据结构脱敏后提供，保留字段与量级，改掉具体名称与金额。

Q：多家同时做 POC，集团配合不过来怎么办？

A：错峰安排，不要并行。同一套数据可以复用，但环境、账号、陪测人力要分开。通常的做法是先做一轮初筛，把候选收敛到两家，再各做一次完整 POC。并行做多家往往导致每家都测不深，结论反而更模糊。

Q：POC 通过是不是就代表上线不会出问题？

A：不代表，POC 验证的是关键场景的可行性，不是全量数据的稳定性与组织推行的顺利程度。POC 通过说明技术路径成立，剩下的是实施方法问题：数据治理、规则梳理、并行验证、用户培训。这也是为什么 POC 之后仍要把验收标准写成「月月能出表」，而不是「系统上线」。

Q：预算有限，只能做一次 POC，应该优先测什么？

A：优先测集团自己最没把握的那一项。多数集团的答案是对账或未实现内部损益，因为这两块人工负担重、规则复杂、各家做法差异大。数据接入与出表虽然也需要验证，但通用性强，出问题的概率低于抵销规则。把有限的时间放在最不确定的环节上，POC 的信息量更大。