24 KiB
需求 - 报销发票 OCR 规约
版本:1.0 日期:2026-05-09 状态:模块级开发规约 上级事实源:海音达OA-MVP需求规格说明书 细则来源:报销、发票与附件规则
本规约细化报销、发票、OCR、附件、查重、财务复核、付款和导出的产品要求。后续报销主链路开发必须先从本规约拆分 Issue CSV,再进入技术方案和代码实现。
1. 模块目标与边界
1.1 目标
- 员工能在 PC、手机和企业微信入口快速创建报销、上传发票和附件、提交审批。
- 系统负责 OCR 识别、发票查重、发票与明细匹配、审批流接入和付款归档。
- 财务能复核发票、处理重复例外、标记付款并导出财务台账。
- 报销审批必须进入 OA 统一审批中心,正式记录以 OA 为准。
1.2 暂不做范围
- 不使用企业微信原生审批处理报销。
- 不接入飞书报销、飞书审批或飞书文档归档。
- 首批不做银行自动付款、企业卡自动对账、ERP 自动入账。
- 首批不做复杂预算占用和多币种核算。
- 首批不把企业微信文件作为发票或附件长期主库。
2. 角色与入口
2.1 角色
| 角色 | 可做动作 | 权限边界 |
|---|---|---|
| 员工/申请人 | 创建草稿、上传发票、上传附件、编辑明细、提交审批、查看自己的报销状态 | 只能操作本人可见的报销单和本人上传或授权使用的发票 |
| 审批人 | 查看待办、查看发票和附件摘要、通过、驳回、退回、转审 | 只能处理分配给自己的 OA 审批任务 |
| 财务 | 查看审批通过的报销、复核发票、处理重复例外、标记付款、导出 | 不默认拥有系统管理权限;例外动作必须审计 |
| 财务主管 | 审核高风险或大额报销、审批重复例外、复核付款批次 | 权限应通过角色配置,不硬编码到个人 |
| 管理员 | 维护费用类型、项目、部门、OCR 配置、权限和基础字典 | admin 不代表业务审批权,不能绕过流程直接替员工完成正式审批 |
2.2 入口
| 入口 | 适用场景 | 要求 |
|---|---|---|
| PC 报销列表/详情 | 明细编辑、批量查看、财务复核、导出 | 可查看完整字段、审批历史、发票和附件 |
| 手机报销页 | 上传 PDF 发票、继续草稿、补充附件、提交审批、查状态 | 不使用桌面宽表,操作路径短 |
| 企业微信自建应用 | 手机工作台入口和消息 deeplink | 默认进入 OA 移动端,审批动作仍在 OA 内完成 |
| 票据或发票添加弹窗 | 从报销草稿中添加发票 | 普通员工只看到“添加发票”,不暴露“发票池”等内部概念 |
| 财务导出页 | 财务按期间、人员、项目、状态导出 | 导出前必须校验财务权限 |
3. 报销单对象与字段
| 字段 | 含义 | 必填规则 |
|---|---|---|
| 报销单号 | OA 生成的唯一业务编号 | 提交前或首次保存时生成,必须唯一 |
| 申请人 | 创建报销单的人 | 必填 |
| 实际报销人 | 款项实际归属人员 | 默认等于申请人,可按权限调整 |
| 部门 | 申请人或实际报销人所属部门 | 必填或由系统带出 |
| 项目 | 关联项目、合同或内部事项 | 项目费用建议必填 |
| 费用明细 | 费用类型、日期、金额、说明、关联发票 | 至少一条有效明细 |
| 报销总金额 | 明细金额合计 | 系统计算,用户不可直接篡改 |
| 发生日期 | 费用发生日期或期间 | 明细级必填 |
| 说明 | 报销原因、用途、备注 | 按费用类型决定是否必填 |
| 发票 | 增值税发票、数电票、普通发票等凭证 | 需报销发票的费用必填 |
| 附件 | 支付截图、订单、合同、聊天记录、情况说明等 | 按费用类型或审批要求决定 |
| 审批状态 | 草稿、审批中、已通过等 | 系统维护 |
| 付款状态 | 未付款、已付款、无需付款等 | 财务维护 |
| 审批历史 | 提交、通过、驳回、退回、转审等记录 | 系统维护 |
3.5 费用类型与材料要求矩阵
以下规则是 10 人以下公司试运行建议值,不等于最终公司财务制度。正式上线前可由管理员按公司制度配置,后续实现不得把阈值和材料要求硬编码在业务逻辑中。
| 费用类型 | 是否必须发票 | 是否必须附件 | 是否建议关联项目 | 试运行审批提示 | 常见附件 |
|---|---|---|---|---|---|
| 交通 | 是,打车或公共交通票据 | 金额 >200 元建议补充行程说明 |
项目出行建议关联 | 单笔 >500 元提示主管关注合理性 |
行程单、支付截图 |
| 餐费 | 是 | 金额 >200 元需说明参与人或事由 |
项目餐费建议关联 | 单笔 >500 元进入费用高风险提示 |
支付截图、事由说明 |
| 招待 | 是 | 是 | 必须关联客户、项目或事项 | 默认提示主管和老板关注,>1000 元建议老板审批 |
招待对象、事由说明、支付截图 |
| 办公采购 | 是 | 金额 >500 元需订单或验收材料 |
建议关联部门或项目 | 按采购金额进入审批规则矩阵 | 订单、收货/验收截图 |
| 硬件 | 是 | 是 | 建议关联资产或项目 | >1000 元建议老板审批并登记资产 |
订单、验收、资产信息 |
| 软件订阅 | 是 | 是 | 项目软件建议关联项目 | 周期性订阅需写明周期和使用人 | 订单、订阅截图、合同或报价 |
| 快递 | 是或按实际票据 | 金额 >100 元建议补充寄件说明 |
项目快递建议关联 | 金额较小可走主管审批 | 运单、支付截图 |
| 项目材料 | 是 | 是 | 必须关联项目 | 按采购或费用金额审批 | 订单、验收、项目说明 |
| 差旅预留 | 是,交通/住宿等票据 | 是 | 必须关联出差或项目 | 首批只保留字段和入口,完整差旅单后续拆分 | 行程单、酒店水单、出差说明 |
提交前应根据费用类型做预检:发票、附件、项目、说明和金额阈值缺失时给出可操作提示。普通员工只看到业务语言,不展示内部规则码。
4. 状态模型
4.1 报销状态
| 状态 | 含义 | 主要动作 |
|---|---|---|
| 草稿 | 员工编辑中,未提交 | 编辑、上传、删除草稿、提交 |
| 审批中 | 已提交 OA 审批 | 审批人处理;申请人按规则撤回 |
| 已通过 | 审批完成,等待财务后处理 | 财务复核、付款标记、导出 |
| 已驳回 | 审批否决 | 查看原因、复制重提或新建 |
| 已退回 | 需要申请人修改 | 修改后重提、撤回 |
| 已付款 | 财务已完成付款 | 查看、导出;普通用户不可修改 |
| 已完成 | 报销归档完成 | 查看、归档、导出 |
4.2 发票状态
| 状态 | 含义 | 前端展示 |
|---|---|---|
pending_ocr |
已上传,正在识别 | 识别中 |
available |
可加入报销单 | 可添加 |
bound |
已加入报销单或明细 | 已添加 |
ocr_failed |
识别失败,需要重试或人工处理 | 识别失败 |
archived |
已归档,不可再添加 | 已归档或已报销 |
4.3 附件状态
| 状态 | 含义 | 规则 |
|---|---|---|
| 已上传 | 文件已存储并关联报销单 | 草稿和退回态可删除 |
| 已提交 | 报销提交后随单据进入审批 | 审批人和财务可查看 |
| 已归档 | 报销完成后归档 | 普通员工不可删除 |
附件不是发票,不参与 OCR,不参与发票查重。
5. 发票与明细关系
5.1 匹配规则
- 报销单只有一条明细时,发票自动加入该明细。
- 报销单有多条明细时,优先按发票金额唯一匹配明细金额。
- 金额无法唯一匹配但发票金额存在时,可自动创建一条新明细,并提示用户确认费用类型和说明。
- 发票金额缺失时,不自动创建明细,提示用户先补全发票信息或手工创建明细。
- 一张发票可按业务规则关联一条或多条明细;首批优先支持一张发票绑定一条明细,复杂拆分后续单独设计。
5.2 校验规则
- 报销总金额必须等于有效明细金额合计。
- 发票金额与对应明细金额不一致时,应提示用户确认差额原因。
- 无发票费用必须有业务规则允许,并通过附件或说明补足依据。
- 已归档或已报销的发票不能再加入新的报销单。
6. OCR 规则
6.1 上传与识别
- 产品长期目标允许按 OCR provider 能力扩展图片和 PDF 发票识别。
- 当前试运行验收只开放 PDF 发票进入 OCR;图片文件按普通附件材料处理,不进入发票 OCR 或发票查重。
- 上传成功后必须展示明确状态,不允许长期停留在“上传中”。
- OCR 识别字段至少包括:发票代码、发票号码、数电票号码或等效唯一号、金额、税额、价税合计、开票日期、销方、购方。
- OCR 完成后,添加发票区域自动刷新,并尝试按规则加入报销明细。
- OCR 失败时保留失败原因,允许重试和人工修正。
6.2 人工修正
- 申请人可在草稿或退回态修正自己发票的识别结果。
- 财务可在复核阶段修正关键字段。
- 修正发票代码、号码、金额、开票日期等关键字段必须写入审计日志。
- 修正后必须重新触发查重校验。
6.3 当前试运行 PDF-only 与后续图片能力口径
- PDF 发票是当前试运行、R7E 和 live OCR 的验收基线。
- 图片 OCR 不作为当前验收项,后续如启动必须另拆 P2/UX Issue,并补充样票、隐私处理、provider 能力和回归口径。
- 图片材料可作为支付截图、订单、说明等普通附件上传;附件不参与 OCR,不参与发票查重。
- PDF 可按 provider 能力直接识别或先转图片后识别,但这属于服务端实现细节,不暴露给普通用户。
- 多页 PDF 首批按一份文件处理;若包含多张发票,后续单独拆分能力。
- 文件原件必须保留,OCR 结果只是结构化识别数据。
6.3.1 BIZ8 图片 OCR 可行性设计
BIZ8 阶段的图片 OCR 结论是“技术可行,但当前不开放为正式能力”。国内主流 OCR provider 已支持图片或 PDF 发票识别,例如腾讯云 VatInvoiceOCR 支持 PNG/JPG/JPEG/PDF 并通过 IsPdf 区分 PDF,阿里云 RecognizeInvoice 支持图片、PDF、OFD 等格式,百度智能云增值税发票识别支持 image/url/pdf_file/ofd_file 输入。以上只作为 provider 能力调研依据,不改变 hyb-oa 当前 PDF-only 验收口径。
启动图片 OCR 前必须满足以下条件:
| 条件 | 要求 |
|---|---|
| 样票授权 | 先完成脱敏样票授权,仓库不得提交真实票据原件、身份证号、手机号、银行卡或公司敏感报价 |
| provider 选择 | 优先复用现有腾讯云 OCR SDK 和字段归一化链路;阿里云或百度只作为后续替代方案,需另写 SDK、计费、字段映射和回滚说明 |
| 入口控制 | 不恢复拍照直传或 HTML capture 作为默认发票入口;若试验图片发票,必须使用明确的受控入口、feature flag 和可回滚配置 |
| 文件规则 | 图片发票只允许明确白名单格式,文件大小、分辨率、页数和错误提示必须与 provider 限制一致 |
| 字段规则 | 识别后仍按发票代码、发票号码、数电票号码、金额、开票日期、销方、购方等统一字段进入查重和人工复核 |
| 审计规则 | 图片 OCR 结果、失败原因、人工修正、重复例外、附件下载和敏感操作继续写审计摘要 |
| 验收规则 | mock OCR、真实 provider、pending、失败重试和人工复核结论分开记录;无授权样票时只能 SKIP 真实图片 OCR,不得标记 PASS |
推荐技术路径:
- 保持 PDF-only 上传校验和现有页面文案不变。
- 在非生产环境用脱敏样票验证现有腾讯云
image_native分支和字段归一化结果。 - 若真实图片样票通过率和失败可解释性达标,再另开 BIZ8 后续行或 BIZ9 开发入口。
- 开发时只放开发票图片入口,不改变附件图片作为普通材料的规则。
- 回滚时关闭 feature flag、恢复 PDF-only allowlist,已上传图片发票按识别失败或人工复核记录处理,不自动转为附件。
参考链接:
- 腾讯云增值税发票识别:https://cloud.tencent.com/document/api/866/36210
- 阿里云增值税发票识别:https://help.aliyun.com/zh/ocr/developer-reference/api-ocr-api-2021-07-07-recognizeinvoice
- 百度智能云增值税发票识别:https://cloud.baidu.com/doc/OCR/s/nk3h7xy2t
6.4 发票合规与人工复核
首批发票合规采用 OCR + 查重 + 财务人工复核。不接自动验真接口,不依赖新增付费服务或第三方验真能力;自动验真进入后续 backlog。
| 校验项 | 首批规则 | 异常处理 |
|---|---|---|
| 公司抬头 | OCR 识别购方名称后与公司抬头或可报销抬头清单比对 | 不一致时提示申请人确认,提交后财务重点复核 |
| 税号 | OCR 识别购方税号后与公司税号比对 | 不一致时提示并进入财务人工复核 |
| 发票代码+号码 | 用于传统发票唯一性判断 | 缺失时允许人工补录,补录后重新查重 |
| 数电票号码 | 用于数电票唯一性判断 | 缺失时允许人工补录,补录后重新查重 |
| 价税合计 | 用于明细匹配和金额校验 | 与明细不一致时提示差额原因 |
| 开票日期 | 用于期间筛选和超期提示 | 超过公司允许周期时提示财务关注 |
| 销方信息 | 作为财务复核参考 | 异常供应商由财务人工判断 |
| 红冲/作废 | 首批由财务人工标记 | 标记后不可进入普通报销流程 |
人工复核状态建议使用:待复核、人工通过、人工驳回、例外通过。人工复核必须记录复核人、复核时间、复核结论和原因;关键字段被修正后必须重新查重。
7. 查重规则
7.1 查重维度
公司级查重按以下优先级执行:
- 文件
file_sha256相同。 - OCR 后
invoice_code + invoice_number相同。 - 数电票号码或其他官方唯一号码相同。
- 后续接入电子发票验真时,使用官方验真结果补充判断。
7.2 不可添加场景
- 同一公司已有相同可用发票。
- 同一公司已有相同发票正在识别。
- 同一公司已有相同发票识别失败。
- 同一公司已有相同发票被他人上传。
- 同一公司已有相同发票处于已添加、已归档或已报销状态。
- 发票已经被其他报销单、差旅单或归档流程占用。
7.3 重复例外
- 普通员工不能强制添加重复发票。
- 确需例外时,只能由授权财务或财务主管处理。
- 例外必须记录原报销单号、重复原因、处理人、处理时间和附件依据。
- 例外处理不得绕过 OA 审批和财务复核。
8. 附件规则
附件用于补充业务事实,包括支付截图、订单、合同、聊天记录、情况说明、验收材料等。
- 发票/OCR 上传仅支持 PDF;附件材料可继续支持 PDF、JPG、PNG、WEBP。
- 支持多文件上传。
- 不参与 OCR。
- 不参与发票查重。
- 草稿和已退回状态允许上传、查看、删除。
- 审批中、已通过、已付款、已完成状态原则上不允许普通员工删除。
- 审批人和财务在处理报销时可查看附件。
- 涉密合同正文、敏感报价、身份证、银行卡等高敏材料不得随意进入公网 OA;确需上传时必须另行定义脱敏和权限规则。
9. 财务动作
| 动作 | 前置条件 | 结果 |
|---|---|---|
| 财务复核 | 报销已通过或进入财务复核节点 | 检查发票、附件、金额、项目和审批历史 |
| 重复例外 | 发现重复但业务确需报销 | 记录原单号、原因和处理人,写入审计 |
| 付款标记 | 审批通过且复核通过 | 写入付款批次号、付款时间、付款人、付款备注和状态 |
| 取消付款标记 | 发现误操作且有权限 | 必须填写原因并审计,首批可只允许管理员或财务主管 |
| 导出 | 有财务导出权限 | 按期间、人员、项目、状态导出报销和发票摘要 |
导出字段至少包括:报销单号、申请人、实际报销人、部门、项目、费用类型、明细金额、发票号码、开票日期、审批状态、付款状态、提交时间、通过时间、付款批次号、付款时间、付款人、付款备注、导出批次号、导出人、导出时间。
9.1 电子档案与归档包
报销进入已付款或已完成后,应形成可追溯归档包。归档包不是新入口,而是报销详情、财务导出和后续审计必须能串起来的数据集合。
| 归档内容 | 要求 |
|---|---|
| 报销单快照 | 包含报销单号、申请人、实际报销人、部门、项目、明细、金额、状态和提交时间 |
| 发票原件 | 保留上传的 PDF 原件,不以 OCR 结果替代原件 |
| OCR 结果 | 保留识别字段、识别状态、失败原因和人工修正记录 |
| 附件 | 保留支付截图、订单、合同、聊天记录、情况说明等非发票材料 |
| 审批历史 | 保留提交、通过、驳回、退回、撤回、转审和处理意见 |
| 付款记录 | 保留付款批次号、付款人、付款时间、付款备注和取消付款原因 |
| 导出记录 | 保留导出批次号、导出人、导出时间、筛选条件和导出摘要 |
| 审计日志 | 保留重复例外、人工复核、附件下载、字段修正、权限变更等敏感动作 |
归档后普通员工不可修改核心字段。确需财务修正时,必须追加修正记录,不覆盖原始归档事实。
10. 异常规则
| 异常 | 处理规则 | 用户提示 |
|---|---|---|
| 无发票 | 按费用类型判断是否允许;不允许则阻断提交 | “该费用类型需要添加发票” |
| 重复发票 | 普通流程阻断;财务例外需留痕 | “该发票已存在或已报销,不能重复添加” |
| 他人上传发票 | 阻断普通员工使用 | “该发票已被其他人员上传,请联系财务确认” |
| 金额不一致 | 提示差额,必要时阻断提交 | “发票金额与明细金额不一致,请确认” |
| OCR 失败 | 允许重试或人工录入;提交前必须满足关键字段要求 | “识别失败,请重试或手工补全信息” |
| 识别中提交 | 若关键字段未完成,不允许提交 | “发票仍在识别中,请稍后再提交” |
| 附件缺失 | 按费用类型、金额或审批要求判断 | “请补充必要附件” |
| 已付款后修改 | 普通用户不可修改;财务修正必须审计 | “已付款报销单不可修改” |
| 文件上传失败 | 不生成空附件或空发票记录 | “上传失败,请重新上传” |
| 通知失败 | 不影响报销提交或审批结果 | 管理员在通知记录中查看失败原因 |
11. 审批与通知边界
- 报销提交后进入 OA 统一审批中心。
- 审批动作包括通过、驳回、退回、撤回、转审和查看历史,规则以 需求 - 统一审批中心规约 为准。
- 报销审批链、直属主管、老板/总经理、自审禁止、
manager、ceo、admin的角色口径,以统一审批中心规约为准;本规约不重复维护第二套审批事实源。 - 企业微信消息只包含脱敏标题、报销单号、状态和 OA deeplink。
- 消息中不得包含完整发票图片、合同正文、银行卡、身份证、敏感报价或大段说明。
- 企业微信通知失败不阻断报销提交、审批或付款标记。
12. 验收场景
12.1 验收数据集
后续拆开发 Issue 和自动化测试时,优先使用以下固定样例,避免每次临时造数导致验收口径漂移。
| 数据 ID | 角色/对象 | 样例数据 | 用途 |
|---|---|---|---|
| U001 | 员工张三 | 普通员工,部门为研发部,直属主管为李四 | 创建报销、查看本人单据 |
| U002 | 主管李四 | 研发主管,具备审批张三单据权限 | 主管审批、退回、驳回、转审 |
| U003 | 财务王五 | 财务角色,具备人工复核、付款、导出权限 | 发票人工复核、重复例外、付款导出 |
| U004 | 老板赵六 | 总经理角色,处理大额和高风险事项 | 大额报销、采购和合同最终审批 |
| R001 | 交通费 | 100 元,发票完整,单明细 | 低金额报销直达主管审批 |
| R002 | 办公采购 | 2000 元,含订单附件,关联项目 | 主管 + 财务复核场景 |
| R003 | 硬件采购 | 6000 元,含发票和验收附件 | 主管 + 老板 + 财务复核场景 |
| INV001 | 正常发票 | 抬头税号匹配,金额 100 元,未重复 | OCR、查重、自动匹配 |
| INV002 | 重复发票 | 与已报销发票号码相同 | 重复阻断和财务例外 |
| INV003 | 异常发票 | 抬头或税号不匹配 | 人工复核和驳回 |
| FILE001 | OCR 失败文件 | 无法识别 PDF 或未来图片 OCR 样本 | 失败重试和人工补录 |
| ATT001 | 支付截图 | 非发票附件 | 附件上传、查看、归档 |
| 场景 | 步骤 | 预期结果 |
|---|---|---|
| 上传 OCR 并添加 | 员工创建草稿,上传 PDF 发票,等待 OCR 完成 | 发票从识别中变为可添加或已添加,识别字段可查看 |
| PDF 上传 | 员工上传 PDF 发票 | 文件保留,OCR 状态明确,失败时可重试或人工修正 |
| 单明细自动匹配 | 草稿只有一条明细,添加发票 | 发票自动绑定该明细 |
| 多明细金额匹配 | 草稿有多条明细,发票金额唯一匹配其中一条 | 发票自动绑定匹配明细 |
| 无法匹配创建明细 | 发票金额存在但无唯一明细 | 系统创建新明细或提示用户确认 |
| 提交审批 | 员工补齐明细、发票、附件后提交 | 报销进入 OA 审批中,生成审批历史和待办 |
| 审批通过到付款 | 审批人通过,财务复核并标记付款 | 报销状态进入已通过或已付款,付款记录可追溯 |
| 财务导出 | 财务按期间和状态导出 | 导出包含报销、发票、审批和付款摘要字段 |
| 重复阻断 | 员工上传已报销发票 | 系统阻断添加并显示可理解原因 |
| 重复例外 | 财务主管处理特殊重复票据 | 记录原单号、原因、处理人和审计日志 |
| OCR 失败处理 | 上传无法识别文件 | 显示失败原因,允许重试或人工补全 |
| 附件上传查看 | 员工上传支付截图,审批人查看 | 附件不参与 OCR 和查重,审批人可查看 |
| 移动端上传 | 企业微信或手机浏览器上传发票和附件 | 移动端无桌面宽表,上传、OCR、提交路径可用 |
13. 后续开发拆分建议
后续实现时建议按以下 Issue 拆分:
- A1:报销单字段与状态收口,覆盖草稿、提交、退回、驳回、已通过、已付款、已完成。
- A2:发票上传、OCR 状态刷新和失败重试。
- A3:发票查重与重复例外处理,覆盖
file_sha256、发票代码号码、数电票号码。 - A4:发票与明细自动匹配、金额不一致提示和人工修正。
- A5:附件上传、查看、删除和归档权限。
- A6:报销接入统一审批中心,覆盖 PC、移动端、企业微信 deeplink。
- A7:财务复核、付款标记、取消付款标记和导出。
- A8:报销主链路回归脚本和 Playwright PC/移动/企业微信 UA 验证。
- A9:费用类型与材料要求矩阵落地,覆盖提交前预检和员工可理解提示。
- A10:发票合规与人工复核落地,覆盖抬头税号、数电票号码、红冲/作废人工标记。
- A11:电子档案归档包落地,覆盖报销单快照、发票原件、OCR 结果、附件、审批、付款、导出和审计追溯。
涉及发票唯一性、付款状态、审批状态机、财务权限或文件存储规则的 Issue,必须在技术方案中写明回滚策略、数据修复策略和回归范围。