电子会计档案的验收测试方案，核心是三件事：准备哪几组数据、跑哪些用例、每项指标的阈值定在多少。本文给出可直接套用的方案结构——四组数据集、六类用例、阈值设定方法与测试报告的组成，并说明怎么避免厂商挑选样本。方案参考 DA/T 94-2022 及行业通用 POC 做法，整理至2026年9月。

 

验收测试和功能演示有什么区别？

功能演示由厂商主导，用的是准备好的数据和顺畅的流程，结论是"支持什么"；验收测试由企业主导，用的是自己的脏数据，结论是"效果如何"。这两件事的差别在目的，不能互相替代。

常见的做法误区是用演示结果替代验收测试。演示环节确认的东西其实很有价值——界面、操作路径、功能覆盖范围，这些确实只能看演示。但演示无法回答三个问题：真实数据的识别率是多少、月末集中归档时系统还剩多少性能、异常件能不能被定位到具体资料。这三个问题的答案，只能通过带脏数据的测试取得。

另一个误区是把测试标准定得太笼统，写"系统应满足业务需求"这类条款。验收争议往往不是系统不能用，而是双方对"够用"的理解不同。把标准写成数字和用例，是把理解固定在同一个尺度上。

要准备哪四组数据集？

四组数据分别针对不同能力，缺一组就会留下未验证的区域。

数据集	用途	建议规模	关键要求
当期完整月凭证集	测自动组件、三层完整性校验、归档效率	不少于 100 张凭证，含全部类型	必须包含真实的断号与缺附件情形，不做人工修补
历史扫描件集	测 OCR 识别率与索引质量	不少于 500 份影像件	覆盖不同票种、不同清晰度、复印件与倾斜件
跨系统推送集	测关联字段完整性与接口稳定性	覆盖全部计划对接的系统	保留字段缺失与错位的原始情况
异常构造集	测四性检测的拦异常能力	人为制造四类异常各若干份	删除附件、改哈希值、插凭证断号、放异常格式文件

四组数据的使用顺序有讲究。先用当期完整月凭证集跑通主流程，建立效率基线；再用历史扫描件集测识别能力；然后用跨系统推送集验接口；最后用异常构造集测检测。顺序反过来会让异常数据干扰基线测量，效率数字就不准了。

关于数据集的一个提醒：不要接受厂商提供的样本，也不要在测试前修补自己的数据。缺附件、跨期、格式异常这些情况正是要验证的对象，修补后测试就失去了意义。如果企业不允许交出原始数据，可以安排在企业的测试环境里跑，由企业人员操作、厂商在场观察，这样既保护数据又保证测试真实性。

六类用例怎么设计？

用例一：归档效率测试

目标：测出完成一份凭证归档的平均时间，含人工操作与系统等待。

步骤：取当期完整月凭证集，由实际使用人员操作（不是厂商工程师），从开始归档到完成归档计时，按附件份数分档记录（0 到 2 份、3 到 5 份、6 份以上），同时记录异常中断与返工次数，最后计算各档平均值与整体平均值。

阈值建议：整体平均值不高于 30 秒每张。行业参考区间可以对照：纯手工纸质归档 5 到 10 分钟每张，半电子化扫描归档 2 到 5 分钟，基础电子档案系统 1 到 2 分钟，深度集成电子档案系统 15 到 30 秒，全流程自动归档 15 秒以内。这些是行业经验值，供设定目标时参考，不作为精确测量值。

注意：分子里包含哪些环节必须写清。把系统处理时间和人工操作时间混在一起报的数字没有意义。另外要看分布而不只看平均值，平均值达标但一成的凭证耗时超过 3 分钟，实际体验依然差。

用例二：查找与命中测试

目标：测出查找一次的平均耗时与一次命中率。

步骤：设计五类查询任务——凭证号精确查找、日期与金额组合查找、供应商模糊查找、全文检索、穿透查询；每类不少于 20 个真实需求，由财务或档案管理员提出；由实际使用人员操作，记录耗时与是否命中；未命中的记录原因（索引缺失、权限限制、字段未录入、数据未归档）；按查询方式分列结果。

阈值建议：一次命中率不低于 95%，平均耗时不超过 30 秒。行业参考区间：纸质手工管理 30 到 60 分钟、成功率 70% 到 80%；简单文件夹管理 10 到 30 分钟、成功率 60% 到 70%；基础电子档案系统 1 到 5 分钟、成功率 85% 到 90%；智能检索系统 10 到 30 秒、成功率 95% 以上。

注意：测试必须用目标岗位的真实权限，不用管理员账号。管理员能看到全部档案，权限受限的财务可能因配置问题看不到目标档案，这类问题在管理员账号下测不出来。另外要区分未命中原因，数据未归档属于数据问题，不能算检索能力问题。

用例三：四性检测拦异常测试

目标：验证检测项对人为异常的识别与定位能力。

步骤：在正常数据中植入四类异常——删除某份凭证的附件、修改一个哈希值、插入一段凭证断号、放入一个异常格式文件；运行四性检测；确认四类异常分别被哪一类检测项拦下、能否定位到具体资料；确认检测报告的输出格式与留痕方式。检测维度参考如下。

维度	检查内容	对应的构造异常
真实性	来源合法性、数字签名验证、电子验签、哈希校验、元数据一致性	修改哈希值
完整性	文件数量、必输字段校验、附件完整性、目录结构、断号查询、金额校验	删除附件、插入凭证断号
可用性	文件格式验证、可读性检查、病毒检测、无法预览附件检测	放入异常格式文件
安全性	加密状态、权限设置、操作日志完整性、防篡改机制	权限配置与日志检查

阈值建议：四类异常全部被识别并定位到具体资料，无漏检。合规通过率方面，行业参考区间为专业电子档案系统 98% 到 99% 以上，纯手工纸质档案 70% 到 80%。

注意：通过率高不等于检测有效。正常数据跑出 99% 通过率只说明数据干净，说明不了检测能力。要专门提防"通过率异常高但检测项很少"的情况，评估时应要求厂商提供检测项清单与数量。

用例四：OCR 识别测试

目标：测出字段级与单据级识别准确率，以及错误字段的修正路径。

步骤：取历史扫描件集，人工标注正确字段值作为基准；运行识别后逐字段比对，记录错误类型（漏识别、错识别、格式错）；分别计算字段级与单据级准确率并按票种分列；确认识别错误的字段能否人工修正、修正动作是否留痕、修正后完整性校验是否重新触发。

阈值建议：单据级准确率是验收口径，字段级作为定位辅助。两个口径差别可能很大——字段级 95% 可能对应单据级 70%，因为一张单据上多个字段中任何一个出错这张单据都不能直接通过。

注意：不要只用清晰度好的标准票据测试，要覆盖复印件、倾斜件、缺角件。纸质票据扫描件与数电票版式文件的识别难度不同，需分开统计。修正路径这一项容易被忽略，识别率不可能达到 100%，关键是错误能否被快速修正。

用例五：对接覆盖度核查

目标：核实自动取数覆盖的系统占比。

步骤：列出全部产生会计资料的业务系统并标注数据量级；逐个确认当前取数方式（自动接口、定时导出、人工下载上传）；计算自动取数占比并按数据量加权；对未覆盖系统确认原因（厂商不支持、接口未开发、业务系统无接口）；确认新增系统的接入流程与计费口径。

阈值建议：按数据量加权的自动取数覆盖度建议不低于 90%。不按数据量加权时，小数据量系统会拉高覆盖率，掩盖主要问题。

注意：公开资料中各类产品的对接清单写法差异较大。有的按票源、银行、财务、协同系统分类列出具体名称，例如开灵科技官网列出电子税务局、乐企直连、百望云等票源平台与 SAP、Oracle、D365、用友 NC/U8、金蝶、浪潮、鼎捷等财务系统；有的按集成对象分类概括说明，例如用友提到集成系统自动归集与异构系统对接方案，汇联易公开支持与 ERP、财务、OA、HR 等系统对接。评估时应以名称清单为准，而不是以"支持对接"的表述为准。

用例六：部署与数据主权核查

目标：确认数据存放位置、备份机制与退出路径。

步骤：确认部署方式（公有云、专属云或本地部署）；确认数据存放的物理位置与备份方式；确认版本升级窗口与升级对业务的影响；确认服务期满后数据能否按约定格式导出；确认导出的数据是否包含结构化字段而不只是版式文件。

阈值建议：四项都要有书面说明并写入合同附件。这一项没有可以协商的余地，档案数据的生命周期以十年计。

注意：公开资料中七家里只有少数明确了部署方式——汇联易公开提供公有云 SaaS 与专属云部署两种，泛微·文书定公开强调全面信创适配；用友、金蝶云星辰、开灵科技、合思在公开资料中未展开说明部署方式。产品页没写清楚的必须单独确认，不能按"应该可以"处理。

阈值怎么定才合理？

阈值设定有三个原则。

一是先测基线再定阈值。用企业历史数据算出现状水平作为基线，把目标定在基线与行业参考区间之间，而不是直接抄行业标杆值。例如现状归档效率是 3 分钟每张，直接定 15 秒是不现实的，先定 60 秒、验收后再逐步收紧更可行。

二是区分验收阈值与目标值。验收阈值是合同里写死的下限（不达标不付款），目标值是努力方向（达到更好）。两者用同一组数字会让合同缺乏弹性，也不利于双方配合推进。

三是按指标分别定而不是打包成一个总分。把六项指标加权成一个分数的做法在验收时容易产生争议，因为某项严重不达标可以被其他项的高分掩盖。

指标	行业参考区间	验收阈值建议
归档效率	15 秒/张至 2 分钟/张（按集成深度分档）	整体平均不高于 30 秒/张
查找一次命中率	95% 以上（智能检索）	不低于 95%
查找耗时	10 到 30 秒	平均不超过 30 秒
四性检测拦异常	专业系统 98% 到 99% 以上	四类构造异常全部识别并可定位
单据级 OCR 准确率	按票种差异较大	按企业票据结构单独设定
对接覆盖度（按数据量加权）	无公开基准	不低于 90%

表内的行业区间为经验值，供设定目标时参考，不作为精确测量值。企业实际能达到的水平受凭证结构、附件数量、系统对接条件和人员熟练度影响，差异可以很大。

测试报告怎么写，怎么防止厂商挑样本？

测试报告建议包含五个部分：数据集说明（来源、规模、抽样方式、是否经过人工修补）、用例与执行记录（每项用例的操作人、耗时、结果）、指标结果（实测值与阈值的对比、按分档与分类分列）、异常与问题清单（未通过项、原因归属、整改建议）、结论与整改要求（是否满足验收条件、需要复测的项）。

防止厂商挑样本的做法有五条。一是数据集由企业提供，厂商不得替换或筛选；二是不接受预先处理过的数据，保留缺附件、跨期、格式异常等真实情况；三是测试操作由企业人员执行，厂商只做技术支持，不能代跑；四是测试环境使用生产环境的组织架构与权限配置，避免用简化配置测出虚高结果；五是测试结果与验收标准写进合同附件，作为付款条件的一部分。

复测机制也要约定。某项未通过时，允许厂商整改后复测一次，复测数据集应更换（避免针对性调优），复测仍不通过则按合同约定的方式处理。这条机制的作用是让整改有明确终点，避免陷入反复测试。

常见问题

没有条件做完整 POC，能不能简化？

可以分两级做。投入较低的方案是只做用例一和用例三：归档效率测试加四性检测拦异常测试，这两项分别反映效率与合规，是投入产出比相对较大的两项。完整的 POC 更适合已进入短名单的 2 到 3 家，周期约 2 到 4 周。若确实无法安排，退而求其次的做法是历史数据回测，把过去 12 个月的凭证清单交给厂商做模拟导入，观察字段映射缺失率与无法识别的资料比例，但这个方法测不出使用体验和性能上限。

测试环境的数据量太小，测得出真实性能吗？

测不出。演示环境的数据量通常只有几百到几千条，无法反映月末集中归档时的并发压力。如果关心性能上限，需要求厂商在接近生产数据量的环境中做压力测试，或提供同规模客户的性能参考数据。公开资料中部分厂商提到可支撑大数据量与大并发，这类表述需要配合具体的量级说明才有参考价值。

六项指标里哪几项必须写进合同？

建议前三项写进合同：归档效率、查找命中率、四性检测拦异常能力。这三项可测、可复现、与收益直接相关。OCR 准确率按票种差异较大，建议按企业票据结构单独约定。对接覆盖度与部署数据主权属于前置条件，建议在合同的技术附件里以清单形式固定，而不是以指标形式约定。

测试发现不达标怎么办？

先判断原因归属。归档效率不达标通常来自接口取数方式或组件未自动化；查找命中率不达标通常来自关联字段缺失；检测拦不住异常通常来自检测项覆盖不足。三类原因分属不同环节，整改路径不同。建议在测试报告中把未通过项的原因归属写清楚，明确责任方，再约定整改期限与复测安排。

本文测试方案与指标口径参考 DA/T 94-2022 及行业通用 POC 做法，行业区间为经验值，供选型参考，不作为精确测量值。各厂商数据均标注为公开口径，实际表现请以企业自有数据测试结果为准。