回单、盖章送货单、发票现在靠手工扫描保存，后续查账很麻烦，能否系统化归档？

结论：可以系统化归档。原生电子发票和银行回单保存原始电子文件及元数据，纸质盖章单保存清晰扫描件并保留原件处置规则；每份单据关联订单、客户和会计期间。OCR 只负责提取和检索，不能证明真伪或替代审核。

当前“按日期建文件夹”的问题不只是难搜索，还包括单据与业务脱节、同一文件重复入账、修改后无法发现、权限过宽和到期后不知如何销毁。滚水科技会先区分订单附件、物流回单、银行电子回单、电子发票和纸质扫描件，因为它们的来源、法律效力、保存内容和查验方式不同，不能全部处理成一张 JPEG。

在继续拆分功能、数据与验收场景时，还可以对照 散户和普通餐厅现在靠人工录单，能否减少人工二次录入？；这些内容补充了需要放在同一项决策中考虑的上下文。

可选建设层级如下：

方案	保存内容	可检索和追溯能力	风险	适用结论
共享盘按月份存扫描件	文件与人工命名	只能按目录和文件名找	重复、误删、权限和业务关联薄弱	仅作临时过渡
业务系统附件中心	原文件、订单关系、标签与操作日志	可按客户、订单、金额和状态查找	会计档案规则仍需补齐	业务查单和回单管理优先
电子会计档案体系	原件、元数据、审签、查验、归档与保管规则	支持核算、审计、防重复和长期管理	制度、系统与财务档案协同成本更高	需正式电子归档时采用

财政部、国家档案局的 电子会计凭证归档通知 明确，来源合法真实的电子会计凭证与纸质凭证具有同等法律效力；仅使用电子凭证归档还要求传输存储安全可靠、篡改可发现、系统可完整读取凭证及元数据、具备必要审签并防止重复入账。尤其要注意：收到原生电子凭证后，不能只保存其打印件或截图，原电子文件必须按要求留存。

归档对象应分为不可覆盖的原件、可修订的结构化字段和业务关系。上传时计算文件校验值，记录来源渠道、上传人、时间、文件类型、页数和原始文件名；随后提取发票号码、金额、税号、订单号、运单号等索引字段，再由人工或接口查验。字段修订不改变原件，修改人、旧值、新值和原因进入日志。相同校验值、发票号码或银行交易号触发重复预警，但由财务判断是否确为重复。

入口应贴近责任环节：仓库或业务员在订单/发货单详情上传盖章回单；扫描室可用批次二维码或封面将整批文件关联到任务；电子发票从受控邮箱或接口接收原文件；银行回单优先从银行或财务系统导入。微信转发的压缩图片可以暂存为待处理材料，但不能自动标记为已查验原件。上传失败、页数缺失或图片模糊要当场提示，不要等月末查账才发现。

OCR 对检索有帮助，但要按字段验收。印刷发票、规则表格、盖章覆盖、手写签收和折叠反光的识别难度差别很大。可以使用 PaddleOCR 官方项目 等工具建立基线，但必须用客户自己的设备、纸张和历史样本测量发票号、金额、日期、订单号等关键字段的完全正确率。低置信、金额勾稽不平或订单匹配多个结果时进入人工复核，不把错误自动写入财务事实。

检索权限按业务目的控制。销售只能查自己订单的回单，仓库能上传和查看履约文件，财务查看金额、发票与银行资料，审计在授权期间只读跨部门材料。批量下载、打印和分享链接单独授权并记录；临时链接短期失效，文件在传输和存储时加密。个人身份证、银行账户或签名信息只展示必要字段，不能因为“做档案”就让所有后台管理员可见。

查账页面应从业务对象进入：订单展示合同、付款、发票、出库和签收是否齐全；客户维度查看期间内单据；财务可按发票号、金额区间、会计期间和缺件状态筛选。每月可生成缺失、重复、待查验、待复核和超过处理时限的清单。归档完成后的更正通过新版本或补充材料实现，不静默替换原件。

试点可选一个业务线，覆盖原生电子文件、扫描件、多页、盖章遮挡、重复和错关联样本。验收统计关键字段正确率、自动关联率、人工复核分钟数、缺件发现率、查询耗时、重复入账拦截和权限越权测试；恢复演练要证明文件、元数据和业务关系可同时还原。滚水科技的 AI 订单 OCR 方案 可作为录入模块参考，但正式会计档案制度仍需客户财务、档案和审计负责人确认。