3. 多级资金体系架构
多级资金归集与下拨体系的核心难点，不在于“能不能把钱收上来”，而在于层级关系是否清晰、账户树是否可映射、权限是否可收敛。当集团、区域、子公司、项目部四层同时存在时，资金关系会从简单的“上下级归集”演变为“多对多、跨层、带条件”的复杂网络。本章聚焦架构设计，给出可落地的层级模型、账户树结构、资金关系映射方法与权限模型。
一、核心原理：四层资金体系的三条主线
四层架构（集团—区域—子公司—项目部）本质上要同时解决三条主线：
- 组织主线：谁是谁的上级，决定管理边界与审批链路。
- 账户主线：每个组织节点对应哪些银行账户，决定资金实际存放位置。
- 资金主线：归集与下拨的路径、额度、频率，决定资金流动规则。
三条主线必须解耦设计。组织调整不应直接改写账户归属，账户变更也不应自动改变审批权限。实践中常见的错误是把三者揉进一张“组织表”，导致后期任何一次架构调整都牵一发而动全身。
二、账户树结构：从实体账户到虚拟账户
账户树不是简单的父子账户列表，而是包含实体账户、虚拟账户、归集专户、下拨专户四类节点的混合结构。典型设计如下：
集团资金池（实体主账户）
├── 区域归集专户（实体）
│ ├── 子公司A基本户（实体）
│ │ ├── 项目部A1虚拟户（虚拟）
│ │ └── 项目部A2虚拟户（虚拟）
│ └── 子公司B基本户（实体）
│ └── 项目部B1虚拟户（虚拟）
└── 区域下拨专户（实体）
└── 子公司C基本户（实体）
关键点在于：虚拟账户不产生实际资金划转，只用于内部核算与额度控制。项目部通常不单独开立银行账户，而是通过子公司基本户下的虚拟户进行资金归集与下拨，既满足核算精度，又避免账户数量失控。
| 账户类型 | 所属层级 | 是否实体 | 主要用途 | 归集方向 |
|---|---|---|---|---|
| 集团主账户 | 集团 | 是 | 总资金池、对外融资 | 接收下级归集 |
| 区域归集专户 | 区域 | 是 | 区域内资金集中 | 向上归集、向下接收 |
| 子公司基本户 | 子公司 | 是 | 日常收付、工资税费 | 向上归集 |
| 项目部虚拟户 | 项目部 | 否 | 项目核算、额度控制 | 内部记账 |
三、资金关系映射：归集与下拨的双向路径
资金关系映射要回答两个问题：钱从哪来、到哪去，以及在什么条件下触发。建议用“归集路径 + 下拨路径 + 触发条件”三元组描述每条资金关系。
映射表建议至少包含以下字段：
relation_id | from_account | to_account | direction | trigger | limit | frequency
R001 | 子公司A基本户 | 区域归集专户 | 归集 | 日终余额>50万 | 无上限 | 每日
R002 | 区域归集专户 | 集团主账户 | 归集 | 每周五 | 5000万 | 每周
R003 | 集团主账户 | 区域下拨专户 | 下拨 | 审批通过 | 按预算 | 按需
R004 | 区域下拨专户 | 子公司C基本户 | 下拨 | 审批通过 | 按预算 | 按需
四、权限模型：从组织权限到资金权限
权限模型不能只做“谁能看哪个账户”，而要区分查看权、操作权、审批权、配置权四类。推荐采用 RBAC + 数据范围的方式：
- 角色：集团资金管理员、区域资金专员、子公司财务、项目部报账员。
- 数据范围：本节点、本节点及下级、指定节点集合。
- 操作权限：查询、归集发起、下拨申请、审批、参数配置。
五、常见误区与复盘
误区一：账户树等于组织树。组织调整后账户未同步，导致归集路径断裂。应通过映射表解耦，组织变更只影响映射关系，不重建账户树。
误区二：虚拟户当实体户用。虚拟户不能对外收付，若误用于实际划转，会造成账实不符。必须在系统层面限制虚拟户的对外交易能力。
误区三：权限一刀切。所有区域共用一套权限模板，导致敏感账户被越权查看。应按区域、金额、账户类型做细粒度数据范围控制。
四层资金体系架构的设计质量，直接决定后续归集规则、下拨策略和风控模型能否顺利落地。把层级设计、账户树、资金映射和权限模型四件事分开建模、再通过映射关联，是避免后期反复重构的关键。