一张申请，可以同时有两类问题
假设一项内部活动的已配置额度为 400 元，三条报销明细为 120 元、80 元和 260 元，合计 460 元，而申请表总额填写了 450 元。这时应分别提示“明细与总额相差 10 元”和“明细合计高于示例额度 60 元”。400 元只是本例规则，不是通行标准。
第一项是数据一致性问题；第二项需要查看适用范围和例外审批。两者不能合成一个含糊的“审核不通过”，更不能据此认定申请人存在不当行为。
| 检查项 | 依据与结果 | 处理去向 |
|---|---|---|
| 金额一致性 | 120＋80＋260＝460，与填写的 450 不一致 | 请申请人核对明细或表头 |
| 示例活动额度 | 460−400＝60 元 | 检查规则是否适用及是否有例外批准 |
| 资料完整性 | 活动用途、日期、票据和参加人员说明 | 缺哪一项就列明哪一项 |
先把制度变成可以执行的规则
每条检查应记录规则编号、适用部门或费用类型、生效日期、计算口径和负责人。例如“按每次活动”“按每天”与“按每人”是不同上限，不能只存一个数字。跨币种费用还要明确采用哪个已确认的汇率，原币金额始终保留。
规则变化后保存新版本，已经处理过的申请仍能回查当时依据。遇到规则描述不完整的情形，应输出“规则待确认”，而不是由程序猜一个最严格的解释。
重复提示也需要看到证据
同一张票据被拍了两次，文件名和图片内容可能不同；同一天同金额的两张票据也可能都真实存在。系统可以按票据标识、金额、日期和来源寻找疑似重复，把相关文件并排展示，由审核人确认是否为同一支出。
如果申请被退回补资料，再次提交应关联原申请编号及新版本，不能新增一笔互不关联的付款候选。识别字段、申请人填写值和审核后确认值分别保留，避免修改时覆盖原始依据。
状态要对应实际发生的动作
可采用“草稿→待补资料或待审批→审批通过→待付款→付款已确认”的主流程。审批拒绝或申请撤销应进入对应结束状态，不生成付款任务；退回补充则保留原申请编号继续处理。预检查通过只是进入审批的条件之一。审批通过不等于钱已支付；付款已确认应关联实际付款凭据和确认人。
退回时明确指出问题所在，例如“明细第 3 行缺用途说明”，比“信息不完整”更容易处理。超限例外可以附批准记录继续流转，但不应靠把金额改小来绕过规则。
怎样验收这个小工具
- 用本例数据得到 10 元金额差异及 60 元额度提示，且分别展示。
- 一条不适用本部门的规则，不对该部门申请触发错误结论。
- 补件后保留旧版本和处理意见，不重复生成付款任务。
- 疑似重复项能打开两份来源，允许有依据地排除。
- 审批通过但没有付款确认时，状态仍为待付款；被拒绝或撤销的申请不会生成付款任务。
第一版交付宜包含申请表、预检查结果和补件入口。把这些常见来回沟通缩短后，再考虑与实际财务系统的导入流程对接。