日本語請求書データを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つのフィールド

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

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

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

支払条件 — 複合テキストから締日と支払サイトへ

日本の支払条件は、経理チームが一目で理解できるコンパクトな構文ですが、定型化された抽出は困難です。「20日締翌月末払い」には2つの情報が含まれています。請求期間は毎月20日に締め切られ、支払いは翌月末までに行われます。計算列（AIが抽出時に値を計算する列）を使用すると、これを2つの構造化フィールドに分割できます。締日（支払条件より：「20日締」の場合は20、「月末締」の場合は31、「10日締」の場合は10）および支払サイト月数（支払条件より：「翌月末払い」の場合は1、「翌々月末払い」の場合は2）です。

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

消費税 — 税務申告に必要な構造化データとしての複数税率区分

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

推論列が抽出時の分類を処理します。税率（品名から判定：食品・飲料品目→8％軽減、標準的な商品・サービス→10％標準、輸出関連が明示されているもの→非課税）。AIが各明細の品名を読み取り、日本の複数税率ルールを適用して税率列に値を設定します。出力されるスプレッドシートでは、すべての明細が事前に分類された状態で届きます。10％標準の小計と8％軽減の小計は、別途分類処理を行うことなく、抽出データから計算可能です。事務用品（10％）と包装飲料（8％）が同梱された混合品目の請求書の場合、明細ごとの分類が、各請求書PDFを開き直さずに税率別合計の正確性を検証する唯一の方法です。

源泉徴収 — 支払者が支払前に控除する必要がある場合

日本の源泉徴収制度では、特定の専門サービス提供者（税理士、公認会計士、弁護士、司法書士、デザイナー、著作家、その他所得税法第204条に定められた区分）への支払いを行う際、支払者が支払金額から所得税を源泉徴収する必要があります。源泉徴収税率は原則として支払金額の10.21％です。支払者は徴収した金額を税務署に納付し、残りの89.79％を取引先に支払います。

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

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

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

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

Yayoi（弥生会計） — 日本の中小企業向け会計ソフトの市場リーダー — は、CSVインポートにより買掛金元帳データを取り込みます。抽出された請求書の各列は、次のように直接マッピングされます。請求書番号 → 伝票番号、仕入先 → 仕入先、日付 → 日付、合計金額 → 金額。税率区分ごとの消費税額は、Yayoiの税務申告モジュールに反映されます。また、Yayoi販売（購買管理モジュール）を併用している企業では、請求書データが対応する発注書レコードにリンクされ、三点照合に必要な証憑連鎖が構築されます。

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

マネーフォワード クラウド会計 — 国内最多の金融機関API連携数（2,451以上）を誇る — は、購買管理モジュールに仕入請求書データをインポートします。同プラットフォームの自動消込機能は、支払い記録と銀行データを照合し、消費税区分を含む抽出済み請求書データは、マネーフォワードの複数税率対応の税務申告をサポートします。

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

共通する点は、請求書データが構造化された列として整っていれば、これらのプラットフォームへのインポートはファイルのアップロード作業に過ぎないということです。現在、何時間もかかっている作業、つまり60枚の請求書の銀行詳細、税額、支払条件を会計システムに入力する作業は、抽出データを確認し、例外的な項目を確認し、インポートするという検証作業に変わります。照合ワークフローの購買側に同じ抽出アプローチを適用する方法については、日本の発注書データをExcelに抽出するステップバイステップガイドをご参照ください。また、銀行側の対応として、請求書支払いとともに表示される取引記録の抽出については、日本の銀行通帳データ抽出ガイドで、通帳からスプレッドシートへの完全なワークフローを解説しています。

よくある質問

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

はい。多くの小規模な日本の仕入先（地域のサービス事業者、個人事業主、地方の製造業者など）は、現在も所定の用紙に手書きの請求書（手書き請求書）を発行しており、金額はボールペンで記入され、会社印が押されています。AIモデルは手書きの漢字や数字を読み取ることができ、手書きの請求書でよく見られる略記（株式会社を㈱、郵便記号の接頭辞として〒、番号をNo.）にも対応しています。スキャンやFAXコピーの品質が著しく低下している場合は、300dpi以上でのスキャンを推奨します。手書き文書の場合、特に手書きの銀行口座番号など、読み間違えると振込に失敗する可能性がある文字については、念のため目視確認を行うことをお勧めします。

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

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

適格請求書（インボイス）登録番号がない場合はどうなりますか？

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

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

はい、対応可能ですが、列定義で希望する出力形式を指定する必要があります。一部の仕入先が内税の請求書を発行し、他の仕入先が外税の請求書を発行する場合、計算列を追加することで抽出時の正規化が解決されます。例：ライン金額（税抜）（単価が税込の場合は、10%品目は1.1、8%品目は1.08で除算。それ以外はそのまま使用）。AIは請求書上の税込や税抜といった表記を含む文書のコンテキストを読み取り、税区分を判断して出力を正規化します。スプレッドシート上のすべてのライン金額は一貫した税抜ベースで出力され、発注書との比較が可能になります。

源泉徴収区分の列は支払金額の計算にどのように影響しますか？

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

同一文書内に複数の消費税率が混在する請求書でも機能しますか？

はい、機能します。日本の請求書では、10%の標準税率、8%の軽減税率、非課税の品目が同一文書内に混在することがあります。適格請求書制度では、税率区分ごとに課税基準額と税額を個別に記載することが求められます。抽出時には、推論列が品目説明に基づいて各ライン品目を税率別に分類します。飲食料品は8%、標準的な商品・サービスは10%、明示的に非課税とされた品目は非課税として分類されます。出力スプレッドシートでは品目が税率別にグループ化され、税率別のグループ合計は請求書に記載された税額内訳と照合できます。両者が一致しない場合（抽出で計算された8%の合計が請求書に記載された8%の合計と異なる場合）、差異がフラグ付けされて確認対象となります。これは買掛金チームが手作業で行うのと同じチェックですが、60件の請求書に対して同時に自動実行されます。

60件のPDFから、支払い準備の整った1つのスプレッドシートへ

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

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