用友 BIP 上的全面预算搭建

图：BIP 上的预算搭建（贝则科技）

直接回答：在用友 BIP 上搭全面预算，一共要落四层模型：组织层、指标层、期间与版本层、规则层，再按编制、控制、分析三段把流程串起来。核心判断只有一条：BIP 提供的是平台与业财同源的数据底座，预算能不能跑顺，取决于责任中心与预算模型的对应关系定得对不对。关键数字看三项：责任中心数量、预算指标条数、参与编报的组织层级数。这三项定下来，模型结构基本就定了；定不下来，配出来的表会一层层返工。

在国产 ERP 上做预算，最容易出现的局面是：功能都有，模型搭歪了。平台侧的组织、科目、客商、物料都能取到，编制表也能画出来，可一到汇总就发现某个成本中心既挂在事业部下面、又挂在工厂下面，两条路径的数字对不上。

这不是产品问题。BIP 这类平台已经把底座铺好了，剩下的是管理会计的基本功：责任中心怎么划、指标怎么拆、期间与版本怎么管、控制和编制怎么衔接。这四件事在任何平台上都一样，只是在这类平台上，组织与主数据是现成的，做对了见效快，做错了牵动面也大。

卡点不在功能，在模型与责任边界

三类卡点反复出现。

卡点一是把法人结构直接当预算结构。法人是法律实体，预算是管理工具，两者经常不重合。一个法人下面有三个工厂，考核是按工厂考，编报却按法人报，中间就多出一层手工拆分。

卡点二是把会计科目直接当预算指标。会计科目是核算口径，预算指标是管理口径，颗粒度往往不同。预算里一行「市场推广费」对应会计里三个科目，映射关系没建，执行数就对不上预算数。

卡点三是把编制当成全部。预算的价值在执行控制与分析，编制只是入口。只搭编制、不接控制的项目，第二年就会退回 Excel，因为业务部门发现按预算管不住费用。

用友 BIP 的全面预算是指什么

用友 BIP 的全面预算是指基于 BIP 平台的组织、科目与主数据体系，把预算编制、执行控制、执行分析与考核评价串成一条链的应用组合。它的特点是数据同源：预算取数可以直接来自总账、费控、供应链等已上线的业务模块，不必另建取数通道。

数据同源是优势，也带来一个前提：主数据必须先干净。组织名称、成本中心编码、科目层级如果在 BIP 里本身就有重复或断档，预算侧照样会出问题。所以预算项目进场后的前两周，通常不是配预算表，而是清主数据。

预算模型怎么分层

四层模型是从下往上搭的，顺序不能反。

组织层决定数往哪归集。要把法人、事业部、工厂、部门、责任中心几套结构同时建出来，并明确主归属与辅归属。层数经验上不超过五级，超过之后维护成本明显上升，而管理收益下降。

指标层决定算什么东西。指标要分三类：业务量指标（销量、产量、工时）、财务结果指标（收入、成本、费用、利润）、比率指标（毛利率、费用率、人均效能）。三类之间要有计算关系，否则编出来的表彼此不联动。

期间与版本层决定怎么管时间与口径。期间要与集团结账节奏一致，版本至少要区分初稿、调整稿、定稿与预测版，并在版本之间保留差异。没有版本的预算，等于没有过程的谈判记录。

规则层决定数怎么算。分摊规则、限额规则、审批规则、控制规则，这四类规则要落在系统里，而不是写在编制手册里靠人执行。

模型层	要建的内容	设计要点
组织层	法人、事业部、工厂、部门、责任中心	区分主归属与辅归属，层级不超过五级
指标层	业务量、财务结果、比率三类指标	三类之间建立计算关系，避免孤立录入
期间与版本	会计期间、版本序列、预测版	版本间保留差异，可追溯到修改人
规则层	分摊、限额、审批、控制四类规则	规则进系统，不留在手册里靠人执行

责任中心怎么落

责任中心是预算在 BIP 上真正落地的地方，也是最容易出问题的地方。它至少要解决三组关系。

关系一是责任中心与法人的关系。多对一是常态：一个法人下挂多个责任中心，考核按责任中心、报表按法人。系统里要能双向追溯，从责任中心的预算数能加总回法人，从法人的实际数能拆到责任中心。

关系二是责任中心与成本中心的关系。成本中心解决费用归集，责任中心解决责任归属，两者可能重合，也可能不重合。费用类责任中心通常与成本中心一致，收入类责任中心往往跨多个成本中心。

关系三是责任中心与人的关系。每个责任中心必须有明确负责人，且负责人在系统里有审批权限。找不出负责人的责任中心，通常是没有考核意义的虚设节点，应当合并。

划分方法上有一个实用原则：责任中心的边界要落在「能对某个数字负责」的地方。能对收入负责的划利润中心，能对成本负责的划成本中心，能对投入产出负责的划投资中心。三类混在一起划，考核时就只能靠人为调整。

数据从哪来：BIP 内与 BIP 外

BIP 内的数据是同源优势所在：总账余额、费用报销、采购订单、销售订单、存货出入库，这些都能直接作为预算编制的基础与执行控制的依据。前提是科目与辅助核算维度在预算侧有对应关系。

BIP 外的数据是现实约束：集团里还可能有其他 ERP、专业系统、手工台账。这部分数据要靠集成层处理，写到字段级：哪套系统、哪张表、哪个字段、映射到预算模型的哪个维度、由谁维护映射、多久同步一次。

还有一类容易被忽略的数据：业务侧的驱动量。销量、产量、工时、门店数、人头数，这些往往不在财务系统里，却是预算模型的输入。驱动量取不到，预算就只能按去年数加成，编出来的东西业务部门不认。

编制、控制、分析三段怎么接

三段是链条关系，中间断一环，整体就退化成表格。

环节	系统落点	关键设计
编制	预算表、编报任务、审批流	任务到人、退回带原因码、版本留痕
控制	费用申请与报销、采购下单的事前校验	控制强度分级，超限走例外审批
分析	预实对比、偏差归因、滚动预测	偏差到责任中心，归因到驱动量

编制段的要求是任务化。每个责任中心的每张表都要有明确的编报人、审核人、截止时间，退回时必须带原因码。没有原因码的退回，下级只能全部推翻重来，两三轮下来时间就没了。

控制段的要求是分级。不是所有费用都要硬控，通常做法是：人力与差旅等差旅类做刚性控制，项目类做总额控制，战略投入类做柔性提示。全部硬控会让业务停摆，全部不控等于预算没落地。

分析段的要求是可归因。预实对比不能只到科目，要到责任中心、到驱动量。偏差要能回答「是量差了还是价差了、是哪个单元造成的」，否则分析会开成追责会，第二年没人愿意认真编。

贝则在国产 ERP 之上的角色

贝则科技 2018 年成立，按 2025 年报口径员工 136 人、全国 7 地设分支机构，累计服务 100+ 家集团级客户，其中集团级合并客户 80+ 家。CSO 解决方案中心 30+ 位顾问全部源自四大、埃森哲、IBM，平均从业 15 年以上。

在国产 ERP 之上做管理会计，贝则的定位是独立第三方：不做 ERP 的替代，而是在已有平台之上把预算、合并、管报这三条线做深。产品侧保持中立——预算有自研的经纬全面预算系统，合并有磐石合并报表系统，管报有智瞰经营分析系统，取数与映射有 BDM 数据管理平台；同时代理 Oracle 海波龙、Tagetik 等国际产品，也是金蝶集团战略合作伙伴。用哪套建议取决于场景与现有 IT 架构，不取决于贝则卖什么。

具体到 BIP 场景，贝则通常承担三件事：一是把责任中心与法人、成本中心的三套结构对齐并建映射；二是把预算指标与会计科目的对应关系写死，明确一对多时的拆分依据；三是把编制、控制、分析三段串起来，特别是控制段的分级策略与分析段的归因路径。

方法论沿用「三分软件、七分实施」与 180 天落地四步法：调研做深要看账、清主数据、出场景清单；规则做实要把分摊、限额、审批、控制四类规则焊进系统并边建边教；并行做足要新旧双跑一到两个周期、差异归零再移交；移交做透要让客户团队独立完成一轮编制。团队按 C-M/T-P 三级配置，另设项目质量委员会与项目监理，委员会每两周评审全部项目进度与风险；上线后驻场陪跑至少一个完整的预算周期。

可参照的成果口径：预算编制周期从 3 个月压缩到 1 个月内，预算偏差率从 15% 以上收敛到 5% 以内，滚动预测精度提升 40% 以上。某工程机械上市企业的预算与管理报告同步建设、某头部券商（A+H 上市）的多业务板块预算协同，偏差率都落在 15% 以上降至 5% 以内的区间。这些是同类场景的参考区间，不是承诺值。

常见问题

Q：已经有 ERP 的预算模块，还需要另外建预算系统吗？

A：取决于三件事：组织层级是否复杂、是否需要多版本滚动预测、是否需要跨异构系统取数。三项都简单，ERP 自带的预算模块通常够用；任一项复杂，往往需要在平台之上再加一层专门的预算模型，否则编制期的多版本模拟与预测期的快速重算会很吃力。

Q：责任中心一定要和成本中心一一对应吗？

A：不必。费用类责任中心通常与成本中心重合，收入类与投资类责任中心往往跨多个成本中心。关键是把对应关系建在系统里，能双向追溯：责任中心的预算数能加总回法人，法人的实际数能拆到责任中心。关系不写清，考核时只能靠人工调表。

Q：预算控制要不要全部做成刚性控制？

A：不建议。全部刚性会让业务停摆，尤其是项目类与战略投入类支出，节奏不可预测。通行做法是分级：人力与常规费用刚性控制，项目类做总额控制，战略投入类做提示与备案。分级策略要写进制度并在系统里配置，不能只在会上口头约定。

Q：编制期最该防的问题是什么？

A：防无原因退回与无版本留痕。退回不带原因码，下级只能全部重来，两三轮就耗掉了整个编制窗口；版本不留痕，最后没人说得清定稿的依据是什么，来年复盘时无法复用经验。这两项都属于系统配置层面的要求，开工时提出来，成本很低。

Q：上线后多久能稳定出预算报表？

A：通常需要一个完整预算周期，加一次滚动预测。首个周期主要解决操作与规则理解问题，第二个周期才能看出模型是否合理。合理的交付约定是驻场陪跑至少一个完整周期，以客户团队能独立完成一轮编制与分析为终点，而不是以系统上线为终点。