在财税数字化进程中，OFD发票与XML发票是两种最常见但也最容易被混淆的电子票据形式。它们虽然都用于承载增值税电子发票的核心信息，但在技术实现、使用场景以及系统处理方式上存在明显差异。本文将从文件本质、结构特征、实际应用等多个维度，对OFD与XML格式进行详尽剖析。
一、OFD发票的技术本质与特点
OFD是Open Fixed-layout Document的缩写，中文称为开放式版式文件，属于我国自主制定的国家标准（GB/T 33190）。它的设计目标是提供一种版面固定、显示一致的电子文档格式，类似于PDF但更强调国产自主与安全可控。发票开具方生成OFD文件后，接收方在任何设备上打开，看到的印章位置、表格线条、字体排布都完全一样。
从技术结构看，OFD实际上是一个压缩包容器，内部采用XML描述页面内容，再配合字体、图像等资源存储。它使用数字签名保证文件自生成后未被篡改，税务UKey签发的发票OFD中带有制章签名，用阅读器验证即可确认来源真实。下面是一段简化示意，展示OFD包内常见的文件组织方式：
ofd_invoice.ofd ├─ META-INF │ ├─ Doc_0.xml <!-- 文档元数据 --> │ └─ Signature.xml <!-- 签名信息 --> ├─ Pages │ ├─ Page_0.xml <!-- 第一页版面描述 --> │ └─ Page_1.xml ├─ Res │ ├─ font.ttf <!-- 嵌入字体 --> │ └─ seal.png <!-- 发票章图片 --> └─ Document.xml <!-- 文档结构入口 -->
由于OFD偏向“所见即所得”，它非常适合财务打印、纸质归档以及人工核对。但其缺点是结构化程度低，如果想把发票上的购方税号、金额等字段批量导入ERP，需要额外做OCR或解析组件，成本较高。另外，OFD阅读器需要支持国密算法才能验章，这对部分老旧系统不够友好。
OFD在实务中的优缺点
优点方面，OFD发票具有强版式一致性，审计人员直接打开就能看到规范票面，且防篡改特性满足档案法对电子凭证原件的要求。缺点则是文件体积相对大，不支持像数据库那样的直接字段查询，在海量发票自动处理时效率偏低。
很多企业在报销系统中要求上传OFD原件，正是看中它不可更改的凭证属性。但当需要与税务局接口做勾选认证时，系统底层其实调用的是另一套数据，并非解析OFD图像，这就引出了XML发票的价值。
二、XML发票的数据结构与用途
XML发票是以可扩展标记语言写成的纯文本数据文件，后缀通常为.xml。它不包含版面信息，只以树形节点记录发票要素，例如发票代码、号码、价税合计、商品名称等。正因为是纯数据，XML极小、极容易被程序解析，是系统间自动传输的首选。
税务平台提供的下载接口往往返回XML，因为后端数据库导出结构化记录最自然。下面展示一个极度简化的增值税电子发票XML片段，注意其中所有标签均为示例转义描述：
<?xml version="1.0" encoding="UTF-8"?>
<invoice>
<head>
<invoice_type>增值税电子普通发票</invoice_type>
<invoice_code>011002300311</invoice_code>
<invoice_number>12345678</invoice_number>
</head>
<body>
<buyer>
<name>示例公司</name>
<tax_id>91110108MA01ABCDEF</tax_id>
</buyer>
<total_amount>113.00</total_amount>
<total_tax>13.00</total_tax>
</body>
</invoice>
从这个例子可以看出，XML把每张发票变成一条条清晰字段。财务系统读取后，可直接生成凭证分录，无需人工录入。它也是全电发票（数电票）对外交付的核心数据载体，纳税人用开票软件导出XML，就能无缝对接自己的进销存。
XML发票的优势与局限
XML的最大优势是机器可读性强，支持XPath、XSLT等标准做校验与转换。税务局的查验接口、报销平台的自动填单都依赖它。局限在于，纯XML没有视觉版面，非技术人员打开只是一堆标签，无法直接当作票据原件给人眼审核，且若未附签名文件，单凭XML难自证未改。
实际工作中，不少单位同时留存OFD与XML：XML给系统跑批，OFD给人工备查。这样既满足效率也满足合规。
三、OFD与XML的核心区别对比
为了更直观理解两者差异，我们从多个技术维度进行对照。下面的表格列出了关键区别点，帮助开发与财税人员在选型时快速判断。
| 对比维度 | OFD发票 | XML发票 |
|---|---|---|
| 文件本质 | 版式容器（含资源包） | 纯文本数据结构 |
| 主要用途 | 展示、打印、归档原件 | 系统对接、自动读取 |
| 是否含版面 | 是，固定版面 | 否，无版面概念 |
| 防篡改机制 | 内嵌数字签名验章 | 需配合签名或源端可信 |
| 解析难度 | 需专用库解包提取 | 标准XML解析器即可 |
| 人工可读性 | 高，像看纸质票 | 低，仅标签与值 |
可以看到，OFD与XML并非替代关系，而是互补。版式文件解决“长得像发票且不能改”，数据文件解决“让程序懂发票”。在发票全生命周期里，开票端生成数据，再渲染成OFD供人看；受票端用XML入库，用OFD存档，这是当前最稳妥的闭环。
开发对接时的注意点
如果你在写程序自动收票，建议优先解析XML。使用Python时，可借助标准库提取字段，示例如下：
import xml.etree.ElementTree as ET
def parse_invoice(xml_path):
tree = ET.parse(xml_path)
root = tree.getroot()
code = root.find('./head/invoice_code').text
number = root.find('./head/invoice_number').text
amount = root.find('./body/total_amount').text
return code, number, float(amount)
# 调用示例
c, n, a = parse_invoice('fp.xml')
print('发票代码', c, '号码', n, '金额', a)
而当需要做电子会计档案时，务必保存OFD原件并定期用合规阅读器验章。有些单位误以为只留XML就行，结果稽查时无法出示版式原件，被要求补纸票。明确两种格式分工，才能少走弯路。
四、常见误区与正确实践
一个典型误区是把XML直接转成PDF或截图，就当成“版式存档”。这种做法丢失了OFD的国家标准签名体系，严格来说不属于合法原件。正确做法是：从税控设备导出OFD，用支持国密的阅器打开验真；XML单独备份进业务数据库。
另一个误区是认为OFD也能轻松取数。实际上，虽然OFD内部有XML，但页面坐标与文本抽取受字体、排版影响，不如原生XML稳定。大型集团应建立“XML为主数据、OFD为凭证”的双套管理策略，并在报销入口做格式自动识别。
综上所述，OFD发票与XML发票的区别根植于“版式”与“数据”的路线分野。理解它们，不仅能写好代码接口，也能让财务流程经得起审查。希望本文的拆解，能帮你在实际项目中少踩坑、多提效。