4. 现金可视化基础
现金可视化的第一步不是画图，而是把“钱在哪里、有多少、什么时候到账”变成可计算的数据。多实体多币种场景下，同一笔资金可能分散在集团总部、区域子公司、海外SPV的多个银行账户中，币种、时区、会计口径、银行接口能力各不相同。若数据来源不清、余额获取方式不统一、清洗规则缺失，后续的归集决策就会建立在错误或滞后的数字上。本节围绕四个基础环节展开：数据来源、账户余额获取方式、银行对账单与API集成、数据清洗与标准化。
一、核心原理：现金可视化的数据链路
现金可视化本质上是一条从银行到报表的数据链路：银行产生交易与余额信息，企业通过不同通道获取原始数据，再经过清洗、标准化、映射，最终形成统一的现金头寸视图。这条链路有三个关键属性：完整性（是否覆盖全部账户）、及时性（T+0还是T+1）、准确性（余额与交易是否对得上）。
数据来源通常分为四类：银行对账单文件、银行API、企业ERP/资金系统、手工台账。不同来源的粒度、频率和可信度差异很大。例如，银行API可提供实时余额，但对账单文件通常按日批量生成；ERP中的现金科目余额反映账面数，未必等于银行实际可用余额。因此，可视化系统必须明确每个数字的“来源标签”和“时间戳”。
二、账户余额获取方式：四种通道的取舍
账户余额获取方式决定了可视化的实时性和实施成本。常见方式包括：
- 银行对账单文件（MT940/MT942、CAMT.053、CSV/Excel）：覆盖广、成本低，适合日终余额和交易明细，但时效性通常为T+1，且格式因行而异。
- 银行API（余额查询、交易查询、支付发起）：可做到准实时，适合高频监控和自动归集，但需要逐行对接、处理认证与限流。
- 银企直联/主机直联：大型集团常用，稳定但部署重、周期长，适合核心账户。
- ERP/资金系统与手工台账：作为补充，用于内部账户、备用金、在途资金，但必须与银行数据交叉核对。
实务中建议采用“API优先、对账单兜底、ERP补充”的混合策略：对资金集中度高的核心账户走API，对长尾账户用对账单批量获取，对内部账户用ERP数据补齐。关键是为每个账户定义余额口径：账面余额、可用余额、冻结金额、在途资金分别存储，避免把“可用余额”误当“账面余额”用于归集。
三、银行对账单与API集成：从文件到接口
对账单集成通常按“获取—解析—校验—入库”四步走。以CAMT.053为例，解析时需要提取账户标识、币种、期初/期末余额、每笔交易的金额、方向、起息日、交易类型代码。API集成则需处理OAuth或证书认证、分页、限流、重试与幂等。下面是一个简化的API余额查询配置示例：
{
"bank": "HSBC",
"endpoint": "https://api.bank.example/v1/accounts/{accountId}/balances",
"auth": {
"type": "OAuth2",
"tokenUrl": "https://api.bank.example/oauth/",
"scope": "accounts balances"
},
"params": {
"currency": "USD",
"balanceType": "available"
},
"retry": {
"maxAttempts": 3,
"backoffMs": 2000
},
"rateLimit": {
"requestsPerMinute": 60
}
}集成时最容易出问题的是“时间口径”和“重复数据”。API返回的余额可能带银行记账时间，而对账单的期末余额对应银行日切时间；两者若混用，会导致同一账户出现两个不同余额。建议在数据模型中统一使用银行记账日期+银行记账时间作为业务时间，并保留获取时间作为技术时间。对于重复数据，用“银行流水号+账户+金额+起息日”做幂等键。
注意：不要用“账户号后四位”作为唯一标识。多实体下不同银行可能存在相同后四位，必须使用“实体编码+银行代码+完整账号+币种”作为账户主键。
四、数据清洗与标准化：让数字可比
清洗与标准化是把原始数据变成可信现金视图的核心。主要动作包括：
- 账户映射：将银行账号映射到内部实体、成本中心、资金池，建立账户主数据表。
- 币种标准化：统一为ISO 4217三位代码，处理小数位差异（如JPY无小数、KWD三位小数）。
- 金额与方向：统一借贷方向，确保流入为正、流出为负，或反之，但全系统一致。
- 日期与时区：统一转换为集团报告时区，保留原始银行时间。
- 去重与对账：按幂等键去重，并与ERP账面数做差异核对。
- 异常标记：对缺失账户、余额突变、币种未知等打标，进入人工复核队列。
下面是一张清洗规则清单示例：
| 字段 | 原始问题 | 标准化规则 | 校验方式 |
|---|---|---|---|
| 币种 | “美元”“USD”“US$”混用 | 统一为ISO 4217代码 | 对照币种字典 |
| 金额 | 千分位、括号负数、逗号小数点混用 | 去除分隔符，统一为Decimal | 正则+精度检查 |
| 日期 | MM/DD/YYYY与DD/MM/YYYY混用 | 统一为YYYY-MM-DD | 范围与格式校验 |
| 账户 | 带空格、连字符、掩码 | 去空格，补全完整账号 | 账户主数据匹配 |
| 交易类型 | 银行代码不统一 | 映射为内部交易分类 | 映射表覆盖率检查 |
五、案例与复盘：一次余额差异的排查
某集团在可视化看板上发现，香港子公司A的美元账户余额比银行对账单少12万美元。排查路径如下：先核对账户主数据，确认账号与币种无误；再检查API返回的余额类型，发现看板取的是“可用余额”，而对账单展示的是“账面余额”，差额正好是未清算支票；最后确认该账户有一笔在途付款尚未清算。修正方案是：看板同时展示账面余额与可用余额，并增加“在途资金”字段。这个案例说明，余额口径不统一是现金可视化最常见的误区之一。
复盘要点：① 每个余额数字必须带来源和口径标签；② 清洗规则要版本化，变更需留痕；③ 账户主数据应每月与银行清单核对一次；④ 对账单与API并行时，以银行记账时间为准做去重和对账。
完成数据来源梳理、余额获取方式选择、对账单与API集成、清洗标准化之后，现金可视化才具备可靠的数据底座。下一步才能在此基础上进行多币种折算、头寸汇总和归集策略设计。