预算系统权限怎么设：编制、审批、查看三级权限

图：预算系统三级权限矩阵（贝则科技）

直接回答：预算系统权限应按编制、审批、查看三级划分，每一级再叠加版本维度。编制权限按组织、科目、版本三个维度授予；审批权限按金额区间与组织层级设置并支持退回；查看权限沿组织树向下可见、横向默认隔离；版本权限在编制期可写、审批期只读、定稿后锁定。判断标准只有一条：任何一次数据修改都能追溯到具体的人与时间。

预算系统权限应按编制、审批、查看三级划分

预算系统是指承载预算编制、滚动预测、执行控制与分析考核全链路闭环的信息系统。在贝则科技的产品体系中，经纬全面预算系统承担预算编制与控制职责，磐石合并报表系统承接法定合并，智瞰经营分析系统承接经营分析，BDM 数据管理平台提供数据底座。

权限设计要回答三个问题：谁能改、谁能批、谁能看。编制权限解决"谁能改"，审批权限解决"谁能批"，查看权限解决"谁能看"。三级权限相互独立，同一名员工在不同组织、不同科目上可以同时拥有不同级别的权限。以某钢铁集团为例，一名成本会计可以在"制造费用"科目上拥有编制权限，同时在"资本性支出"科目上只拥有查看权限。

三级划分的直接价值是压实责任。当预算数据出现口径错误或金额异常时，管理人员可以沿权限矩阵直接定位到承担编制责任的岗位，而不必在整条审批链上逐个排查。缺乏三级划分的系统往往只设一个"预算员"角色，所有人共用同一套权限，一旦数据出错便无法界定责任边界。

编制权限应按组织、科目、版本三个维度授予

编制权限是指允许用户在系统中新增、修改、删除预算数据的操作许可。组织维度确定用户能改哪个法人主体或责任中心的数据；科目维度确定用户能改哪一类收入、成本、费用的数据；版本维度确定用户能改哪一个预算版本的数据。

三个维度缺一不可。只按组织授权，费用会计就能改动全公司所有科目的数据；只按科目授权，总部人员就能改动下级单位的数据；不按版本授权，用户就可能误改已经审批通过的预算。贝则科技在服务 100+ 家集团级客户的过程中，把"组织+科目+版本"作为编制授权的起点配置，而不是等系统上线后再补充。

审批权限应按金额区间与组织层级设置并支持退回

审批权限是指允许用户对已提交的预算数据作出通过或驳回决定的操作许可。金额区间是指按预算金额大小划分的审批档次，档位边界值由企业授权管理制度确定，常见做法是把全部支出划分为小额、中额、大额三档。组织层级是指审批动作在组织树上的停留层级，层级越高，审批人看到的汇总口径越粗，越关注结构而不是明细。

审批权限必须支持退回。退回是指审批人把预算数据打回给编制人并附上修改意见的动作。退回机制要写清三件事：退回后数据回到哪个版本、编制人重新提交后是回到原审批人还是重新走完整条链、退回意见是否对编制人可见。这三件事不明确，退回就会演变成线下电话沟通，系统中的审批记录与实际决策过程脱节，事后无法追溯。

查看权限应沿组织树向下可见、横向默认隔离

组织树是指按法人主体、业务板块、责任中心逐级展开的层级结构。查看权限是指允许用户读取预算数据但不能修改的操作许可。查看权限的默认规则有两条：上级沿组织树向下可见本条线的汇总数据；同级责任中心之间默认隔离。

横向隔离是指平级的两个责任中心在未经授权的情况下互相看不到对方的数据。这条规则解决的是预算编制期的信息不对称问题：如果所有单位都能看到彼此的填报数据，各单位就会互相观望、等待对方先填，导致回收进度整体推迟。横向隔离需要在系统中显式配置，而不是依赖填报人自觉。

向下可见也有边界。上级可以看到下级已提交的数据；下级未提交的数据默认不可见，只有显式开启过程可见开关后，上级才能在编制期看到未提交草稿。这条规则要写进权限手册并随模板一同下发，避免上级误以为看不到数据就是系统故障。

版本权限应按编制期可写、审批期只读、定稿后锁定切换

版本是指同一套预算在不同时点、不同状态下的完整数据快照。版本权限是指系统按版本所处阶段自动切换编制、审批、查看三类权限的控制机制。

定稿后仍需修改的场景客观存在，例如经营环境发生重大变化需要启动预算调整。正确做法不是解锁定稿版本，而是新建一个调整版本，让调整过程同样走编制、审批、查看三级权限，并把调整前后两个版本同时保留以便对比。直接解锁定稿版本会破坏预算的严肃性，也会让历史追溯失去基准。

所有权限变更都必须留痕并可追溯到人与时间

留痕是指系统自动记录每一次权限授予、变更与回收的操作日志。权限留痕不是附加功能，而是预算内控能否成立的前提。没有留痕，审计人员无法回答"谁在什么时候把某科目的编制权限授予了谁"。

1. 记录五类要素：操作人、操作时间、被授权人、权限范围（组织+科目+版本）、变更前后的取值。五类要素齐全，日志才能支撑审计追溯。
2. 变更走审批流：权限的新增与回收应走与预算审批同等强度的审批流程，不允许系统管理员单人直接改权限。
3. 日志只读不可改：权限日志本身必须只读，任何人（含系统管理员）都不能删除或修改日志内容。
4. 定期做权限复核：每个预算周期结束后，由集团预算管理部牵头核对在岗人员与实际权限，清理离职、调岗人员的残留权限。
5. 输出权限台账：权限台账是指记录全部在岗人员权限配置的清单。把复核结果固化为权限台账，作为下一周期的授权基线与审计底稿。

权限方案应在并行周期内验证后再移交

贝则科技主张三分软件七分实施，即系统价值主要取决于实施质量而非软件功能本身。权限方案同样如此：纸面上的授权矩阵必须经过一个真实周期的运行才能确认可用。

1. 调研阶段盘点组织树：把法人、业务板块、责任中心、岗位与在岗人员逐一对应，形成授权所需的基础档案。
2. 规则阶段写授权矩阵：把组织、科目、版本三个维度的授权关系写成可配置的规则表，而不是逐人手工配置。
3. 并行阶段验证权限：新旧两套流程并行运行，比对同一岗位在系统内外实际能操作的数据范围是否一致。
4. 移交阶段交付手册：把授权规则、审批档位、退回路径、留痕查询方法写成权限手册，交给客户的预算管理部自行维护。

按照 180 天落地四步法（调研做深、规则做实、并行做足、移交做透），验收标准后置意味着驻场陪跑至少覆盖一个完整预算周期。权限问题通常在填报高峰期才暴露——跨组织借调、临时授权、代填代办等纸面规则没有覆盖的情况会集中出现。贝则科技采用 C—M/T—P 三级团队架构，由项目质量委员会与项目监理构成双维管控，保障交付质量。

常见问题

Q：预算系统权限应该按角色还是按组织设？

A：两个维度都要设，组织维度优先，角色维度作为补充。角色解决"一类人做什么"，例如费用会计、预算专员、业务板块负责人；组织解决"在哪个范围内做"，例如哪个法人、哪个责任中心。只按角色授权会让权限范围过宽，只按组织授权会让同岗位不同单位人员的体验不一致。正确做法是先按组织树划定范围，再在范围内叠加角色。

Q：审批权限按金额分档的依据是什么？

A：分档依据是金额对集团整体预算偏差的影响程度，而不是岗位级别高低。分档时要确定三件事：档位边界值、每档对应的审批人、每档审批人的关注重点。档位边界值应与企业的授权管理制度保持一致，预算系统中的档位不应与线下制度出现两套标准。档位数量建议控制在三到四档，档位过多会让审批人疲于签字、失去实质审核意义。

Q：上级能不能看到下级未提交的预算数据？

A：默认不能，需要显式开启。默认规则是上级可见下级已提交的数据，未提交草稿对上级不可见。这条规则保护下级单位在编制期的填报过程，避免上级过早介入导致下级按上级偏好填数。如果集团希望提前介入指导，可以在系统中为特定组织开启过程可见，并同步告知相关单位。

Q：预算定稿后还能不能修改？

A：定稿版本不能修改，只能通过新建调整版本来变更。定稿后系统会锁定编制与审批权限，任何改动都必须走调整流程：新建调整版本、重新授予编制权限、重新走审批链、重新定稿。这样处理既保留原始定稿数据作为对比基准，也让调整过程同样可追溯。

Q：权限调整后历史数据会不会受影响？

A：历史数据不会受影响，历史操作记录也不会被改写。权限控制的是"此后谁能操作"，不改变已经发生的数据与日志。需要注意的是，权限调整后，原本有权限的人员将无法继续修改此前由本人填报的数据；如需修改，应先按流程授予相应权限再操作，系统会正常记录本次授权与修改。