孟买Andheri区的一家中型会计师事务所，4名初级会计师的全部工作就是核对80多个客户的进项税数据。每人每月处理6-8小时，老板算账发现：每新增一个客户，利润反而变薄。

「每接一个新客户，我们就亏一点」

打开网易新闻 查看精彩图片

事务所负责人向我摊牌：「我们向客户报价每月5000卢比做核对，实际要投入价值8000卢比的会计工时。」

这是典型的规模不经济——人力密集型服务的通病。4人年薪168万卢比，加上基础设施开销12万，合计180万卢比/年，换一套200行Python脚本就能替代的流程。

印度实行商品及服务税（GST）后，企业每月面临两套数据源：

• 供应商上传的GSTR-2B（进项税对账单）——政府门户生成
• 企业自己的采购登记簿——来自Tally、Zoho、Busy或手工Excel

会计需要逐行匹配：发票号码、供应商税号（GSTIN）、应税金额、税额。错配项——税号错误、发票缺失、进项税抵扣资格标记——全部手工标红。

流程枯燥、容易出错、且与客户数量线性挂钩。

三步流水线：4分钟替代8小时

我搭建的自动化管道核心逻辑很简单：解析→标准化→匹配。

第一步处理GSTR-2B的嵌套JSON。政府门户导出的数据结构复杂，供应商信息嵌套发票明细，发票里再嵌套税额分项。我用pandas将其展平为表格：

提取关键字段：供应商税号、名称、发票号（统一转大写去空格）、日期、应税金额、中央税/邦税/综合税分项，以及进项税抵扣资格标记。80多个客户的原始数据格式各异，但这一步输出统一。

第二步解决采购登记簿的「巴别塔」问题。客户使用的系统五花八门：Tally导出、Zoho CSV、Busy报表、手工Excel。列名混乱——同一概念叫「Invoice No」「Inv No」「Bill Number」「Document Number」。

我建立别名映射表，把见过的15种格式全部对齐到统一模式。CSV或Excel自动识别，首表单直接读取。

第三步是匹配引擎。核心算法不复杂：用供应商税号+发票号作为复合键，比对金额容差。但真实场景充满噪音——发票号大小写不一致、前后空格、供应商在GSTR-2B里简称「ABC Ltd」而采购簿写「ABC Limited」。

我加入模糊匹配：Levenshtein距离处理名称变体，正则表达式清洗发票号格式。匹配结果分三档——精确匹配、建议复核、未匹配，对应不同处理路径。

为什么偏偏是这家事务所？

印度有数十万GST注册企业，会计服务市场高度碎片化。大型软件厂商盯着ERP集成，看不上中小事务所的「脏活」。而这类脏活，恰恰是数百万工时堆积的地方。

事务所负责人的痛点很具体：不是技术不懂，是没时间自建系统；不是不想数字化，是市面方案要么太贵，要么强制改变现有工作流。

200行脚本的价值不在于技术深度，在于精准切入一个被忽视的场景——政府强制格式与企业杂乱数据之间的鸿沟。

这个案例的启示是：自动化机会往往藏在「不得不做、但没人愿意优化」的缝隙里。不是取代会计，而是把她们从机械核对解放出来，去处理真正需要判断的例外事项。

4名会计师现在负责异常复核和客户沟通。脚本跑4分钟，人处理那5%的复杂情况——这才是合理的分工。