图版 III · BillFlow · 2026
骨白颜料 · 沿航迹掠过的侧光
面向欧盟跨境 Shopify 商家的订单发票网关：发出前完成税号校验，未通过的发票进入待修正队列。
合规流程 / 业务规则 / 异常恢复
案例摘要
- 问题
- B2B 买方因格式或税号瑕疵拒收了 7.9% 的发票，买家还常把税号随手填在订单备注里。
- 用户
- 欧盟跨境 Shopify 商家，其中 3 位德国商户接受了访谈；另有发票售后工单。
- 关键决定
- 发出前校验，未通过的发票进入待修正队列；抽取税号用正则、校验位算法和 VIES 核验，不用大语言模型。
- 结果
- 6 周后买方拒收率从 7.9%（63/797）降到 1.2%（11/914）；代价：上线后头两周，询问发票为何停在待修正队列的工单上升 35%。
正在加载本地演示…
交互演示暂时无法加载，原图和案例仍可阅读；可以重新尝试。
一个决定
合规场景里，AI 在哪一步停手
BillFlow 从订单备注里抽取税号这一步，用规则完成，不交给模型。在 80 条脱敏备注上，正则初筛、校验位算法加 VIES 接口核验共抽出 44 条，44 条全部正确；没能识别的 8 条转给商户人工确认。发票改为先校验再发出，运行 6 周后，B2B 发票被买方拒收的比例从 7.9%（63/797）降到 1.2%（11/914）。
买家常把税号随手填进订单备注，一位德国商户说，要靠人工反复猜哪些买家属于企业客户。通用大语言模型能从自由文本里找出号码；规则只认得出符合已知格式的那部分。运营同事另有顾虑：前置拦截会让商户恐慌，他们主张“先出具发票，后续出问题再修改”。
模型抽出 52 条，其中 47 条正确；错的 5 条里，有 3 条被模型自作主张“纠正”了一位校验数字。合规场景里这类错误最危险：号码看上去有效，却并非买家的税号，一旦开票，就会印进具有法律效力的单据。规则抽出的少，但没有犯这类错。同样的考虑也定下了超时的处理：批处理中 VIES 两次超时，系统标为“待核验”，外部服务暂时不可用，推不出税号无效。
拦截要付出时间。上线后头两周，询问“发票为何停在待修正队列”的客服工单增加了 35%，直到第 4 周商户熟悉规则后才恢复正常。我们上线前没有向商户推送操作指引和规则变更提示，这部分沟通成本本来可以避免。
模型在错误会变成法律事实的地方停手，只用在反正有人复核输出的环节。“没能核验”单独作为一种状态，和“错误”分开。规则改动先告诉会被它拦下的人，再开始拦。
- 订单备注
- 正则初筛
- 未匹配：转给商户确认
- 校验位
- 校验失败：进入待修正队列
- VIES 核验
- 超时：标为“待核验”
- 发出发票
系统如何分工
- 01订单与税号
- 02规则校验：校验位 + VIES
- 03待修正队列
- 04生成与发送发票
数据错误进入待修正队列并标出缺失字段；VIES 超时标记为待核验，不判为税号无效。
品牌卡 · 图版 III
BillFlow
账本停在它无法担保的那一栏。
色彩
- 象牙黑
#0E0D0C账本 - 骨白
#EDE6D8已核验的数值 - 灰 7
#B9B2A6被拦下的字段，加一道外框 - 灰 5
#8E887F待核验
字体
- Geist账本与表单
- 等宽字体税号与校验位
动效
- 印
240 ms税号随核验逐位印出 - 光
1200 ms被拦下的字段一直亮着，直到改好
问题与背景
BillFlow 属于面向欧洲跨境 Shopify 商家的订单合规发票网关，技术栈采用 Shopify 集成代码、Hono、SQLite 与 React。业务对接欧盟 EN 16931 电子发票标准与 VIES 增值税号核验接口，同时响应德国 2025 年起企业须具备接收 B2B 电子发票能力的法规要求。我负责订单到发票的数据流转、校验规则与异常恢复。
用户验证：工单分析与商户访谈
抽取 1 个月内的 15 笔发票售后工单，由 2 人独立进行类别编码，评定者一致性 κ = 0.71。
| 故障类别 | 工单数 |
|---|---|
| 采购方系统因格式标准拒收 | 6 笔 |
| 增值税号缺失或校验格式不符 | 3 笔 |
| 订单退款与红字发票冲销 | 2 笔 |
| 其余杂项 | 4 笔 |
我还访谈了 3 位德国商户。一位咖啡器材商户说：“从电商订单难以区分哪些买家属于企业客户。买家常常把税号随手填在订单备注栏，需要人工反复猜测辨认。”
评测：从订单备注抽取税号
测试集：80 条脱敏处理后的真实订单备注。
| 方案 | 抽取出税号 | 完全正确 | 错误 |
|---|---|---|---|
| A：通用大语言模型直接抽取 | 52 条 | 47 条 | 5 条（其中 3 条被模型自动“纠正”了一位校验数字） |
| B：正则初筛 + 校验位算法 + VIES 接口核验 | 44 条 | 44 条 | 0 条 |
方案 B 没能直接识别的 8 条备注，统一转入商户人工确认。批处理评测中遇到 2 次 VIES 临时超时，系统把这些税号标记为“待核验”，不把外部服务暂时不可用判定为“税号无效”。
抽取规则采用方案 B。模型悄悄改掉一位校验数字，会产生一个看起来正确的错误税号，这比请商户确认一次更糟。
团队决策：前置拦截，并为此付出代价
运营同事担心前置拦截发票会引发商户恐慌，主张“先出具发票，后续出问题再修改”。改动前 6 周，B2B 发票因格式或税号瑕疵被买方拒收 63/797 笔，拒收率 7.9%。
我们上线了前置校验拦截：校验失败的发票进入“待修正队列”，商户补充税号或修正地址后再发出。运行 6 周后，拒收率从 7.9% 降到 1.2%（11/914）。
代价同样真实。上线后头两周，关于“发票为何停在待修正队列”的客服咨询增加 35%，到第 4 周商户熟悉规则后才恢复正常水位。上线前我们没有向商户推送操作指引和规则变更提示，造成了本可避免的沟通成本。
异常处理规范
| 故障类别 | 典型诱因 | 系统处理 | 商户端展示 |
|---|---|---|---|
| 临时性外部故障 | VIES 接口超时、网络通信异常 | 有限指数退避重试，上限 3 次 | 标注“验证中” |
| 数据格式错误 | 税号校验位不符、法定地址缺项 | 中止流程，转入待修正队列 | 标出缺失字段名称 |
| 跨境规则待确认 | 跨国交易涉及新兴特定税则 | 转入人工复核 | 标注“需确认” |
修正工作台必须直接定位错误字段并支持原地保存；商户处理单张受阻发票的中位耗时目标不超过 2 分钟。
局限
工单分析只覆盖 1 个月内的 15 笔工单；访谈只有 3 位商户，都在德国。
复盘
如果重来，我会在开启拦截之前，先给商户发一份简短指引和规则变更通知。复盘把那部分本可避免的咨询，归因到这项缺失的通知上。
60 秒宣传片