まずは卸売ECを小規模でスタートしたい方へ。リーズナブルなSaaS(ASP)版『EC-Rider Primo(プリモ)』誕生! 詳しくはこちら

Web受発注システムの帳票機能の比べ方|出せる帳票・様式の自由度・出力形式を確認する手順

◆監修・編集責任者 小園 将隆 

B2B EC-COLUMN

この記事のポイント

  • 機能表の「帳票出力」は入口にすぎず、取引先ごとにやり取りする帳票の一覧を比較の物差しにする。
  • 様式の自由度は必須の帳票に届くかで見て、追加・変更の手段・費用・期間を契約前に聞いておく。
  • 帳票として出す形式と、データとして取り出す形式を分けて確認すると、取引先と社内の転記がどこに残るかが分かる。
  • JP PINTは請求書の標準仕様で、注文書・納品書の標準ではなく、取引先が非対応ならPDFなど別の手段が要る。
  • 保存とインボイスの要件は国税庁の原典で確かめ、候補には保存・検索・記載項目の出し方を聞く。

50代後半の日本人男性が経費精算の確認をしている場面

機能表の「帳票出力」だけで判断できない理由と、先にやる帳票の洗い出し

候補のWeb受発注システムを機能表で比べると、どれにも「帳票出力」の印が並び、違いが見えにくくなります。
ところが導入後に困るのは、取引先が指定する注文書の形で出せない、請求書を相手が受け取れる形式で渡せない、といった場面です。
この差は、比べる前に自社の取引で動く帳票を洗い出し、各候補へ同じ質問をすると見えてきます。
質問は、標準で出せるか、様式をどこまで変えられるか、どの形式で渡せるか、変更時の費用と期間はどうか、の4点です。
そのうえで、取引パターンに応じて必要な水準を決めます。

発注側が出す帳票と受注側が出す帳票

「帳票出力あり」という表記から分かるのは、何らかの帳票を画面や印刷で出せるということまでです。
どの種類の帳票を、どの項目の並びで、どの形式で出せるかは、その一行からは読み取れません。
たとえば納品書は出せても、取引先が決めた項目順の注文請書は出せない、という候補もありえます。
機能表の印は、比べる材料の入口にすぎません。

帳票は、一社で完結する書類ではありません。
発注側が注文書を作って送り、受注側はそれを受けて注文請書や納品書を返し、最後に請求書を出します。
受け取った側は、その内容を自社の仕入・売上・支払の処理に使います。
そのため帳票機能を比べるときは、自社が出す帳票と、相手から受け取る帳票の両方を見る必要があります。

自社が発注側としてシステムを使うなら、中心は注文書の作成と送付、そして届いた納品書や請求書と注文内容との照合です。
検収の記録を残す運用があれば、それも対象に入ります。
受注側として使うなら、注文を受け取ったあとに出す注文請書・納品書・請求書が中心になります。
同じ会社が、仕入では発注側、販売では受注側になることもあります。
その場合は、どちらの取引でシステムを使うのかを先に決めておかないと、候補への質問が噛み合いません。

取引先ごとの一覧の作り方

一覧は、帳票の種類から作るより、取引先から作るほうが漏れにくくなります。
取引先ごとに、どの帳票をやり取りしているか、その様式は自社と取引先のどちらが決めているか、どの手段で渡しているかを書き出します。
手段は、紙の郵送や同梱、FAX、メール添付のPDF、取引先が用意したシステムへの入力などです。
現行で使っている帳票の現物か控えを一枚ずつ手元に置くと、項目の並び、押印欄、社内で手書きしている欄まで見えてきます。

書き出したら、帳票ごとに「必須」と「代替可能」に分けます。
必須は、その形で出せなければ取引が止まる、または取引先との取り決めに合わなくなるものです。
取引先が様式を指定している注文請書や、相手の支払処理に合わせた請求書がこれにあたることがあります。
代替可能は、システムの標準様式に変えても取引先の了解を得られそうなもの、あるいは社内でしか使わない控えのようなものです。
この区分は取引先との関係で決まるため、迷う帳票は先方に聞いておくと、候補の比較で無理な条件を課さずに済みます。

この一覧が、以降の質問すべての物差しになります。
候補ごとに書き方の違う説明資料を読み比べるのではなく、自社の一覧の一行ずつに対して、各候補が出せるかどうかを埋めていく形にすると、比較の軸がぶれません。

取引先 やり取りする帳票 様式を決める側 渡し方 区分
取引先A(仮) 注文請書 取引先 メール添付のPDF 必須
取引先A(仮) 請求書 自社 メール添付のPDF 代替可能
取引先B(仮) 注文書の受け取り 取引先 FAX 必須
取引先B(仮) 納品書 自社 紙で同梱 代替可能
社内 納品書の控え 自社 社内保管 代替可能
発注側と受注側の帳票のやり取り(模式図)
注文書、注文請書・納品書、請求書の順に帳票が渡り、受け取った側が自社の処理に使う流れ1発注側が注文書を作って送る2受注側が注文請書や納品書を返す3受注側が請求書を出す4受け取った側が仕入・売上・支払に使う

▼ 図の内容を文字で読む
  1. 発注側が注文書を作って送る
  2. 受注側が注文請書や納品書を返す
  3. 受注側が請求書を出す
  4. 受け取った側が仕入・売上・支払に使う
帳票の洗い出しから候補への質問までの手順(模式図)
取引先ごとに書き出し、必須と代替可能に分け、同じ質問を各候補へ向けて必要な水準を決める手順1取引先ごとに帳票を書き出す2必須と代替可能に分ける3各候補へ同じ質問をする4取引パターンに応じて水準を決める

▼ 図の内容を文字で読む
  1. 取引先ごとに帳票を書き出す
  2. 必須と代替可能に分ける
  3. 各候補へ同じ質問をする
  4. 取引パターンに応じて水準を決める

様式の自由度を見る:標準テンプレートのみか、レイアウト編集か、取引先別の切替か

候補に同じ質問票で確認する5点

様式の自由度は、三つの段階で考えると整理しやすくなります。
一つ目は、システムが用意した標準テンプレートの中から選ぶだけの段階です。
二つ目は、項目の位置や表示・非表示、ロゴや文言などを利用者側で編集できる段階です。
三つ目は、取引先ごとに異なる様式を登録しておき、帳票を出すときに相手に応じて切り替わる段階です。
どの段階までが標準で提供され、どこから先が個別対応になるかは、製品やプランによって異なります。

標準テンプレートだけの候補でも、前節の一覧に様式の指定がある帳票がなければ困らないことがあります。
逆に、指定様式の取引先が複数あるのに切替ができない候補を選ぶと、帳票を出すたびに様式を選び直したり、システムの外で作り直したりする作業が残ります。
自由度は高いほど良いというものではなく、一覧の「必須」に届くかどうかで見ます。

確認は、様式の指定がある帳票だけを一覧から抜き出し、各候補に同じ質問票で尋ねる形が向いています。
質問は、標準テンプレートで出せる範囲、レイアウト編集の可否、取引先別の様式切替の可否、追加・変更が標準機能かオプションか、費用と納期、の5点です。

質問票には、抜き出した帳票の現物か控えの写しを添えると、回答が具体的になります。
「この様式を再現できますか」と聞くと「できます」で終わりやすいのに対し、「この欄にこの項目を出せるか」「この取引先のときだけ別様式にできるか」と帳票に即して聞くと、標準の設定で済むのか、個別の作り込みが要るのかが回答から読み取れます。
回答は候補ごとに表へ並べ、同じ行どうしで見比べます。

追加・変更が標準かオプションか

導入時の比較では、今ある様式が出せるかに目が向きがちです。
しかし様式は運用中にも変わります。
新しい取引先が自社の様式を指定してくる、既存の取引先が書式を改める、社内で記載項目を足す、といった場面です。

そのとき、利用者が管理画面で編集して済むのか、提供者へ依頼して作ってもらうのかで、手間と時間が変わります。
依頼が必要な場合は、一件ごとに費用がかかるのか、契約の範囲に含まれるのか、依頼から使えるようになるまでどのくらいかかるのかを、契約前に聞いておきます。
この点は製品ごとに違い、料金表に載っていないこともあります。
見積もりを取るなら、導入時の様式作成と運用中の追加・変更を分けて書いてもらうと、あとから比べやすくなります。

利用者側で編集できる場合も、社内で誰が担当するかは決めておく必要があります。
編集画面の操作に慣れた人が限られると、様式変更のたびにその人へ作業が集まるからです。
デモや試用の機会があれば、指定様式の一枚を実際に編集してみると、画面の操作で済む範囲と、提供者への依頼が必要になる範囲の境目がつかめます。

確認項目 聞き方の例 回答で見ること
標準テンプレートの範囲 この帳票は標準の様式で出せるか 設定だけで済むか
レイアウト編集の可否 この欄の位置にこの項目を出せるか 利用者が編集できる範囲
取引先別の様式切替 この取引先のときだけ別様式にできるか 出力時に自動で切り替わるか
追加・変更の扱い 様式の追加は標準機能かオプションか 誰が作業するか
費用と納期 一件の追加・変更にかかる費用と期間 導入時と運用中を分けた金額と期間
様式の自由度の三つの段階(模式図)
標準テンプレートから選ぶ段階、レイアウトを編集する段階、取引先別に切り替える段階の違い標準テンプレートから選ぶ段階、レイアウトを編集する段階、取引先別に切り替える段階の違い標準テンプレートから選ぶ用意された様式の中から選ぶ指定様式がなければ足りることもあるレイアウトを編集する項目の位置や表示・非表示を変えるロゴや文言を利用者側で編集する取引先別に切り替える取引先ごとの様式を登録しておく出すときに相手に応じて切り替わる

▼ 図の内容を文字で読む
  • 標準テンプレートから選ぶ
    • 用意された様式の中から選ぶ
    • 指定様式がなければ足りることもある
  • レイアウトを編集する
    • 項目の位置や表示・非表示を変える
    • ロゴや文言を利用者側で編集する
  • 取引先別に切り替える
    • 取引先ごとの様式を登録しておく
    • 出すときに相手に応じて切り替わる

出力形式と連携を見る:PDF・Excel・CSV・EDI、そして標準仕様

人が読む形とシステムが読む形

様式が出せると分かっても、それをどの形式で相手に渡すかで、受け取った側の作業は変わります。
PDFや紙は、人が目で読むための形です。
受け取った担当者は内容を確認し、多くの場合は自社のシステムへ金額や品目を入力し直します。
これに対してCSV、EDI、APIは、システムが読み込むための形です。
EDIは企業間で取引データを決まった形式で交換する仕組み、APIはシステム同士が直接データをやり取りする窓口のことです。
相手側の仕組みが対応していれば、受け取ったデータを取り込めるため、手で打ち直す作業を減らせます。

Excelはその中間にあたります。
人が開いて読めるうえに表として加工もできますが、帳票の見た目を保ったまま作られたファイルは、行や列の構造が取り込みに向かないことがあります。
候補に「Excelで出せる」とあれば、見た目を再現した帳票ファイルなのか、データとして加工しやすい一覧なのかを聞き分けると、使い道がはっきりします。

形式の問題は、取引先だけでなく自社の後工程にも関わります。
受注側なら、出した請求書のデータを会計の仕訳や入金の照合に使います。
発注側なら、届いた請求書を注文内容や納品内容と突き合わせ、支払の処理へ回します。
このとき帳票の元データをCSVなどで取り出せるかどうかで、社内の別システムへの転記が残るかどうかが決まります。
候補には、帳票として出す形式と、データとして取り出す形式を分けて尋ねます。

どの形式で渡すかは、自社だけでは決まりません。
受け取る側が対応していなければ、データで送っても使ってもらえないからです。
最初の一覧に書いた「渡し方」の欄が、ここで効いてきます。
データでのやり取りに切り替えられそうな取引先と、当面はPDFや紙が続く取引先を分けておくと、候補に求める出力形式の幅が決まります。

JP PINTとは何か

請求書については、データで受け渡すための国の標準仕様があります。
JP PINTは日本のデジタルインボイスの標準仕様で、国際標準仕様のPeppol(ペポル)をベースにしており、デジタル庁が日本のPeppol Authorityとして管理しています1。
ここでいうデジタルインボイスは、紙やPDFのように人が読む請求書ではなく、システムが読み取って処理できる構造化されたデータの請求書のことです。

取引先ごとに異なるデータ形式で請求書をやり取りすると、相手ごとに取り込みの設定が要ります。
共通の標準仕様に沿っていれば、その仕様に対応した仕組みどうしで同じ形のデータを受け渡せる、というのが標準仕様を使う考え方です。
候補を比べる際は、JP PINTに沿った請求書の送受信に対応しているかを、公式の説明で個別に確かめます。
対応の書き方は製品ごとに異なるため、送る側と受け取る側のどちらに対応しているのかまで読み取ります。

注意したいのは、JP PINTは請求書の標準仕様であり、注文書や納品書の標準を示すものではない点です1。
注文書・納品書をデータでやり取りしたい場合は、取引先とどの形式で合わせるかを別に決める必要があります。
また、自社の候補がJP PINTに対応していても、取引先側が対応していなければ、その相手にはPDFなど別の手段で請求書を渡すことになります。
請求書の電子化を進める場合も、取引先ごとに渡し方を分けて考えるのはそのためです。

渡し方 主な読み手 受け取った側の作業 確認すること
PDF・紙 人 目で確認して自社システムへ再入力 様式の再現度
Excel 人とシステム 加工や取り込み(ファイルの構造次第) 見た目用かデータ用か
CSV システム 取り込みの設定をして読み込む 項目の並びを相手と合わせられるか
EDI・API システム 相手のシステムが受け取って処理 相手が同じ方式に対応しているか
人が読む形とシステムが読む形(模式図)
PDF・紙、Excel、CSV・EDI・APIを、人が読む形、中間、システムが読む形に分けた比較PDF・紙、Excel、CSV・EDI・APIを、人が読む形、中間、システムが読む形に分けた比較人が読む形(PDF・紙)担当者が内容を確認する自社のシステムへ入力し直すことが多い中間の形(Excel)人が開いて読め、表として加工もできる見た目用かデータ用かを聞き分けるシステムが読む形(CSV・EDI・API)相手の仕組みが対応していれば取り込める手で打ち直す作業を減らせる

▼ 図の内容を文字で読む
  • 人が読む形(PDF・紙)
    • 担当者が内容を確認する
    • 自社のシステムへ入力し直すことが多い
  • 中間の形(Excel)
    • 人が開いて読め、表として加工もできる
    • 見た目用かデータ用かを聞き分ける
  • システムが読む形(CSV・EDI・API)
    • 相手の仕組みが対応していれば取り込める
    • 手で打ち直す作業を減らせる

保存とインボイスの要件を、帳票機能に照らして確認する

候補に聞く質問

請求書や納品書を電子データで出したり受け取ったりすると、そのデータをどう保存するかという問題が出てきます。
電子帳簿保存法の電子取引の保存や、インボイス制度(適格請求書等保存方式)の記載事項は、帳票を発行する側にも受け取る側にも関わる制度です。
ただし、候補の比較で見たいのは制度そのものではなく、候補の帳票機能が自社の対応をどこまで支えるかです。

PDFで請求書を送る運用でも、送った・受け取った電子データの保存の扱いは考える必要があります。
システムの中に帳票が残っていても、後から取引先や日付、金額で探し出せる状態になっているとは限りません。
データが残っていることと、それを探せるように保存する仕組みがあることは別の話です。
候補には、たとえば次の点を尋ねます。

  • 発行した請求書・納品書の電子データを、システム内でどのように保存しているか
  • 保存したデータを、取引先・日付・金額などで検索できるか
  • 取引先から受け取った帳票も、同じように保存・検索できるか
  • 自社が記載すべき項目を、帳票の様式上に出せるか
  • 納品書と請求書など、複数の書類を組み合わせて記載事項をそろえる運用に対応するか
  • 様式を変えたあとも、過去の帳票を発行時の内容で表示できるか
  • 契約を終えるとき、保存したデータを取り出せるか

回答は、口頭の「対応しています」で済ませず、どの機能でどう実現しているかを公式の説明や資料で確かめておくと、社内に説明しやすくなります。
製品が制度への対応をうたっていても、自社の運用全体が要件を満たすかどうかは、帳票を使う手順や社内での保管の仕方にもよります。

原典で確認する先

保存の要件や、適格請求書に何を書く必要があるかといった制度の中身は、所管する国税庁の公表資料で確かめるのが確実です。
国税庁は、適格請求書等保存方式や電子帳簿保存法について、質疑応答の形の資料を公表しています。
資料は改訂されることもあるため、候補の説明資料や比較記事の要約ではなく、最新の原典に当たります。

原典で要件を確かめたら、それを前の小見出しの質問と突き合わせます。
要件の側から「この条件を満たすには、システムに何ができる必要があるか」と考えると、候補への質問がより具体的になります。
判断に迷う点は、顧問の税理士など自社の会計処理を知る専門家に相談すると、システムで担う部分と社内の運用で担う部分の線引きがしやすくなります。

保存とインボイス対応で候補に尋ねる観点(模式図)
保存と検索、記載事項と様式、契約終了時のデータ取り出しの三つの観点に質問を分けた整理保存と検索、記載事項と様式、契約終了時のデータ取り出しの三つの観点に質問を分けた整理保存と検索発行した帳票の電子データをどう保存するか取引先・日付・金額で検索できるか受け取った帳票も同じように保存・検索できるか記載事項と様式自社が記載すべき項目を様式上に出せるか複数の書類を組み合わせた運用に対応するか様式を変えても過去の帳票を発行時の内容で表示できるか契約を終えるとき保存したデータを取り出せるか

▼ 図の内容を文字で読む
  • 保存と検索
    • 発行した帳票の電子データをどう保存するか
    • 取引先・日付・金額で検索できるか
    • 受け取った帳票も同じように保存・検索できるか
  • 記載事項と様式
    • 自社が記載すべき項目を様式上に出せるか
    • 複数の書類を組み合わせた運用に対応するか
    • 様式を変えても過去の帳票を発行時の内容で表示できるか
  • 契約を終えるとき
    • 保存したデータを取り出せるか

取引パターン別に、必要な機能水準を決める

指定様式が多い場合

ここまでの確認項目は、すべてを最高水準で満たす候補を探すためのものではありません。
自社の取引の形に応じて、必須・あると良い・取引先次第に振り分けると、候補の絞り込みが現実的になります。
以下の三つは振り分け方を示すための仮の例で、特定の企業の実績ではありません。

取引先の多くが自社の注文書や納品書の様式を指定している、という受注側の会社を仮に考えます。
この場合、取引先別の様式切替は必須に入ります。
切替ができないと、帳票を出すたびに担当者が相手を見て様式を選ぶ必要があり、選び間違えれば相手から差し戻されます。
加えて、取引先が増えるたびに様式の追加が起きるため、追加・変更を誰が行い、一件ごとにどれだけの費用と期間がかかるかが比較の決め手になりやすくなります。
導入時の見積もりが近い候補どうしでも、運用中の追加の扱いで差が開くことがあります。

紙・FAX併用の場合

取引先の一部がWebでの受発注に移れず、紙やFAXでのやり取りが残る場合を考えます。
システムを入れても、その取引先とは注文書をFAXで受け取り、納品書を紙で渡す運用が続きます。
ここで見たいのは、システムの外で起きる取引を、どこまでシステムの中へ取り込めるかです。

受注側なら、FAXで届いた注文を担当者がシステムへ代わりに入力できるか、入力した注文から納品書や請求書を、Webの取引先と同じ流れで出せるかを確かめます。
これができれば、紙の取引先の分だけ別の台帳やExcelで帳票を作る、という二重の管理を避けられます。
残るのは、FAXの内容をシステムへ入力する作業と、その入力内容の確認です。
紙で渡す帳票は印刷したときの見た目が問われるため、印刷向けの様式の再現度は必須寄りになります。
Webに移った取引先と移っていない取引先が混在する間は、同じ帳票を相手によってPDFでも紙でも出せる柔軟さが役に立ちます。

請求書の電子授受が中心の場合

注文や納品のやり取りはWebで済み、請求書をデータで受け渡すことが中心になっている場合は、重点が様式から形式へ移ります。
人が読む見た目よりも、相手のシステムが取り込める形で渡せるかが問われるからです。
JP PINTに沿った請求書の送受信への対応、CSVなどでのデータ取り出し、受け取った請求書と注文・納品の内容を突き合わせる仕組みの有無が、必須の側に入ります。

ただし、すべての取引先がデータでの受け取りに対応しているとは限りません。
データで渡せる相手とPDFで渡す相手が並ぶことを前提に、両方を同じ元データから出せるかを見ておくと、取引先の対応が進むのに合わせて切り替えていけます。
受け取る請求書がデータで増えるほど、保存と検索の質問の重みも増します。

どのパターンでも、最後に残るのは導入後の変更にどう対応するかという問いです。
様式の追加や渡し方の切替は、契約後にも繰り返し起きます。
変更の手段、費用、依頼から使えるまでの期間を各候補から同じ形で聞き取り、帳票の一覧の横に並べておくと、導入後の見込み違いを減らせます。

確認項目 指定様式が多い 紙・FAX併用 請求書の電子授受が中心
取引先別の様式切替 必須 あると良い 取引先次第
様式の追加・変更の手段と費用 必須 あると良い あると良い
印刷向けの様式の再現度 あると良い 必須 あると良い
JP PINTに沿った請求書の送受信 取引先次第 取引先次第 必須
CSVなどでのデータ取り出し あると良い あると良い 必須
電子データの保存と検索 必須 必須 必須
取引パターン別の重点(仮の例の模式図)
指定様式が多い場合、紙・FAX併用の場合、請求書の電子授受が中心の場合で、重点が置かれる確認項目の違い指定様式が多い場合、紙・FAX併用の場合、請求書の電子授受が中心の場合で、重点が置かれる確認項目の違い指定様式が多い場合取引先別の様式切替が必須様式の追加・変更の手段と費用が決め手になりやすい紙・FAX併用の場合FAXの注文を代わりに入力し、同じ流れで帳票を出せるか印刷向けの様式の再現度が必須寄り請求書の電子授受が中心の場合JP PINTに沿った請求書の送受信が必須CSVなどでのデータ取り出しが必須PDFで渡す相手にも同じ元データから出せるか

▼ 図の内容を文字で読む
  • 指定様式が多い場合
    • 取引先別の様式切替が必須
    • 様式の追加・変更の手段と費用が決め手になりやすい
  • 紙・FAX併用の場合
    • FAXの注文を代わりに入力し、同じ流れで帳票を出せるか
    • 印刷向けの様式の再現度が必須寄り
  • 請求書の電子授受が中心の場合
    • JP PINTに沿った請求書の送受信が必須
    • CSVなどでのデータ取り出しが必須
    • PDFで渡す相手にも同じ元データから出せるか

取引先ごとの帳票と渡し方を一覧にしても、どれを必須とし、候補への質問をどう組むかは、自社の取引の事情に照らさないと決めにくいためです。

相談では、洗い出した帳票の一覧をもとに、候補へ尋ねる質問と、必須・あると良いの振り分けを整理できます。無料相談で要件を整理する

要点の整理

軸 基準
帳票の洗い出し 取引先ごとにやり取りする帳票・様式を決める側・渡し方を一覧にし、必須と代替可能に分ける
様式の自由度 標準テンプレート・レイアウト編集・取引先別切替のどこまで要るかを、必須の帳票で判断する
追加・変更 利用者が編集できる範囲と、依頼時の費用・期間を契約前に聞く
出力形式 帳票として出す形式と、データとして取り出す形式を分けて確認する
請求書の標準仕様 JP PINTへの対応は公式の説明で確かめ、非対応の取引先への渡し方も決めておく
保存と記載事項 制度の要件は国税庁の原典で確認し、候補には保存・検索・記載項目の出し方を聞く

様式の追加費用や保存・検索の仕組みは料金表や機能表だけでは比べにくく、候補ごとの回答を同じ物差しにそろえる作業が残るためです。 相談では、自社の取引パターンに照らして各候補の回答のどこに差があり、契約前に何を追加で聞くべきかを確かめられます。

BtoB通販システムのご相談

貴社の商習慣に合わせたご提案をいたします。

無料相談はこちら

よくある質問

取引先が指定する様式があるとき、候補システムに何を聞けばよいか。

指定様式の現物か写しを添えて、その様式を標準の設定で再現できるのか、個別の作り込みが要るのかを聞きます。
あわせて、その取引先の帳票を出すときに様式が自動で切り替わるか、作成にかかる費用と期間、先方が様式を改めたときの変更の扱いも確かめます。
可能であれば、実際に出力した見本を見せてもらうと、欄の位置や改行の崩れまで確認できます。

帳票の様式を後から追加・変更するとき、確認しておくことは何か。

利用者が管理画面で編集できる範囲と、提供者へ依頼が必要になる範囲の境目です。
依頼が必要な場合は、費用が一件ごとにかかるのか契約に含まれるのか、依頼から使えるまでの期間を聞きます。
様式を変えたあとも、過去に発行した帳票を発行時の内容で表示できるかも確認しておくと安心です。

PDFで請求書を送る運用でも、保存や検索の要件は確認が要るのか。

確認が要ります。
PDFでも電子データでのやり取りになるため、送った・受け取ったデータの保存の扱いを考える必要があります。
具体的な要件は所管する国税庁の公表資料で確かめ、候補には、発行・受領した帳票をどう保存し、取引先・日付・金額などで検索できるかを尋ねます。

紙やFAXの取引先が残る場合、システムの帳票機能はどう使い分けるのか。

受注側なら、FAXで届いた注文を担当者がシステムへ代わりに入力し、そこからWebの取引先と同じ流れで納品書や請求書を出せるかが要点です。
これができれば、紙の取引先だけ別のExcelで帳票を作る二重管理を避けられます。
紙で渡す帳票は印刷時の見た目が問われるため、印刷向けの様式の再現度もあわせて確認します。

JP PINTに対応した請求書は、すべての取引先で受け取ってもらえるのか。

受け取ってもらえるとは限りません。
JP PINTは日本のデジタルインボイスの標準仕様で、データの形をそろえるための取り決めです。
受け取る取引先の側も対応した仕組みを持っていなければ、その相手にはPDFなど別の手段で請求書を渡すことになります。
また、JP PINTは請求書の標準であり、注文書や納品書の標準ではありません。

◆監修・編集責任者

小園 将隆

株式会社フライトソリューションズ ECサービス部 マネージャー

BtoB通販のパッケージシステム「EC-Rider B2B Ⅱ」の導入支援をはじめ、製造業、卸売業をはじめとした法人向け通販サイト構築を多数手掛ける。卸売領域の専門知識をもとに、日本の商習慣に固有の課題をパッケージシステムの機能追加によって解決。BtoB流通の販路拡大を支援する。

> プロフィールの詳細を見る

  1. 1 出典:デジタル庁「デジタルインボイス(電子インボイス)」(2026年閲覧)

◆この記事について

独自調査以外の一次情報は、省庁・公的機関を中心とした信頼性の高い情報源から引用し、出典を明記しています。
年次更新される統計については、引用元の最新版を確認したうえで掲載しています。

※この記事は上記の監修・編集責任者がAIの協力を得て制作しています。

監修確認日:

記事内容に関するお問い合わせ:お問い合わせフォーム

BtoB EC(受発注)サイト構築システム「EC-Rider B2B Ⅱ」への
各種お問い合わせ

ページTOPへ戻る
無料相談を予約 お見積
平日10:00~18:00
page
top