一张供应商账单只有在人工确认后才能成为应付账款数据

申报文件并不是财务团队唯一要打交道的纸质材料。供应商账单、采购订单、收据，也就是应付账款的日常流转，出现的频率丝毫不低，却往往因为没人有时间逐行核对而受到更少的信任。Rexfin 把它用在已申报报表上的那种直觉，任何数值都必须能指回它的来源，同样用在了这一堆文档上。只是它不会假装这个结果拥有同样的分量。

同样的纪律，不同的文档

一张账单、采购订单或收据会经过与申报文件相同的上传流水线，但提取方式是通用型的，而不是按发行方逐一匹配的档案：这里没有申报结构可以对照，只有供应商自己的发票排版。产出的记录分为四个层级：交易方、单据头、行项目、税务行，对应一张标准发票实际承载的字段：供应商名称与税号、发票号和日期、逐行的数量与单价，以及按税率拆分的增值税明细。银行对账单单独处理，完全不在这套提取范围之内，交易行不是行项目，而且对账单通常以结构化文件形式出现，需要的是确定性解析器，而不是逐字段阅读。

每个值都带着来源，绝不只是一个数字

一张被提取的账单上，没有任何一个值是裸露的。每一个末端字段，供应商名称、行合计、税率，都带着数值本身，以及它是从哪一页、哪个边界框读取出来的、一个置信度分数，以及是哪个提取器生成的。这个置信度分数是参考性的，不是信任等级：一个以 0.99 置信度读取的字段，其可信程度依然完全取决于这份文档的整体审核状态，这与申报文件所遵循的多后端提取一致性是同一套纪律。

提取本身按优先级顺序运行：首先尝试匹配该供应商的已知模板，这一步是确定性的，完全不涉及模型;若不成功，则改用一个具备视觉能力的模型进行按模式驱动的读取;再之后是一个单独的定位环节，负责在渲染出的页面上找到每个被提取字段的位置，使其拥有真正的边界框，而不是一个猜测出来的值。任何无法在页面上定位的字段，都会带着低置信度标记呈现出来，而不是伪装成一个看起来自信的占位值。

由人来确认，而不是由分数来确认

提取产出的是一份草稿，不是事实。每一张被提取的账单都处于一个隔离的“已提取”状态：可见、可以钻取回溯到源页面，但不能作为数据使用，直到有人审核并确认它，或将整份文档驳回。确认这一步刻意设计为按整份文档进行，而不是按字段逐一进行：有人对照源页面查看提取出的字段，纠正错误的地方，一次性签字确认。驳回必须附带理由，所以一份被舍弃的读取结果依然会留下轨迹，而不是就此消失。在这两种结果发生之前，总额会先经过一次合理性检查，净额加税额应等于总额，各行项目应能加总到合计数，这会作为一个提示标记呈现给审核者，而不是一次静默拦截。

一份经过更正重新提交的文档，比如供应商修订过的发票或一张贷方通知单，绝不会覆盖原始记录。它以自己独立的上传和独立的提取结果出现，通过一条替代链条追溯回原始记录，让最新确认的版本生效，同时不抹去之前存在的内容。这与对照打印总额进行对账背后的原则是一致的：只向前修正，绝不原地改动。

为什么它永远不会成为一个引用来源

即便完全经过确认，一张被提取的账单也有一个不可逾越的上限：它是未审计的内部数据，在它出现的每个地方都会带上这个标记，而且它在结构上根本无法像申报文件里的数字那样携带引用，因为压根就没有这样一个字段。这不是一个日后要补上的缺口，而是对“一张发票经过单次确认读取实际是什么”的诚实归类，区别于决定申报文件中什么才算可引用的多后端一致性门槛。一张确认过的账单是真实、有用、可审核的应付账款数据，按供应商统计的支出、按类别统计的支出，只是它从不被要求假装自己是申报文件里那种必须独立赢得信任的数字。

想了解提取、确认与引用在整个平台中如何协同运作，请见产品导览主页。