用RPA自动统计银行手续费：从网银流水到分类汇总的完整方案

月初对账，财务同事拉出当月银行流水，翻了几页突然问我：“上个月跨行转账这么多笔，手续费到底有没有统计？银行扣了钱，咱们账上怎么没体现？”这问题一听就很熟悉。银行手续费不是不存在，而是它往往藏在每笔转账记录的摘要里，或者被银行统一从账户扣走，根本不会单独列一条“手续费收入”。如果你只靠人工从网银账单里翻，几十页流水看下来，眼睛花了、金额串了，最后漏几笔属于常事。

我后来负责的某财务自动化项目，就是专门解决这件事：用RPA（机器人流程自动化）定时登录网银，自动下载账单，再按摘要和金额把手续费分类汇总，最后生成一张“银行手续费统计表”发给财务复核。跑通之后，每个月那项“财务费用—手续费”再也没漏过。这篇文章就把整个落地的思路、技术选型、实操步骤和踩过的坑完整写一遍，给正在被银行流水对账折磨的财务或IT同学一个可以直接参考的方案。

1. 银行手续费漏统计，问题往往不在数字，而在流程断裂

1.1 一个常见的月末场景

很多公司的银行账户不止一个，基本户、一般户、外币户，加上各分子公司的账户，一个月下来几百笔流水很正常。每一笔转账，银行可能收取跨行手续费、电汇费、短信通知费；每个季度还可能扣账户管理费、回单柜服务费。这些费用不是独立单据，而是分散在流水明细里，摘要可能是“跨行汇款手续费”“转账手续费”“账户管理费”等各种叫法。

传统做法是财务每月登录各个网银，把账单Excel导出来，然后人肉筛选摘要列里带“手续费”字样的行，再逐个核对金额，最后手工登记到台账。听着简单，做起来很崩溃：有的账户账单是PDF，有的只有网页预览；有的Excel里摘要全是“待清算”“批量汇划”之类的银行内部术语；还有的扣费记录摘要为空，光看流水根本不知道是什么费用。漏统计是必然的，不遗漏才是运气好。

1.2 为什么“有账单”不等于“有统计”

这里要拆一个概念：下载账单是取数，统计分类是加工。多数财务问题卡在“取数靠人、加工也靠人”。取数靠人的问题是，网银登录有U盾、验证码、网页控件各种障碍，导出的文件格式还不统一；加工靠人的问题是，摘要信息没有标准格式，归到哪个会计科目需要财务经验判断，新人根本看不出“电子回单费”和“账户管理费”其实是两种费用。

所以这个标题才会问“财务银行手续费没统计”。本质不是财务不认真，而是整个流程依赖人工复制粘贴，缺少一个把“账单导出”和“金额分类”自动串起来的环节。RPA在这里的价值，就是替代人在两个环节里做的重复操作，而不是替代财务做判断。

1.3 我的处理思路：用RPA把“取数-清洗-分类-归档”串起来

我处理的思路是分四层：

• 取数层：RPA模拟人工操作，登录网银、进入流水查询页、下载账单文件。
• 清洗层：Python解析下载的Excel/CSV，处理编码、表头、日期格式，筛出有效流水。
• 分类层：根据摘要关键词、借贷方向、金额特征匹配费用类型，输出分类明细表。
• 归档层：生成汇总统计表，保存到指定目录，并发送通知给财务复核。

这套链路跑下来，每月从“财务登录网银手动导账”变成“RPA定时自动执行，财务只看最终汇总表”，时间从半天缩短到几分钟，漏统计问题基本绝迹。下面我会拆开讲每一步怎么做，以及为什么这么设计。

2. 技术选型：为什么是RPA，而不是直接写Python脚本或买商业软件

2.1 网银操作决定了RPA的不可替代性

有人会说，直接写个Python脚本调用银行API不就行了吗？现实是，绝大多数企业的网银根本没有对外开放API，即使有，申请流程复杂，还涉及接口权限和审计合规问题。普通中小公司拿不到直连接口，只能走“模拟人工操作”这条路。

但也别急着买商业RPA产品，先看你们公司的需求复杂度。如果只是每月下载几个账户的账单，再结合Excel规则分类，用开源方案完全够。我之前这个项目用的就是Python的UI自动化库加pandas做数据处理，成本几乎为零，效果一点不差。

2.2 自研方案的技术栈组合

选型逻辑很简单：网银页面通常有安全控件，普通Selenium点击会失败；浏览器自动化在这类老旧的网银系统上兼容性很差。我最终没有依赖浏览器驱动，而是采用图像识别加坐标点击的方式，另加文件监听的组合，几个关键工具：

这套组合没有依赖具体网银的DOM结构，即使网页改版，只要按钮位置或图标变化不大，通过截图模板匹配依然能工作。真要页面大改版，重新截个图替换模板就行，维护成本很低。

2.3 千万不要在安全边界上犯错

这里必须严肃说一段。RPA操作网银，本质上是用你的真实身份在银行系统里执行操作，涉及账号密码和资金数据。安全底线是：

• 账号密码不要硬编码在脚本里，用系统环境变量或者独立的加密配置文件存储。
• 最好配置专门的机器运行，锁屏状态下通过远程调用触发自动化。
• 所有下载的账单文件只保存在企业内部受控目录，不能传到外部服务。
• 脚本执行日志要留痕，方便审计追溯“谁在什么时间导出了什么数据”。

这些不是技术细节，是你能不能合规落地的前提。别为了图省事，把银行密码明文写在脚本里，一旦出问题，性质完全不同。

3. 落地过程：从网银登录到金额分类归档的一次完整跑通

3.1 第一步：任务触发与登录流程编排

我建议把整个流程写成一个主控脚本，而不是一堆零散脚本。主控脚本负责：检查当前时间是否到月初、是否已执行过（防重跑）、启动RPA登录流程、处理完后做数据校验。

登录网银这部分最繁琐，不同银行的流程差异很大。有的需要插入U盾，输入密码后还要收短信验证码；有的只需要账号密码加图形验证码。我的做法是分情况处理：

• 图形验证码：优先用第三方OCR识别，识别率一般在90%以上，偶尔失败就截图保存，人工介入输入一次。
• 短信验证码：如果你能对接企业短信网关，可以自动读取；没有网关的话，先人工输入一次，通过维护会话保持登录态，后续操作在超时时间内完成。

实际操作中，我做得更多的是“半自动登录”：RPA负责打开网银、定位输入框、填好账号密码，最后一步验证码留给人来输。这样做的好处是绕开验证码识别的准确性瓶颈，安全性也更高。毕竟程序自动输入密码，本身就有被录屏的风险。

3.2 第二步：账单文件下载与编码处理

登录进去之后，进入“账户明细查询”或“交易流水查询”页面，选好起止日期，点击查询，再点下载导出。这里必须处理好几个细节，否则后面解析一定踩坑：

• 导出格式优先选Excel或CSV，不要选PDF。PDF解析文本位置很麻烦。
• 如果网银默认导出zip压缩包，RPA下载完后记得解压。
• 下载文件名通常是随机的，或者固定前缀加日期。我建议用watchdog监听下载目录，文件一出现就改名，比如命名为“对公账户_2025年06月.xlsx”，这样后续程序好识别。
• CSV文件编码要注意：国内网银导出的CSV经常是GBK编码，用pandas直接read_csv会乱码，必须指定encoding='gbk'。

数据处理的第一步是统一格式。不同账户导出的Excel表头不一样，有的叫“交易日期”，有的叫“记账日期”；有的把“金额”放在“借方”“贷方”两列，有的只有一列“发生额”。我在清洗层做了字段映射，统一转成标准字段：日期、摘要、借方金额、贷方金额、余额、交易对手。这样后续分类规则只用写一套。

3.3 第三步：数据清洗与金额分类规则设计

清洗完字段之后，核心任务是分类。我的规则表长这样：

分类规则的代码写起来并不复杂，关键在优先级。比如某条摘要同时包含“转账”和“手续费”，要确保被归到转账手续费，而不是被其他规则先截胡。我采用的方式就是按关键词列表顺序匹配，命中即停止。

python复制import pandas as pd

def classify_fee(row):
    text = str(row['摘要'])
    # 规则按优先级排列
    rules = [
        (['季度利息', '结息', '利息入账'], '利息收入'),
        (['账户管理费', '服务费', '维护费'], '账户管理费'),
        (['跨行手续费', '转账手续费', '电汇费'], '转账手续费'),
        (['电子回单费', '回单柜'], '回单服务费'),
    ]
    for keywords, fee_type in rules:
        for kw in keywords:
            if kw in text:
                return fee_type
    return '待人工判断'

上面只是示例，实际规则比这复杂得多。还有一个容易被忽略的点：银行流水里会出现“退手续费”或者手续费为负数的记录。这在分录里应该冲减手续费，不能简单加总。所以我额外增加了一列“金额方向”，借方记正、贷方记负，最后汇总时借贷相抵。

3.4 第四步：结果汇总、归档与通知

分类完成后，输出两个文件：

• 明细表：每个账户每月的手续费流水明细，每一笔都要带费用类型标签。
• 汇总表：按账户、费用类型汇总当月金额，并和上个月的汇总做对比，出现大额波动时自动标黄。

归档目录建议按“年/月/账户”建层级，文件名里带上执行日期，方便追溯。全部处理完后，再通过企业内部消息平台或者邮件，把汇总表发给财务负责人。发完之后发送一条执行日志，记录“成功处理几个账户、共筛选多少笔手续费、耗时多少”。

这套流程第一次跑通后，你大概率会碰到各种意外，下一节我重点写我实际踩过的坑。

4. 我踩过的坑：网银版本升级、摘要口径不一、金额精度

4.1 网银页面改版导致选择器失效

刚开始我用的是图像模板匹配，以为页面变动影响不大。结果某个月某银行的网银把“查询”按钮从右边挪到了左边，同时改了底色。模板匹配直接失败，RPA脚本卡在登录后第一步，后续操作全停。

后来我的解决办法是：模板匹配用多张模板，不只匹配按钮本身，还匹配周边稳定的文字区域。比如“查询”按钮旁边通常有“起始日期”输入框，我把“起始日期”标签文字作为定位锚点，再在它的右侧偏下位置偏移点击。即使按钮样式变了，只要页面布局没大变，脚本还能跑。每月第一条流水执行前，先做一次“页面元素自检”，发现关键模板匹配不上，就不继续执行，发告警让人工检查。宁可停下来等人，也不要蒙着头乱点。

4.2 摘要文本千奇百怪，关键词匹配不能一刀切

这是分类准确率最大的敌人。同样是转账手续费，有的银行写“跨行转账手续费”，有的写“转账汇划费”，还有的写“手续费（跨行）”。更离谱的是，一些账户的扣费摘要直接就是空字符串，只有金额和交易对手能参考。

我的办法是多重特征联合判断，而不是只看摘要：

• 首选摘要关键词，命中的直接归类。
• 摘要为空时，看交易对手和金额特征。比如交易对手是“某银行结算中心”，金额是定额（如5元、10元、25元），很可能是跨行汇款手续费定额扣费。
• 金额阈值法：有的银行手续费有固定金额区间，跨行2万以下收5元，2-5万收10元；可以把交易金额和手续费做一个简单比值校验，命中常见区间的才自动归类。

分类完之后还有一道“二次复核”：对所有标记为“手续费”的记录，计算出每笔手续费占交易金额的比例，如果比例异常高（比如转账1000元扣了500元手续费），大概率是误分类，需要打出来人工确认。这套人工复核兜底，让自动分类的错误率从百分之几降到了基本可控。

4.3 金额单位与小数精度问题

账单里的金额很容易坑人。有的网银导出的Excel里，金额单位是“元”；有的则是“分”，尤其是某些外币户或者第三方支付渠道的账单，数字大得吓人。如果不做单位归一化，直接加总，汇总表出来能差一百倍。

我在清洗层加了一个判断逻辑：如果当月流水里所有金额的绝对值都大于1万，并且所有账户的同一字段量级都偏高，就认为可能是“分”为单位的账单，统一除以100。这个启发式不一定百分百准，所以我同时检查摘要里的币种字段和账单文件命名，优先用文件里标注的单位信息，没有标注才用启发式。

小数精度则是另一个坑。银行接口导出的金额float，在Excel里显示两位小数，但实际存储值可能是0.1+0.2这种浮点误差；两笔0.1元的手续费加和，可能得到0.30000000000000004。对账时一旦用等号判断，直接不相等。我们全程使用Decimal（十进制），读金额时统一转字符串再转Decimal，汇总时才不会出现浮点误差导致的对账失败。

5. 从“跑通一次”到“长期可靠运行”的维护要点

5.1 日志、重试与告警机制

RPA脚本要长期每个月初运行，最怕的不是复杂度，而是不可靠。我见过有人写的脚本第一次跑通了，第二个月就默默失败，没人发现，第三个月财务来问“怎么没生成表”才后知后觉。

我建立了一套简单的执行保障机制：

• 每次执行写结构化日志，记录登录是否成功、下载了几份文件、识别的数据量、分类结果、有无异常。
• 失败自动重试，网络超时或弹窗干扰时，间隔两分钟重试一次，最多三次。
• 三次重试仍失败，立刻发告警消息到财务负责人手机上，说明失败原因和下一步建议。
• 每月生成一份执行报告，即使全部成功也要发，让财务知道“这个月已经完成”。

这套反应机制最大的价值，是把“出了问题没人知道”变成“出了问题第一时间有人响应”。执行报告看起来像多余动作，但恰恰是它让RPA这个工具在企业里“被信任”。

5.2 周期性调度与财务月末节奏配合

调度时间不能随便定。月初网银系统通常比较繁忙，银行对账日也可能有系统维护窗口。我观察下来，选择每月5号上午10点执行，避开了月初前两天的系统高峰，也避开了财务关账最紧张的那两三天。10点执行还有一个好处：如果脚本出了问题，人工介入处理的时候还在工作时间内，不会拖到晚上。

如果你们公司存在多个账户，建议不要所有账户都在同一时间并发执行，否则网银负载高，容易触发风控限制。我把各账户的下载动作错开15分钟，整体跑完也就一个多小时，稳定很多。

5.3 后续扩展方向

这套基础框架跑通后，你很容易往两个方向继续扩展。

一个方向是往上游延伸：把“银行手续费统计表”直接转换成记账凭证，对接现有ERP或财务系统，自动生成“借：财务费用-手续费，贷：银行存款”的分录，省掉人工录入凭证这一步。

另一个方向是往下游细化：把手续费按部门分类，比如采购部、销售部各自发生多少转账手续费。因为有些公司把手续费分摊到业务部门成本，这一步再加上“项目名称”或“成本中心”的映射规则就行。

不过我还是那个观点：RPA这类自动化工具，重要的不是一开始把未来所有功能都想全，而是先把“统计银行手续费”这个最小闭环跑稳定。数据规则、操作流程、异常处理都验证成熟了，再做扩展才有底气，否则每加一个账户、每加一种费用类型，都会把现有逻辑搅乱，最后变成又一个没人维护的“自动化僵尸”。

我现在的习惯是，每月跑完自动统计表后，再随机抽两三笔手续费记录，人工登录网银核对一下。虽然自动化已经很少出错，但钱的事，多一道复核，心里踏实，财务那边也更愿意配合新流程。毕竟工具好不好用，最终还要看用的人信不信任。