孟買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%的復雜情況——這才是合理的分工。
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.