請求書の電子化のやり方｜発行側の手作業をなくす7工程とは

結論は3つです。

 

1. 電子化の対象は帳票そのものではなく、承認後に人の手で動いている工程である
2. 既存の承認システムは残し、承認済みのデータをAPIで受け取れば転記は生まれない
3. 最初に着手すべきは製品選びではなく、承認から受領確認までの工程の仕分けである

 

1つ目は、電子化の対象が帳票ではなく工程だということです。今回の事業本部では、承認そのものはすでに社内グループウェアで電子化されていました。残っていたのは、承認の後にPDFを作る、営業が確かめる、メールで送るという人の手の工程です。帳票をPDFにしただけでは、この工程は1つも減りません。

 

2つ目は、承認の仕組みを作り直さないことです。今回の電子化では、承認後の工程を担う仕組みとして、ノーコードで業務アプリを組み立てられるSlopebase（スロープベース）を活用しました。社内に承認システムがある以上、Slopebase上に同じ承認をもう1本作れば二重管理になります。今回は承認済みの見積・請求情報をAPI連携でSlopebaseの見積・請求トランへ登録し、そこから帳票の出力、送付、受領確認までを一続きにする設計にしました。

 

3つ目は、最初にやるべき作業が、承認から受領確認までを「誰が・どこで・自動か手動か」で仕分けることだという点です。どこに人の判断を残すかが決まらないまま製品を選ぶと、導入後に確認の手順が抜け落ちます。

 

この進め方には、向いている業務と向いていない業務があります。

 

向いている業務：

1. 社内に承認の仕組みがあり、承認済みの見積・請求情報をデータとして取り出せること。
2. 帳票のひな型が固定で、明細が1ページに収まること（今回は5〜10行）。
3. 押印を帳票のひな型に埋め込む運用で、社内の合意が取れること。
4. 取引先がWeb上でファイルを受け取る運用に応じられること。

 

向いていない業務：

1. 明細の行数が案件ごとに大きく変わり、複数ページの帳票が多いこと。
2. 取引先ごとに、先方指定の請求受付システムへの登録を求められること。
3. 発行した請求データを会計や販売管理のシステムへ自動で戻す必要があること。

 

 

この記事で扱う範囲と、扱わない範囲

 

扱う範囲
見積書・請求書の発行という1つの業務を対象に、承認後の工程の仕分けから、データの受け渡しの設計、タスクに置く項目、見送った設計判断までを、電子化後の想定フローと確認事項への回答から記録します。

 

扱わない範囲
次のテーマはそれぞれ独立した記事にまとめているため、本記事では深追いせず、該当記事へご案内します。

 

請求処理を自動化するツールの種類と選び方
請求処理を自動化する最新ツール事情と導入メリット、選び方を紹介
紙の帳票全般のペーパーレス化の進め方
ペーパーレス化の事例と進め方
受け取った請求書の支払処理の効率化
支払処理にかかる日数が減らないのはなぜ？
押印の廃止と内部統制の考え方
脱ハンコで内部統制を強化する実践ガイド
承認ルートの型と分岐の設計論
承認ルート設計の実務ガイド
API連携そのものの進め方
ノーコードで始めるAPIデータ連携入門
見積管理システムの選び方
見積管理システムの導入で承認フロー高速化と利益率向上へ

請求書の電子化とは、紙で作成・郵送・保管していた請求書を、電子データで作成・送付・受領・保存する形に切り替えることです。PDFをメールで送る、取引先にWeb上でダウンロードしてもらう（Web請求書）、請求書発行システムから電子請求書を送るといった方法があり、いずれも請求書の電子化にあたります。

 

ただし、ひと口に請求書の電子化といっても、請求書を「発行する側」と「受け取る側」とでは、電子化する工程がまったく異なります。どちらの電子化を進めるのかを最初に決めておかないと、検討するツールも社内で提案する相手もずれていきます。

発行側の電子化と受取側の電子化の違い

発行側の電子化
対象となるのは、請求内容の確定（承認）、帳票の作成、取引先への送付、受領の確認、控えの保存です。主な目的は、作成と送付の手間や郵送費を減らし、「送ったか」「受け取ってもらえたか」を見えるようにすることです。

 

受取側の電子化
対象となるのは、請求書の受領、内容の確認と承認、支払処理、会計システムへの計上、保存です。主な目的は、紙の請求書を読み取って入力する手間を減らし、支払処理を早めることです。

 

本記事で扱うのは、このうち発行側の電子化です。なかでも、請求内容の承認が済んだ後の「作成・送付・受領確認」の工程を対象にしています。受け取った請求書の処理については、支払処理にかかる日数が減らないのはなぜ？をご覧ください。

請求書の電子化で押さえておきたい電子帳簿保存法のルール

請求書を電子データで送ったり受け取ったりすると、そのやり取りは電子帳簿保存法でいう「電子取引」にあたります。2024年1月からは、電子取引でやり取りしたデータは、紙に印刷して保存するのではなく、電子データのまま保存することが必要になりました。

 

この保存のルールは、受け取る側だけでなく送った側にもかかります。つまり発行側で請求書を電子化すると、取引先へ送った請求書の控えも、電子データのまま保存しておく必要があるということです。

 

電子データで保存するときは、主に次の2つの要件を満たすことが求められます。

 

改ざんを防ぐ措置：
タイムスタンプの付与、訂正・削除の履歴が残る（または訂正・削除ができない）システムでの保存、訂正・削除の防止に関する事務処理規程の制定と運用などのいずれかを行うこと

 

必要なときに確認できる状態：
取引年月日・取引金額・取引先で検索できるようにし、ディスプレイやプリンタ、操作説明書などを備え付けておくこと

 

売上高が一定以下の事業者は検索の要件が不要になるなど、条件によっては緩和の措置もあります。自社にどの要件がかかるかは、国税庁の電子帳簿保存法関係のページで最新の内容を確かめてください。

 

また、インボイス制度のもとでは、紙で発行する場合も電子で発行する場合も、登録番号や税率ごとの消費税額といった記載事項をそろえた適格請求書を発行する必要があります。電子化するときは、これらの記載事項が帳票のひな型に入っているかも確かめておきます。

 

発行側の電子化を設計するときは、承認後の工程の仕分けとあわせて、「送った請求書の控えを、どこに、どの要件で保存するか」も決めておく必要があります。今回の設計では、出力した帳票を仕組みの上の格納先に置いていますが、保存要件への対応そのものは本記事では扱っていません。使う仕組みで要件を満たせるのか、控えを経理側の保存の仕組みへ渡すのかを、工程を仕分ける段階で確かめておくことをおすすめします。

ここでは、請求書の電子化全般の話ではなく、承認後の発行業務に絞ります。自社に当てはまるものがないか確かめながらお読みください。

承認後の発行業務を人の手で回している組織に共通する3つの状況

1. 承認は電子化されているのに、PDF化と送付が手作業で残っている
2. 送付前の確認のタイミングを、その都度人が調整している
3. 送った後の状況が、個人のメールの中にしか残らない

 

1つ目は、承認の後に手作業が残っていることです。今回の事業本部では、見積や請求は社内システムで承認されたあと、担当者が手作業でPDFにし、お客様へメールで送っていました。承認が電子化されていても、その後の工程が人の手である限り、発行の速さは担当者の手が空いているかどうかで決まります。

 

2つ目は、送付前の確認を都度調整していることです。帳票をお客様に送る前に、営業側で内容を確かめたいというニーズがありました。これ自体は必要な確認ですが、仕組みの上に確認の場所がないため、誰がいつ確かめるのかを毎回人が段取りしていました。

 

3つ目は、送付後の状況がメールの中にしか残らないことです。メールで送った帳票は、お客様が開いたかどうかを送り手の側から確かめる手段がありません。同社では、ほかの業務についても「メールでのやりとりでナレッジにならない」という声が挙がっていました。

 

この3つはいずれも、メールやPDFの性能ではなく、承認のデータと送付の仕組みが途切れている業務フローが原因です。

承認と送付のあいだで工程が途切れる構造

承認システムの守備範囲は「承認する」までで、送付はそれぞれの担当者のメールが担っています。そのあいだにある「承認済みのデータを帳票にし、確かめ、お客様に渡す」工程には、明確な責任者がいません。責任者が不在の工程は、手の空いている人が善意で埋めることになり、その段取りはどこにも記録されません。

 

なお、この業務の直接の当事者は事業本部と社外の取引先ですが、同社では関係会社への案内や、フォーキャストの確認といった社外・社内とのやり取りも、メールとExcelの送り合いで行われていました。請求書の発行は、こうした「承認や依頼の後に、人の手で相手に渡している業務」の1つとして検討の対象になっています。

 

ここからが本題です。製品を選ぶ前の作業として、承認後の工程の仕分けを手順に落とします。要件定義書の書き方そのものは要件定義書の必要項目と書き方｜実案件のサンプルと未決事項の管理法（テンプレート付）で解説しているため、ここでは発行業務の仕分けを扱います。

承認から受領確認までを7つの工程に分解する

「発行の手間を減らしたい」という認識のままでは設計に入れません。承認から受領確認までを、誰が・どこで行い、自動か手動かで分けます。今回は次の7工程でした。

 

① 見積・請求情報の承認 事業本部／社内グループウェア／既存のまま
② 見積・請求トランへの登録 Slopebase／API連携で自動
③ 帳票の出力と格納 Slopebase／帳票出力ツールとのAPI連携で自動
④ 帳票の送付依頼 Slopebase／タスク機能（起票が手動か自動かは要検証）
⑤ 通知メールからのログイン 取引先／メール通知のURLからゲスト環境へ
⑥ 帳票のダウンロード 取引先／ゲスト環境での操作
⑦ ダウンロード済みの確認 Slopebase／ステータスで自動反映

 

こう並べると、手作業が残りうるのは④だけになります。そして④は「自動にできないから手動」なのではなく、「送る前に営業が確かめたい」という判断を残すための工程です。仕分けのコツは、自動にできるかどうかではなく、人の判断を挟むべき工程かどうかで分けることです。この2つの基準を混同すると、確認の手順ごと自動化してしまい、導入後に誤送付のリスクが発生する可能性があります。

現物の帳票とやり取りから確認事項を書き出す手順とチェックリスト

工程が決まったら、実際の帳票と、いまのやり取りを見ながら確認事項を書き出します。今回、事業本部との間で確認した項目と回答は次のとおりです。

 

Slopebase上でワークフローや押印を行うか
行わない。社内に承認システムがあるため、押印は帳票のひな型に入れておく運用で可
押印がある場合の押印フロー
上記の回答により対象外
見積書・請求書のひな型にどの項目があるか
帳票のサンプルで確認を進める
帳票上の項目以外に、Slopebaseだけで持ちたい管理項目があるか
現状は不要
明細の行数は可変か
ほぼ可変ではない。見積も請求も5〜10行で、基本は1ページに収まる
後続システムへのデータ引き継ぎがあるか
今のところない
引き継ぐ場合のデータ項目
上記の回答により対象外

 

あわせて、帳票を送る前の確認の方法を、次の4つから選んでもらう形で確かめました。

 

A：PDF帳票をワークフローで確認する
B：PDF帳票に押印する（押印サービスの利用や連携）
C：PDF帳票をプレビューして目で確認する
D：その他（印刷して押印など）

 

選択肢を並べて聞くと、「確認は必要だが、承認をもう一度回したいわけではない」などという本音が引き出せます。

 

着手前に、以下の2つのチェックリストで自社の業務要件とシステム選定の観点を整理しておくと、その後の設計がスムーズになります。

 

検討チェックリスト
□取引先とのデータ授受が必要か？
□自社内で営業や経理等の役割が分担されているか？
□承認フローが必要か？（既存の承認システムで足りるか）
□取引先マスタ等の自社独自のマスタ管理が必要か？
□管理番号を採番するか？
□帳票作成には計算式が必要か？
□取引先と帳票のデータ授受を行うか？
□システム内／外でデータ連携が必要か？

 

システム選定のポイント
□スモールスタートができるか？
□ユーザ課金かトランザクション課金か？（社外の取引先にもアカウントが必要か）
□プラグイン必須で高額にならないか？
□カスタマイズが必須か？
□取引先とのデータ授受は可能か？
□システム内、システム間のデータ連携ができるAPI機能があるか？

帳票のサンプルで出力ツールとの相性を先に確かめる

もう1つ、着手前にやっておくと後が楽なのが、実際の請求書のサンプルを使って、帳票出力ツールとの相性を突き合わせておくことです。ひな型の項目や明細の行数、押印の位置が出力ツールで再現できるかは、サンプルを流してみないと分かりません。今回についても、後からシステムの手戻りが発生するのを防ぐため、API連携の構築に入る前の段階で、この出力テストを行っています。

 

---

請求書発行の棚卸しから始めたい方へ

 

本記事で使った7つの工程への分解の考え方と、確認事項の整理表をまとめた資料をご用意しています。承認後の発行業務のどこから手をつけるかを決めたい方は、こちらからお受け取りください。

 

---

 

「請求書の自動化」と聞くと、請求書（帳票）そのものを自動で作成する機能を思い浮かべがちです。しかし、実務において最も効果を発揮するのは、「承認済みのデータを、人の手を介さずに次の工程へ受け渡す仕組み」を構築することです。ここでは、今回のシステム設計の全体像について、実現できたことと、あえて見送ったことの両面から解説していきます。

承認済みデータをAPIで受け取ると転記は消える

今回の設計では、社内グループウェアで承認された見積・請求情報を、API連携でSlopebaseの見積・請求トランへ登録します。この登録をきっかけに帳票出力ツールが動き、PDF帳票がSlopebase上の任意の格納先に配置されます。承認済みの内容がそのまま帳票になるため、担当者が承認画面を見ながらPDFを作り直す工程がなくなります。

 

設計上のポイントは、データの入口を承認システムに一本化したことです。Slopebase側で見積や請求の内容を入力し直す画面は作らず、帳票上の項目以外の管理項目も持たせていません。入口が1つなら、承認された内容と送った帳票の内容が食い違う余地がありません。

送付と受領確認を1帳票1タスクで管理する

送付と受領確認には、Slopebaseのタスク機能を使います。帳票1通につきタスクを1件起票し、宛先に取引先のゲストユーザを指定して送付します。一覧画面では送付ボタンを押すと送付され、送付後はチェックマークに変わります。取引先がゲスト環境でファイルをダウンロードすると、ダウンロード状況の矢印のマークもチェックマークに変わります。

 

帳票1通につきタスクを1件起票し、宛先に取引先のゲストユーザを指定

 

送付ボタンで送付。送付後とダウンロード後はチェックマークに変わります

 

取引先には通知メールが届き、そのURLからゲスト環境へログインしてダウンロードします。ゲストユーザは社外のユーザに機能を限定して使ってもらうためのアカウントで、使える機能はトランの登録更新、ストーリーの閲覧・検索、タスク機能での進捗管理とメッセージ、ログの閲覧に限られます。項目の追加といった管理の機能は使えません。

 

通知メールのURLから、取引先がゲスト環境へログインします

 

取引先がダウンロードすると、送り手側のステータスも更新されます

 

これにより、「送ったか」「受け取ってもらえたか」がメールの中ではなく、帳票ごとのステータスとして残ります。担当者が休んでも、一覧を見れば誰でも状況が分かります。

タスクに配置する項目例と、決めておくべき型

タスクに配置する項目は、確認の場でお見せしたモック画面で次のように組みました。桁数や値域は、帳票のひな型が確定してから決めていきます。

 

タスク項目例（請求書受領専用タスクフォーム）

分類	名称	代表項目	項目タイプ	桁数・値域／備考
トラン	見積・請求トラン	見積・請求情報	API連携で登録	項目はひな型の確定後に決定
タスク	請求書ご受領専用タスクフォーム	件名	文字列	設計確定前
		宛先	ゲストユーザ選択	登録済みのゲストから選ぶ
		詳細	リッチテキスト	ナレッジ検索の対象
		請求書番号	文字列	設計確定前
		請求書PDF	添付ファイル	帳票出力ツールが生成
		取引日	日付	―
		取引先ID／取引先名	選択／自動表示	IDを選ぶと名称が入る
		送信状態	ステータス	未送信→送信済
		ダウンロード状況	ステータス	未→済（ゲストの操作で更新）

出典：PoCで使用した請求書・見積書発行の電子化想定資料

 

表1の項目を置いた入力欄。取引先IDを選ぶと取引先名が入ります

 

見ていただきたいのは、送付と受領を「ステータス」という型で持たせている点です。送ったかどうかを担当者の記憶やメールの送信履歴に頼らず、項目の値として残すことで、発行業務の進み具合を一覧で追えるようになります。なお、タスクの「詳細」とチャットの内容は、Slopebaseのナレッジ検索の対象になります。

 

 

 

データを次の工程へ受け渡す仕組みは、データフロー機能で解説しています。

請求書の発行を電子化するときは、既製の請求書発行システムを購入するか、自社の業務に合わせて仕組みを作るかで迷う企業が多くあります。導入には社内の承認（稟議）が必要なことが多く、その際には「なぜこの方法を選んだのか」「ほかの方法ではいけないのか」を説明しなければなりません。

 

この章では、今回の事例で比べた選択肢と、それぞれを採用しなかった理由を紹介します。自社で方法を検討するときや、上司・決裁者への説明資料をつくるときの参考にしてください。

検討したほかの方法と、採用しなかった理由

社内で新しい仕組みの導入を提案すると、決裁者からは「なぜこの方法なのか」に加えて、「ほかの方法ではだめなのか」と聞かれることがあります。承認を得るには、選んだ方法の良さだけでなく、ほかの方法を採用しなかった理由も説明できるようにしておく必要があります。

 

そのとき、採用しなかった理由を次の3つの観点に分けて説明すると、決裁者にも伝わりやすくなります。

 

費用：導入や運用にかかるお金が、得られる効果に見合わない
期間：使い始めるまでに時間がかかりすぎる
機能：必要な機能が足りない、または必要以上に多すぎる

 

ここからは、今回の事例で検討した内容と、同じような業務でよく比較される方法について、それぞれ採用しなかった理由を、この3つの観点にあてはめて紹介します。

 

■今回の事例で実際に比べたこと

 

今回の検討では、仕組み全体を選ぶ前に、次の2つの点で複数のやり方を比べました。

 

送付前の確認の方法（採用しなかった理由の観点：機能）
帳票をお取引先に送る前に、内容をどう確認するかを検討しました。候補は、Slopebase上で承認の手続き（ワークフロー）を回す方法、押印サービスと連携して押印する方法、PDFを画面で目視確認する方法などです。このうち、ワークフローと押印の方法は採用しませんでした。見積や請求はすでに社内の承認システムで承認済みのため、同じ承認をもう一度行うことになり、機能として必要以上に多くなるからです。現時点では、営業担当者が内容を確かめてから送付の手続き（タスクの起票）を行う運用を中心に、検証を続けています。

 

帳票の渡し方（採用しなかった理由の観点：機能）
お取引先へ帳票を渡す方法としては、2つの案がありました。1つは、お取引先にゲスト用のアカウントでSlopebaseにログインしてもらい、帳票をダウンロードしてもらう方法です。もう1つは、Slopebaseと連携する別のサービスから帳票を送信する方法です。今回の想定では、1つ目の方法を中心にしています。お取引先が帳票をダウンロードすると、その記録がSlopebase上に残り、「受け取ってもらえたか」を送り手が確認できるためです。

 

■同じような業務でよく比較される方法

 

次の4つは、今回の事例で詳しく比べたものではありませんが、請求書の発行を効率化するときに一般的によく比較される方法です。参考として、採用しにくい理由を整理しておきます。

 

既製の請求書発行システム（採用しにくい理由の観点：費用・機能）
請求書の作成から送付までを行う市販のシステムです。社内の承認システムとつなぐための費用や、お取引先ごとのアカウントの費用がかさみやすい傾向があります。また、承認の機能がすでに社内にある場合は、機能が重なってしまいます。

 

基幹システムや承認システムの改修（採用しにくい理由の観点：費用・期間）
いま使っている社内システムに、送付や受け取り確認の機能を追加で作り込む方法です。作り込む範囲が広くなるため、改修の費用も、使えるようになるまでの期間もかかりやすくなります。

 

RPAによるPDF化とメール送付の自動化（採用しにくい理由の観点：機能）
RPA（パソコン上の操作を自動で行うツール）で、PDFの作成とメール送付を自動化する方法です。作成と送付の手間は減らせますが、お取引先が受け取ったかどうかまでは確認できず、必要な機能が足りません。

 

現状維持（採用しにくい理由の観点：機能）
今の運用を続ける方法です。費用はかかりませんが、送付前の確認の段取りも、送付後の状況も、担当者の手作業とメールのやり取りに頼ったままになります。

 

このように、採用しなかった理由を「費用」「期間」「機能」のどれにあたるかで整理しておくと、社内での説明がしやすくなります。「なんとなく合わなかった」ではなく、「この機能がここまで必要で、それを満たすには費用と期間がこれだけかかる」と具体的に示すことで、決裁者が比べて判断できる材料になります。

既製の請求書発行システムで足りるのはどんな場合か

既製の請求書発行システムで十分なケースもあります。

 

1. 承認の仕組みを持っておらず、承認から発行までを1つの製品にまとめたい場合
2. 発行した請求データを会計システムへそのまま連携したい場合
3. 郵送代行など、電子で受け取れない取引先への対応も1か所で済ませたい場合

 

これらに当てはまるなら、既製品を検討したほうが早く費用も抑えられます。一方で、「承認の仕組みはすでにある」「送る前の確認や受領の確認を自社の業務に合わせたい」「同じ仕組みを請求書以外の社外とのやり取りにも広げたい」という場合は、承認後の工程だけを業務に合わせて作る選択肢が考えられます。

 

ツールの種類ごとの比較は、請求処理を自動化する最新ツール事情と導入メリット、選び方を紹介にまとめています。

検証の過程で挙がった疑問にどう答えたか

検証の過程では、次のような疑問が挙がりました。

 

「請求書の情報をどのように登録するのか」という疑問には、社内グループウェアで承認された情報をAPI連携で見積・請求トランへ登録する流れを、想定フローの図で示して説明しました。

 

「通常のユーザとゲストユーザの違いが分からない」という疑問には、ゲストは社外のユーザ向けに機能を限定したアカウントであることと、使える機能の一覧を示して回答しました。

 

「ゲストユーザをどのように招待するのか」という疑問には、システム設定のゲスト管理で追加した時点でメールが届く仕組みであることと、その通知機能が当時は未実装であることを、そのまま伝えています。できないことを隠さずに答えたことで、残課題の認識をそろえられました。

今回の事例は某メーカーですが、承認した見積や請求を社外の取引先へ発行するという業務の型は、製造業、商社、ソフトウェア企業の営業部門とも重なります。ここでは、事業本部との確認の場で示された回答を要旨でご紹介します。

 

押印については、社内に承認システムがあるため、押印は帳票のひな型に入れておく運用でよいという回答でした。明細の行数は、見積も請求も5〜10行で対応でき、基本は1ページに収まるという見立てです。後続システムへの引き継ぎについては、手作業になっている部分を拾うことが目的なので、今のところ必要性は薄いという判断でした。

 

一方で、帳票を送る前に営業目線で確認するタイミングは欲しい、という要望ははっきり示されています。自動化を進めながらも、人が確かめる場所は残したいという考え方です。

 

同社の他部門における検討や、様々な業種・規模の事例は、導入事例一覧でご覧いただけます。
段階的に導入を進める方法は、バックオフィスDX「スモールスタート×アジャイル」導入ガイドにまとめています。

 

---

自社の請求書発行で同じ形が成立するかを確かめる

 

本記事の設計は、製品を選ぶ前に承認後の工程を棚卸しするところから始まっています。同じ手順を自社に当てはめ、「載る条件」に収まるかどうかを一緒に確認するところからご相談いただけます。ご用意いただくのは、現在お使いの帳票のサンプルだけで構いません。

 

---

 

Q1 社内に承認システムがあるのに、別の仕組みが必要なのはなぜですか？

A.承認システムの守備範囲は「承認する」までで、承認後のPDF化、送付前の確認、送付、受領の確認は多くの場合その外側にあるためです。今回は承認をSlopebaseで作り直さず、承認済みのデータをAPIで受け取り、承認後の工程だけを担わせる設計にしました。

Q2 押印が必要な帳票でも電子化できますか？

A.今回は、押印を帳票のひな型に入れておく運用で合意しました。社内の承認は承認システムで済んでいるため、帳票上の押印は形式として残す考え方です。取引先との取り決めで押印の扱いが決まっている場合は、先に確認しておくことをお勧めします。脱ハンコの考え方は、脱ハンコで内部統制を強化する実践ガイドを参照してください。

Q3 取引先にもSlopebaseのアカウントが必要ですか？

A.取引先には、機能を限定したゲストユーザとしてログインしてもらいます。同社の別の業務の検討では、お客様が都度変わるため、営業からの要望に応じてゲストのアカウントを都度追加する運用が挙がっています。取引先の数が多い場合は、アカウントの追加と管理の手順を先に決めておく必要があります。

Q4 請求書をPDFで送る運用に、法令上の注意点はありますか？

A.請求書や見積書をPDFなどの電子データで授受する形は、電子帳簿保存法上の電子取引に該当し、そのデータを一定の要件を満たして保存する必要があります。また、適格請求書（インボイス）を電子で交付する場合も、交付した側に保存が求められます。詳細は国税庁の公表資料をご確認のうえ、個別の判断は所轄税務署または専門家にご相談ください。

請求書の電子化で最初に着手すべきは、帳票をPDFにすることではなく、承認後に人の手で動いている工程の仕分けです。承認から受領確認までを7つの工程に分け、人の判断を残すべき工程を見極めます。既存の承認システムは残し、承認済みのデータをAPIで受け取れば転記は生まれません。送付と受領は帳票ごとのステータスで残します。自動化を見送った箇所と未実装の点は、理由とともに記録しておきます。

 

---

請求書発行の業務構築について、資料と個別相談をご用意しています

 

本記事で紹介した業務概要・業務フロー・業務ポイント・データの受け渡しは、某メーカーの事業本部との実際の検討内容にもとづくものです。同じ形式で自社の業務を設計するとどうなるのか、資料でご確認いただくか、個別にご相談いただけます。

 

 

---