NetSuiteの電子インボイス(JP PINT・Peppol)対応|デジタルインボイスの送受信

「請求書はPDFにしてメールで送っている。だから電子インボイスには対応済みだ」

経理の現場で、よく聞く言葉です。

ところが受け取った側では、そのPDFを見ながら、金額や取引先を手で打ち込んでいます。

デジタルインボイスとは、請求書を、機械が処理できる構造化されたデータでやり取りする仕組みです。

日本の標準仕様がJP PINT、その土台となる国際的な仕組みがPeppol(ペポル)です。

NetSuiteは、NetSuite E-Invoicingでデジタルインボイスの送信と受信に対応しています。

ただ、送受信は相手があって初めて成り立ちます。

自社だけが準備しても、取引先がネットワークに乗っていなければ、データは届きません。

では、どの取引先から、どの順番で始めればよいのか。

目次

この記事で分かること

  • デジタルインボイスとPDF請求書の違い
  • Peppol・JP PINTとは何か、4コーナーモデルの仕組み
  • NetSuite E-Invoicingでできることと、日本での利用の確認先
  • 「制度対応」と「送受信の仕組み」の違い
  • 取り組む順番と、ベンチャーネット・日本オラクル・自社の役割の分け方

デジタルインボイスとは|PDF請求書との違い

構造化されたデータとは、金額・取引先・税率などの項目を、機械が処理できる形に整えたデータです。

PDFをメールで送るのは、「請求書の電子化」ではあります。

しかし受け取った側は、内容を目で読み、自分のシステムへ入力や転記をしなければなりません。

デジタルインボイスは、相手のシステムへデータのまま届きます。

入力も転記も要らず、打ち間違いも減ります。

観点PDF請求書(メール添付)デジタルインボイス(JP PINT)
データの形人が目で読む文書・画像機械が処理できる構造化データ
受け取る側の作業入力・転記が要るシステムに取り込める
様式送り手ごとにばらばらJP PINTで標準化されている
届け方メールなどで個別に送るPeppolの共通のネットワークで送受信

PeppolとJP PINTの関係

Peppolは、電子文書をやり取りするための国際的な標準仕様であり、ネットワークでもあります。

国や会社の違いを越えて、請求書などのデータを送受信できるよう設計されています。

このPeppolをもとに、日本の制度や商習慣に合わせた仕様がJP PINTです。

デジタル庁の公式ページでは、次のように案内されています(出典:デジタル庁公式、2026年9月確認)。

  • デジタル庁は、2021年9月からOpenPeppolのメンバー(Japan Peppol Authority)として活動している
  • 標準の請求書の仕様「Peppol BIS Standard Invoice JP PINT」は、Ver.1.1.3に更新・公表されている(2026年6月8日)
  • 仕入明細書の仕様と、適格請求書発行事業者以外の請求書の仕様も、それぞれ用意されている

デジタル庁のよくある質問では、JP PINTの利用も電子インボイスのやり取りも義務ではないとされています。

(出典:デジタル庁公式、2026年9月確認)

取り組むかどうかは、効果の大きさで決めてかまいません。

4コーナーモデル

Peppolは「4コーナーモデル」という形でデータを届けます。

  • 売り手(C1)が、自社の窓口となるアクセスポイント(C2)へデータを渡す
  • 窓口が、買い手側の窓口(C3)へネットワーク経由で送る
  • 買い手側の窓口が、買い手(C4)へデータを届ける

送り手と受け手が別のシステムを使っていても、共通の仕様に沿っていればやり取りできます。

取引先ごとに専用のやり方を用意する必要はありません。

裏を返せば、C3・C4がそろわない相手には、データを送れないということです。

Peppolの4コーナーモデル 売り手C1が自社の窓口C2へデータを渡し、C2がネットワーク経由で買い手側の窓口C3へ送り、C3が買い手C4へ届ける。 Peppolの4コーナーモデル C1 売り手 請求書のデータを作る C2 売り手の窓口 アクセスポイント ネットワーク経由 C3 買い手の窓口 アクセスポイント C4 買い手 データのまま取り込む C3・C4がそろわない相手には データを送れない
Peppolの4コーナーモデル

NetSuite E-Invoicingでできること

NetSuiteは、「NetSuite E-Invoicing」でデジタルインボイスの送受信に対応しています。

Oracleは2025年7月23日、日本向けの発表でJP PINTのサポートを案内しました。

公式の説明は、請求書の発行の速度と精度を高め、インボイス制度に効率よく対応できるというものです(出典:Oracle日本公式、2026年9月確認)。

公式の製品ページの案内は、次のとおりです(出典:Oracle NetSuite公式、2026年9月確認)。

機能内容
作成・送信NetSuiteで作った請求書を、各国の規制で求められる形式に変換し、ネットワークへ送る
受信・取込届いた各国の形式の電子インボイスを、JP PINT形式に変換してNetSuiteに取り込む
ネットワークへの接続Peppolなどの国内外のネットワークや、各国の電子インボイスの基盤につなぐ
グローバルAPI1つの連携で複数の国の要件に対応。電子署名・QRコード・税務当局の承認にも対応
CTCへの対応税務当局への登録・承認に必要な形式に変換して送る
変換と保管UBL 2.1形式のXMLを各国の形式に変換。作成・送信・保管までを自動化

CTC(継続的取引管理)は、税務当局が取引のデータを継続的に把握する仕組みです。

UBLは、請求書などの電子文書の国際的なデータの書き方を指します。

見落とされやすいのが、受信にも対応している点です。

取引先から届いたデジタルインボイスも、データのまま取り込めます。

買掛・支払の側の入力が減るので、効果は送る側だけにとどまりません。

日本で使うときの確認先

2025年7月の発表では、日本での提供の時期は示されていません。

自社のアカウントで使えるか、利用の条件や費用はどうか。

ここは、日本オラクルのアカウントの担当に聞いてください。

NetSuite認定パートナー(Solution Provider)であるベンチャーネットは、次の3段で整理しています。

  • (a) いま日本で使えること:自社のアカウントでE-Invoicingを有効にできるか、JP PINTで送受信できるか
  • (b) 開発で補えること:取り込んだ後の承認の流れ、デジタルインボイスとPDFの送り分けなど
  • (c) 順次提供されること:JP PINTの版の更新への追従など、公式の更新を追う部分

「制度対応」と「送受信の仕組み」は別物

電子インボイスの話には、性質の違う2つの層があります。

  • 制度対応:適格請求書の記載の要件を満たす、電子帳簿保存法に沿って保存する、といった税・制度の中身
  • 送受信の仕組み:請求書を構造化データとしてネットワークでやり取りする、JP PINT・Peppolへの対応

E-Invoicingが担うのは、後者です。

NetSuiteでは、制度対応を主にJapan Localization SuiteApp(日本の制度・商習慣に合わせる拡張機能)が受け持ちます。

詳しくはNetSuite Japan Localization SuiteAppとはをご覧ください。

制度そのものは、NetSuiteと電子帳簿保存法・インボイス制度の対応で扱っています。

  • 「適格請求書を正しく発行・保存したい」→ 制度対応
  • 「請求書をデータのまま送受信し、転記をなくしたい」→ デジタルインボイス
やりたいことから、層を選ぶ:制度対応と送受信の仕組み 適格請求書を正しく発行・保存したいなら制度対応で、主にJapan Localization SuiteAppが担う。請求書をデータのまま送受信して転記をなくしたいなら送受信の仕組みで、NetSuite E-Invoicingが担う。 やりたいことから、層を選ぶこうしたいならこの層適格請求書を正しく発行・保存したい制度対応主にJapan LocalizationSuiteApp請求書をデータのまま送受信し、転記をなくしたい送受信の仕組みNetSuite E-InvoicingJP PINT・Peppol2つは別の層。棚卸しも分けて行う
やりたいことから、層を選ぶ:制度対応と送受信の仕組み

月末にまとめて請求する会社は、NetSuiteで締め請求書(Invoice Summary)を作る方法と注意点もあわせてご覧ください。

判断の物差し

請求書のやり取りの3つのやり方

やり方中身向く会社注意点
A. PDFをメールで送る請求書をPDFにして送る請求の枚数が少ない受け取る側の転記が残る
B. PDFを受け取ってデータ化受け取ったPDFを読み取りのサービスでデータにする取引先の多くがPDFのまま読み取り結果の確認の手間が残る
C. JP PINTで送受信Peppolのネットワークでデータのままやり取りする取引先の対応が進んでいる、枚数が多い取引先の対応が前提

Cに近づくほど、最初から項目がそろったデータが手に入ります。

「いつもと違う請求額」をAIで点検するような使い方も、データがそろっていてこそです。

受け取ったPDFの入力を減らす方法は、NetSuite×TOKIUM連携でも扱っています。

取り組む価値が大きい会社・急がなくてよい会社

価値が大きいのは、次のような会社です。

  • 送る・受け取る請求書の枚数が多い
  • 取引先から「データで受け取りたい」と言われ始めている
  • 海外の拠点や取引があり、国ごとの電子インボイスの要件がある

反対に、請求書の枚数が少ない会社や、主な取引先がPeppolに対応していない会社は、急がなくてかまいません。

適格請求書や電帳法への対応がまだなら、そちらが先です。

NetSuiteを使っていない会社は、いまの会計ソフトや請求のサービスがPeppolに対応しているかを先に見てください。

デジタルインボイスのためだけに、ERPを入れ替える必要はありません。

これから選ぶ会社と、いま使っている会社

これからNetSuiteを選ぶ会社

デモや見積もりの段階で、次の3つを聞いておきます。

  • E-Invoicingを使う場合の、利用の条件と費用
  • JP PINTでの送信と受信を、どこまで試せるか
  • 制度対応(Japan Localization SuiteApp)との役割の分け方

NetSuiteの導入そのものの費用は、中身によって大きく開きます。

ベンチャーネットが支援したNetSuite導入の費用では、3名程度で購買・販売だけの事例が150万円程度・1.5か月でした。

100名程度で購買・販売・在庫・会計に外部システム連携を含めた事例は、2億円程度(うち開発約7割)・1.5年です。

その間に、30名程度・購買・販売・プロジェクト管理で2,000万円程度・1年の事例があります。

20名程度・購買・販売・在庫・会計で情シスなしの事例は、3,000万円程度・2年でした。

差を生む要因は、機能範囲・開発(特に外部システム連携)・社内の体制・ユーザー数の4つです。

電子インボイスの承認の流れを作り込むなら、「開発」の側に入ります。

4事例の詳細は、NetSuiteの料金で扱っています。

いまNetSuiteを使っている会社

見直しは、次の順で進めます。

  1. 制度対応が、いまの運用で回っているか
  2. 送受信の枚数が多い取引先はどこか
  3. その取引先が、Peppolに対応しているか

パートナーを変えて見直す場合も、この順番は変わりません。

2つの立場で確かめることを図にすると、次のとおりです。

立場ごとに確かめること:これから選ぶ会社といま使っている会社 これからNetSuiteを選ぶ会社は、E-Invoicingの利用の条件と費用、JP PINTの送受信をどこまで試せるか、制度対応との役割の分け方を聞く。いま使っている会社は、制度対応、枚数の多い取引先、その取引先のPeppolへの対応の順で見直す。 立場ごとに確かめることこれからNetSuiteを選ぶ会社デモや見積もりの段階で聞くE-Invoicingの利用の条件と費用JP PINTの送受信をどこまで試せるか制度対応との役割の分け方いまNetSuiteを使っている会社この順で見直す1制度対応が、今の運用で回っているか2送受信の枚数が多い取引先はどこか3その取引先がPeppolに対応しているか
立場ごとに確かめること:これから選ぶ会社といま使っている会社

よくある3つの失敗

失敗1:「PDFを送れば対応済み」と思い込む

起きること:受け取った請求書を、今も手で転記している。取引先から「データで受け取りたい」と言われて慌てる。

原因:PDFは電子化であって、構造化されたデータのデジタルインボイスではない。

避け方:電子化で止めるかデジタルインボイスまで進めるかを分けて考えます。

そのうえで、枚数の多い取引から優先順位をつけます。

失敗2:「制度対応」と「送受信の仕組み」を混同する

起きること:インボイス制度に対応したから、デジタルインボイスも済んだと考える。逆に、JP PINTに対応すれば税の要件まで満たせると考える。

原因:2つは別の層。制度対応はJapan Localization SuiteAppなど、送受信はE-Invoicingが担う。

避け方:制度対応と送受信を分けて棚卸しします。

それぞれをどの機能で賄うかを、一覧にしておきます。

失敗3:取引先の対応を見ずに一斉に切り替える

起きること:全取引先へ一気に切り替えようとして、現場が混乱する。結局、紙やPDFとの併用が続く。

原因:送受信は相手があって成り立つ。買い手側もネットワークに乗っていなければ、データは届かない。

避け方:対応している取引先から段階的に始めます。

一部で回し、運用が固まってから広げます。

ベンチャーネットならこう見る|取引先を「送る・補う・残す」に分ける

ベンチャーネットは、NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しています。

電子インボイスの相談で、最初に伺うのは3つだけです。

  • 制度対応は、もう済んでいるか
  • 送る枚数と受け取る枚数は、それぞれどれくらいか
  • 枚数の多い取引先は、Peppolに対応しているか

型:取引先を3つに仕分ける

答えがそろったら、取引先を次の3つに分けます。

  • 標準で送る:Peppolに対応済みの取引先。E-Invoicingの標準の送受信に乗せる
  • 開発で補う:取り込んだ後の承認の流れや、PDFとの送り分けを作り込む
  • 残す:対応していない取引先。当面はPDFや紙のまま続ける
取引先を3つに仕分ける:標準で送る/開発で補う/残す Peppolに対応済みの取引先はE-Invoicingの標準の送受信に乗せ、承認の流れやPDFとの送り分けは開発で補い、対応していない取引先は当面PDFや紙のまま残す。効果の大きい1〜2社から試す。 取引先を3つに仕分ける標準で送るPeppolに対応済みの取引先E-Invoicingの標準の送受信に乗せる開発で補う取り込んだ後の承認の流れやPDFとの送り分けを作り込む残す対応していない取引先当面はPDFや紙のまま続ける効果の大きい1〜2社から試す「残す」取引先があっても、失敗ではない
取引先を3つに仕分ける:標準で送る/開発で補う/残す

全取引先を一度に切り替える必要はありません。

「残す」に入る取引先があっても、失敗ではない。

効果の大きい取引先を1〜2社選び、そこから試すのが近道です。

役割の分け方

電子インボイスは、税・制度の知識とシステムの知識の両方が要る領域です。

誰が何を持つかを、最初に決めておきます。

担い手受け持つこと
日本オラクルライセンス、トレーニング、製品サポート。E-Invoicingの利用の条件と費用
ベンチャーネット要件定義、設定、承認の流れなどの開発、保守、プロジェクトの管理
自社(経理・税の専門家)制度の要件の判断、取引先への確認、枚数の把握

ベンチャーネットは請負契約に対応しています(準委任も相談可)。

要件を伺うのは、営業ではなく導入コンサルタントです。

税の専門家とシステムの担当が別々に話を進めると、2つの層の境目で抜けが出ます。

今日できること|請求書の枚数を数える

先月の請求書について、次を書き出してください。1時間ほどでできます。

項目記入の例(架空)自社
送った請求書の枚数300枚
受け取った請求書の枚数150枚
受け取った請求書のうち、手で転記したもの150枚
枚数の多い取引先の上位3社A社・B社・C社
上位3社のPeppolへの対応不明

最後の行が「不明」なら、上位3社に聞いてみることが最初の一歩になります。

よくある質問

Q1. JP PINTとPeppolは、何が違うのですか

PeppolをもとにJP PINTが日本向けに作られています。

Peppolは国際的な標準仕様とネットワークです。

JP PINTはデジタル庁が管理する、日本のデジタルインボイスの標準仕様です(第2章)。

Q2. PDFの請求書をメールで送るだけでは、だめなのですか

PDFでのやり取り自体が禁止されているわけではありません。

デジタル庁も、電子インボイスのやり取りは義務ではないとしています。

ただしPDFでは、受け取る側の入力や転記が残ります(第1章・第2章)。

Q3. 取引先がデジタルインボイスに対応していなくても使えますか

相手もネットワークに乗っている必要があります。

対応している取引先から始め、対応していない取引先は当面PDFや紙のまま残します。

取引先を「標準で送る・開発で補う・残す」に分けると、順番を決めやすくなります(第7章・第8章)。

Q4. 電帳法・インボイス制度の対応も、これで同時にできますか

送受信の仕組みと制度対応は別の層です。

適格請求書に何を書くか、電帳法に沿ってどう保存するか。

こうした要件は、主にJapan Localization SuiteAppなどが担います(第4章)。

Q5. NetSuite E-Invoicingは、日本ですぐに使えますか

利用できるかと条件はアカウントの担当に聞いてください。

Oracleは2025年7月にJP PINTのサポートを発表していますが、提供の時期は示されていません(第3章3-1)。

Q6. 海外取引がない中小企業でも、関係がありますか

国内の取引でもJP PINTの送受信は使えます。

請求書の枚数が多い会社や、受け取った請求書の転記に手間がかかっている会社では、効果が出やすい領域です。

まとめ

  • デジタルインボイスは、請求書を構造化されたデータでやり取りする仕組み
  • 日本の標準仕様がJP PINT、土台がPeppol。利用は義務ではない
  • NetSuiteはNetSuite E-Invoicingで送信と受信に対応。日本での利用の条件はアカウントの担当に聞く
  • 制度対応と送受信の仕組みは別の層
  • 取引先を「標準で送る・開発で補う・残す」に分け、効果の大きい取引から段階的に

PDFを送っているから対応済み、とは限りません。

まず先月の請求書の枚数と、上位の取引先の対応を数えてみてください。

もう少し詳しく知りたい方へ

制度対応と送受信の仕組みを、どの順番で整えるか。

その整理の段階から、ご相談をお受けしています。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

持田 卓臣のアバター 持田 卓臣 株式会社ベンチャーネット代表取締役

持田 卓臣(もちだ たくおみ)
株式会社ベンチャーネット 代表取締役

ヒューレット・パッカード社でITコンサルタントとして従事した後、2005年に株式会社ベンチャーネットを設立。
Oracle NetSuite Solution Provider Partner として、中堅・中小企業向けクラウドERP「NetSuite」の導入・運用支援を提供しています。
SEO・広告・SNS・ウェブ・MA・SFAと一気通貫で培ってきたデジタルマーケティング領域の業務知見を活かし、NetSuiteを軸とした経営DXを支援しています。
著書:『普通のサラリーマンでもすごいチームと始められる レバレッジ起業「バーチャル社員」があなたを救う』(KADOKAWA、2020年)

目次