Meridian Apparel 是一家中型消费品品牌，原料来自多个地区的海外工厂。每一批进来的供应商发票，在数据流入财务和库存系统之前，都要由两到三名采购分析师与公司的未结 PO 数据库和供应商主数据清单进行核对。主工作簿中的错误会直接级联到由 CFO 审阅的报告包中。
分页断裂、合并单元格和被埋藏的 PO 编号正在悄无声息地破坏主工作表
在每个月的周期中，团队要处理数十张发票，每张最多包含 50 条明细行——这些发票以扫描 PDF、原生数字文件以及带有合并单元格布局的 Excel 工作簿形式到达。合并几乎完全依赖人工：打开每张发票，目视解析，逐行手工录入。
三种故障模式相互叠加。分页断裂会产生数量为空的孤立 SKU——这些记录看起来完整，但结构上已经损坏。供应商的 Excel 模板使用合并单元格，导致空白行，而分析师对这些空白行的补录方式并不一致。供应商把 PO 参考号埋在自由文本表头里——“Re: Your order 45992-A”——会触发 PO 未匹配标记，并引发单独的更正流程。数学对账能捕获大约 90% 的分行 OCR 错误，但那已经是在数据录入完成之后了。随着季节性扩产，需要接入三到五家新工厂，以及一项将付款条款从 net-45 压缩到 net-30 的财务计划，原本非正式的扩展模式被打破：现在发票批次必须在一个工作日内完成校验。
Energent.ai 成为了端到端的合并流水线
团队评估了一个扩展版 Excel 宏套件和一个独立的 OCR 点解决方案。两者都把采集和校验当作彼此分离的步骤；两者都无法将提取值与供应商主数据或未结 PO 数据库进行对账。Energent.ai 在一次完整的 agent 会话中处理了整个流程：
- 按文本层存在情况路由每份文档——原生 PDF 直接处理，扫描 PDF 通过视觉提取——消除了坐标漂移
- 跨分页提取明细行，以表头而非页边界为锚点
- 对合并单元格列进行向前填充——工厂名称、款号、PO 编号——以符合供应商意图
- 通过对完整文本块进行正则匹配恢复被埋藏的 PO 编号，并用
source: text_recovery标记恢复值 - 在追加前执行两阶段校验：阶段 1 规范化日期和数值字段；阶段 2 匹配供应商主数据、验证未结 PO，并执行行级和发票级数学校验
- 按失败代码暂存异常——
vendor_unmatched、math_fail、po_not_found、confidence_below_85pct——放入专用选项卡，而不触碰已验证数据
没有定制 OCR 流水线。没有单独的校验脚本。也无需维护脆弱的宏套件。
校验被前移到主工作表追加之前
- 85% 的置信度门槛。 低于阈值的记录永远不会进入主工作表——它们会连同失败原因一起进入暂存选项卡。
- 先做数学校验，而不是事后补做。 行级和发票级对账作为自动化流水线的一部分运行，在损坏工作簿之前就能捕获约 90% 的分行错误。
- 与格式无关的路由。 扫描 PDF、原生 PDF 和 Excel 工作簿都在同一个会话中运行；文档类型决定提取路径，而不是分析师的判断。
- 带注释的异常队列。 每条被标记的记录都带有具体的失败代码，用一个有优先级的审核列表取代了非正式的临时更正。
每批两到三个人日的分析工作减少为仅异常审核
- 过去，每批 10 张发票、每张包含 30 到 50 条明细行时，需要两到三个人日；现在，凡是通过阶段 2 对账的记录都可直接处理，无需分析师介入
- 向前填充规范化和正则 PO 恢复，消除了所有供应商模板格式中的两类静默提取错误
- 带标签的暂存选项卡——每条异常都附有具体失败代码——用清晰、可执行的队列取代了非正式的更正流程
“变化在于，我们不再把校验当作数据录入之后才发生的事情。异常会放在一个暂存选项卡中，并已附上原因——在我们动手之前，就能准确知道要修什么以及为什么要修。” — Priya Sharma，Meridian Apparel 采购运营负责人