日本語の請求書データをExcelに抽出して
買掛金管理と税務申告に活用する方法

日本の請求書の項目 — 項目別解説

日本の請求書は法的枠組みに基づいて運用されており、その項目構成は一般的な欧米の請求書よりも標準化され、かつ詳細です。2023年10月以降、適格請求書等保存方式（インボイス制度）では、仕入税額控除を受けるための請求書に、「T」で始まる13桁の適格請求書発行事業者登録番号を記載し、消費税額を税率区分（10％標準税率と8％軽減税率）ごとに区分して表示することが義務付けられています。法的要件に加え、長年の国内商習慣により、支払条件の表記や銀行振込ルート情報が追加されており、これらは国際的なデータ抽出ツールでは解析が困難です。

以下は、経理部門が請求書（seikyūsho）を処理する際に実際に扱う全項目構成です。

フィールド構造は推測ではありません。内閣府による適格請求書制度の公式概要には、すべてのインボイスに必須の6項目が明記されています。しかし、抽出作業はこの6項目にとどまりません。手作業のAP処理で最も時間を消費するフィールド（振込先情報、支払条件の解釈、源泉徴収）は、法的にはインボイスへの記載が義務付けられていません。これらは慣行として記載されるものであり、日本の請求書処理ワークフローを米国や欧州のものと異なるものにしているフィールドです。

汎用抽出が日本の請求書で機能しない理由

ほとんどのAI請求書抽出ツールは英語の請求書データセット（米国・EU形式で「請求書番号」「支払期日」「合計」「仕入先」などのフィールド）で学習されています。日本の請求書をこうしたツールに入れると、3つの問題が発生します。

第一に、仕入先の振込先情報が無視されるか誤読されます。日本の請求書では、銀行名（例：三菱UFJ銀行）、支店名（例：新宿支店）、口座種別（普通）、口座番号がそれぞれ別のラベル付きフィールドとして記載されます。しかし、汎用抽出エンジンはページ下部の4つのテキスト文字列を認識するだけで、「振込先情報」という列定義を持たないため、スキップするか、1つの壊れたフィールドに連結してしまいます。APチームは依然として各PDFを開き、支払システムに銀行情報を手入力する必要があります。

第二に、支払条件は、2つの計算可能な値を含むにもかかわらず、不透明なテキスト文字列として読み取られます。「20日締翌月末払い」は装飾的なテキストではありません。これはAPチームに対し、請求期間が20日に締め切られること（それ以前の取引は今月分、それ以降は翌月分）、支払いが翌月末までに完了することを伝えています。汎用抽出はこの文字列をそのまま出力します。日本の支払慣行を理解する抽出エンジンは、これを「締日：20日」と「支払遅延：1か月」という2つの構造化された値に分割し、支払カレンダー計算式で利用できます。

第三に、消費税の内訳と源泉徴収区分には、欧米の抽出スキーマに相当するものがありませ ん。米国の請求書の税フィールドは単一の売上税行です。日本の請求書には、最大3つの税関連フィールドがあります：10％消費税の小計、8％軽減税率の消費税小計（複数税率の請求書の場合）、そして仕入先が適格請求書発行事業者である場合は源泉徴収額または区分マークです。すべての税フィールドを1つの数値に平坦化する汎用抽出では、APチームが検証時にその平坦化を元に戻す作業を強いられます。

請求書データをExcelに抽出する方法 — ステップバイステップ

手作業による請求書からAPスプレッドシートへの転記を置き換えるワークフローは、発注書で使用するアプローチと同様ですが、列スキーマ（請求書に固有のフィールド）と、PO照合プロセスではなく銀行支払プロセスへの下流パイプラインが異なります。この3段階のワークフローは一度定義すれば、すべての仕入先、すべての請求書形式、および以降の毎月末バッチに適用されます。

汎用の請求書抽出が失敗する項目とその対処方法

日本の請求書における4つのデータ項目は、他の項目よりも自動抽出が難しい傾向があります。これはOCRが文字を読み取れないからではなく、各項目に業務ロジックが組み込まれており、単なるテキスト文字列ではなく構造化データとして保持する必要があるためです。

振込先 — 支払バッチになる4つのフィールド

振込先情報ブロックは、日本の買掛金処理において最も反復的なデータ入力作業です。AP担当者は請求書を受け取り、インターネットバンキング画面を開き、銀行名、支店名、口座種別、口座番号の4つの値を入力します。これらは会計ソフトの仕入先マスターにすでに登録されている同じ4つの値です。月末に60枚の請求書が届くと、1枚につき4フィールドの再入力が60回発生し、合計240件の個別データ入力になります。これは新しい情報を追加するものではなく、あるシステムから別のシステムへの情報の重複入力にすぎません。

抽出アプローチでは、4つのフィールドをそれぞれ独立した列に取得します。銀行名（振込先銀行名）、支店名（支店名）、口座種別（口座種別 — 普通または当座）、口座番号（口座番号）です。ゆうちょ銀行への振込では、口座参照に記号-番号形式（例：記号12345 番号6789012）が使用され、商業銀行システムで必要な7桁の振込口座番号とは異なります。この場合、推論列を使用して抽出時にゆうちょ形式を変換できます。たとえば、振込口座番号（ゆうちょの場合、ゆうちょ銀行の変換ルールに従って記号-番号を7桁形式に変換）のような列を定義します。AIが抽出時に変換を適用するため、APチームは振込可能な形式の口座番号を受け取ることができます。

銀行情報が構造化された列に格納されると、次のステップである銀行用の支払バッチファイルの作成は、再入力作業ではなくスプレッドシート操作になります。抽出フォームの銀行名、支店名、口座種別、口座番号、口座名義の各列が、銀行のインターネットバンキングシステムがアップロードとして受け付けるCSV形式のバッチ支払ファイルへの入力となります。

支払条件 — 複合テキストから締日と支払遅延月数へ

日本の支払条件は、APチームが一目で把握できるコンパクトな構文ですが、定型抽出には対応しにくい形式です。「20日締翌月末払い」には、請求期間が毎月20日に締め切られることと、支払いが翌月末までに完了することという2つの決定が含まれています。計算列（抽出時にAIが値を計算する列）は、これを2つの構造化フィールドに分割します: 締日（支払条件より: 「20日締」の場合は20、「月末締」の場合は31、「10日締」の場合は10）および支払遅延月数（支払条件より: 「翌月末払い」の場合は1、「翌々月末払い」の場合は2）。

締日は形式的なものではなく、実務上の意味を持ちます。20日締条件のもとで3月18日付の請求書は3月の請求期間に該当し、支払いは4月末までに完了し、会社が3月31日に決算を締める場合、その費用は当期に属します。同じ20日締条件のもとで3月22日付の請求書は4月の請求期間に該当し、支払いは5月末までに完了し、その費用は翌期に属します。締日は、請求書の発行日や暦月の区切りではなく、会計年度の分類を決定します。同じ支払条件ロジックは、日本の発注書データ抽出のガイドでも詳しく説明されており、調達側から同じ支払条件フィールドを引き継ぎます。

消費税 — 税率区分の二重構造を税務申告に必要な構造化入力として

日本の消費税制度は、標準税率10%と軽減税率8%の2つの税率を使用し、適格請求書には税率区分ごとに課税標準と税額を別々に記載する必要があります。支払い前に請求書を検証するAPチームは、請求書に記載された税率別の合計が会計システムの期待値と一致することを確認する必要があります。消費税申告書を提出する税務チームは、10%と8%の合計を申告計算の入力データとして必要とします。

推論列が抽出時の分類を処理します: 税率（品名より: 食品・飲料品目 → 8%軽減、標準的な商品・サービス → 10%標準、輸出関連と明示されているもの → 免税）。AIは各明細行の品名を読み取り、日本の二重税率ルールを適用して税率列に入力します。出力されるスプレッドシートには、各行が事前に分類された状態で表示され、10%標準の小計と8%軽減の小計は抽出データから計算可能であり、別途の分類処理は不要です。混合品目の請求書（事務用品（10%）とパッケージ飲料（8%）が同梱されている場合）では、行ごとの分類が、各請求書PDFを開き直すことなく請求書の税率別合計の正確性を検証する唯一の方法です。

源泉徴収 — 支払者が支払い前に差し引く必要がある場合

日本の源泉徴収制度では、税理士、公認会計士、弁護士、司法書士、デザイナー、著作家など、所得税法第204条に定められた特定の専門サービス提供者への支払いを行う際、支払者が源泉徴収を行う必要があります。源泉徴収率は一般的に支払金額の10.21%です。支払者は徴収した金額を税務署に納付し、仕入先には残りの89.79%を支払います。

源泉徴収区分が記載された請求書（多くの場合「源泉徴収あり」と記載されるか、「源泉徴収額」の行が別途表示される）は、支払計算を変更します。経理チームは請求書合計から源泉徴収額を差し引き、正味額を仕入先に支払い、徴収額を別の税預り債務として計上する必要があります。抽出時に源泉徴収が取得されない場合、経理チームは対象となる各請求書を再確認し、源泉徴収額を手動で計算して支払いを調整する必要があります。請求書ごとの算術作業であり、60件の請求書では、経理チームの相当な時間を消費します。

源泉徴収区分（請求書に源泉徴収の記載があるか確認。仕入先が対象の専門家であり源泉徴収が記載されている場合は「該当」、それ以外は「非該当」と出力）として定義された列は、どの請求書で控除が必要かを示します。正味支払額（源泉徴収該当の場合：合計×0.8979、それ以外：合計）のような計算列は、実際の振込額を直接計算します。

抽出した請求書データを日本の会計ソフトに取り込む

抽出ジョブの出力は構造化されたスプレッドシートです。取り込み先は、仕入仕訳が記録される会計ソフトと、支払いが実行される銀行システムです。日本の主要な会計プラットフォームはすべて構造化データのインポートに対応しています。ボトルネックは常にインポートの前段階、つまり仕入先のPDFから請求書データを抽出して構造化された形式に変換するステップでした。

弥生会計 — 日本の中小企業向け会計ソフトの市場リーダー — はCSV経由で仕入台帳データをインポートします。抽出された請求書列は直接マッピングされます：請求書番号→伝票番号、仕入先→仕入先、日付→日付、金額→金額。税率区分ごとの消費税額は弥生の税務申告モジュールに反映されます。弥生販売（購買管理モジュール）も利用している企業では、請求書データが対応する発注書レコードにリンクし、三点照合に必要なドキュメントチェーンが作成されます。

freee — 7万以上の中小企業が利用するクラウド会計プラットフォーム — はCSVインポートからの自動仕訳生成をサポートしています。各請求書行とともに抽出された適格請求書登録番号はfreeeのインボイス適合チェックに反映され、税率別にグループ化された消費税額はfreeeが自動生成する消費税申告計算に反映されます。銀行振込情報（抽出時にすでに別の列に分かれている）は、銀行一括ファイル作成のためのfreeeの支払モジュールに反映されます。

マネーフォワード クラウド会計 — 日本で最も多い金融機関API接続数（2,451以上）を誇る — は仕入請求書データを購買管理モジュールにインポートします。このプラットフォームの自動銀行照合は、支払記録と銀行フィードを照合し、消費税内訳付きの抽出請求書データはマネーフォワードの複数税率対応の税務申告をサポートします。

勘定奉行 — OBCの中堅企業向けスイート（年間売上高5億〜50億円）— は、部門別原価管理に対応した仕入請求書データのバッチCSVインポートをサポートしています。請求書に部門コードやコストセンターの参照が含まれている場合、それらのフィールドは勘定奉行の部門別損益レポートに自動的に反映されます。

共通点は、請求書データが構造化された列に入ると、これらのプラットフォームへのインポートはファイルのアップロードになることです。現在数時間かかっているステップ — 60枚分の請求書の銀行詳細、税額、支払条件を会計システムに入力する作業 — は、検証作業になります：抽出されたデータを確認し、外れ値を確認し、インポートする。照合ワークフローの調達側に同じ抽出アプローチを適用するには、日本語の発注書データをExcelに抽出するステップバイステップガイドを参照してください。銀行側の対応 — 請求書の支払いと一緒に表示される取引記録の抽出 — については、日本の銀行通帳抽出ガイドで通帳からスプレッドシートへの完全なワークフローを説明しています。

FAQ

小規模仕入先からの手書き請求書も読み取れますか？

はい。多くの小規模な日本の仕入先 — 地元のサービスプロバイダー、個人事業主、地方の製造業者 — は、事前印刷された用紙に手書きの請求書（手書き請求書）を発行しており、金額はボールペンで記入され、会社印が押されています。AIモデルは手書きの漢字や数字を読み取ることができ、手書きの請求書で一般的な略記法（株式会社の㈱、郵便番号のプレフィックスとしての〒、番号のNo.）にも対応しています。劣化したスキャンやFAXコピーの場合は、300dpi以上でのスキャンが推奨されます。難しい文字 — 特に誤読すると振込が失敗する手書きの銀行口座番号 — のスポットチェックは、手書き文書では慎重に行うことをお勧めします。

ゆうちょ銀行の口座番号形式はどのように処理されますか？

ゆうちょ銀行は、一般銀行で使用される7桁の口座番号とは異なる記号-番号形式（例：記号12345 番号6789012）を使用しています。一般銀行からゆうちょ銀行の口座への振込時には、記号-番号を7桁の振込用口座番号に変換する必要があります。推論列を使用すると、抽出中にこの変換を実行できます：列ロジックを定義して、銀行名としてゆうちょ銀行を検出し、記号-番号フィールドを解析し、変換された7桁の番号を出力します。ゆうちょ銀行のウェブサイトには変換ルールが公開されています — 基本的に、記号の数字は振込用口座番号の最初の部分にマッピングされ、番号の数字（8桁の場合は最終チェックディジットを除く）は残りの部分にマッピングされます。

インボイス登録番号がない場合はどうなりますか？

仕入先が適格請求書発行事業者として登録されていない場合、その請求書には登録番号が記載されません。この場合、買い手は仕入税額控除を全額受けることはできませんが、経過措置により一部控除が認められます。2023年10月から2026年9月までは仕入税額の80%が控除可能です。2026年10月から2029年9月までは50%が控除可能です。2029年9月以降（2026年税制改正による延長により2031年まで）はゼロとなります。経過期間中、APチームは非適格請求書を別途フラグ付けする必要があります。これは、軽減された控除額を適格請求書とは異なる基準で計算する必要があるためです。登録番号を取得する抽出列（またはその欠落を記録する列）を設けることで、各請求書を正しい税務処理に振り分けるためのデータが得られます。

同じ抽出で税込と税抜の両方の請求書を処理できますか？

はい、ただし列定義で出力形式を指定する必要があります。一部の仕入先が内税の請求書を発行し、他の仕入先が外税の請求書を発行する場合、計算列を追加することで抽出時の正規化が解決されます。例：税抜行金額（単価が税込の場合は、10%品目は1.1で除算、8%品目は1.08で除算。それ以外はそのまま使用）。AIは請求書上の税込や税抜などの表記を含む文書の文脈を読み取り、税務処理を判断して出力を正規化します。スプレッドシート上のすべての行金額は一貫した税抜基準で揃い、発注書との照合に備えることができます。

源泉徴収列は支払金額の計算とどのように連動しますか？

源泉徴収は、支払者が仕入先への送金前に差し引く控除です。請求書の合計額は総額の請求金額であり、仕入先が受け取る金額は合計額から源泉徴収を差し引いた金額です。正味支払額（源泉徴収区分が「対象」の場合：合計額×0.8979。それ以外の場合：合計額）として設定された計算列により、各請求書の実際の振込額が出力されます。源泉徴収額（合計額と正味支払額の差額）は、別途預り金として税務署に納付する義務があります。AP元帳には、源泉徴収対象の各請求書につき3つの列が必要です：総額（請求書の合計額）、源泉徴収額（税控除額）、正味支払額（振込額）。抽出によりこの3つすべてが生成されるため、支払バッチファイルと税納付スケジュールは同じソースデータから作成されます。

同一文書に異なる消費税率のインボイスが混在する場合にも対応できますか？

はい、対応可能です。日本のインボイスには、標準税率10%の品目、軽減税率8%の品目、非課税の品目が混在する場合があります。適格請求書等保存方式では、税率区分ごとに課税標準と税額を区分して記載することが求められます。抽出時には、推論列が品名に基づいて各明細行を税率別に分類します。飲食料品は8%、標準的な商品・サービスは10%、明示的に非課税とされた品目は非課税として分類されます。出力されるスプレッドシートでは、品目が税率別にグループ化され、税率別の合計がインボイスに記載された税額の内訳と照合できます。両者が一致しない場合、つまり抽出で計算された8%の合計がインボイスに記載された8%の合計と異なる場合、その差異はレビュー用にフラグが立てられます。これは、APチームが手作業で行うチェックと同じですが、60件のインボイスを同時に自動で実行します。

60件のPDFから支払い準備完了のスプレッドシートへ

日本のインボイスは単なる請求書ではありません。支払い指示書です。銀行口座情報は、APチームが送金先を特定するために必要です。税務文書でもあります。消費税の内訳は国の税務申告に使用され、適格請求書発行事業者の登録番号は仕入税額控除の前提条件です。コンプライアンス記録でもあります。源泉徴収区分は、買い手側に別途の税務申告義務を発生させます。そして照合のための書類でもあります。支払いが承認される前に、インボイス番号、明細項目、金額が対応する発注書および納品書と照合されなければなりません。

合計金額と日付だけでなく、これらすべての項目を抽出するワークフローは、月末のインボイスの山をデータ入力キューから検証チェックリストへと変えます。銀行振込の詳細は列に並び、支払いバッチファイルの作成にそのまま使用できます。消費税は税率別に分けられ、税務申告にそのまま使用できます。源泉徴収区分はフラグが立てられ、対象となるインボイスが誤って総額で支払われることがありません。支払条件は決済日と遅延日数に解析され、支払いカレンダーが自動的に入力されます。スプレッドシートは構造化された状態で届き、APチームの時間は入力から検証へ、データ入力から財務管理へと移行します。