ERP

业财通识24：银行对账——银行流水与账本的逐笔核对

2026/3/717 min read

ERP资金管理银行对账业财一体化十三Tech

大家好，我是十三。

在前两篇文章中，我们分别聊了应收对账和应付对账：与客户核对该收的钱是否到账，与供应商核对该付的钱是否准确。

但这里有一个容易被忽略的环节。与客户和供应商对完账后，企业的财务工作并没有结束。还有一笔最重要的账要对——与银行对账。

原因很简单。企业的每一笔收入和支出，最终都要经过银行账户。如果企业账本上的银行存款余额，与银行实际记录的余额不一致，那么之前所有的应收应付对账，都可能建立在一个错误的基础上。你算清了该收多少、该付多少，但口袋里到底有多少钱，心里还是没底。

今天我们就来聊聊，为什么企业的银行余额和账本余额经常对不上，以及如何通过银行对账来确保资金数据的准确性。

银行对账解决什么问题

业务定义

银行对账，是指企业定期将自身的银行存款日记账与银行提供的对账单进行逐笔核对，找出差异、分析原因，并编制银行余额调节表的过程。

通俗地说，就像两个人各自记了一本账。一个人记的是"我认为我有多少钱"，另一个人记的是"银行认为我有多少钱"。由于记账时间和信息传递的延迟，这两本账很少完全一致。银行对账的目的，就是找出差异原因，确认真实的资金状况。

差异的必然性

企业的银行余额和账本余额不一致，不是操作失误，而是业务特性决定的。

在第4篇文章中，我们讲过企业付款的流程：财务人员在 ERP 中发起付款，生成支付指令，银行执行转账。从发起付款到银行实际扣款，中间存在时间差。在这个时间差里，企业账本已经记了"钱已付"，但银行还没扣款。

同样，在第11篇文章中，客户付款后，银行先收到资金，企业财务人员可能需要隔天才能在系统中确认收款。这时银行已经记了"钱已到"，但企业账本还没记。

这些时间差，就是对账差异的根源。只要企业持续发生收付款业务，差异就永远存在。银行对账不是消灭差异，而是让差异变得可控、可解释、可追踪。

如果不做对账，可能会出现账面有钱但实际已透支，或者账面没钱但实际有大笔在途资金的误判。这种误判直接影响付款审批、投资决策和现金流预测。

银行余额调节表

银行余额调节表是银行对账的核心产物。它不是一个简单的数字对比，而是一张有固定结构的表格，用来系统性地展示差异并推导出真实的资金余额。

调节表结构

银行余额调节表通常包含左右两个部分：企业账面余额调节和银行对账单余额调节。最终，两边调节后的余额必须相等。

项目	金额（元）
企业账面余额	100,000
加：银行已收，企业未收	+ 20,000
减：银行已付，企业未付	- 5,000
调节后余额	115,000

项目	金额（元）
银行对账单余额	120,000
加：企业已收，银行未收	+ 10,000
减：企业已付，银行未付	- 15,000
调节后余额	115,000

这个表格的核心逻辑是：无论从哪里出发，只要把所有"未达账项"考虑进去，最终应该得到同一个真实余额。如果两边调节后的余额不相等，说明还有遗漏或错误，必须重新核对。

编制逻辑

编制调节表遵循三步走。

第一步，获取基准数据。从 ERP 系统中导出企业银行存款日记账的期末余额，从银行网银或银企直联接口获取银行对账单的期末余额。这两个数字通常不相等，这是正常的。

第二步，逐笔比对。将两边的流水按金额、日期、摘要进行匹配，找出已经双方确认的流水，以及只在一方出现、尚未被另一方记录的流水。

第三步，分类归集。将未匹配的流水按四种未达账项类型归类，填入调节表的对应位置，计算调节后余额。调节后余额才是企业在该时点可以真实动用的资金。

四种未达账项

未达账项，是指在某一时间节点，企业和银行之间由于记账时间不同步，导致一方已记而另一方未记的业务。所有对账差异，最终都可以归类为以下四种之一。

企业已收，银行未收

定义：企业已经确认收到了一笔款项并记入账本，但银行尚未将这笔资金记入企业账户。

典型场景：企业收到客户的银行承兑汇票或异地支票，财务在收到票据当天就记了"银行存款增加"，但银行实际入账需要票据交换和清算时间，通常需要 1-3 个工作日。

示例：3月31日，财务收到客户寄来的 50,000 元转账支票，当日记入账本。但银行在 4月2日才完成清算入账。3月底对账时，这 50,000 元就是"企业已收，银行未收"。

处理方式：在调节表的企业账面余额一侧无需调整（因为企业已经记了），在银行对账单余额一侧需要"加：企业已收，银行未收"。

企业已付，银行未付

定义：企业已经签发支票或发起付款指令并记入账本，但银行尚未实际扣款。

典型场景：财务在月末开出一张转账支票给供应商，当日记了"银行存款减少"。但供应商可能过几天才去银行兑付，银行在这几天内还没有实际扣划资金。

示例：3月30日，财务开出 30,000 元支票支付供应商货款，当日记入账本。供应商在 4月3日才到银行兑付。3月底对账时，这 30,000 元就是"企业已付，银行未付"。

处理方式：在调节表的银行对账单余额一侧需要"减：企业已付，银行未付"。因为银行记录的余额比企业实际可用的钱多，需要扣减这部分已经承诺支付但尚未扣款的金额。

银行已收，企业未收

定义：银行已经收到一笔款项并记入企业账户，但企业尚未在账本中记录。

典型场景：客户直接转账到企业银行账户，银行实时到账。但企业财务人员尚未在 ERP 系统中录入收款单，或者银企直联接口同步存在延迟。

示例：3月31日下午，客户转账 20,000 元，银行已实时入账。但由于是月底最后一天，财务人员已经结账，这笔收款要到 4月初才录入系统。3月底对账时，这 20,000 元就是"银行已收，企业未收"。

处理方式：在调节表的企业账面余额一侧需要"加：银行已收，企业未收"。因为企业账本上少记了这笔已经到账的资金。

银行已付，企业未付

定义：银行已经从企业账户扣划了款项，但企业尚未在账本中记录。

典型场景：银行自动扣除账户管理费、网银年费、短信通知费等。银行在扣款时已经记录了支出，但企业财务人员可能到月底看到对账单才发现，此前并未逐笔记录这些小额费用。

示例：3月25日，银行自动扣除季度账户管理费 500 元。银行流水显示支出，但企业账本上没有这笔记录，直到 3月底收到对账单才发现。这 500 元就是"银行已付，企业未付"。

处理方式：在调节表的企业账面余额一侧需要"减：银行已付，企业未付"。企业在确认这笔费用后，还需要及时补记入账本，否则下月对账时差异会继续存在。

对账流程

银行对账不是简单的"看一眼余额对不对"，而是一套标准化的操作流程。

graph TD;
    A[获取银行对账单] --> B[导出企业银行日记账];
    B --> C[逐笔匹配流水];
    C --> D{是否存在差异};
    D -- 否 --> E[余额一致无需调节];
    D -- 是 --> F[标记未达账项];
    F --> G[编制余额调节表];
    G --> H[财务主管审批];
    H --> I[归档保存];

第一步：获取银行对账单。通常通过银企直联接口自动下载，或财务人员从网银导出 Excel 文件。对账单需要包含交易日期、交易金额、交易摘要、对方账户等关键字段。

第二步：导出企业银行日记账。从 ERP 系统的资金模块中，导出同一账户、同一期间的企业记账流水。确保时间范围与银行对账单完全一致。

第三步：逐笔匹配。将两边的流水进行比对，确认每一笔银行流水是否在企业账本中有对应记录，反之亦然。已经匹配的流水标记为"已核对"，未匹配的流水进入差异分析环节。

第四步：标记未达账项。对于无法自动匹配的流水，按四种未达账项类型进行分类标记，并记录原因和预计到账时间。这一步需要财务人员的业务判断。

第五步：编制调节表。将基准余额和未达账项填入调节表，计算调节后余额。两边调节后的余额必须相等。如果不等，说明匹配过程有遗漏，需要返回第三步重新检查。

第六步：审批与归档。调节表需要财务主管审批确认，作为财务档案保存，以备审计查验。通常保存期限不少于 5 年。

自动对账规则

在信息化系统中，银行对账的大部分工作可以通过规则自动完成。自动对账的核心是"匹配引擎"，它按照预设规则将银行流水与企业记账流水进行配对。

匹配策略

系统通常采用三层匹配策略，从精确到模糊。

第一层：精确匹配。按金额 + 日期 + 摘要完全一致进行匹配。这是最常见的场景，比如一笔 10,000 元的货款，两边金额、日期和摘要都一致，系统自动勾对。精确匹配的准确率最高，但覆盖率有限，因为银行摘要和企业摘要的表述往往不同。

第二层：模糊匹配。当精确匹配失败时，系统尝试按金额 + 日期窗口（如 ±3 天）+ 摘要关键词匹配。适用于银行摘要和企业摘要表述不一致，但核心信息相同的情况。例如银行摘要是"跨行转账收入"，企业摘要是"客户A货款"，系统通过关键词和金额进行关联。

第三层：人工兜底。当自动匹配无法完成时，将流水推送到人工待处理列表，由财务人员手动确认和匹配。人工兜底的比例是衡量自动对账质量的关键指标，通常目标控制在 10% 以下。

如果人工兜底比例长期高于 20%，说明匹配规则需要优化，或者基础数据质量存在问题，比如摘要填写不规范、日期录入错误等。

自动对账伪代码

以下是一个简化的自动对账逻辑：

function autoReconcile(bankFlows, ledgerFlows) {
  const unmatchedBank = [];
  const unmatchedLedger = [];
  
  for (const bank of bankFlows) {
    // 第一层：精确匹配
    let match = ledgerFlows.find(l => 
      l.amount === bank.amount &&
      l.date === bank.date &&
      l.summary === bank.summary
    );
    
    // 第二层：模糊匹配
    if (!match) {
      match = ledgerFlows.find(l =>
        l.amount === bank.amount &&
        Math.abs(l.date - bank.date) <= 3 &&
        l.summary.includes(bank.summary.slice(0, 4))
      );
    }
    
    if (match) {
      bank.status = 'matched';
      match.status = 'matched';
    } else {
      unmatchedBank.push(bank);
    }
  }
  
  // 未匹配的流水推送到人工处理
  return { unmatchedBank, unmatchedLedger };
}

关键设计考量：

金额方向：收入和支出的金额符号必须一致。银行流水中的"贷方"对应企业账本的"收入"，"借方"对应"支出"。方向搞反了，匹配就会出错。

日期窗口：模糊匹配时，日期窗口不宜过大。通常设为 1-3 天，超过这个范围，匹配的准确性会显著下降，容易将两笔无关的业务错误关联。

摘要清洗：银行流水摘要常包含"网银转账""手续费"等固定前缀，系统需要先清洗去除冗余信息，再与企业的摘要进行比对。例如将"【网银转账】客户A货款"清洗为"客户A货款"后再匹配。

常见异常场景

即使有了自动对账，实际业务中仍然会遇到一些棘手的异常情况。

场景一：重复扣款

问题：由于网络超时或系统重试，同一笔付款指令被银行执行了两次，企业账户被扣了两笔钱，但企业账本只记了一笔。

识别：对账时会发现，企业账本有一笔 50,000 元的付款记录，但银行流水有两笔相同金额、相同时间、相同对手的扣款。

处理：财务人员需要立即联系银行申请退款或调账，同时在系统中补记一笔付款记录，并标注"银行重复扣款"原因。这不是未达账项，而是银行操作错误，需要单独跟进并保留证据。

场景二：银行手续费漏记

问题：银行在转账时自动扣除了手续费，但企业发起付款时只按货款金额记账，没有单独记录手续费。或者银行扣了年费、账户管理费，企业从未在系统中维护这些费用的预期。

识别：对账时发现，银行流水金额比企业账本金额少了 15 元或 25 元，差异恰好是银行转账手续费。或者月底发现有一笔银行已扣、企业未记的账户管理费。

处理：财务人员需要在企业账本中补记一笔手续费支出，并设置后续自动计提规则。例如，对于高频的跨行转账手续费，可以与银行协商包月费率，或设置每月自动预提。这类小额费用如果长期漏记，累积起来会影响财务数据的准确性。

场景三：跨行转账时间差

问题：企业发起跨行转账后，付款行已经扣款，但收款行尚未入账。或者企业收到跨行转账，付款行已划出，收款行已入账，但企业财务人员尚未确认。

识别：跨行转账通常涉及央行清算系统，工作日的 9:00-17:00 之间基本可以实时到账，但非工作时间提交的转账可能延迟到下一个工作日。对账时会发现一笔企业已付、银行未付（或相反方向）的记录，但原因不是支票未兑付，而是跨行清算延迟。

处理：对于在途资金，需要在调节表中作为未达账项处理。财务人员还需要关注大额跨行转账的到账状态，避免因资金未实际到账而影响后续付款计划。一些资金密集型企业会设置"在途资金"科目，专门跟踪这类尚未完成清算的资金。

一个实用的经验是：对账截止日最好避开周五下午和节假日前一天，因为这些时点发起的跨行转账，在途时间最长，容易产生大量未达账项。

总结

银行对账是企业资金管理中最基础，也最容易被忽视的一环。它的价值不仅在于"让两个数字对上"，更在于通过逐笔核对，及时发现重复扣款、手续费漏记、在途资金等潜在问题。

三个关键判断值得记住。

第一，银行余额和账本余额不一致是正常的。差异本身不是错误，未达账项是业务时间差的自然产物。真正的问题是"不知道差异在哪里"。只要差异可以被解释、被归类、被调节，它就是可控的。

第二，银行余额调节表不是形式主义。它是推导真实资金余额的唯一可靠工具，调节后余额才是企业可以动用的真实资金。不做调节表，只看账面余额或只看银行余额，都可能做出错误的资金决策。

第三，自动对账可以提升效率，但不能替代人工判断。匹配规则再完善，也处理不了重复扣款、异常摘要、跨行延迟等特殊情况。人工兜底是对账流程不可或缺的一环，目标是让机器做机器擅长的事，让人做人擅长的事。

在第23篇文章中，我们聊了应付对账，确保该付的钱准确无误。今天聊完银行对账，资金管理的三条核对线——应收、应付、银行——已经完整。

下一篇，也是业财对账系列的收尾，我们将跳出单一流水核对的视角，聊聊更高维度的业财对账：当业务系统的数据与财务系统的数据整体对不上时，应该如何定位和解决。

往期回顾

关于十三Tech

资深服务端研发工程师、架构师、AI 编程实践者。
专注分享真实的技术实践经验，持续记录企业系统、架构设计与 AI 编程实践。