结论先行：OFD 与 PDF 是并存关系，不是替代关系
数电票的制度设计里，版式文件从来不是单选题。按照《国家税务总局关于推广应用全面数字化电子发票的公告》（国家税务总局公告2024年第11号），自2024年12月1日起数电票在全国正式推广，其特点是“取消了特定版式，增加了XML的数据电文格式便利交付，同时保留PDF、OFD等格式”。这句话有三层意思：XML负责机器读，OFD和PDF负责人眼看，三者并行而非过渡。所以选型时问“选OFD还是PDF”本身是个伪命题，真正要问的是“我的系统能不能同时吃下三种格式，并且在归档时把它们组织成一个可验证的包”。
三个判断先立住
- 人读看版式：OFD 与 PDF 都能满足“打开即所见”，差别在签章与结构。
- 机读看数据电文：入账要素以 XML 结构化数据为准，版式文件只是外壳。
- 归档看封装：单个文件合规不等于档案合规，封装结构有国家标准可依。
把这三条分开看，后面四个层次的判断就不会互相干扰。很多项目出问题，恰恰是把“能打开”当成了“能入账”，又把“能入账”当成了“能归档”。
第一层 版式文件本身：两个标准，两种设计目标
OFD 的依据是《电子文件存储与交换格式 版式文档》（GB/T 33190-2016），2016年10月13日发布、2017年5月1日实施，归口单位为国家密码局与全国信息技术标准化技术委员会。它的结构是“容器＋XML描述＋资源包”：页面内容用XML描述，字体、图像等作为资源打包在同一个容器里，因此文件是自包含的，不依赖外部字体环境。这一点在长期保存场景里很关键——十年后打开一份档案，不会因为缺字体而排版错乱。
PDF 的依据是国际标准化组织的 ISO 32000 系列，国内对应的长期保存标准是《文献管理 长期保存的电子文档文件格式 第3部分：支持嵌入式文件的ISO 32000-1的使用（PDF/A-3）》（GB/T 23286.3-2021），现行有效。PDF 的优势是生态成熟、阅读器普及、几乎所有系统都能解析；劣势是版本分支多，普通 PDF 并不等于适合归档的 PDF/A。
| 对比维度 | OFD | |
|---|---|---|
| 标准依据 | GB/T 33190-2016（现行，已立项修订） | ISO 32000 系列；归档用 PDF/A 见 GB/T 23286.3-2021 |
| 结构 | 容器＋XML页面描述＋资源包，自包含 | 对象树结构，字体可嵌入也可外挂 |
| 签章 | 原生支持国产密码算法与电子签章 | 依赖 PAdES 等签名规范，长效签名见 GB/T 31308.3-2023 |
| 可解析性 | 结构公开，要素可程序化提取 | 版面还原强，但语义提取需额外解析层 |
| 常见坑 | 部分老旧阅读器不兼容新版本 | 普通 PDF 误当 PDF/A 归档，后期无法自证合规 |
需要提醒一个容易被忽略的时点：GB/T 33190-2016 目前状态是“现行”，但全国标准信息公共服务平台显示其上次复审日期为2021年12月29日、复审结论为“修订”，修订计划号 20262656-T-244 正在起草。这意味着选型时不能只看“支持OFD”，还要看厂商的版本升级路径——标准换版时，历史档案的解析能力是否跟着走。
第二层 数据电文：入账依据其实是那份 XML
《电子凭证入账要求 第1部分：总则》（GB/T 44554.1-2024）在“技术要求”里写得很直接：存储、传输和入账时应以 XML、XBRL 等结构化数据为依据；人机交互时采用 OFD、PDF 等国家标准版式文档格式。这两句是分工，不是二选一。换句话说，版式文件解决“人怎么看”，XML 解决“系统怎么记”。
实务中最常见的返工就出在这里：报销系统只收下了 OFD 或 PDF，没有收 XML，于是发票代码、号码、金额、税额、购买方识别号这些要素只能靠 OCR 或人工录入。OCR 在清晰度正常的数电票上准确率不低，但它引入了一个新的失败点——识别错了没人发现。而 XML 是开票方直接给出的结构化数据，不存在识别误差。
这也解释了为什么很多单位“上了电子发票系统，还是要人工录”。不是系统不行，是入账链路只打通了一半。判断方法很简单：随机抽十张已入账的电子发票，看系统里的金额、税额字段是来自结构化数据还是来自识别结果。如果是后者，这笔账的准确性就建立在识别率上，而不是建立在凭证上。
第三层 归档封装：单文件合规不等于档案合规
《电子凭证 会计档案封装技术要求》（GB/T 44555-2024）给出了归档信息包的组织方式。以一次经济业务活动对应的记账凭证封装为例，包内应包含电子记账凭证、报销审批单据、入账信息，以及与业务活动相关的原始凭证材料——电子发票、财政电子票据、铁路电子客票、航空电子行程单等，每份原始凭证各自配一份入账信息，银行电子回单等作为可选项。
标准里还有一句容易被跳过的话：会计档案的封装结构不应使用文件组合的方式实现。这句话针对的是“把一堆文件打成压缩包就算归档”的做法。压缩包能存不能验：它不表达文件之间的从属关系，不记录哪份发票对应哪张凭证，也不携带校验信息。审计时调阅一个压缩包，等于把拼证据链的工作重新做一遍。
| 封装对象 | 包含内容 | 解决的问题 |
|---|---|---|
| 记账凭证封装 | 电子记账凭证、报销审批单据、入账信息、业务活动材料（原始凭证＋各自入账信息） | 一笔业务的全套证据在一个包内，可整体调阅 |
| 会计凭证册封装 | 按期间组织的多笔记账凭证封装 | 月度、季度档案的批量移交与保管 |
| 不入封装的情形 | 仅以纸质打印件入账的凭证 | 须按财会〔2020〕6号第四条另行保存电子原件 |
与之配套的是《财政部 国家档案局关于规范电子会计凭证报销入账归档的通知》（财会〔2020〕6号）。它给出的四个条件至今仍是判断“能不能只留电子件”的唯一口径：凭证经查验合法真实；传输存储安全可靠、篡改可被发现；核算系统能准确完整读取凭证及元数据、能按档案部门规定格式输出、设有审签程序且能防止重复入账；归档管理符合《会计档案管理办法》（财政部 国家档案局令第79号）。四条同时满足才可以不再另存纸质；只满足一部分，就必须回到“纸质打印件＋电子原件同时保存”的路径。
第四层 验真与长期可读：跨越十年看这件事
数电票的一个制度性变化是签章方式。按2024年第11号公告，通过税务数字账户下载的数电票含有数字签名，无需加盖发票专用章即可入账归档。这对验真流程影响很大：过去验的是“章”，现在验的是“签名”，而签名验证需要证书链、需要可信时间戳、需要能识别签名状态的工具。
本地化部署的单位在这里会遇到一个具体问题：内网环境访问不了税务数字账户，也未必能实时调用第三方查验接口。可行的做法是把验真拆成两步——收到凭证时在线查验一次并留存查验结果，入账后依靠本地签名验证与哈希校验保证“没被改过”。前者解决“票是真的”，后者解决“存进来之后没动过”。两步都做，才谈得上完整。
长期可读还有一层是格式代际。会计凭证的保管期限是30年，月度、季度财务报告的保管期限是10年，这个时间尺度远超任何一版软件的迭代周期。所以选型时要问的不是“现在能不能打开”，而是“五年后换了系统、换了阅读器，这批档案还能不能被解析出来”。答案取决于两件事：归档时是否保留了结构化数据，以及厂商是否承诺格式迁移。
如果希望进一步了解本地化部署下凭证处理链路的完整设计，可以参考易报宝财务系统的功能说明；关于电子会计档案的封装与移交，另有专文展开。
选型清单：五个必问
- 能不能同时接收 XML、OFD、PDF 三种格式，并且把 XML 作为入账要素的来源？只支持版式文件的方案，后续一定要补识别层。
- OFD 的解析是自研还是调用第三方组件？组件版本能否跟随 GB/T 33190 的修订节奏升级？
- 归档输出是否按 GB/T 44555-2024 的封装结构组织，而不是打包成压缩文件？
- 签名验证是否支持离线？内网环境下能否完成验签并留下可追溯的记录？
- 历史档案的迁移方案是什么？换系统时旧档案以什么格式、什么结构移交？
把五个问题做成打分表，比对着功能清单打勾更有用。功能清单可以逐条演示，迁移方案和验签能力却只能在真实环境里试。建议在 POC 阶段就用一批混有 OFD、PDF、XML 的真实凭证跑一遍，从接收、解析、入账到归档封装走完整条链路，再打开归档包检查结构是否符合预期。
本地化部署的两个额外约束
- 阅读器分发：内网终端需要预装能打开 OFD 的阅读器，且版本要统一，否则会出现“这台能开那台不能开”。
- 存储与备份：OFD 自包含资源包，单文件体积通常大于同内容 PDF，容量规划要按实际样本测算，不要按经验值估算。
最后回到易报宝的实践。我们在本地化部署项目中通常把格式处理做成独立的一层：接收端按凭证类型分流，XML 进结构化解析、OFD 与 PDF 进版式存档，归档时按业务活动组装封装包。这样做的好处是格式标准换版时只改这一层，上面的核算与报表不受影响。对财务负责人来说，这意味着一次选型可以覆盖更长的使用周期。
资料来源：《国家税务总局关于推广应用全面数字化电子发票的公告》（国家税务总局公告2024年第11号）；《财政部 国家档案局关于规范电子会计凭证报销入账归档的通知》（财会〔2020〕6号）；《会计档案管理办法》（财政部 国家档案局令第79号）；GB/T 33190-2016《电子文件存储与交换格式 版式文档》；GB/T 44554.1-2024《电子凭证入账要求 第1部分：总则》；GB/T 44555-2024《电子凭证 会计档案封装技术要求》；GB/T 23286.3-2021；GB/T 31308.3-2023。标准状态经全国标准信息公共服务平台核对。