文档与票据
如何判断 PDF 或 OFD 文件有没有被修改:验签、比对与核查
核查 PDF 与 OFD 文件是否被改动:取得可信对照件,验证电子签名或电子签章,区分文件属性日期与系统日期,逐项比对金额与收款信息。
发布于 · 更新于 · 17 分钟阅读
本页内容
判断 PDF 或 OFD 文件有没有被修改,最可靠的做法是取得一份独立来源的对照件逐项比对,验证文件中的电子签名或电子签章,并对关键字段的差异逐一查明原因。文件属性、元数据和版面上的异常可以为核查指明方向,但它们都不是通用的“修改检测器”。对于数电发票,全国增值税发票查验平台和贵单位自己的税务数字账户本身就是最直接的对照来源。
动手之前,先写清要验证的命题。“这是供应商实际开具的发票”与“这份文件自签署后没有被改动”是两个不同的问题,一份文件可能通过其中一项、却通不过另一项。文件也可能包含正当的改动:填写完毕的表单、追加的审批签名、重新开具的发票。核查要回答的是:改了什么,改动是否经过授权,当前这份文件能否支撑您要作出的业务决定。
先确定起点
先原样保存收到的附件,再按手头已有的证据选择路径。如果既有可靠的对照件,又有可验证的签名,两项检查都要做:它们回答的是不同的问题。
| 手头有什么 | 第一步 | 能得到的结果 |
|---|---|---|
| 数电发票(PDF、OFD 或 XML) | 在查验平台查验,或从本单位税务数字账户下载同一张发票作对照;见第一步 | 票面信息是否与税务系统记录一致 |
| 出具方提供或此前审批过的可靠副本 | 确认版本,再比对关键字段与页面;见第一步和第四步 | 一份逐项列明的差异清单 |
| 带证书的电子签名或电子签章 | 用支持验签的阅读器验证,并查看签名覆盖的版本;见第二步 | 验证状态、覆盖内容与签署后允许的改动 |
| 既无可靠对照件,也无可验证的签名 | 锁定有争议的字段,向出具方书面核实;元数据与版面检查只用于指导这次核实 | 一项具体的取证请求,而不是缺乏依据的“已被修改”结论 |
Fileverity 文档检测可检查 PDF 保留版本、数字签名和文档结构,并结合扫描字段与文本来源分析呈现具体证据。下文从文件完整性、版本变化及出具方记录入手,说明如何组织一次有效的复核。
第一步:保全文件,确定对照件
原样保留收到的附件或下载文件,记录发件人或下载渠道、接收时间、原始文件名和单据编号;说明版本或用途的随附邮件、聊天消息一并保存。添加批注、运行 OCR 或保存比对报告之前,先另建工作副本。
SHA-256 哈希值可以标识收到的这组字节。哈希值相同,说明是同一个文件;哈希值不同,只说明字节不同,具体改了什么还要通过比对确定。把哈希值与文件一起记入核查记录。
对照件应当经由既有渠道取得:出具方的门户网站、供应商准入时备案的联系人,或者官方查询平台。同一个陌生发件人再转来的第二份附件,不是独立的对照件。比对之前,确认对照件与收到的文件属于同一账户、同一期间、同一单据号码和同一版本;如果出具方可能已经重新开具,先问清楚,再拿旧的审批件与当前文件比较。
发票类文件,首选官方查验渠道。国家税务总局 2024 年第 11 号公告规定,单位和个人可以登录自有的税务数字账户,免费查询、下载已开具或接受的数电发票,也可以通过电子发票服务平台或全国增值税发票查验平台免费查验数电发票信息(公告第十一条)。如果发票开给的正是贵单位,从本单位税务数字账户下载的那一份,就是独立于邮件、聊天渠道的对照件。数电发票取消了特定版式,增加了 XML 数据电文格式,同时保留 PDF、OFD 等格式(国家税务总局解读,2024 年 11 月 12 日),因此同一张发票可能以三种文件形态流转。
查验平台的“导入查验”功能,可以把电子发票的 XML、PDF、OFD 文件单张导入系统查验(查验平台常见问题)。查验结果的边界也要清楚:平台“仅提供所查询发票票面信息的查验结果。如对查验结果有疑议,请持发票原件至当地税务机关进行鉴定”(查验说明)。查验一致,说明票面信息与税务系统记录相符;它不说明货物已经到达,也不说明随附邮件里的收款账户是对的。
合同、对账单、银行回单等非发票文件,则按问题选择对照件:
| 核查问题 | 合适的对照件 | 比对一致能说明什么 |
|---|---|---|
| 文件在传递途中被改过吗? | 经独立确认的发送方原始文件 | 与那一份特定文件字节一致 |
| 审批之后金额被改过吗? | 审批时的版本及审批记录 | 与已审批金额一致 |
| 这份文件是出具方开具的吗? | 出具方门户中的副本,或经独立确认的开具记录 | 与出具方记录一致 |
| 签署之后内容被改过吗? | 相关签名所覆盖的那个版本 | 与签署时的状态一致 |
如果找不到可靠的对照件,要尽早在记录中写明这一局限。您仍然可以检查文件本身,但不能仅凭当前金额“看起来可疑”就推断出原始金额。
第二步:验证电子签名或电子签章,并确认覆盖范围
PDF 上的红色公章,可能只是一张图片。手写签名的扫描图、打字输入的姓名、盖章的图片,都是版面上的视觉元素,它们的存在不能证明文件含有基于数字证书的电子签名;反过来,版面上看不到印章,也不能说明文件没有签名。这是国内审核人员最常见的误区。要在支持验签的阅读器中查看签名信息,而不是看印章的颜色和清晰度。
签名之所以值得验证,在于它的法律意义。《电子签名法》第十三条规定,可靠的电子签名须同时符合若干条件,其中包括“签署后对电子签名的任何改动能够被发现”和“签署后对数据电文内容和形式的任何改动能够被发现”;第十四条规定,“可靠的电子签名与手写签名或者盖章具有同等的法律效力”(《电子签名法》,2019 年修正,中国人大网)。验签正是检验“改动能否被发现”这一条件的技术手段。
发票方面,通过税务数字账户下载的数电发票含有数字签名,无需加盖发票专用章即可入账归档(公告解读)。对于增值税电子专用发票,可以从查验平台下载增值税电子发票版式文件阅读器,查阅电子专票并验证电子签名有效性(国家税务总局公告 2020 年第 22 号第九条)。财政部会计司等三部门的答问说明,如验证结果为“该签章有效!受该签章保护的文档内容未被修改。该签章之后的文档内容无变更”,表明销售方的电子签名有效(2021 年 2 月 5 日答问)。其他类型的电子发票与 OFD 文件,请使用出具方或主管部门指定、支持验章的阅读器,并记录阅读器名称和版本。
PDF 文件可以在 Adobe Acrobat 或 Reader 的“签名”面板中验证。Adobe 的签名验证说明把状态拆成两项检查:签名人身份(证书是否受信任,并在签署时间、时间戳时间或当前时间有效)和文档完整性(签名内容是否未变,或只按签名人允许的方式变化)。“未知”(Unknown)表示检查尚未执行;“有问题”(Problematic)对应证书验证问题或签名后存在未签署的改动;“无效”(Invalid)则可能源于不允许的改动、文件损坏、违反签署策略,或签署时证书已过期、被吊销(Adobe 签名验证说明)。因此,中文界面上常见的“签名有效性未知”,往往与证书信任或验证环境有关,本身并不等于伪造;“无效”则必须查明具体原因。
对每一个相关签名,按以下顺序核查:
- 记录签名人名称、验证结果、阅读器版本和验证时间。
- 阅读警告的具体原因,把证书信任问题与内容完整性问题分开。
- 确认该签名覆盖的是哪一个版本,查看签署时的版本与当前文件。
- 查明签署后发生了哪些改动,以及文件的签署规则是否允许这些改动。
- 确认该签名人正是您这项审批所需要的人员或单位。

概念示意:签署后经允许的更新,可以与一个有效的早期签名同时存在。签名有效,不等于文件的每一个字节都没有变。
身份、范围、权限这三项检查,回答的是文件层面的问题。发票所列货物是否真实交付,需要另行取得交易记录。
如果签名人证书不受信任,请照实记录“在本验证环境中未能确认签名人可信”,并附上警告原文。不要为了得到“有效”而随意修改信任设置;证书链、吊销信息或时间戳的问题,可能需要信息部门处理。这类警告本身不构成伪造的结论。
第三步:区分文件内的属性日期与系统日期
Windows 资源管理器或手机文件管理器显示的“创建时间”“修改时间”,是本机文件系统对这个文件副本的记录;PDF 文档属性里显示的创建日期、修改日期,则保存在文件内部。两者记录的是不同的事件。下载、复制、解压都可能改变本机的文件时间,而不会改变单据上的开具日期。
例如,一份落款为 10 月 1 日的对账单,PDF 创建日期为 10 月 2 日,本机文件创建时间为您下载它的 10 月 28 日,这个先后顺序本身并不矛盾。时区不同或未记录时区,也会让表面上的先后关系不可靠。请照原样记录显示的数值和时区,不要自行换算后再下结论。
PDF 元数据可以包含创建和修改日期、生成软件以及 XMP 元数据。这些信息与页面上看到的内容相互独立,用常见的 PDF 编辑软件即可修改。因此,元数据变了,不一定意味着金额变了;元数据看起来正常,也不是独立的审计记录。
记录时写明字段和数值,例如“生成软件字段显示为某某应用”。生成软件字段只说明文件经过了哪种软件处理,不说明是谁处理的。如果元数据与出具方说明的导出流程不符,可以请出具方提供一份已知正常的样本作比较,或请其解释差异。
第四步:比对页面、提取的文字与文件结构
先比对决定业务结果的字段:主体名称、单据号码、日期、金额、币种、收款账户。再比对其余内容、页数和页序。附件被替换或缺页,即使首页完全一致,也可能改变文件的含义。
PDF 里的文字可能是软件直接生成的,也可能是扫描页面的图片,或二者混合。OCR 可以让扫描件变得可搜索、可选中,所以“能选中文字”并不能证明这些文字原本就是电子文本。PDF 协会的术语表指出,OCR 结果的准确度因页面图片质量等因素而异,PDF 格式本身对此不作任何限定(PDF Association 术语表)。
关键字段要同时看页面显示值和提取值。扫描件中,OCR 可能把数字 0 识别成字母 O,或漏掉小数点。这类差异是识别错误,不是文件被改动。
实际核查可以分三遍进行:
| 遍次 | 检查内容 | 应避免的常见错误 |
|---|---|---|
| 可见内容 | 逐页并排比对页面与关键字段 | 把扫描噪点、对齐偏差或字体差异当作改动证据 |
| 文字与数值 | 对照页面核对提取出的文字 | 把 OCR 错误算作原文件的改动 |
| 文件特征 | 表单、批注、附件和签名版本 | 以为页面比对已经覆盖了所有嵌入内容 |
如果两个阅读器对同一个关键字段显示不同,请把两种显示都记录下来并上报这一渲染差异,而不是选择符合预期的那一种。表单值、提取文字和页面显示三者不一致时同样如此:先记录分歧,再决定在本流程中以哪一种表现为准。
技术原理:PDF 为什么能显示新内容,同时保留旧字节
PDF 页面通过编号引用各个对象(如内容流),交叉引用结构告诉阅读器这些对象存放在文件的什么位置。PDF 支持增量更新:改动追加到文件末尾,原有内容保持不变(PDF Association 术语表:增量更新、交叉引用)。阅读器按最新的引用链取用对象,早先的表示形式可能仍留在文件字节里,所以“在原始文件中搜到旧金额”与“查明当前页面显示什么”是两回事。
举一个刻意简化的例子。页面引用对象 17 0 R。在版本 A 中,该对象的内容流显示“价税合计 ¥84,000”。一次增量更新追加了对象 17 的新版本,显示“价税合计 ¥89,000”,并附上指向新位置的交叉引用。阅读器按更新后的引用显示新金额;专业人员检查早先的版本时,仍可能找到旧的表示形式。

简化的增量更新示意:新的交叉引用把对象 17 解析为更新后的金额,早先的字节仍留在文件中。
这一原理可以避免两种常见误判。第一,文件中多次保存留下的结构,可能来自正当的批注或签署操作,并不说明有人恶意编辑;增量更新本来就常用于在不破坏已有签名的前提下追加批注。第二,完整重写或重新导出的文件,可能已经丢弃了早先的表示形式,所以“找不到历史版本”不能证明文件干净。即使找回了一个旧金额,也需要解释:它可能属于作废的表单值、某个附件,或一个正当的早期版本。
Fileverity 文档检测分别核验 PDF 签名、内容摘要、证书信任与允许修改范围,并将结果关联到签名覆盖的版本。扫描页的金额与日期检查配合原文摘录、字段框选和页码,让复核人员能从具体发现回到原件。
历史发票扫描件:一个余额改变了对账结果
下面用一张历史发票的扫描件,补充演示金额被改后的算术核对(主案例见后文的价税合计示例)。这张 1912 年 Dowdeswell 画廊的发票记有 560-0-0,扣减 400-0-0,余额 160-0-0。这是当时英国通行的英镑-先令-便士记法,三段分别对应镑、先令、便士。Fileverity 用 AI 在另一份副本中把余额改为 760-0-0,两项分项金额保持不变。

AI 改动演示,底图为真实的档案发票:余额由 160 英镑改为 760 英镑,两项分项金额保持不变。
来源:Dowdeswell Galleries,1912 年;费城艺术博物馆藏,经 DPLA 与 Wikimedia Commons 发布;公有领域标记,原始记录标明其在美国属于公有领域。AI 改动与排版:Fileverity。原始扫描件另行保存。
原件的算术是 560 − 400 = 160 英镑,各项的先令和便士均为零。改动后的余额比这个结果多出 600 英镑。这组对比检验的是算术关系;要检查 PDF 的版本历史,则需要 PDF 文件本身。
示例:价税合计与收款账户同时不符
以下为假设示例,单位名称与编号均为虚构。应付人员收到一张服务合同发票的 PDF,同时附有一份《收款账户变更通知函》。为便于说明,下表按含税金额列示各项目。
| 项目 | 查验平台导入查验结果 | 收到的 PDF | 核查发现 |
|---|---|---|---|
| 服务费 + 运输费 | ¥80,000 + ¥4,000 | ¥80,000 + ¥4,000 | 明细一致 |
| 价税合计 | ¥84,000 | ¥89,000 | 收到的文件比明细之和多 ¥5,000 |
| 收款账户尾号 | 供应商主数据:1842 | 变更通知函:7719 | 收款账户不同 |
| 收到金额的 OCR 结果(假设) | 不适用 | 89,OOO | 与页面显示的 89,000 核对;本例中字母 O 属识别错误 |
| 电子签名 | 不适用 | 无可验证的签名 | 无法通过验签确认文件开具后未被改动 |
先确认两边是同一张发票、同一版本。再计算 89,000 − (80,000 + 4,000) = 5,000 元。这证明收到的文件内部存在算术矛盾,并且与税务系统记录不符;它不能证明是谁改的文件,也不能排除这是一份打印另存后被改过的副本。
把金额差异与账户差异作为两项独立的问题记录,并把付款指令转入单位的例外处理流程。应付人员从本单位税务数字账户下载同一张发票,与查验结果一致,金额为 84,000 元。随后按供应商准入时备案的电话联系对方财务负责人,对方确认 84,000 元的发票、否认发出过账户变更通知。结论可以写得很精确:“收到的 PDF 在价税合计上与税务系统记录不符;随附的账户变更未获供应商确认。”OCR 错误只记在文字提取备注中。账户变更的后续处理,见对公付款前如何核验发票与收款账户。
留下他人可以复核的记录
《电子签名法》第八条规定,审查数据电文作为证据的真实性,应当考虑生成、储存或者传递数据电文方法的可靠性、保持内容完整性方法的可靠性、用以鉴别发件人方法的可靠性等因素(《电子签名法》)。日常核查无需达到诉讼标准,但按这几个维度留存记录,能让后来的复核人员看懂您做了什么。结案前,请对照以下清单:
- 收到的证据:原始文件、来源渠道、接收时间,以及计算过的哈希值。
- 对照件:具体文件或出具方记录、取得渠道,以及它为何是正确版本的理由。
- 已做的检查:查验平台结果、阅读器及版本、签名详情、比对设置、页码范围和人工核对过的字段。
- 发现:精确的差异描述,与推断和未经确认的解释分开写。
- 处理结果:独立确认的情况、决定、负责的复核人员和尚未解决的问题。
一项完整的核查,结论可能是“差异来自经授权的修订”“重大差异仍未解决”或“现有证据不足以确定文件历史”。这些具体结论,比笼统的“假的”或“没问题”更有用。
按问题选择核查工具
金额被改的问题,用查验平台、对照件和上文的比对流程;签名的问题,用支持验签、验章的阅读器。Fileverity 在这一流程中的位置如下:
- 文档检测汇集文件结构、保存版本、数字签名与文本来源证据。文档检测比对保留版本,指出保存后或签名后文本发生变化的页面,分别列出签名完整性、信任与修改权限结果,并检查扫描字段与文档内嵌照片。
- 扫描件与手机翻拍的单据图片,可使用图像鉴伪,以像素坐标标出可疑区域。
- 发票、表单与 OFD 文件的真伪,以查验平台、出具方记录和支持验章的阅读器为准;加入文字来源检测后,请把查验、比对和验签继续保留在核查流程中。
关于 AI 撰写文字与其他类型文件造假如何分工核查,见 如何识别 AI 伪造文件;报销场景的发票与小票,见如何核查报销发票与小票造假。如需为团队评估,请联系 Fileverity,说明文档类型、语言、审核量以及需要回答的撰写问题,在投入正式流程之前先确定评估范围与报价;文件处理方式见信任中心。
私有证据自标签页接收起最多保留 3 小时,刷新不续期;关闭标签页或退出登录可能提前清除。服务器确认交付后删除临时证据,未交付结果到期清理。 原文件与生成的 PDF 不作为长期档案保留;摘要和核验记录仍保留。邮件副本遵循邮件服务商和收件箱规则。到期后可能只能下载不含原文与预览的结果副本。
作者 Yang Zheng · 审核 Bill Liu