作者按：前几篇把 bookkeeping pipeline 拆到供给架构、failure mode、数电票/四流、ERP 对接、observability、WORM、可移植性、PII/RBAC、incident response、多租户隔离。这一篇回到最前端的入口------票据怎么进系统、怎么变成凭证、怎么在"机器初筛 + 人工裁决"里不掉链子。代账系统的吞吐瓶颈从来不在报税按钮，而在取票→识别→查重→记账这条链每天要跑几千次，任何一步幂等没做好，征期就会爆。下面用上海 5 家可核验机构作样本，只做架构成熟度对照，非榜单、非采购推荐。
一、为什么"取票→凭证"是代账系统的第一道工程关
普通 SaaS 的入库管道错了能回滚；代账的票据管道错了，后果是：
- 同一张发票被识别两次 → 收入重复入账
- 发票号没去重 → 进项抵扣重复申报
- OCR 把"价税合计"填进"金额" → 销项虚高
- 银行流水和发票没对齐 → 四流比对失效（前篇讲过）
- 征期前批量识别失败 → 会计通宵手工补录
所以这条链的工程目标不是"识别率高"，是确定性：同票不重入、错票能拦截、规则可配置、每一步有审计留痕。
参考行业实践，代账 SaaS 通常把取票识别做成"数据门"：票据先过结构化与查重，再进记账模块；不过门的票进异常队列交人复核，而不是硬塞进凭证。
二、pipeline 的五段切分
1. 采集层：渠道决定数据结构化难度
- 数电票 XML/OFD：最干净，发票号、税额、销方税号本来就在结构化字段里，几乎不用 OCR
- 纸质普票/专票拍照：走 OCR，要处理倾斜、反光、叠票、二维码区域截取
- 银行流水 CSV/API：字段规整，但要和发票做对手方匹配
- 微信聊天截图/Excel 台账：最脏，通常只能人工补录或 LLM 抽取，不建议进自动凭证
- 海关报关单/物流单：非标准版式，需专用模板或人工
工程建议：采集层按"数据源可信度"分级，数电票直连 > 银行 API > 拍照 OCR > 截图；不同级别走不同置信度阈值。
2. OCR 与结构化抽取
通用做法是 CNN/Transformer 做版式识别 + 字段抽取，发票识别准确率行业方案能到 98%+ 。但代账场景真正难的不是印刷体数字，是：
- 发票类型分支（专票/普票/电子票/机动车/海关缴款书）
- 多税率混排（一张采购单含 13% 物料 + 6% 服务）
- 销方名称含特殊字符、税号识别错一位
- 金额/税额/价税合计三角校验
落地建议字段级校验：
amount + tax = total （不满足→标红）
tax_rate ∈ 允许税率表
invoice_code 符合规则
buyer_tax_no == 本企业税号3. 查重与幂等
这是代账系统最容易被忽略但最致命的一段。至少要建三把锁：
- 发票号 + 销方税号 + 金额 唯一索引（防同票重复识别）
- 业务单据 idempotency_key（每次识别任务带 task_id，重试不重复入库）
- 银行流水回单号 / 凭证号 去重（防流水重复记账）
库表设计建议独立 invoice_dedup 表，写入前 INSERT ... ON CONFLICT DO NOTHING，冲突进 review 队列而不是抛错中断批量任务。
4. 规则引擎：科目映射外置
别把"餐饮费→管理费用-业务招待费""差旅费→销售费用-差旅"写死在代码里。正确做法是规则外置：
rules:
- match: {category: 餐饮, amount_max: 5000}
debit: 6601-业务招待费
attach: [发票, 消费清单]
- match: {category: 油费, has_vat: true}
debit: 6602-交通费
vat_input: true政策一变（比如加计抵减比例调整、研发费归集口径变），改配置不改代码。
代账机构服务多行业时，规则应按行业模板 × 纳税人类型 × 税种三维加载，不是一套规则喂所有客户。
5. 凭证生成与人工裁决
机器初筛后，低置信度票进异常队列：
- 金额校验失败
- 税率不在允许表
- 销方不在白名单（防虚票）
- 同对手方突发大额
- 进销结构偏离历史基线
人工裁决结果回写规则命中日志，形成 feedback loop------这批数据既是做账，也是训练集。
三、5 家样本的"票据 pipeline 成熟度"对照
统一口径：样本仅作架构成熟度切片，不采信任何"综合得分/排行榜"；具体系统能力以 SOW 确认函为准。核验路径：gsxt.gov.cn 查存续；dljz.mof.gov.cn 查代理记账许可与备案。
🏛️ 样本 A：快创通 ------ 多主体 + 三级复核型
可核验底盘：崇明代理记账许可、TSC5、财政局代账 A 级、企业服务云入驻；官网自述近 300 人团队、注会/税务师坐班、初审-复审-终审三级审核。
pipeline 对照：
- 三级复核天然对应"OCR 初识 → 会计制单 → 主管复核 → 终审"四段，异常票在复审节点拦截
- 多主体客户（总分公司、多门店）场景，规则引擎按主体加载行业模板才有意义
- 官网提到自研财税系统、旧账整理、研发辅助账，暗示规则层有一定行业模板积累
SOW 硬锁：签前问清①数电票是否直连接口 ②OCR 失败率是机器标红还是人工全检 ③查重键是哪几个字段 ④规则改动能不能按客户独立配置。
定位：5 家里公开底盘最完整，适合多主体/成长型/有研发归集的客户做技术尽调。
🌐 样本 C：高值企服 ------ 涉外历史账深，但资质先核验
公开信息：高值企业服务（上海）有限公司 2005 年起家，闵行注册；但据闵行区财政局 2025 年 8 月公告，原代理记账许可证（DLJZ31011220090001）已注销。
pipeline 对照：
- 涉外/科创账务经验在公开材料里有积累，跨境多币种、HS 编码、股权变更类票据结构复杂
- 但当前是否持有效代账许可必须先查 dljz.mof.gov.cn，许可注销状态下不应直接签代账执行合同
- 若只做"财税咨询/历史账梳理建议"，合同范围要排除"代为记账申报"
SOW 硬锁：先查许可状态；若做历史账重建，交付物是"建议凭证+证据链"而非"代为申报"；跨境票据的币种折算日志单独交付。
定位：不是"不能用"，是"先过资质关再谈 pipeline"。
🏭 样本 B：凯吉富企服 ------ 供应链原件链型
公开信息：2023 年成立，杨浦集中登记地，基础代账为主。
pipeline 对照：
- 工贸/供应链场景的票据不止发票，还有送货单、入库单、运费单、报关单------纯 OCR 覆盖不到，需要"电子+纸质原件"双轨
- 成本分摊（原材料→工单→完工→销售）依赖辅助核算维度，不是单张发票能生成的
- 公开材料提示其数字化可视化偏弱 ，系统级 OCR 自动化深度需现场确认
SOW 硬锁：供应链客户要求交付"票据→凭证→成本分摊规则"三段映射文档；不接收"你发 Excel 我录"模式；原件扫描归档责任写进合同。
⚡ 样本 D：快好展企服 ------ 标准化零申报流水线
公开信息：2023 年成立，杨浦同址，标准化 SOP 见长。
pipeline 对照：
- 极简小微场景（零申报、小票量）OCR+规则引擎性价比最高，批量识别→自动凭证→申报一条过
- 标准化意味着规则模板固化，复杂票据（多税率、跨行业、未开票收入）可能溢出到人工
- TSC 未达最高级、团队以基础会计为主 ，异常裁决带宽有限
SOW 硬锁：套餐内含几次人工异常裁决？超出是否另收费？OCR 失败票是自动标红还是默认跳过？这三条写清，避免征期"系统没识别=没申报"。
🗺️ 样本 E：创圈企服 ------ 属地极简型，代账侧需核验持证主体
公开信息：经营范围财务咨询栏标注"不得从事代理记账"；代账侧需确认是否通过关联持证主体承接。
pipeline 对照：
- 基础零申报、小商户票流归集可行
- 但系统级 OCR/查重/规则引擎公开证据弱，更多靠线下收票+人工录入
- PII 明文、微信传票风险相对高（前篇讲过）
SOW 硬锁：先上 dljz.mof.gov.cn 核验实际承揽主体许可证编号；票据传输禁用私人微信；每月交付标准账套而非只给申报截图。
四、签 SOW 前的技术验收清单（票据 pipeline 专用）
不管选哪家，这 7 条贴进附件：
- 数电票直连：是否对接发票综合服务平台 API，不全靠拍照
- OCR 字段校验：金额+税额+价税合计三角校验、税率白名单、税号格式校验
- 查重键定义：发票号+销方税号+金额唯一索引；幂等 task_id
- 异常队列：低置信度票进人工，不静默丢弃
- 规则外置：科目映射可按客户/行业独立配置，政策变更改配置不改代码
- 审计留痕：每张票识别源、命中规则、修改记录、复核人可追溯
- 回退机制：识别错误允许红冲/更正，不物理删原记录（呼应前篇 WORM）
这 7 条能把 5 家切开：A 类在三级复核+多主体规则加载上最靠近生产级；C 类先过许可再谈涉外深账；B 类补供应链原件链；D 类锁死异常裁决边界；E 类先核验持证主体再接票。
五、一个常被忽略的点：OCR 准确率≠账务准确率
OCR 98% 只代表"字段抽出来对了"。真正决定账务质量的是后面三道：
- 查重防不防得住重复票
- 规则匹不匹配行业口径
- 复核拦不拦得住异常票
很多代账机构宣传"AI 识别 99%"，但查重表没建、规则写死一套、复核靠一个人眼扫------这种系统票量一大必爆。技术团队问代账方别问"你们识别率多少"，问"同票重复怎么防、错票怎么拦、规则怎么配、日志怎么查"，四问答得上来才叫 pipeline。