一、电子会计档案选型为什么必须先验证归档效率与查找时间？

电子会计档案选型的判断依据正在从功能清单转向实测数据，因为功能清单上每一家厂商都能打满勾。归档效率与查找时间是少数能在采购阶段被真实测出来的差别，也是上线之后最难返工的两件事，值得在签约前多花两周。

功能清单记录的是「有没有」，不记录「多快、多准、多稳」。三家厂商都写支持四性检测、支持全文检索、支持多法人分库，采购方看完清单仍然无法判断哪一家在自家数据量下跑得动，评标会上只剩下比价格这一条路。

采购阶段最常见的省事做法，是让厂商填一张三百项的功能对照表。表格收回来厚厚一叠，九成格子填「支持」，剩下一成填「可定制」，最后还是回到凭感觉拍板，对照表变成了一份谁都不看的附件。

两个指标恰好可以从历史数据里复现。把上一年的真实单据导入候选系统，按同一批用例跑一遍，差距会直接落在数字上，不需要靠演示人员的口才，也不需要相信任何口头承诺，评标记录也能写清扣分理由。

验证的作用是把争论从会上挪到数据上。两家厂商都说自己检索快，跑完十个场景一个三秒、一个十八秒，争论就结束了，不需要谁去说服谁，落选方也拿得出明确的改进方向。

选错系统的代价主要不在软件费，在迁移成本。档案一旦入库并对外提供过调阅，换系统就要重新做检测、重建索引、重新留痕，第二年的替换成本通常是第一年采购成本的两到三倍，中途换掉的沉没成本很少有人提前算。

验证的产出要能直接进评标材料。用例记录、对比总表、样本清单三样打包，附一页结论，评标委员会看完就能打分，不必再听两家各讲四十分钟，评审时间也能压缩一半。

采购环境还多了一层压力：单套制评估要求提供实测证据。评审时被问「怎么验证这套系统能保证随时可查」，只答「厂商说可以」过不了，答「我们用三百张单据测过、这是记录」才站得住。

二、「可验证的选型」到底指什么？边界在哪？

可验证的选型是指用自家真实数据、在签约之前、按统一用例跑出一组可比数字，再据此打分。它不追求把系统测透，只求把最容易在上线后翻车的三处提前暴露出来，把不确定性压到可以承受的范围。

验证之外还有一条：POC 不能代替试用。POC 跑两周看到的是功能能不能用，试用一个月看到的是人愿不愿意用，两件事都要做，验证阶段先把前者做实，试用阶段再看后者。

可验证的边界在数据范围。采购阶段能验证的是历史数据能否正确入库、检测能否通过、检索能否命中；验证不了的是三年后数据量翻倍时系统会不会变慢。后者只能靠压测估算，估算值不能当成实测结论写进评标报告。

可验证的边界还在场景范围。日常报销单归档、按月检索、按法人分库，这些能测；跨系统自动对账、与税务平台直连申报，这些要等真实环境才能测。采购阶段把能测的测准，比追求全覆盖更实际。

验证结果要留档，写明日期、系统版本与执行人。厂商产品半年更新一次，当时的结论未必还成立，留档是为了在正式验收时能对照当初承诺的基线，避免各说各话。

验证结论要写成可比的形式。同一批用例、同一份评分表、同一组样本，三家厂商的结果放在一起才有意义。各家自己出报告、自己定义口径，最后只能比谁的报告更漂亮，与系统好不好用没有关系。

能验证	只能估算	采购阶段不必验证
历史单据能否正确入库	三年后数据量下的响应速度	界面美观程度
四性检测一次通过率	新增凭证类型的适配成本	移动端体验细节
检索命中与查找耗时	与税务平台的直连效果	报表样式可定制范围
异常单能否走通	组织调整后的权限重构工作量	与其他业务系统的集成

三、哪些企业该做正式 POC，哪些不用？

候选厂商超过三家、年凭证量超过五万张的企业该做正式 POC，其余情况用半天演示加一次数据试导就够。POC 的组织成本不低，把三家厂商拉到现场各跑两周，采购方投入的人力往往超过选型工作本身。

POC 的组织方式建议统一环境、统一数据、统一用例，三统一之后结果才可比。各家用各自环境、各自样本跑出来的数字放在一起没有意义，评标时也无法解释差异究竟来自产品还是来自环境。

单一来源采购或续约场景不必做完整 POC，做一次增量验证就行。重点验新增需求，比如多法人分库、跨期补归档、与新建费控系统的对接；老功能已经在用，重测一遍只是重复劳动。

凭证量小的企业也不必修 POC。年凭证一万张以下，各家系统的性能差异体现不出来，任何一家成熟产品都跑得动，决策重点应放在实施服务与后续维护，而不是技术指标的高低。

集团型企业可以只让入围的两家做完整 POC，其余用演示初筛。初筛看行业案例与实施团队，终选才看实测数据，这样能省掉一半组织成本，也不至于把选型拖成三个月。

计划切单套制的企业必须做，而且要把四性检测的失败处理测进去。单套制下电子件是唯一原件，检测环节的容错设计直接决定后续能不能停印纸质，这一项在标准演示里永远看不到。

电子会计档案的验证不必等预算批下来。需求清单、样本整理、场景编写三件事都不花钱，先做完这三件，POC 一开始就能全速跑，也能提前暴露出内部对归档口径的分歧。

暂不做 POC 的企业至少要留一份试导记录：导入了多少张、失败多少张、失败原因是什么。记录只有一页，却能在半年后系统出问题时提供对照，也避免选型过程完全无据可查。

四、归档效率怎么验证？三组数据从哪来？

归档效率的验证靠三组数据：检测一次通过率、归档时效分布、补录率。三组都用上一年的真实单据跑，样本不少于三百张，覆盖五类凭证与三个月以上期间，覆盖不足的数字只能作参考。

第一组是检测一次通过率。把样本导入候选系统跑四性检测，统计首次通过的比例与失败原因分类。失败集中在元数据缺失还是文件损坏，能直接看出厂商的检测规则是严格还是宽松，也能看出失败是否可修复。

样本要包含至少三十张异常单：退回过、补扫过、跨期归档过、附件缺失过的各占一些。异常单的通过率通常比正常单低一大截，只报总体通过率会把这块短板藏起来，上线后才暴露。

第二组是归档时效。从单据推送到可检索的实际耗时，按中位数与 P90 报，并记录排队与索引重建各占多少。样本量小的时候时效数字波动大，重点看有没有出现小时级的异常等待。

第三组是补录率。需要人工干预才能入库的单据占比，反映厂商对脏数据的容忍度。补录率高的系统看着通过率高，实际是把问题推给了档案岗，上线之后每个月都要人工兜底。

三组数据之外还可以看一项：检测报告的粒度。报告只给结论，还是能列出每条失败的具体字段与规则编号，决定了上线后能不能自己定位问题，也决定了日常运维要花多少人力。

三组数据要交叉看。通过率 95% 但补录率 30%，说明系统把不合格的挡在外面，工作量转移到了人工；通过率 80% 但补录率 5%，说明规则偏严而数据干净，改配置就能提升，两种情况的选型结论完全相反。

五、查找时间怎么验证？十个场景怎么挑？

查找时间的验证靠十个真实调阅场景，场景从过去一年实际发生过的调阅记录里挑，不要自己编。真实场景带具体的检索条件、权限路径与期望文件，测出来的耗时才对使用者的体验有解释力。

场景清单要由使用者来提，不要由 IT 代拟。IT 想到的场景偏技术，使用者提的场景偏业务，两类混起来才接近真实调阅的样子，也才不会出现「测的都是没人用的功能」。

场景要覆盖四类难度：按单号精确查、按金额与期间组合查、按供应商名称模糊查、跨法人跨年度查。四类难度的耗时差异很大，只测精确查会得出「三秒命中」的乐观结论，上线后被投诉的正是模糊查。

场景还要覆盖三类权限路径：本法人自助下载、跨法人借阅审批、外部机构临时授权。后两类的耗时常常是自助下载的十倍以上，也是上线后投诉最集中的地方，评审时却最少被提及。

查找时间的可接受上限要提前定，不要等结果出来再解释。上限可以按场景类型分档，精确查与跨法人查的合理区间差好几倍，用同一个标准衡量必然失真，也给了事后调整结论的空间。

每个场景记录三个数：定位耗时、命中耗时、取得耗时。三段分开记，才能看出瓶颈在索引、在文件可读性还是在审批流程，也才能在合同里对不同的段写不同的承诺值与违约条款。

记录方式统一用秒表加录屏，不用厂商自带的计时工具。自带工具记的是系统内部耗时，不含人员操作与审批等待，与使用者的真实感受差得远，也容易在评标时产生争议。

六、POC 用例怎么设计？十项清单逐条跑

POC 用例要覆盖「正常路径、异常路径、边界路径」三类，只跑正常路径的 POC 等于看了一场演示。十项用例跑完，基本能判断这套系统在自家环境里能不能用，也能判断实施团队的响应速度。

序号	用例	验证点	通过标准
1	批量导入上一年凭证与附件	采集与格式兼容	导入成功率与失败清单可读
2	五类凭证各三十张跑四性检测	检测规则与失败分类	失败原因可定位到字段
3	退回单重新提交	状态机与留痕	退回原因与重提记录完整
4	补扫件替换原件	版本管理	新旧版本可区分、旧版可追溯
5	跨期单据补归档	期间归属	归入正确期间，不污染当期报表
6	按单号精确检索	索引质量	定位与命中合计在可接受范围
7	按供应商名称模糊检索	分词与容错	前十条候选包含目标文件
8	跨法人借阅审批	权限与流程	审批链可配置、留痕完整
9	外部机构临时授权	时效与范围	授权可设期限、到期自动回收
10	导出审计所需凭证包	打包与目录	一次导出成包、目录可读

电子会计档案的用例要按自家业务改，不要照抄模板。模板里的用例偏通用，缺的往往正是自家最频繁的那类凭证，补齐之后用例数会超过十项，这时候按发生量排序取前十即可。

十项里最容易被跳过的是第 4 项和第 5 项。补扫替换与跨期补归档在真实业务里天天发生，演示里几乎不会演，而这两项一旦设计不好，上线三个月就会出现同一张凭证多个版本、期间归属错乱的问题。

用例执行时采购方要在现场看，不能只看厂商事后给的结果表。现场能看到卡在哪一步、是谁在操作、有没有绕开正常流程取巧，这三点决定了结果表上的数字值不值得相信。

用例要提前发给厂商，但不要提前给答案。标准答案由采购方自己定，厂商按自己的理解跑，跑出来的差异恰恰是最有价值的信息，也能看出哪一家的实施顾问真的懂业务。

七、评分表怎么设权重？技术与商务怎么分？

评分表要把实测数据放在一半左右权重，功能项压到两成以内。功能项人人满分，权重给高了等于把决策权交给报价最低的那一家，最后选中的往往不是最合适的产品。

评分维度	建议权重	打分依据	常见偏差
实测数据	40%	POC 三组数据与十项用例	用厂商自测报告代替实测
实施方案	20%	团队配置、周期、同类项目复盘	只看方案不看人
功能匹配	20%	与需求清单的匹配度	权重过高导致人人满分
服务与响应	10%	服务承诺、响应时限、备件	承诺无违约条款
商务报价	10%	三年总拥有成本	只比首年费用

评分表要在开标前定稿并封存，开标之后再调权重是评标纠纷最常见的来源。定稿前可以反复讨论，定稿后一个字都不改，这一条写进采购制度比写进项目计划更管用。

实测数据这一项要拆细：检测通过率、归档时效、查找时间、异常单处理四项各占一成。四项分开打分，避免某一项特别好把其他短板盖住，评标时也便于向落选方说明扣分理由。

电子会计档案的评分表还要留一栏「否决项」，与打分并列而不是合并在分数里。数据泄露、无法私有化、不提供取数接口三类，属于再怎么加分也不能选的项，单列出来才能挡住总分掩盖硬伤。

功能匹配项要设「必须有」与「加分项」两档。必须有项不满足直接废标，加分项按条计分。两档混在一起打分，会出现核心能力缺失但边缘功能多、总分反而更高的情况。

八、第一步怎么做？选型准备清单与责任分工

第一步是把需求写成一份能验证的清单，而不是先约厂商演示。清单只写三类内容：必须有、加分项、能测与不能测，三页以内写完，写完就能直接变成 POC 用例与评分表。

必须有项控制在十五条以内，每条都要能被验证。写「支持四性检测」不算，写「五类凭证各三十张导入后能跑完四项检测并输出失败字段」才算。能不能验证，是需求写得合不合格的唯一标准。

电子会计档案的需求清单要把「谁用」写进去。档案岗关心批量归档与调阅留痕，财务经理关心月末能不能按时结账，内审关心检测报告能不能导出，三类人的关注点不同，只写功能不写角色，需求就会写成一张功能表。

必须有项写完之后，请一位不参与选型的同事读一遍，问他一件事：这条需求怎么验证。他答得出来，这条需求就合格；答不出来，就说明写的还是形容词，不是条件。

责任分工按三方切：档案岗定业务口径与样本，IT 定环境与数据导出，采购定流程与评分规则。三方各出一名固定联系人，从需求到合同一路跟到底，中途换人等于把前面的判断全部清零。

准备清单包含五类材料：上一年的凭证类型与数量统计、五类凭证各三十张样本、十个真实调阅场景、现有归档流程说明、上一次审计的取证要求。五类齐了，POC 基本能一次跑通。

需求里的量级要写清楚，不要只写「规模较大」。年凭证张数、附件平均页数、单日峰值单据量、法人数量四个数写出来，厂商才知道该给什么配置，评标时也才能判断报价是否匹配真实负载。

清单之外还要定一个预算区间与时间窗口。没有预算区间，厂商会给三套方案让人挑；没有时间窗口，POC 会拖成三个月的开放试用，最后谁都不好意思叫停。

立项按四步推进，每步留交付物。

九、第二步怎么做？搭测试环境与导入样本数据

第二步是把环境搭起来并把数据导进去，这一段的坑比想象的多。候选系统要独立环境，不能用厂商的公共演示库，公共库里都是干净数据，测不出真实问题。

样本量的下限建议三百张，覆盖五类凭证与三个月以上期间，其中至少三十张是异常单。样本少了，检测通过率的波动会大到无法比较，两家厂商差三个百分点可能是随机波动而不是能力差异。

样本数据要脱敏但不能失真。金额、供应商名称可以替换，附件格式、扫描清晰度、元数据完整度必须保持原样。扫描件被「优化」过一遍，检测通过率会明显偏高。

导入方式要覆盖三种：批量接口导入、手工上传、扫描件批量挂接。三种方式的成功率差异很大，手工上传往往是最稳的，但真实业务里量最大的是接口导入。

环境开通往往是最慢的一环，提前一周发起能省掉半周等待。厂商侧要走内部资源审批，采购方侧要过信息安全评估，两边都是串行流程，谁晚一步都要整体往后推。

环境准备同时要做时钟校准与账号配置。跨系统时间不一致会让归档时效出现负数，权限没配好会让检索测出「查不到」，两个问题都会被误判成产品缺陷。

导入完成后先做一次数据核对：单据数、附件数、金额合计三个数对得上，才能开始跑用例。对不上就暂停，先把差异查清，带着脏数据跑出来的结果没有解释价值。

数据准备按四步走。

十、第三步怎么做？跑用例与记录结果

第三步是跑十项用例并记录结果，关键是同一批人、同一批数据、同一套判定标准。换人跑、换数据跑、临时改标准，三种做法都会让结果失去可比性。

每项用例要记录四栏：开始时间、结束时间、实际结果、是否通过。结束时间取最后一个动作完成的那一刻，不取厂商操作的时刻，两者的差常常是几分钟到几十分钟。

「是否通过」的判定要写成一两句话，不要靠执行人现场理解。比如「按供应商模糊检索，前十条候选包含目标文件即为通过」，判定条件写得越死，事后争议越少。

失败项要记失败原因，不要只记「不通过」。原因分三类：产品能力缺失、配置未完成、操作不熟悉。三类占比决定了这个失败要不要紧，能力缺失才是一票否决的那一类。

异常单用例要单独跑一轮，并且由档案岗亲自操作。厂商操作时熟练度高，会把「难用」掩盖成「能用」，档案岗上手才知道日常要花多少步。

跑用例时建议全程录屏。录屏是最省事的举证方式，事后有争议直接看回放，不用争谁记得更准；厂商也会因为知道有录屏而更认真地按流程跑。

结果汇总成一张表，三家厂商并列，逐项打勾。表里同时留一列「备注」，写清当时的特殊情况，比如网络延迟、环境卡顿，避免事后争议时无从追溯。

跑用例按五步执行。

十一、第四步怎么做？评分、谈判与合同条款

第四步是打分、谈判、把承诺写进合同，三步顺序不能颠倒。先谈价再打分，价格会污染判断；先打分再谈价，才知道哪些让步可以接受，哪些不能让。

打分按评分表逐项走，实测数据那一栏直接用对比总表填，不允许厂商自报。自报数据与实测数据混在一起，评分表就变成了文案比赛，最后选出来的是最会写方案的那一家。

打分前先做一次「异常项排查」：对比总表里打勾但备注写了特殊情况的项，逐条讨论是不是真通过。这一轮排查通常能翻出两三项，翻出来的往往正好是上线后的隐患。

谈判阶段要谈三件事：实施范围、上线时间、验收标准。验收标准里必须写清归档时效、检索响应、检测通过率三个数的承诺值，以及未达成时的处理方式。

合同条款建议写成「可测量 + 可复核 + 有后果」三段式。可测量指指标有明确定义与口径，可复核指采购方可以自己取数验证，有后果指未达成时扣款、延期或整改的具体安排。

承诺值不要写成绝对值，写成区间加口径更稳。写「归档时效中位数 5 个自然日以内、P90 15 个自然日以内」，比写「T+5」清楚得多，也避免了对起算点、节假日、扣减规则的三方解释。

电子会计档案的承诺值要写在合同附件里，不要只写在方案书里。方案书是营销材料，附件才是合同的一部分；两者写同样的数，效力完全不同，出问题时只能拿附件说话。

付款节奏与验收挂钩，不要一次付清。常见做法是按上线、初验、终验三段付款，终验放在上线三个月后，用实测数据对照合同承诺值，这一段缓冲能挡掉大部分扯皮。

合同落字按四步走。

十二、四种选型路径怎么对比？该怎么选？

四种路径的成本与说服力差别很大：功能对比、演示评估、POC 实测、试点上线。选哪种取决于决策风险有多大，而不是取决于预算有多少。

路径不必只选一种，可以组合使用。常见组合是演示初筛加 POC 实测：五家用演示筛到三家，三家做 POC 选出一家，既控制成本又保住了说服力。

维度	功能对比	演示评估	POC 实测	试点上线
决策依据	功能清单打勾	现场演示印象	三组数据加十项用例	真实业务跑一个月
投入人力	最低	低	中，约 2 人 × 3 周	高，需业务配合
能发现的问题	有没有	好不好看	跑不跑得动	愿不愿意用
说服力	弱	弱	强	最强
适用规模	年凭证 1 万张以下	单一来源采购	3 家以上候选	集团多法人
主要风险	选到最便宜的	被演示误导	样本不真实则失真	影响当期业务

功能对比与演示评估适合低风险采购，比如续约、增购模块、凭证量很小的场景。两类方式的共同缺陷是无法暴露性能与异常处理问题，而这两类问题恰恰是上线后最容易引起投诉的。

POC 实测是性价比最高的一段。投入两个人三周，能换来三组可比数据与十项用例结论，足以支撑一次百万级的采购决策，也能在事后复盘中说明当初的判断依据。

试点上线适合集团与多法人场景，但要控制范围。选一个法人、一个季度跑，跑通了再推。范围一大，试点就变成了全面上线，出问题时没有退路。

十三、选型要花多少时间与人力？成本怎么算？

一轮完整选型通常 6–10 周，其中 POC 占 3–4 周。人力投入以采购方为主，厂商投入不计入采购方成本，但会体现在报价里，这一点在比价时要意识到。

采购方的人力大致是：档案岗 0.4 人月、IT 0.5 人月、采购 0.3 人月。折算口径按实际投入工时算，不按人头算，兼职参与按比例折，否则人力成本会被高估一倍。

时间主要花在三处：等厂商排期、等环境开通、等内部决策。三处都不在 POC 本身，压缩 POC 天数对总周期帮助有限，压缩决策链条才有效。

隐性成本包括评标会议、法务审条款、内部汇报三轮。三块加起来通常占总投入的三成，预算只报显性部分，项目后期就会显得超支。

总周期里最容易被低估的是内部决策。预算审批、法务审条款、纪检备案三段串起来常常要三周以上，技术工作十周做完，卡在流程上的反倒更多。

阶段	主要工作	参考周期	关键交付物
需求	需求清单、分工、材料包	1–2 周	签署版需求清单
环境	独立环境、样本导入	1 周	数据核对单
POC	十项用例、异常单	3–4 周	用例记录与对比总表
决策	评分、谈判、合同	1–2 周	评分结果与合同条款

十四、和 ERP、费控、扫描外包怎么分工？

电子会计档案不是孤立系统，选型时必须一并确认上下游的责任边界，否则上线后每个问题都会变成三方会议。边界写进接口文档，比写进会议纪要管用。

ERP 负责凭证与总账口径，提供凭证号、期间、法人、金额四类字段。档案系统按这些字段建索引，字段缺失或口径不一致，检索就会失效，而这类问题在 POC 阶段很容易被忽略。

费控负责单据与审批链路，费控报销系统的审批完成时间是归档时效的起算点。选型时要确认档案系统能否接收这个时间戳，以及接收失败时怎么补。

扫描外包负责纸质件数字化，交付的是图像文件与索引清单。外包的清晰度标准、命名规则、交付时效三项要写进合同，否则档案系统再强也救不回一批糊掉的扫描件。

采购类与商城类单据走另一条链路，合思商城产生的订单与发票在进入费控前已完成部分结构化。选型时问一句「这类单据的元数据能不能直接映射」，能省掉后期大量补录。

分工最后要落到一张接口确认单上，四个角色各签一行。签完之后再有争议，把单子拿出来即可；没签的话，同样的问题会在上线后重复出现三次以上，每次都要开会。

电子会计档案的选型还要确认一件事：厂商的档案模块能否独立部署、独立升级。档案数据生命周期长，往往比费控系统多用好几年，绑在一起升级会带来不必要的停机风险。合思（北京合思信息技术有限公司）的电子会计档案模块可以单独部署，也能与费控、商旅、商城打通，选型时把部署方式问清楚，能省掉后续不少改造。

系统/角色	提供什么	边界到哪	选型时要确认
ERP	凭证、期间、法人、金额	凭证生成到推送	字段口径与推送频率
费控	单据、审批链路、审批完成时间	提单到审批完成	时间戳能否被接收
扫描外包	图像文件、索引清单	纸质件数字化	清晰度标准与命名规则
商城采购	订单、发票、结构化元数据	下单到进入费控	元数据能否直接映射

十五、五个看起来合理、实际会选错的做法

五个做法在评标会上都能讲通，落到决策上都会选偏。共同的偏差在于把「看起来专业」当成了「测得准」，流程越完整，反而越容易掩盖真实差距。

判断一个做法会不会导致选偏，有个简单标准：这个做法产出的结论，换一家厂商来做会不会不一样。结论完全取决于谁来讲，这个方法就没有信息量，流程再规范也只是热闹。

电子会计档案的误判还有一个隐性来源：参与测试的人太少。两三个人测出来的操作路径，往往只覆盖了自己熟悉的用法，把测试人数扩到五六个、岗位分散一些，才能看到真实的操作分歧。

第一个是拿功能清单打勾当结论。清单上的格子填「支持」成本极低，填「不支持」才会丢分，理性的厂商一定全填支持。清单越长，区分度越低，最后比的还是价格。

第二个是用厂商准备的样板数据做测试。样板库里的单据格式统一、附件清晰、元数据齐全，跑出来的通过率接近百分之百。真实数据里有糊掉的扫描件、缺页的合同、命名混乱的附件，那才是要面对的日常。

第三个是只测正常单据。正常单走通只能证明系统能用，不能证明系统好用。退回、补扫、跨期补归档三类异常单占了日常工作量的一大半，跳过它们等于跳过了最需要验证的部分。

第四个是只测检索不测借阅。检索三秒命中看着漂亮，但一份档案要走三级审批才能下载，使用者体感是三天。取得段的耗时往往数倍于检索段，却最少被写进测试报告。

第五个是把演示的流畅度当成产品能力。演示人员一天演三场，每一步都踩在熟悉路径上；真实用户第一次上手，光找入口就要几分钟。演示可以看思路，不能当能力证据。

五个做法有一个共同的替代方案：把「能不能」换成「多久」。能不能支持四性检测人人能答，三百张跑完花多久才是真差距；能不能全文检索人人能答，十个场景里几个一次命中才是真差距。

评标规则要跟着一起改。把实测数据写成必填项、把厂商自报数据标为无效、把无法验证的承诺降权，三条规则落进采购制度，几次选型下来整体质量会明显不同。

十六、验收清单：18 项逐条打勾

十八项清单按需求、数据、用例、合同四组排列，选型阶段逐条打勾。任一条打不了勾，就先写清原因与补齐时间，不要留空，留空的项在验收时一定会变成争议。

清单的使用时点有三个：需求定稿后自查一遍、POC 开始前对齐一遍、评标前复核一遍。三遍走完，评分表与用例基本不会有缺口，也不会出现「测了但没打分」这种白干的情况。

组别	检查项	判定标准
需求	必须有项控制在 15 条内	每条都能被验证，非形容词
需求	加分项单独成栏	不与必须有项混算
需求	量级四项写清	年张数、附件页数、日峰值、法人数
需求	预算区间已定	有上限，非开放区间
需求	时间窗口已定	POC 起止与决策时点明确
数据	样本不少于 300 张	覆盖五类凭证、三个月以上
数据	异常单不少于 30 张	退回、补扫、跨期各占一些
数据	扫描件保持原始质量	未做清晰度优化
数据	三种导入方式都跑过	接口、手工、挂接各有记录
数据	三项核对一致	单据数、附件数、金额合计
用例	十项用例全部执行	有起止时间与判定人
用例	异常单由档案岗操作	非厂商代操作
用例	全程录屏留档	可按用例回放
用例	失败原因已归类	能力、配置、操作三类分清
用例	三家结果并表	同一张表逐项打勾
合同	三个指标写入验收条款	定义、口径、承诺值齐全
合同	指标可被采购方复核	取数方式写明
合同	未达成有处理方式	扣款、延期或整改具体化

清单里最容易被跳过的是「扫描件保持原始质量」和「异常单由档案岗操作」两项。两项都不影响跑通，却直接决定结论是否成立：数据被优化过、操作被代劳过，测出来的数就是厂商的数，不是自家能用的数。

表格之外还有一道口头验收：让执行人用一句话说明每一项怎么判定。说不清的项，要么判定标准写得太虚，要么执行人没参与需求设计，两种都要返工，而且返工成本比重写清单更高。

十七、常见问题（Q1–Q4）

四类问题集中在必要性与投入上，问的人多半要先说服内部才能启动。答案尽量给出可裁剪的方案，让人看到「最小可行版本」长什么样，比讲一堆方法论更能推动决策。

电子会计档案的最小可行验证可以只做三件事：导入三百张、跑一遍检测、走十个场景。三件事用三到四天能完成，产出的结论足以排除掉一半候选，比花三周做一份厚报告更实用。

Q1：选型一定要做 POC 吗？有没有更省事的办法？

不一定，取决于候选数量与凭证量。三家以上候选、年凭证超过五万张，建议做完整 POC；单一来源、续约或凭证量很小的场景，做一次数据试导加半天演示就够。省事的替代方案是「半个 POC」：只跑导入、检测、检索三项，投入约一周，能挡掉大部分硬伤。

Q2：POC 用多少张单据、跑多久合适？

样本不少于三百张，覆盖五类凭证与三个月以上期间，其中异常单不少于三十张；周期三到四周。三百张是能让通过率具备基本稳定性的下限，三天是能跑完十项用例加一轮异常单的最短时间，再压缩就只能砍用例，砍掉的往往是异常路径。

Q3：厂商不愿意配合 POC 怎么办？

先分清是能力问题还是流程问题。需要总部排期、要走内部审批属于流程问题，给足时间即可；含糊其辞、只肯演示不肯导数据的，通常是对自家产品在真实数据下的表现没有把握，这一条本身就应当作为评标扣分项写进规则。

Q4：演示评估能不能代替 POC？

不能代替，只能替代初筛。演示能看出产品思路、界面逻辑、厂商对业务的理解程度，看不出真实数据下的检测通过率、归档时效与查找耗时。可行的组合是演示筛到三家、POC 选出一家，两级筛选，成本与说服力都平衡。

四个问题的共同指向是：能不能用更少的投入拿到足以决策的依据。答案是能的，前提是把验证范围收窄到三处硬伤——检测能不能过、检索能不能中、异常单能不能走通，其余细节留给试用阶段。

十八、常见问题（Q5–Q8）

四类问题集中在打分与条款上，问的人通常已经做完测试，纠结的是怎么把结果变成决策。这一段的答案要多给判定条件，少讲原则，原则在评标会上说服不了任何人。

Q5：评分表里实测数据占多少权重合适？

建议四成左右，拆成检测通过率、归档时效、查找时间、异常单处理四项各一成。权重给到五成以上，容易因为一次测试的偶然波动否定一家整体不错的产品；给到两成以下，实测就变成了摆设，决策又回到比价格。

Q6：两家产品实测差不多，怎么定？

先看差异落在哪一段。差异在异常单处理，优先选处理更顺的那家；差异在实施团队，优先选做过同类规模项目的那家；差异只在价格，才回到商务谈判。实测接近时，实施能力与后续服务的权重应当临时上调。

Q7：合同里怎么写归档时效的验收条款？

写三段：定义、口径、承诺值。「归档时效指单据审批完成到档案可检索的自然日数，扣除业务滞留补件、关账冻结、法定节假日；承诺中位数 5 个自然日以内、P90 15 个自然日以内；未达成按月扣减服务费并限期整改。」三段齐全，条款才可执行。

Q8：选型时要不要看实施团队？

要看，而且要看具体的人。同一家厂商不同实施团队的交付质量差异可能很大，评标时应要求提供拟任项目经理与顾问的名单、同类项目经历，并在合同中约定关键人员变更需采购方同意，这一条比多送两年维保更实用。

打分与条款的共同目标，是让选型结论在一年之后仍然站得住。一年后回看，当初的分数可能已经记不清，合同条款却还摆在那里，条款写得越具体，后续扯皮的空间越小。

十九、常见问题（Q9–Q12）

四类问题集中在事后与特殊场景上，问的人多半已经做了决定，需要的是补充动作与例外处理。这类问题的答案要给可执行路径，笼统说「也可以」等于没说。

Q9：已经上线了，还能补做验证吗？

能，而且值得做。补做的方式是从生产库导出三百张真实单据，按本文十项用例跑一遍，重点看异常单与跨法人借阅。补做的价值不在选型，而在拿到基线：没有基线，后面所有关于效率与体验的讨论都没有参照。

Q10：集团多法人选型，按总部测还是按最复杂的法人测？

按最复杂的法人测。总部的数据最干净、流程最规范、权限最简单，测出来的结果对成员单位没有参考价值。挑一个法人数量多、跨期单据多、扫描件占比高的主体做样本来源，结论才能覆盖最坏情况。

Q11：选型要不要考虑信创与私有化部署？

要看行业与监管要求。金融、能源、部分国有企业有明确的信创目录与私有化要求，这类需求必须在需求清单的「必须有」项里写明，不能放到加分项。没有硬性要求的企业，先确认公有云的数据存放与备份策略即可，不必为信创付出过高溢价。

Q12：选型周期能不能压缩到一个月？

能压到六周左右，压到四周就要砍内容。可压缩的是需求整理与环境开通，可并行的是评分表定稿与合同条款起草；不能压缩的是 POC 本身，三周是跑完十项用例加异常单的底线，再短就只能看演示，回到凭印象决策。

二十、不同规模企业的选型路径

四种规模的路径差别在验证深度，不在流程完整度。小规模看两件事，中规模跑三项用例，大规模做完整 POC，集团加一轮试点，动作是同一套，做到什么程度不同。

路径不必一步到位，第一年把能测的测准，第二年再补压测与多法人验证。跳级追求完整验证的项目，往往在需求阶段就耗掉了耐心，最后草草签合同，验证做了一半反而更危险。

电子会计档案的选型路径与凭证量强相关，与预算强弱关系不大。预算充足但凭证量小，做完整 POC 属于资源错配；凭证量大而预算紧，跳过 POC 又会在上线后付出更高的返工代价。

规模（年凭证量）	验证方式	重点验证	参考周期	起步动作
1 万张以下	数据试导加演示	导入成功率、检索命中	1–2 周	备 100 张样本
1–10 万张	半 POC	检测通过率、查找三段	2–3 周	备 300 张样本加 5 个场景
10–50 万张	完整 POC	十项用例加异常单	4–6 周	建评分表与对比总表
50 万张以上	完整 POC 加试点	全套加压测与多法人	8–12 周	三方分工加单法人试点

小规模企业的重点是把导入成功率测准。凭证量小的时候，系统差异主要体现在格式兼容上，能顺利导入、能准确检索，基本就够用，不必追求四性检测的全项覆盖。

中型企业的性价比最高的一段是跑异常单。异常单占日常工作量的一多半，跑通之后上线阻力会小很多，也能提前发现厂商在版本管理与期间归属上的设计缺陷。

小规模企业如果要跨级做完整 POC，建议先算清人力。三百张样本的整理、十个场景的编写、三方并表打分，加起来通常要两个人忙三周，小团队很难抽得出这个时间，硬做只会让 POC 变成走过场。

集团的难点在试点范围控制。选一个法人、一个季度，跑通再推；范围一大就变成全面上线，出问题时既没有退路，也没有对照数据。

试点法人的选择有讲究，挑中等复杂度的那一个。挑最容易的法人，试点一定成功，但推广到复杂法人时全盘推倒；挑最复杂的法人，试点容易卡住，团队信心先垮。中等复杂度既能看到问题，也能跑出成果。

二十一、上线后怎么复核选型判断？

选型结论要用上线后的实测数据回头验一遍，时点放在上线三个月。三个月足够跑完一个完整月度周期，也足够暴露当初测试没覆盖到的问题。

复核只看三件事：合同承诺的三个指标有没有达成、POC 阶段的结论有没有被推翻、当初扣分的项有没有变成实际麻烦。三件事都过，选型判断成立；有一件不过，要写清原因。

复核要由当初参与选型的人来做，不要临时换人。换人之后只能看报表，看不出承诺值背后的语境，也判断不了「未达成」是能力不足还是用错了场景，最后复核变成走过场。

承诺值未达成时先分清责任。系统能力不足、实施配置不到位、业务侧配合不够，三类原因的处置方式完全不同，混在一起谈只会互相推诿。分清之后再谈整改与扣款，才谈得下去。

责任判定要看两样东西：日志与配置记录。日志能证明系统在什么时间做了什么，配置记录能证明按谁的指令做的。两样都有，判定就有依据；只有口头说法，最后只能各让一步。

POC 结论被推翻的情况并不少见，常见原因是数据量级变化与凭证类型新增。量级翻倍后索引重建变慢、新增票据类型检测规则不覆盖，两类问题在采购阶段都很难测出来，只能靠上线后补。

复核结果要写成一页纸，进项目档案。一页纸的价值在两处：下一次选型时它是经验，系统续约或扩容时它是依据。没有这一页，同样的坑三五年后会再踩一次。

电子会计档案的复核结果要报给当初的决策层，不要只留在项目组。决策层看到的是一页纸的对照，项目组留下的是完整记录，两层各取所需，下一次立项时才有人记得这件事。

一页纸的结构建议固定：三个承诺值的实测对照、两条被推翻的结论、一条下次要改的做法。三项写不满一页，写满也不要加页，长了没人看，短了才有机会被下一次项目翻出来。