几十家子公司、多套 ERP、与多家银行合作，总部看得到余额，资金会上却仍说不清下个月缺多少钱。集团司库要先把管理边界、决策权限、数据贯通和交易核实定下来，再谈系统怎么建。

假设一个集团有几十家子公司，分布在境内外，使用多套ERP，与多家银行合作。

总部每天能看到银行余额，也已经实现统一付款。

但资金会上，聊到以下问题时，仍然说不清：下个月到底缺多少钱，哪家子公司的钱可以调，几笔贷款集中到期会不会有压力，海外订单产生的汇率风险有没有人管。

这些问题，需要放到同一套集团司库架构里解决。

从集团架构设计看，司库建设要同时确定四件事：管哪些资金业务、谁有权做决定、数据怎样贯通、交易怎样执行并得到核实。

一、先定集团怎么管，再定系统怎么建

立项时，先划清集团的资金管理边界。

哪些主体只能查看资金，哪些可以归集和调拨？境外公司、上市公司、合资公司有什么限制？融资由总部统一谈，还是允许板块自行办理？子公司能否自行开户、投资和对外担保？

这些答案决定司库的管理模式，也决定系统权限。

一家子公司的余额纳入集团报表，并不自动意味着总部有权把钱调走。集团合并口径、账户所有权和资金调度权限，需要分别记录。

组织上，通常可以形成这样的分工：

财务公司有相应准入及业务规则，设立司库职能本身不要求集团一定设财务公司。规模较小的集团，也可以由现有财务团队承担相关职责。

集团统一的是规则、数据和监督要求；具体交易可以按地区、主体和金额分级执行。

二、业务全景，要覆盖资金的一生

账户、支付和归集是司库的基础。完整规划还要覆盖后续的平衡、配置和风险管理。

日常运营：钱在哪里，发生了什么

管理账户开户、变更、注销及使用权限，处理收付款、资金归集、内部调拨和银行对账。

每个账户都要关联法律主体、银行、币种、用途及受限状态。付款则需要从申请追踪到银行结果，失败、退回、撤销等情况有明确处理人。

流动性管理：今天能用多少，未来是否够用

资金头寸回答某个主体、某个时点实际能够使用多少资金。

资金计划反映集团批准的收支安排；现金流预测根据最新业务进展更新预计收付时间；流动性管理据此确定安全储备、缺口方案和余资安排。

销售回款、采购付款、工资税费、项目开支、债务本息，都要进入相应期间。集团可以按需要建立近期按日、中期按周、远期按月的预测，不必让所有期间采用同样精度。

金融资源管理：钱怎么筹、怎么配、成本怎么算

这部分覆盖授信、贷款、债券、票据、保函、信用证、担保、投资和内部资金融通。

一笔融资要管完整生命周期：申请、额度占用、合同、提款、计息、付息、还本及到期后的结清。需要同时观察综合成本、抵质押条件和债务期限，防止几笔交易分别合理、放在一起却出现集中到期压力。

内部调拨还要记录资金提供方和使用方、用途、期限、价格与偿还安排。内部利息影响各主体的经营评价，即使合并时会抵销，也要把计息和内部对账做完整。

金融风险管理：可能损失多少，准备怎样应对

至少识别流动性、汇率、利率、交易对手及操作合规风险。有大宗商品相关业务的集团，再按实际职责纳入相应市场风险。

风险应追到具体业务和交易。美元采购与美元销售能匹配多少，要结合主体、金额、日期和调拨条件判断；浮动利率借款，则要看重定价时点和利息敏感性。

对冲交易需要关联被管理的风险敞口，持续检查限额、估值、结算和效果，避免业务已经变化，原来的对冲安排却继续存在。

资本安排：支持集团长期发展

司库还要为扩产、并购、增资、分红和债务与权益组合提供资金方案，评估对杠杆、偿债及流动性的影响。

重大投资是否开展，仍按集团治理权限决策。司库负责说明资金怎样到位、成本和约束是什么、后续现金流能否承受。

三、系统架构，先把现有系统摆对位置

集团通常已经有ERP、共享、预算、合同、项目和银企直联系统。司库建设要明确每个系统保留什么职责，以及它们怎样交换数据和结果。

下面是一套可用于规划讨论的参考架构。

业务系统提供收付款依据，司库统筹资金安排与金融风险，银行完成资金执行，财务系统完成核算。

具体可以这样划分：

审批也要分清性质。

业务审批确认这笔交易应不应该发生，资金授权确认由哪个账户、通过什么渠道、在什么时间支付。是否需要再次审批，按风险和授权规则确定。

如果集团ERP较统一，可以优先评估ERP内的司库能力；如果存在大量异构系统、跨国银行和专业金融交易，可以评估独立司库平台或组合架构。这是架构选择的方向，最终还要用真实业务验证集成成本与能力覆盖。

技术上，银行连接要独立适配不同报文和协议；业务接口统一处理编号、重复请求、回执和补偿。查询与付款权限分开，银行密钥等凭证专门管理，敏感账户操作保留审计记录。

跨国集团还要明确时区、银行截止时间、假日和资金到账日。支付通道中断时，谁负责切换、怎样防止恢复后的重复执行，也要纳入应急演练。

四、最关键的数据，是把计划、预测和实际接起来

司库数据设计，最容易出问题的地方是重复计算。

同一笔设备款，先出现在项目计划里，随后成为合同付款节点，再形成应付单和付款申请，最后变成银行流水。如果每接一个系统就增加一笔现金流，集团会把同一笔支出算好几次。

因此，需要建立同一笔业务在不同阶段的关联关系。

计划、预测和实际各自保留，但每个预测口径下，应明确采用哪个阶段的数据。业务形成更确定的付款申请后，要冲减或替代相应的早期预测；实际付款后，转入实际收支，保留原预测用于偏差分析。

每条资金事项至少应能回答：属于哪个主体、什么业务、哪种币种、预计或实际在哪天发生、金额多少、来自哪个系统、现在处于什么状态。

金融交易还要有相应的合同、现金流计划和生命周期记录。

利率、计息规则或还款安排发生变更时，能重新生成后续现金流，并保留变更前的版本，避免台账、付款计划与核算各算一套。

还要保留数据更新时间、预测版本和调整依据。

昨天导入的余额，不能在今天的页面上被误认为刚刚查询的结果；按汇率折算的集团总额，也不能替代各币种的实际支付能力。

集团要统一资金数据模型，原始业务仍可以保留在各自系统中。

五、用一笔设备款，检验架构是否连得起来

仍以这家制造集团为例。假设某子公司三周后要支付1000万美元设备款，本地可用美元200万美元，在保留必要经营储备后，仍有800万美元缺口。

这笔业务应当这样走：

1. 业务需求进入

项目系统提供合同、付款节点和预计日期；子公司确认付款条件及现有资金，形成美元需求。

2. 集团形成方案

司库检查其他主体的美元余资、调拨资格和可达时间，再比较内部融资、银行融资或购汇安排。人民币总余额充裕，也要继续确认美元能否按期到位。

3. 方案审批并执行

获批后生成内部借款、外部融资或外汇交易，关联原始资金需求。内部借款记录期限和价格，购汇或对冲安排记录对应敞口。

4. 付款结果返回

到期支付后，银行状态、流水和回单回到司库，再向原付款平台反馈，并向财务系统传递核算信息。

5. 结果核实并更新

对账确认资金实际扣划，更新余额、内部债权债务、授信和剩余风险敞口。若设备延期，原预测、资金安排与相关交易也要重新检查。

接口超时时尤其要谨慎。

结果不明时应先查询和核实，避免直接重发造成重复付款；失败重试、退汇和人工介入都要有记录。

这一笔业务能够走通，才说明项目、司库、银行和核算之间的关系基本成立。

基础薄弱的集团，先把主体、账户、银行连接、支付和对账做可靠；再建立滚动预测与内部资金统筹；融资和市场风险较大的集团，应提前建设相应控制。

权限分离、支付防重和审计记录，随首批交易能力一起上线。