本文内容
Reducto 德语发票提取：测量人工复核成本
证据范围：文档核对日期为2026年10月8日。本文是基于研究的实施指南。下文试点是建议方案，我们没有实际运行这些供应商评测，也没有测量其性能。
Reducto 何时适合德语发票？
当输入是 PDF 或扫描件，而业务流程需要结构化字段时。从真实供应商组合、多页表格和贷项通知单开始。通用文档 benchmark 不能证明应付记录无需修正就能进入 ERP。
Reducto Extract 文档区分完整文档解析与 schema 字段提取，并指出提取无法恢复解析阶段未捕获的值。某一行缺失时，先看解析源，而不是直接改写提取指令。
发票 schema 应保留什么？
Reducto 发票提取示例用数组处理数量不固定的行项目，并说明来源引用。按业务语义定义 schema，不要为预期的每行设置固定属性。当地格式可能改变金额或日期时，在标准化值之外保留原始字符串。
| 输入情况 | 必须检查 | 触发人工复核 |
|---|---|---|
1.234,56 EUR | 转为1234.56并保留明确币种 | 分隔符或币种含糊 |
| 跨页行项目 | 保留全部源行及顺序 | 缺行或重复行 |
| 贷项通知单 | 保留文档类型与符号规则 | 表头及行符号不一致 |
| 混合税类别 | 按类别核对金额 | 合计差异无法解释 |
| 折扣或运费 | 区分行金额和整单调整 | 调整被重复计算 |
| 缺失字段 | 缺失不等于零 | 必需业务值缺失 |
使用十进制运算或整数最小货币单位，并明确约定舍入容差。不要静默修改行金额以匹配表头。账面平衡但被改动的发票，不是成功提取。
XRechnung、ZUGFeRD 应走相同路径吗？
先检查文件是否有结构化发票载荷。存在受支持 XML 时，应直接解析验证，而不是 OCR 视觉表示。KoSIT 验证器项目使用 schema 和 Schematron 验证 XML；正确规则集及版本仍由集成方选择。这是处理路径区别，不是法律合规判定。
嵌入 XML 与可见 PDF 不一致时，要保留原始文件并走人工异常审查。不能默默选择合计更方便的表示。
怎样公平测量人工复核？
准备获准使用、人工标注的语料，按供应商版式、扫描质量、行数及文档类型分层。保留部分供应商或版式不参与调优，以检验泛化。让现有流程与 Reducto 使用相同保留文档和 schema。
- 独立核实行数、字段值与预期合计。
- 固定设置及模型版本，保存用量与来源位置。
- 用一致规则计时人工修正。
- 分开记录关键错误和外观差异。
- 报告无需改动的验收率、修正分钟、处理失败及每张已验收发票的完整成本。
只有完成规定检查才算验收，API 返回 JSON 不算。测量前定义关键字段，供应商、币种、文档身份、合计及付款信息可能需要独立门槛。
减少复核时间有什么经济意义？
示例：1000张发票平均修正两分钟，约需33.3小时；平均三十秒则约8.3小时。差值25小时，还没有扣除 API、异常处理和维护费用。这是假设规划输入，不是 Reducto 实测。
不要仅依据供应商置信度自动验收。先看它能否在自身语料上区分正确和错误字段。来源位置能加快复核，但不能证明金额被正确解释。
什么时候采用 Reducto？
当保留语料显示关键错误可接受、修正工作减少、异常可追溯，并且完整成本合理时。如果原路径已满足要求，就保留它。带上脱敏发票及 ERP 验收规则，规划发票提取试点。
下载建议试点协议（JSON）。其中包含验收用例与空结果字段，不是供应商实测结果。
相关实施指南
pdf-inspector 评测：先本地解析 PDF，再按页调用 OCR. Firecrawl AnyDoc 评测：14 种格式转 AI 可用 Markdown.
已核对的来源
独立性与商标声明: 本页由 Wavect 发布，Wavect 自身也是服务商，因此我们对本页存在商业利益。我们与本页提及的其他公司没有关联，未获得其背书，也不是其合作伙伴；所有第三方公司名称、品牌与商标均归各自所有者所有。关于其他服务商的陈述来自公开可查的来源，主要是其自己发布的页面，以本页标注的核查日期为准，此后可能已经发生变化。做决定前请自行直接核实。本页依据我们所知的情况撰写，并力求保持客观。如果你认为其中有不准确或不公平之处，请写信告诉我们，我们会更正： [email protected]