孟買Andheri區(qū)的一家中型會計師事務(wù)所，4名初級會計師的全部工作就是核對80多個客戶的進項稅數(shù)據(jù)。每人每月處理6-8小時，老板算賬發(fā)現(xiàn)：每新增一個客戶，利潤反而變薄。

「每接一個新客戶，我們就虧一點」

事務(wù)所負(fù)責(zé)人向我攤牌：「我們向客戶報價每月5000盧比做核對，實際要投入價值8000盧比的會計工時?！?/p>

這是典型的規(guī)模不經(jīng)濟——人力密集型服務(wù)的通病。4人年薪168萬盧比，加上基礎(chǔ)設(shè)施開銷12萬，合計180萬盧比/年，換一套200行Python腳本就能替代的流程。

印度實行商品及服務(wù)稅（GST）后，企業(yè)每月面臨兩套數(shù)據(jù)源：

? 供應(yīng)商上傳的GSTR-2B（進項稅對賬單）——政府門戶生成
? 企業(yè)自己的采購登記簿——來自Tally、Zoho、Busy或手工Excel

會計需要逐行匹配：發(fā)票號碼、供應(yīng)商稅號（GSTIN）、應(yīng)稅金額、稅額。錯配項——稅號錯誤、發(fā)票缺失、進項稅抵扣資格標(biāo)記——全部手工標(biāo)紅。

流程枯燥、容易出錯、且與客戶數(shù)量線性掛鉤。

三步流水線：4分鐘替代8小時

我搭建的自動化管道核心邏輯很簡單：解析→標(biāo)準(zhǔn)化→匹配。

第一步處理GSTR-2B的嵌套JSON。政府門戶導(dǎo)出的數(shù)據(jù)結(jié)構(gòu)復(fù)雜，供應(yīng)商信息嵌套發(fā)票明細(xì)，發(fā)票里再嵌套稅額分項。我用pandas將其展平為表格：

提取關(guān)鍵字段：供應(yīng)商稅號、名稱、發(fā)票號（統(tǒng)一轉(zhuǎn)大寫去空格）、日期、應(yīng)稅金額、中央稅/邦稅/綜合稅分項，以及進項稅抵扣資格標(biāo)記。80多個客戶的原始數(shù)據(jù)格式各異，但這一步輸出統(tǒng)一。

第二步解決采購登記簿的「巴別塔」問題?？蛻羰褂玫南到y(tǒng)五花八門：Tally導(dǎo)出、Zoho CSV、Busy報表、手工Excel。列名混亂——同一概念叫「Invoice No」「Inv No」「Bill Number」「Document Number」。

我建立別名映射表，把見過的15種格式全部對齊到統(tǒng)一模式。CSV或Excel自動識別，首表單直接讀取。

第三步是匹配引擎。核心算法不復(fù)雜：用供應(yīng)商稅號+發(fā)票號作為復(fù)合鍵，比對金額容差。但真實場景充滿噪音——發(fā)票號大小寫不一致、前后空格、供應(yīng)商在GSTR-2B里簡稱「ABC Ltd」而采購簿寫「ABC Limited」。

我加入模糊匹配：Levenshtein距離處理名稱變體，正則表達式清洗發(fā)票號格式。匹配結(jié)果分三檔——精確匹配、建議復(fù)核、未匹配，對應(yīng)不同處理路徑。

為什么偏偏是這家事務(wù)所？

印度有數(shù)十萬GST注冊企業(yè)，會計服務(wù)市場高度碎片化。大型軟件廠商盯著ERP集成，看不上中小事務(wù)所的「臟活」。而這類臟活，恰恰是數(shù)百萬工時堆積的地方。

事務(wù)所負(fù)責(zé)人的痛點很具體：不是技術(shù)不懂，是沒時間自建系統(tǒng)；不是不想數(shù)字化，是市面方案要么太貴，要么強制改變現(xiàn)有工作流。

200行腳本的價值不在于技術(shù)深度，在于精準(zhǔn)切入一個被忽視的場景——政府強制格式與企業(yè)雜亂數(shù)據(jù)之間的鴻溝。

這個案例的啟示是：自動化機會往往藏在「不得不做、但沒人愿意優(yōu)化」的縫隙里。不是取代會計，而是把她們從機械核對解放出來，去處理真正需要判斷的例外事項。

4名會計師現(xiàn)在負(fù)責(zé)異常復(fù)核和客戶溝通。腳本跑4分鐘，人處理那5%的復(fù)雜情況——這才是合理的分工。