这是一个 bank statement converter：把 PDF 银行对账单转成 CSV / Excel / QIF / OFX / QBO 。这个品类工具不少，我做的时候盯的是两个一直没被解决的问题。
一、转出来的文件导不进会计软件
这跟提取质量无关，卡的是列名、日期格式、文件大小这些事。Intuit 自己的文档写得很明确： QuickBooks 收的 CSV 必须是英文、不超过 350 KB 、单次最多 1000 行、只能是三列 （ Date, Description, Amount ）或者四列。一年的活期账单，后两条都会超。
所以我按 QuickBooks 和 Xero 各自文档要的形状分别出文件，而不是给一个通用 CSV 让你自己改。
二、漏读了，但没人告诉你
这个更要命。版面解析或者 OCR 漏掉一整块交易，输出看起来完全正常，你导进账里， 几个月后对账才发现少了一截。
我这边的做法：
- 每份文件都跑余额校验。期初 + 所有交易 = 期末，对不上当场告诉你。
- 读不到的地方按页点名报出来，而不是安静填个空值或者 0 混过去。 纸上印着的字才允许写进结果，算出来的只许点名。
管线里专门有一步是干这个的：先用本机 OCR 去找「只有图、文字层读不到」的块， 报出「这里必须重读」的，单独渲成图再送一次模型，读到的东西并回结果，然后才做余额校验和告警。
顺序反过来的话，重读补进来的交易会被当成「没解释的金额」再报一遍， 用户看到一堆假警报，下次就学会无视告警了。告警只在真有东西没读到时才响，这条比多报几条重要。
还有一条贯穿全流程的红线：任何一步失败都不许降级成「抽到了空结果」。 模型调用炸了，整次转换就失败；本机 OCR 用不了，就在 warnings 里写明「这一项本次没判定」。 静默地给出一份看起来完整的表，是这个产品唯一不能犯的错。
这两件事——余额校验，和读不到就明说——是我觉得一个 bank statement converter 最该有、但这个品类里普遍没有的东西。
三、关于「支持多少家银行」
我没有按银行做模板，所以也没有支持列表——读的是眼前这份文档，没见过的版式通常也能出来。
但我也不想写「支持 1000+ 家银行」，那个数得编。所以我把手上真有的回归语料公开了： 157 份 PDF ，其中 61 份是对账单本体，41 份来自 24 家真实机构（美国、加拿大、印度、印尼、尼日利亚）。 存款和信用卡这两组里的每一份都人工核过期初/期末余额——改动解析器如果让其中任何一份对不上， 构建直接失败。
清单在这：我们测过哪些银行
同理，整站一个准确率百分比都没有。我给不出可信的数，就不写。
技术栈
后端 Python + Starlette ，前端 Hugo 静态站加原生 JS ，没上框架。
站在这：bank statement converter。有问题欢迎问，砖也欢迎。
Select Language