什麼是數位發票（Digital Invoice）？──與「把請款單 PDF 寄送 email」有何不同

「我們的請款單已經改成 PDF，用 email 寄送了。我們公司的請款業務已經電子化了。」

能這樣說的公司愈來愈多。然而，收到請款單的一方，會計人員仍然要打開收到的 PDF，確認金額、交易對象與日期，再重新輸入到會計系統。開立請款單的一方，也是把銷售管理系統做出來的請款資料，特地轉換成給人閱讀的文件後才寄出。

消除這種「資料 → 文件 → 再變回資料」的繞路，讓請款資訊直接從系統傳到系統的機制，就是數位發票（Digital Invoice）。

本文將整理數位發票是什麼、與 PDF 請款單有何不同、與發票制度是什麼關係，以及中小企業該如何面對這個議題。

另外，本文僅為機制解說，不涉及稅務判斷（例如保存方式是否適當、能否扣除等）。個別的稅務判斷請務必向稅理士或所轄稅務機關確認。

1．先講結論

根據日本數位廳的說明，數位發票是指將請款資訊從賣方系統直接傳遞給買方系統、不經人工介入、自動處理的機制。

重點在於「不經人工介入」這一部分。整理紙本、PDF、數位發票三者的差異如下。

PDF 請款單只是把紙本變成電子檔案，「人閱讀後重新輸入」這種業務型態並沒有改變。這是紙本的替代，也就是電子化。

數位發票則是把請款資訊本身，以電腦可以處理的資料形式來交換。這是改變業務型態本身的數位化。數位發票推進協議會（EIPA）也將數位發票定位在「不只是紙本電子化，而是重新檢視整體業務流程」的數位化脈絡之中。

這層關係，與先前文章整理過的訂購／出貨 EDI 完全相同。「什麼是 EDI？如何讓企業間的訂購作業更輕鬆」一文處理的是訂單資料，把數位發票想成它的請款單版本，會比較容易理解。

2．發票制度與數位發票，是兩回事

首先要釐清兩個容易混淆的詞彙。

發票制度（合格請款單等保存方式）是與消費稅有關的稅制。如國稅廳的說明所述，該制度於 2023 年 10 月 1 日開始實施。這是為了讓買方能夠獲得進項稅額扣除，而要求保存賣方交付的「合格請款單（Invoice）」等的制度，合格請款單須記載以下事項。

• 收受文件之對方的姓名或名稱
• 賣方的姓名或名稱及登錄號碼
• 交易年月日
• 交易內容（是否為減輕稅率適用品項）
• 依稅率區分並合計後的對價金額與適用稅率
• 依稅率區分的消費稅額等

登錄號碼是向稅務署申請登錄後取得的號碼，根據國稅廳合格請款單發行事業者公示網站，其格式為「T ＋ 13 位數字」。

這裡重要的是，合格請款單無論用紙本或 PDF 交付都可以。發票制度規範的是「記載什麼內容」，而不是「用什麼形式、什麼途徑傳送」。

數位發票，就是「用什麼形式、什麼途徑傳送」這個問題的其中一個答案。它把合格請款單所需的資訊，以標準化的結構化資料，直接在系統之間交換。

也就是說，兩者的關係如下。

「使用已因應發票制度的會計軟體」和「用數位發票收發請款資料」是不同的狀態。前者多數公司已經完成，後者則正處於逐漸普及的階段。

3．Peppol 這個基礎架構 ── 世界標準的網路與 JP PINT

之所以能說數位發票是「標準化」的資料，是因為它建立在 Peppol（Peppol）這套國際標準規格之上。

Peppol 是一套用來在網路上交換請款單等電子文件的「文件規格」「運用規則」「網路」框架，主要在歐洲，但目前已被許多國家採用。在日本，由數位廳擔任 Japan Peppol Authority（日本 Peppol 管理局）負責管理，自 2021 年 9 月起以 OpenPeppol 會員身分展開活動。

3.1．四角模型 ── 類似 email 的機制

Peppol 的資料交換採用稱為「四角模型（4 Corner Model）」的架構。EIPA 的解說以 email 的機制來比喻說明。

賣方（C1）                                  買方（C4）
    │                                          ↑
    │ 傳遞請款資料                              │ 接收請款資料
    ↓                                          │
賣方端存取點（C2） ──────────→ 買方端存取點（C3）
                    Peppol 網路

賣方（C1）將資料傳遞給自己簽約的存取點（C2），C2 透過 Peppol 網路將資料傳送到買方端的存取點（C3），最後送達買方（C4）。

以 email 來比喻，存取點就相當於郵件伺服器。就像不論對方使用哪一家郵件服務都能收到信一樣，即使賣方與買方各自使用不同的會計軟體・服務，只要雙方都因應 Peppol，就能互相交換請款資料。這一點，正是它與過去那種每個交易對象都得個別協商規格的傳統 EDI 之間的一大差異。

3.2．JP PINT ── 日本標準的文件規格

在 Peppol 網路上交換之請款資料的日本標準規格，就是JP PINT。由數位廳公布，其項目定義已對應發票制度所需的合格請款單內容。

適用的文件不僅限於請款單。截至 2026 年 7 月，已公布以下 3 種規格。

這套規格會持續更新，根據數位廳的公布，上述 3 種規格已於 2026 年 6 月 8 日全數更新至 Ver. 1.1.3。

不必因此擔心「自家公司是不是也要讀懂這份規格書並自行實作」。如同第 8 章所述，對多數公司而言，JP PINT 是隱藏在因應軟體內部的存在，直接接觸規格的是開發、提供軟體的一方。

4．數位發票中，實際流動的「資料」是什麼

光說「結構化資料」不容易想像，這裡再具體說明一步。

數位發票中流動的核心項目，正是第 2 章所列合格請款單的記載事項本身。同樣的資訊，用 PDF 傳遞和用資料傳遞，「之後能做的事」完全不同。

4.1．可自動化登錄號碼的比對

在這張表中，實務效果最容易理解的，就是登錄號碼的處理方式。

在發票制度下，為了確認收到的請款單開立者是否真的是合格請款單發行事業者，必須在國稅廳合格請款單發行事業者公示網站上檢索登錄號碼──這是一道作業程序。在 PDF 請款單的運作方式下，這道程序是靠人工輸入號碼來確認的。

國稅廳為這個公示系統提供了Web-API 功能，可以透過系統直接取得指定登錄號碼的公示資訊，或指定期間內的更新資訊（使用前須申請發行應用程式 ID，免費）。

如果登錄號碼不是「印在 PDF 上的文字」，而是以「資料項目」的形式送達，這道比對工作就能交給系統處理。可以用來自動化新交易對象的登錄確認，或既有交易對象登錄狀態的定期檢查。有些會計軟體本來就內建這類比對功能，因此先確認自家軟體的功能，若要整合進自行開發的系統再考慮使用 Web-API，會是比較務實的順序。

4.2．從「閱讀」轉為「驗證」

不只是登錄號碼，資料化送達的本質，在於確認作業性質的改變。

在 PDF 運作方式下，會計人員的工作是「閱讀、抄錄、用眼睛確認」。若改為資料送達，抄錄這道工序就會消失，確認也會轉變成「只看系統驗證結果中被標記出來的部分」這種形式。各稅率的金額是否正確、付款期限是什麼時候、與過去同一交易對象的請款相比是否有異常──這類檢查，是系統比人工更快、也更不容易遺漏的工作類型。

5．數位發票能讓哪些工作變輕鬆

5.1．接收方 ── 減少輸入與比對作業

效果最容易理解的，是接收請款單一方的會計業務。

使用 PDF 請款單時，會計人員通常要進行以下作業。

• 從 email 中找出請款單並開啟
• 確認交易對象名稱・金額・日期・登錄號碼
• 輸入到會計系統
• 再次確認輸入內容
• 反映到付款排程中

在數位發票的情況下，因為請款資料會直接匯入系統，這個流程中核心的「看、輸入、確認」原則上都不再需要。人的工作會轉變為對匯入內容的核可，以及處理金額不符或不明來源等例外狀況。

月底請款單集中湧入的公司，這種差異會愈明顯。減少抄錄錯誤與重複輸入的道理，與訂購／出貨的 EDI 相同。

5.2．開立方 ── 「製作文件並寄送」這道工序消失

在開立方，銷售管理系統或請款系統做出來的請款資料，不再需要印出來封裝寄送，也不需要轉成 PDF 附加在 email 中寄出。

寄出後「有沒有收到」「請重寄一次」之類的往返也能減少。也能擺脫收件人寫錯、忘記附加檔案、加密 ZIP 密碼傳遞方式等 email 附件常見的問題（email 附件式請款單運作方式的問題，在「為什麼 email 安全上 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 請款單，暫時仍會與 PDF 並行使用。這與傳真・Web 接單並行的情況相同，轉移會是分階段進行的。

另一方面，在與大型客戶或地方政府・官方機關的交易中，談到使用數位發票的場合今後會愈來愈多。數位廳也正在推動公布政府採購及企業間交易中的活用案例。哪怕只是先確認一次「若被交易對象要求，自家軟體是否能夠應對」，作為預先準備也已足夠有意義。

8.4．判斷檢討優先順序的檢查清單

作為「我們公司該何時行動」的參考標準，符合以下項目愈多，檢討的優先順序就愈高。

• 每月收發的請款單有數十張以上
• 月初月底，會計人員因請款單的輸入・比對・開立作業而加班
• 收到請款單的登錄號碼確認是靠人工進行
• 曾有過輸入錯誤或重複付款的驚險經驗
• 主要交易對象或業界團體已開始談論數位發票或 Peppol
• 剛好在規劃更換會計・請款軟體，或改造自行開發系統

反之，若請款單每月只有幾張、交易對象也固定，就沒有急著行動的理由。只要在軟體更換時機，把「下一套軟體是否因應 Peppol」列為選型條件之一即可。

重要的是，不要把導入本身當成目的。將第 4 章、第 5 章所列「哪些手工作業會減少」套用到自家業務去計算，如果能看到具體會減少的作業，就值得推進；若看不出來，那就只是時機尚早而已。

9．在受發訂數位化的整體地圖中

本文是處理受發訂周邊資料串接系列文章的第 3 篇。這裡整理一下整體的定位關係。

EDI 是「企業間資料交換」這個大方向的概念，而接單方的實踐是傳真接單轉移到 Web，請款方的標準化形式則是數位發票，三者之間就是這樣的關係。

該從哪裡著手，因公司而異。若接單輸入的負擔較大，就從接單方著手；若請款單的開立・接收張數較多，就從請款方著手，這是很直觀的判斷。共通的做法是，從計算「同樣的資訊，人工重複輸入了幾次」開始。

總結

• 數位發票是指將請款資訊從賣方系統直接傳遞給買方系統、不經人工介入、自動處理的機制
• PDF 請款單是文件的「電子化」，接收方的輸入作業依然存在。數位發票則是以結構化資料串連業務的「數位化」
• 發票制度（稅制）與數位發票（資料交換的機制）是兩回事。即使已因應制度，多數公司在數位發票的使用上仍處於今後才要展開的階段
• 基礎是 Peppol 這套國際標準，在日本由數位廳擔任 Peppol Authority 進行管理，並公布日本標準規格 JP PINT
• 透過經由存取點的四角模型，即使雙方使用不同軟體也能互相交換資料，這是與傳統個別式 EDI 的差異所在
• 流動的內容正是合格請款單的記載事項本身。登錄號碼的比對（國稅廳公示系統的 Web-API）、各稅率金額的覆核等，過去靠人工目視的確認作業，都可以轉變為系統驗證
• 收到的數位發票屬於電子帳簿保存法上的電子交易，必須以電子資料原樣保存
• 使用與否是任意的，並非義務。判斷依據不是「不因應會困擾」，而是自家請款業務中哪些手工作業能夠減少
• 中小企業現實可行的入口，是使用因應 Peppol 的會計・請款軟體。若有自行開發的系統，則需設計與因應軟體之間的資料串接部分

給正在考慮請款業務・受發訂資料串接的您

如果您想減少請款單開立或接收的事務負擔，卻不知道該從自家銷售管理系統或請款業務的哪個環節著手，首先需要整理目前請款資料的流向。

只要確認銷售管理系統如何產生請款資料、如何寄送給交易對象，以及收到的請款單如何輸入到會計系統，就能看出透過數位發票或因應軟體的串接，可以自動化的範圍有多大。

合同會社小村軟體，可就自行開發的業務系統與會計軟體・Peppol 因應服務之間的串接，以及請款・受發訂周邊的資料串接，提供現狀整理與實現方式的諮詢服務。

不必以全面翻新為前提，也可以在保留現有機制的情況下，研議僅將資料的出入口分階段串接的方案。

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

數位發票和電子發票（PDF 請款單）有什麼不同？

PDF 請款單只是把原本給人閱讀的文件變成電子檔案，收到的一方仍必須一邊看內容、一邊重新輸入到會計系統。數位發票則是把請款資訊本身以標準化的結構化資料傳送，買方系統可以直接匯入並處理。前者是把紙本換成檔案的「電子化」，後者是用資料串連業務處理流程的「數位化」，兩者性質不同。

如果已經因應了發票制度，是不是也代表已經因應數位發票了？

這是兩回事。發票制度（合格請款單等保存方式）是與消費稅進項稅額扣除有關的稅制，合格請款單無論用紙本或 PDF 交付都可以。數位發票則是在系統之間交換這些請款資訊所用的資料格式與流通機制（Peppol・JP PINT），是否採用要與稅制因應分開判斷。

中小企業要開始使用數位發票，需要準備什麼？

現實可行的入口，是使用已因應 Peppol 的會計・請款軟體。數位發票推進協議會（EIPA）已公布已因應服務的清單，若自家使用的軟體本來就支援，有時只要開啟設定就能開始收發。若是使用自行開發的銷售管理系統，就需要研議如何與因應軟體或服務供應商串接。

收到的數位發票應該如何保存？

數位發票的收發屬於電子帳簿保存法上的電子交易，自 2024 年 1 月起，必須以電子資料原樣保存，並同時符合防止竄改的「真實性確保」措施，以及可依日期、金額、交易對象檢索的「可視性確保」要求。多數因應 Peppol 的軟體都具備符合保存要求的功能，但自家的實際操作是否符合要求，請務必向稅理士或所轄稅務機關確認。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。