什么是数字发票？──与「用邮件发送 PDF 发票」有何不同

「我们的发票已经是 PDF 格式，通过邮件发送。开票业务已经电子化了。」

能这么说的公司越来越多。然而，在接收方，财务人员仍然要打开收到的 PDF，核对金额、交易对象和日期，再重新录入到财务系统中。在开具方，销售管理系统生成的发票数据，也还是要先转换成供人阅读的文档，才能发送出去。

把这种「数据 → 文档 → 再变回数据」的绕路彻底去掉，让发票信息直接从一个系统传递到另一个系统的机制，就是数字发票。

本文将梳理数字发票究竟是什么、它与 PDF 发票有何不同、它与日本的 Invoice 制度是什么关系，以及中小企业该如何看待和应对它。

需要说明的是，本文只是对机制本身的说明，不涉及税务层面的具体判断（例如某种保存方式是否合规、能否抵扣等）。个别税务判断请咨询税务师或所辖税务机关。

1．先说结论

根据日本数字厅的说明，数字发票是一种让发票信息从卖方的系统直接对接到买方的系统、无需人工介入、可自动处理的机制。

关键在于「无需人工介入」这一点。把纸质发票、PDF 发票、数字发票三者做个对比，如下表所示。

PDF 发票只是把纸质文档变成了电子文件，「人工阅读后重新录入」这种业务形态本身并没有改变。这属于纸质的替代，也就是「电子化」。

数字发票则是把发票信息本身作为计算机可以直接处理的数据来交换，改变的是业务流程本身的形态，这才是「数字化」。数字发票推进协会（EIPA）也是在这个意义上定位数字发票的——它不是单纯的纸质电子化，而是要在重新审视整个业务流程的语境下推进数字化。

这种关系，和此前几篇文章中梳理的订购 EDI 是完全相同的结构。「什么是 EDI？如何让企业间的订购业务更轻松」一文处理的是订单数据，而数字发票可以理解为它在发票场景下的对应版本，这样会更容易理解。

2．日本的 Invoice 制度与数字发票，是两件不同的事

首先要把两个容易混淆的概念区分开来。

日本的「Invoice 制度」（合格发票等保存方式）是一项与消费税相关的税务制度。正如日本国税厅的说明所示，该制度于 2023 年 10 月 1 日起施行。为了让买方能够获得进项税额抵扣，卖方需要交付满足要求的「合格发票（Invoice）」并加以保存，合格发票需要记载以下事项：

• 接受文件一方的姓名或名称
• 卖方的姓名或名称及登记编号
• 交易发生的年月日
• 交易内容（是否属于适用轻减税率的品目）
• 按税率分类合计后的对价金额及适用税率
• 按税率分类的消费税额等

登记编号是向税务机关提出登记申请后获得通知的编号，根据日本国税厅的合格发票开具事业者公示网站的说明，其构成为「T + 13 位数字」。

这里需要注意的重点是，合格发票既可以用纸质形式交付，也可以用 PDF 形式交付。Invoice 制度规定的是「要记载什么内容」，而不是「要以什么格式、通过什么渠道发送」。

数字发票正是「以什么格式、通过什么渠道发送」这个问题的答案之一。它把合格发票所需的信息，作为标准化的结构化数据，在系统之间直接交换。

也就是说，二者的关系可以整理如下：

「使用的会计软件已经支持 Invoice 制度」和「已经通过数字发票收发发票数据」，是两种不同的状态。前者很多公司已经完成，后者才刚刚开始普及。

3．作为基础的 Peppol ── 全球标准网络与 JP PINT

数字发票之所以能被称为「标准化」的数据，是因为它建立在 Peppol 这一国际标准规格之上。

Peppol 是一套用于在网络上交换发票等电子文档的「文档规格」「运营规则」「网络」框架，主要在欧洲各国被广泛使用。在日本，日本数字厅担任 Japan Peppol Authority（日本 Peppol 管理局）负责管理，自 2021 年 9 月起作为 OpenPeppol 的成员参与运作。

3.1．四角模型 ── 类似邮件的运作方式

Peppol 的数据交换采用被称为「四角模型（Four-Corner Model）」的结构。EIPA 的说明将其比喻为邮件的运作方式。

卖方（C1）                                   买方（C4）
    │                                          ↑
    │ 传递发票数据                              │ 接收发票数据
    ↓                                          │
卖方接入点（C2） ──→ 买方接入点（C3）
                    Peppol 网络

卖方（C1）把数据交给自己签约的接入点（C2），C2 通过 Peppol 网络发送给买方一侧的接入点（C3），再送达买方（C4）。

用邮件来类比，接入点相当于邮件服务器。就像无论对方使用哪家邮件服务，邮件都能送达一样，只要卖方和买方都支持 Peppol，即便双方使用的是各自不同的会计软件或服务，也能相互收发发票数据。这正是与传统 EDI 的重大区别——传统 EDI 往往需要针对每个交易对象单独商定对接方式。

3.2．JP PINT ── 日本标准的文档规格

在 Peppol 网络上收发的发票数据所遵循的日本标准规格，就是 JP PINT。它由日本数字厅公布，其字段定义与 Invoice 制度中合格发票的要求相对应。

适用对象不仅限于普通发票。截至 2026 年 7 月，已公布以下三种规格：

该规格处于持续更新之中，根据日本数字厅的公布，2026 年 6 月 8 日上述三种规格已全部更新至 Ver. 1.1.3。

不必因此担心「是不是要自己读懂这份规格并自行实现」。正如第 8 章所述，对大多数公司而言，JP PINT 只存在于所使用软件的内部，直接接触规格本身的是开发和提供软件的一方。

4．在数字发票中，作为「数据」流动的到底是什么

「结构化数据」这个说法比较抽象，这里再具体展开一步。

数字发票中流动的核心内容，正是第 2 章列出的合格发票记载事项本身。同样的信息，究竟是以 PDF 形式还是以数据形式送达，「之后能做什么」完全不同。

4.1．登记编号的核对可以自动化

在这张表中，最容易看出实务效果的，是登记编号的处理方式。

在 Invoice 制度下，为了确认收到的发票开具方是否确实为已登记的合格发票开具事业者，需要在日本国税厅的合格发票开具事业者公示网站上检索登记编号。在 PDF 发票的运作方式下，这项工作是靠人工输入编号来完成核对的。

日本国税厅为这个公示系统配备了 Web API 功能，可以通过系统直接获取指定登记编号的公示信息，或指定期间内的更新信息（使用前需要申请应用 ID，免费）。

如果登记编号不是以「印在 PDF 上的文字」而是以「数据字段」的形式送达，这项核对工作就可以交给系统来完成。可以把它嵌入到新交易对象的登记确认，或既有交易对象登记状态的定期核查中，实现自动化。有些会计软件本身就自带这类核对功能，因此比较现实的顺序是：先确认自家软件已有的功能，如果要嵌入自主开发的系统中，再考虑使用 Web API。

4.2．从「阅读」到「验证」

不仅是登记编号，以数据形式送达的本质变化，在于确认工作的性质本身发生了改变。

在 PDF 运作方式下，财务人员的工作是「阅读、转录、目视核对」。而以数据形式送达后，转录环节消失，确认工作变成了「只查看系统验证后被标记出来的异常项」。按税率分类的金额是否吻合、付款期限是什么时候、与该交易对象过去的发票相比是否有异常——这类核查，恰恰是系统比人工做得更快、更不容易遗漏的工作。

5．数字发票能让哪些工作变得轻松

5.1．接收方 ── 录入与核对工作减少

效果最容易看出来的，是接收发票一方的财务工作。

在使用 PDF 发票的情况下，财务人员通常需要完成以下工作：

• 从邮件中查找并打开发票
• 核对交易对象名称、金额、日期、登记编号
• 录入财务系统
• 再次核对录入内容
• 反映到付款计划中

在数字发票的场景下，由于发票数据直接被系统读取，这个流程中最核心的「查看、录入、核对」环节原则上不再需要。人工的工作转变为对已读取内容的审批，以及处理金额不符、来源陌生等例外情况。

月末发票集中到来的公司，这种差异会更加明显。转录错误和重复录入减少的原理，与订购 EDI 完全一样。

5.2．开具方 ── 「制作文档并发送」这道工序消失

在开具方，把销售管理系统或开票系统生成的发票数据打印出来装订邮寄、或转换成 PDF 附加到邮件中发送，这些工序都不再需要。

发送之后「是否已经收到」「请重新发送」这类往来沟通也会随之减少。收件地址填错、忘记添加附件、加密压缩包（ZIP）的处理等邮件附件常见的问题，也可以一并规避（邮件附件方式发送发票所存在的问题，在「为什么邮件安全领域中 PPAP 是不可取的？正确的做法是什么？」一文中也有提及）。

5.3．更进一步 ── 与付款、收款核销的对接

当发票信息作为结构化数据流动起来之后，还能进一步对接到后续业务：在买方一侧，可以生成付款计划、反映到转账数据中；在卖方一侧，则可以与收款核销进行比对。

这正是订购篇文章中提到的「EDI 会成为从订单一路连接到库存、发货、开票的基础」这一说法，从发票一侧看到的样子。当订单到发票、再到付款的整个流程都通过数据连接起来时，企业间的事务性工作会被压缩到最小。

6．与电子账簿保存法的关系

一谈到数字发票，日本的电子账簿保存法（电帳法）必然会同时被提起。这里简单梳理二者的关系。

根据日本国税厅关于电子账簿等保存制度的说明，自 2024 年 1 月 1 日起，凡是以电子数据方式收发（电子交易）发票、收据等文件，就必须以电子数据的原始形式保存，保存时大致需要满足以下两点要求：

• 确保真实性 ── 通过时间戳、更正删除记录或防止更正删除等措施，防止数据被篡改
• 确保可视性 ── 保持可按日期、金额、交易对象检索的状态，并能够输出到屏幕或纸面上

数字发票的收发也属于电子交易，因此同样属于这项保存义务的适用对象。也就是说，一旦引入数字发票，就需要同时决定收到和发送的数据要如何保存。

在实务中，许多支持 Peppol 的会计、开票软件本身就具备满足保存要求的功能，因此基本做法是「使用已支持的软件，并确认其保存功能的设置与运行方式」。不过，自身的保存方式是否满足要求，最终判断属于税务层面的问题，请务必咨询税务师或所辖税务机关确认。

7．梳理常见的误解

在谈论数字发票时，总会反复出现一些误解。这里先做一次梳理。

第一点尤其重要。既然不是强制义务，采用与否就不应基于「不用会有麻烦」这样的心态，而应该基于能为自家开票业务减少多少手工工作量来判断。正因如此，后面「如何入手」一章，请把它当作业务改善的话题来读，而不是合规话题。

另一方面，交易对象提出「希望以数字发票的方式发送（或接收）」的可能性今后会越来越高。正因为是自愿性质，先采用的一方反而会在交易条件的沟通中占据主动，这一点和从传真订购转向 Web 订购的过程是一样的。

8．中小企业该如何入手

8.1．现实可行的入口是「使用已支持的软件」

一提到数字发票，听起来像是要构建某种全新的系统，但对大多数中小企业而言，现实可行的入口是：确认目前正在使用（或即将选用）的会计、开票软件是否已经支持 Peppol。

EIPA 公布了已支持 Peppol 数字发票的服务清单。此外，日本数字厅也公开了在日本获得认证的 Peppol 服务提供商清单。如果贵公司使用的软件本身已经支持，就有可能无需大规模开发即可开始收发数据。

建议按以下顺序确认：

1. 贵公司的会计、开票软件是否支持 Peppol（数字发票）
2. 如果支持，是支持发送还是接收，费用如何
3. 主要交易对象是否具备接收能力（对方也需要有支持相关软件或服务）
4. 收到数据后的保存（电帳法合规）在软件端是如何处理的

8.2．已有自主开发系统的情况

如果贵公司使用自主开发的系统来运营销售管理或开票业务，还需要再多考虑一层。

不过，通常并不需要读懂 JP PINT 的规格文档，自行对接 Peppol 接入点。更现实的架构大致是这样的：

• 由自家系统通过 CSV 或 API，将发票数据传递给支持 Peppol 的开票服务或会计软件，把发送工作交给对方处理
• 接收也交由已支持的软件来完成，再把读取到的数据回传到自家系统中

也就是说，自家系统需要改造的重点，并不是「支持 Peppol」本身，而是与已支持软件之间准确传递数据的对接部分。这一点，完全可以套用订购 Web 化一文中提到的「CSV 导入作为中间形态」（「如何把传真订购迁移到 Web」）中同样的设计思路。

8.3．不必着急，但也不能置之不理

截至 2026 年，数字发票并不是那种「不用就会导致业务停摆」的东西。如果交易对象仍然要求 PDF 发票，当前阶段两者并用的状态还会持续。这与订购业务中传真、Web 并用的情况一样，迁移是分阶段推进的。

另一方面，在与大型交易对象或地方政府、政府机构的交易中，数字发票被提及的场景今后会越来越多。日本数字厅也在持续公布政府采购和企业间交易中的应用案例。哪怕只是提前确认一次「如果交易对象提出要求，自家软件是否能够对应」，作为一种准备也已经很有意义。

8.4．判断优先级的检查清单

作为「我们公司该什么时候行动」的参考，符合以下条目越多，检讨的优先级就越高：

• 每月收发的发票数量在数十份以上
• 月末月初，财务人员因为发票的录入、核对、开具工作而经常加班
• 收到发票后需要手工核对登记编号
• 曾有过录入失误或重复付款的惊险经历
• 主要交易对象或行业协会已经开始提及数字发票或 Peppol
• 恰好正在计划更换会计、开票软件，或改造自主开发的系统

反之，如果每月发票只有几份，交易对象也相对固定，就没有必要着急。只需在下次更换软件时，把「是否支持 Peppol」加入选型条件即可。

重要的是不要把「引入数字发票」本身当作目的。把第 4 章、第 5 章列出的「哪些手工工作会减少」套用到自家实际业务中去数一数，如果能具体看到会减少的工作，就值得推进；如果看不到，那就说明时机还未到，仅此而已。

9．在订购数字化的整体版图中

本文是围绕订购相关数据对接的系列文章中的第 3 篇。这里梳理一下整体的位置关系。

EDI 是「企业间数据交换」这一大的思路，其在接单一侧的实践是传真订购向 Web 的迁移，而在发票一侧的标准化形式，就是数字发票。

该从哪里入手，因公司而异。如果订单录入的负担较大，就从接单一侧入手；如果发票的开具、接收数量较多，就从开票一侧入手，这都是很自然的判断。二者的共同点在于：都要从数一数「同一份信息被人工重复录入了多少次」开始。

总结

• 数字发票是一种让发票信息从卖方的系统直接对接到买方的系统、无需人工介入、可自动处理的机制
• PDF 发票是文档的「电子化」，接收方的录入工作依然存在。数字发票则是用结构化数据把业务本身连接起来的「数字化」
• 日本的 Invoice 制度（税务制度）与数字发票（数据交换机制）是两件不同的事。即使已经完成制度层面的合规，大多数公司在数字发票的使用上仍处于起步阶段
• 基础是国际标准 Peppol，在日本由数字厅作为 Peppol Authority 负责管理，并公布了日本标准规格 JP PINT
• 通过接入点构成的四角模型，即使对方使用不同的软件也能相互收发数据，这正是与传统一对一 EDI 的区别
• 流动的数据正是合格发票记载事项本身。登记编号的核对（借助日本国税厅公示系统的 Web API）、按税率分类的金额核算等，原本靠人工目视完成的确认工作，都可以转变为系统的自动验证
• 收到的数字发票属于电子账簿保存法所定义的电子交易，必须以电子数据的原始形式保存
• 使用与否是自愿的，并非强制义务。判断依据不应是「不采用会有麻烦」，而应是自家开票业务中能减少多少手工工作
• 中小企业现实可行的入口，是使用支持 Peppol 的会计、开票软件。如果已有自主开发的系统，需要设计的是与已支持软件之间的数据对接部分

正在考虑开票与订购业务数据对接的朋友

如果希望减少发票开具或接收环节的事务负担，却不清楚该从自家销售管理系统或开票业务的哪个环节入手，第一步需要先梳理清楚目前发票数据的流转方式。

只要确认清楚销售管理系统是如何生成发票数据的、如何发送给交易对象、收到的发票又是如何录入财务系统的，就能看清哪些环节可以通过数字发票以及与已支持软件的对接实现自动化。

合同会社小村软件（KomuraSoft LLC）可以就自主开发的业务系统与会计软件、支持 Peppol 的服务之间的对接，为您提供开票与订购相关数据对接的现状梳理与实现方案探讨咨询。

我们也可以在不以全面重建为前提的情况下，保留现有机制，只对发票数据的收发入口部分进行分阶段对接的方案设计。

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

常见问题

汇总了咨询这一主题时常见的问题。

数字发票和电子化发票（PDF 发票）有什么区别？

PDF 发票只是把一份供人阅读的文档变成了电子文件，接收方仍然需要一边看内容一边重新录入到财务系统中。数字发票则是把发票信息本身作为标准化的结构化数据发送，买方的系统可以直接读取并处理。这是把纸质文件替换成文件的「电子化」，和用数据把业务流程本身连接起来的「数字化」之间的区别。

如果已经符合日本的 Invoice 制度要求，是不是也就等于支持数字发票了？

这是两件不同的事。日本的 Invoice 制度（合格发票等保存方式）是一项与消费税进项税额抵扣相关的税务制度，合格发票既可以用纸质形式交付，也可以用 PDF 形式交付。数字发票指的是在系统之间交换这些发票信息所使用的数据格式和流通机制（Peppol、JP PINT），是否采用它，是与税制合规完全独立的另一项决策。

中小企业要开始使用数字发票，需要做哪些准备？

现实可行的入口，是使用已支持 Peppol 的会计、开票软件。数字发票推进协会（EIPA）公布了已支持相关服务的清单，如果贵公司正在使用的软件已在其中，有时只需启用相应设置即可开始收发。如果贵公司使用的是自主开发的销售管理系统，则需要考虑如何与支持相关标准的软件或服务商对接。

收到的数字发票应该如何保存？

数字发票的收发属于日本电子账簿保存法所定义的电子交易，因此自 2024 年 1 月起，必须以电子数据形式原样保存，并满足防篡改措施（确保真实性）以及可按日期、金额、交易对象检索（确保可视性）这两项要求。许多支持 Peppol 的软件本身就具备满足保存要求的功能，但贵公司的具体运营方式是否满足要求，请咨询税务师或所辖税务机关确认。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。