領収書データをExcelに抽出する方法
確定申告向け

なぜ日本の領収書は汎用OCRでは処理が難しいのか

一般的な領収書OCRは単純な前提に基づいています。すべての領収書が米国や欧州の小売レシートと同じ構造——商品の縦リスト、単一の税率、下部に合計、MM/DD/YYYY形式の日付——であるという前提です。日本の領収書は、これらの前提をすべて覆します。

最も顕著な違いは複数税率（軽減税率）です。2019年10月以降、日本ではほとんどの商品・サービスに標準税率10%、食品（酒類と外食を除く）と新聞購読に軽減税率8%が適用されます。コンビニの1枚のレシートでも、10%対象、8%対象、0%対象（非課税品）の3つの税区分が見られることがあります。各区分にはそれぞれ小計と税額があり、品目欄にはどの商品が軽減税率の対象かを示す必要があります。

米国のレシートで訓練された標準的なOCRツールは、数字を見て「税」とラベル付けします。2つの税率が存在することを知らないため、2つの税率に分けることはできません。その結果、Excelの出力で税額が誤り、最終的な確定申告の際に控除額が間違ってしまいます。

2つ目の問題は日付形式です。日本の領収書は元号を使用します。2025年6月15日ではなく、令和7年6月15日です。元号は天皇の交代ごとに変わります（令和は2019年5月に始まりました）。元号システムを理解しないツールは、日付を完全に誤読するか、意味のない文字列を出力します。1月から12月までの領収書を処理するフリーランサーにとって、すべての日付フィールドでExcelでの手動修正が必要になります。150枚の領収書で各日付の修正に30秒かけると、1つのフィールドだけで75分を費やしたことになります。

3つ目の問題は構造的なものです。多くの日本の領収書は、欧米のレシートの厳密な縦書きフローとは異なる横書きと縦書きの混在レイアウトを使用しています。宛名は右側に縦書きで表示されることが多く、発行者の名称と印鑑は左下に配置されます。標準的なOCRは上から下、左から右に読み取ります。縦書きのテキストは意味不明な文字列として読み取られます。

さらに、手書きの領収書もあります。修理、コンサルティング、フリーランスの仕事など、ベンダーが手書きで領収書を書くケースは日本では今も一般的です。日本のQ&AプラットフォームQiitaのユーザーが指摘しているように、freeeのOCRを手書き領収書でテストしたところ、金額フィールドの精度は約20%でした——4桁が2桁に減り、正しい桁は1桁だけでした。日本語の手書き文字認識には、日本語の文字に特化して訓練されたモデルが必要ですが、ほとんどの汎用領収書OCRは印刷された英語で訓練されています。

法的に有効な日本の領収書に必要な記載事項（国税庁の要件）

抽出を始める前に、何を探すべきかを把握しておく必要があります。国税庁（NTA）は、領収書が経費の証明として認められるための具体的な要件を定めています。これらの項目を理解することで、抽出結果に必要な列が決まります。

国税庁のガイドラインによると、有効な領収書には8つの必須項目が含まれている必要があります。

2024年1月から完全施行されている日本の電子帳簿保存法では、電子的に受領した領収書（メールのPDF、ウェブサイトからのダウンロード、アプリのスクリーンショット）は電子データとして保存しなければならず、印刷して紙のみを保管することはできません。データは日付、金額、取引先で検索可能でなければならず、システムは不正な改ざんを防止する必要があります。これらの要件は、2023年の税制改正に伴って公表された国税庁の運用ガイドラインに基づき、事業規模に関わらずすべての法人および個人事業主に適用されます。

つまり、Amazon JapanからメールでPDFの領収書を受け取った場合、印刷したコピーだけを保管するのは非準拠となります。デジタル原本が必要です。元のデジタルファイルを保持しながら、検索可能なExcelデータベースを作成する抽出ワークフローは、抽出ニーズとコンプライアンス要件の両方を同時に満たします。

手入力による領収書処理の隠れたコスト（確定申告シーズン）

内閣官房の推計によると、日本のフリーランス人口は462万人に達しています。個人事業主、一人社長、副業を持つパラレルワーカーを含みます。従業員20人以下を小規模事業者と定義した場合、日本の全企業の84.5%を占めます（総務省、2014年経済センサス）。これらの数字は、毎年何百万もの人々が確定申告を行うことを意味し、その全員にとって領収書の処理が最も面倒な部分です。

国税庁によると、2024年分の確定申告は2,339万件が提出され、そのうち1,329万件が自宅からe-Taxで提出されました。期限は毎年2月16日から3月15日までと決まっています。この期間に向けた2ヶ月間、全国のフリーランサーや小規模事業者は同じ儀式に直面します。1年分の領収書を銀行口座の明細やクレジットカードの記録と照合し、それぞれを会計ソフトやスプレッドシートに入力し、紛失がないことを祈るのです。

手入力が実際にどれだけのコストをかけているか、定量化してみましょう。スプレッドシートに直接入力する場合、領収書データの平均的な手入力速度はおよそ1枚あたり45秒です。日付を探し、和暦から変換し、事業者名を入力し、金額を入力し、消費税を按分し、但し書きを読み取り、経費カテゴリを推測します。年間150枚（週3枚未満）の場合、純粋なデータ入力だけで112.5分、つまり2時間弱になります。しかし、実際のコストはさらに高くなります。

各領収書にはコンテキストスイッチングが必要です。吉野家のものは文字が薄れた感熱紙、取引先とのランチのものは漢字がかろうじて読める手書きの領収書、Amazon Japanのものは確認メールに金額が埋もれたPDFです。フォーマット間の精神的切り替えコストは、1枚あたり15〜20秒と推定されます。和暦変換、消費税の按分、手書きの事業者名がある領収書は90秒以上かかることもあります。このペースだと、150枚の処理でほぼ1営業日を消費します。それは顧客に請求していない作業です。

さらに、エラーによるコストはこれに含まれていません。国税庁の2024年分の申告データによると、1,329万件のe-Tax申告のうち824万件が納税者自身による申告です。つまり、800万人以上が税理士なしで自分で会計処理を行っていることになります。自動検証なしで手作業で経費分類を行う場合のエラー率は、控除の見逃しや税務調査の引き金につながる可能性があります。税務調査中、国税庁は青色申告者は7年分、白色申告者は5年分の領収書を遡って要求することができます。記録が色あせた紙の領収書の入った靴箱だけに存在する場合、この取り出し作業はほぼ不可能です。

AI抽出が日本語の領収書をテンプレートOCRとどう違う形で処理するか

従来のOCRとAI抽出の本質的な違いは、精度のパーセンテージではなく、各アプローチがページ上のデータをどのように見つけるかという点にあります。そして日本語の領収書では、この違いが、使える出力になるか、空白のスプレッドシートになるかを左右します。

テンプレートベースのOCRは座標マッチングで動作します。ストアAのレシート形式で合計金額が表示される領域を定義すると、ソフトウェアは毎回その領域を調べます。ストアBが異なるレイアウト（合計の座標が異なる）を使用する場合、テンプレートは機能しません。日本語の領収書では、すべての店舗、レストラン、タクシー会社が異なる形式を使用するため、テンプレートベースのOCRではベンダーごとに個別のテンプレートが必要になります。40社の異なるベンダーから領収書を受け取るフリーランサーは、40個のテンプレートが必要です。これがテンプレートOCRが規模に対応できない理由です。

列名抽出（AIビジョンモデルが使用するアプローチ）は、異なる方法で動作します。ツールにページ上のどこを見るかを指示する代わりに、何を欲しいかを指示します：日付、ベンダー名、合計金額、但し書き、10%税対象額、8%税対象額。これらを列名としてアップロード前に入力します。AIは文書全体を読み取り、各フィールドの意味を意味論的に理解し、ページ上のどこに表示されているかに関係なく対応する値を特定します。ある領収書の右上にある日付も、別の領収書の中央にある日付も、AIが両方を日付として認識するため、どちらも「日付」列に解決されます。

これが、50の異なる店舗からの50枚の領収書を1回のアップロードでバッチ処理できるようにするメカニズムです。テンプレート不要、ベンダーごとの設定不要、座標描画不要です。抽出ロジックは、位置ベースではなく意味ベースであるため、フォーマット非依存です。

日本語の領収書に特化して、このアプローチはテンプレートOCRを壊す3つの形式レベルの課題に対処します：

• 二重税率：消費税10%対象額と消費税8%対象額の2つの列を作成すると、AIは各小計の横にある税率ラベルを認識して合計を分離します。単一の税フィールドを想定するのではありません。
• 元号日付：抽出中に計算を実行する計算列機能を使用できます。Excelでの後処理は不要です。「西暦日付（令和年を2018を加えて西暦に変換）」のような列を定義すると、AIは令和7年6月15日ではなく2025-06-15を出力します。手動変換のステップは不要です。
• 但し書きの抽出：AIは但し書きフィールドを読み取り、テキストとして抽出します。これを推論列（AIが文書の内容に基づいて判断を下す列）と組み合わせることができます。例えば、カテゴリ（選択肢：飲食費/交通費/消耗品費/通信費/その他）という名前の列は、AIに但し書きを読み取らせ、経費カテゴリを判断し、適切な値を入力させます。「お食事代として」と記載された領収書は、自動的に飲食費に分類されます。抽出と分類が1回のパスで完了します。

ステップバイステップ：領収書の山から確定申告用スプレッドシートへ

ここでは、年末に溜まった領収書を、確定申告にそのまま使える1つの整頓されたExcelファイルに変換する正確なワークフローを紹介します。freee、弥生、MoneyForwardで申告する場合も、税理士にスプレッドシートを渡す場合も同じです。

ステップ1：まずすべてをデジタル化する

抽出の前に、すべての領収書をデジタル形式にする必要があります。紙の領収書はスマホのカメラを使用し、暗い面に平らに置き、領収書全体（発行者名から合計額まで）が写るようにし、手の影が入らないようにします。保存から6〜12ヶ月経つとよくあることですが、感熱紙の領収書がすでに薄れ始めている場合は、今すぐ写真を撮ってください。画像は時間とともに良くなることはありません。オンライン購入のメール領収書やPDFは、アップロード前に1つのフォルダに保存します。

ファイル名はわかりやすく付けましょう。YYYY-MM-DD_発行者.pdfのような規則（例：2025-06-15_吉野家.pdf）にすると、後から各ファイルを見つけやすくなります。手動で名前を変更するファイルが多すぎる場合は、ほとんどの抽出ツールが出力スプレッドシートに元のファイル名を保持するため、各データ行から元の文書へのトレーサブルなリンクが得られます。

ステップ2：列を一度だけ定義する

このステップが出力の品質を左右します。すべての領収書のすべてのフィールドを抽出するのではなく、確定申告に必要なフィールドだけを正確に抽出します。青色申告を行う一般的なフリーランサーや個人事業主の場合、列は次のようになります：

白色申告の場合は要件がよりシンプルです。白色申告は青色申告の特別控除に対応していないため、細かい税額の内訳は必要ありません。日付、発行者、金額、勘定科目の基本列セットで通常は十分です。

このように列を定義する主な利点は、一度設定すれば、7-Elevenの感熱紙レシートからフリーランス通訳者からの手書き領収書まで、アップロードするすべての領収書に同じ設定が適用されることです。

ステップ3：一括アップロードして抽出

溜まった領収書ファイルを一度にアップロードしましょう。30枚でも80枚でも150枚でも構いません。AIが各ファイルを処理し、定義した列に一致する値を特定して、各行が1枚の領収書、各列が指定したフィールドに対応するスプレッドシートを作成します。処理は1ページあたり数秒かかります。100枚の領収書バッチは数分で完了し、数時間はかかりません。

出力には各行のソースファイル参照が含まれるため、値を確認する必要がある場合、スプレッドシートから元の領収書画像にクリックして戻ることができます。このトレーサビリティは税務調査への備えとして重要です。電子帳簿保存法に基づく国税庁の要件である、日付・金額・取引先による検索可能性を満たします。

ステップ4：提出前に出力を検証する

どの抽出ツールも、すべての領収書に対して100%の精度を達成できるわけではありません。これは文書処理の現実であり、特定のツールの欠点ではありません。バッチ抽出の目的は、「すべての項目を手入力する」作業を「外れ値をスポットチェックする」作業に減らすことです。以下が2分間の検証ルーチンです：

1. 金額（降順）で出力を並べ替えます。上位10行を目視で確認します。これらは最大の支出であり、監査リスクが最も高い項目です。それぞれを元の領収書と照合します。
2. カテゴリ列で「その他」の分類がないか確認します。AIはカテゴリを確信を持って判断できない場合にこの汎用分類を使用します。これらは手動で再分類します。
3. 日付で並べ替え、現在の課税年度（1月1日〜12月31日）外のエントリがないか確認します。2026年1月の領収書は2025年の申告に含めるべきではありません。
4. 青色申告の申告者の場合：10%課税対象小計＋8%課税対象小計＋消費税の合計が総額とほぼ一致することを確認します。不一致がある場合は、抽出エラーの可能性を示します。

青色申告と白色申告の申告に合わせた出力の構成

青色申告と白色申告の選択は、税務上の結果と領収書処理の戦略の両方に影響します。その違いを理解することで、申告タイプに適したデータを取得するための抽出列を設計できます。

青色申告では、e-Taxで電子申告し、複式簿記を維持する申告者に対し、最大65万円の特別控除が受けられます。2027年以降、e-Taxと「優良な電子帳簿」を組み合わせた場合、最大控除額は75万円に引き上げられますが、書面申告者は10万円に制限されます。青色申告では、最大3年間の損失繰越も可能で、事業に従事する家族従業員への給与を経費にできます。その代わり、総勘定元帳、仕訳帳、貸借対照表の作成が必須で、すべての領収書と記録を7年間保存する必要があります。

白色申告はよりシンプルです。現金主義の記録で、貸借対照表は不要、領収書の保存期間は5年間ですが、特別控除も損失繰越もありません。事業所得400万円の個人事業主の場合、青色申告の65万円控除を限界税率（330万円〜695万円の所得に対する20%）で適用すると、約13万円の節税効果があります。個人事業にとっては無視できない金額です。

これは抽出ワークフローに何を意味するのでしょうか？青色申告の申告者は詳細なデータが必要です。各領収書を税率別に分類し、支払い方法（現金かカードか）を記録し、仕訳用の正しい勘定科目にマッピングする必要があります。出力されたスプレッドシートは、青色申告決算書の元データになります。白色申告の申告者は、取引先、日付、金額、大まかなカテゴリで十分であり、収支内訳書に必要な情報が揃います。

freee、弥生、MoneyForwardを使用している場合、プロセスは異なります。これらのプラットフォームは銀行取引やクレジットカード取引を自動インポートでき、多くはアプリ内で領収書のOCR機能を提供しています。ただし、これらの会計プラットフォームの領収書OCRは、アプリのモバイルインターフェース内で1枚ずつ個別に処理するように設計されています。年間100枚以上の領収書が溜まったフリーランサーにとって、モバイルアプリで1枚ずつ処理するのは手入力より速いものの、依然として1枚ずつの直線的なワークフローです。すべての領収書を1回のアップロードで処理し、単一のスプレッドシートを出力するバッチ抽出ツールを使用すれば、全データセットを一度に取得でき、会計ソフトにすでにインポートされている銀行取引と照合できます。

よくある質問

AIは手書きの日本語の領収書を本当に読めるのでしょうか？

部分的に読めます。最新のビジョン言語モデルは印刷された日本語を高い精度で読めますが、手書きの漢字は最も難しいケースです。日本のモバイル領収書画像に特化してファインチューニングされたオープンソースモデル「Japanese-Receipt-VL-3B」のようなモデルは、標準的な印刷領収書を問題なく処理します。明確でブロック体の手書き項目は通常AIが判読できます。しかし、筆記体や装飾的な手書きの領収書（特にベンダーが個人印や筆書きを使用した古い領収書）は抽出精度が低くなるため、目視確認が必要です。手書きの領収書を頻繁に受け取る場合は、ワークフローを確定する前にサンプルバッチでテストしてください。

このツールは和暦（令和、平成、昭和）を自動的に処理しますか？

ほとんどのAI抽出ツールは、文書に記載されているとおりの日付を抽出します。領収書に「令和7年6月15日」とあれば、そのままスプレッドシートに出力されますが、多くの会計ソフトではそのまま使用できません。これは計算列で対応できます。「令和は2018を加算、平成は1988を加算、昭和は1925を加算して西暦に変換」というルールを定義すれば、AIが西暦日付を出力します。計算列に対応していないツールの場合は、抽出後に日付列に対してExcelの数式（令和の場合=DATE(era_year+2018, month, day)）を一度実行すれば対応できます。

領収書の8%と10%の税区分はどの程度正確に分割されますか？

領収書に8%と10%の小計が明確に別々に記載されている場合（日本のコンビニやスーパーの領収書のほとんどが該当）、AI抽出は確実に分割処理します。税率の内訳がなく合計金額のみが記載されている領収書（古い手書きの領収書や小規模事業者の領収書によく見られる）の場合、AIは存在しない情報を分割できません。その場合は、内容に基づいて手動で税区分を計算する必要があります。食品は8%、その他の品目は10%です。インボイス制度に基づいて発行された領収書（2023年10月以降、B2B取引で義務化）は税率別の内訳表示が義務付けられているため、それ以降に受け取った業務用領収書の抽出はより信頼性が高くなります。

感熱紙のレシートが薄くなってしまった場合、AIは読み取れますか？

薄くなった度合いによります。感熱紙のレシートは通常6〜12か月で劣化し始めます。化学コーティングが壊れるにつれて、文字は黒からグレー、そして見えなくなるまで薄くなります。レシートがすでにほとんど真っ白なら、人間の目に見えないデータを復元できる抽出ツールはありません。文字がかすれていてもまだ判読できる場合、AIビジョンモデルは従来のOCRよりも上手く処理できることが多いです。ピクセル単位のコントラストだけに頼るのではなく、画像全体を処理して周囲の文脈から文字を推測するからです。実用的な教訓は次の通りです：レシートを受け取ったらすぐにデジタル化しましょう。感熱レシートが一度薄くなってしまえば、データは失われます。経済産業省（METI）もこの理由から、発行から3か月以内のスキャンを推奨しています。

出力をExcelではなくfreeeや弥生にインポートできますか？

freee、弥生、MoneyForwardはいずれも取引データのCSVインポートに対応しています。レシートがスプレッドシートに抽出されたら、CSVとしてエクスポートし、お使いの会計ソフトのインポート形式に合わせて列の順序を調整してインポートします。freeeのインポートテンプレートは、日付、金額、勘定科目、摘要、取引先の列を想定しています。適切に構成された抽出結果の出力は、これらのフィールドに直接マッピングされます。このインポート手順により、会計アプリでの1件ずつの手入力が不要になります。150件のレシートを個別に入力する代わりに、CSVファイルを1つアップロードするだけです。

抽出したスプレッドシートは国税庁の監査要件を満たしますか？

国税庁は、電子的に受け取ったレシートについて紙の原本を保管することを義務付けていません。電子帳簿保存法は、電子的に受け取った文書の電子保存を義務付けています。スキャンしてデジタル化した紙のレシートについては、スキャンしたコピーが証拠書類として機能しますが、監査時に国税庁が原本の提示を求める場合があります。実際には、ソースファイル参照（各行を元のレシート画像にリンク）付きの抽出スプレッドシートと、適切に整理されたデジタルファイリングシステムを組み合わせれば、日付・金額・取引先で検索可能であるという記録要件を満たします。重要なのはトレーサビリティです。確定申告のすべてのデータポイントは、オンデマンドで取得できる特定のソース文書に遡れる必要があります。

確定申告を乗り切るための、恐れる必要のない方法

手入力で領収書を打ち込むのをやめると、何が変わるのか。年間150枚の領収書があるフリーランサーや小規模事業者の場合、データ入力に丸一日かかっていたのが（フォーマット切り替えのコストやエラー修正を含めると6〜8時間）、抽出に約15分、検証に約30分で済むようになります。抽出自体は数分です。検証（並べ替え、外れ値のスキャン、不明なものの再分類）は、年間を通してファイル名をきちんと付け、鮮明な画像を撮っておけば、30分で終わります。合計で1時間未満。以前はほぼ丸一日かかっていたのが、です。

これは午後を節約するという話ではありません。最終的な確定申告プロセスから、最大の不安要素を取り除くということです。領収書をなくしたのではないか、経費を誤って分類したのではないか、シューボックスが多すぎてきちんと整理できず控除を逃したのではないか、という恐れです。すべての領収書が、日付、ベンダー、金額、税区分、カテゴリ、元の画像へのリンクとともにスプレッドシートに保存されていれば、確定申告は再構築プロジェクトではなく、照合作業になります。ゼロから作成するのではなく、データを検証するのです。

青色申告特別控除（最大で課税所得を65万円減らせる）には、きちんとした記録が必要です。スプレッドシートは、そのまま青色申告の経費セクションにエクスポートでき、各行は追跡可能なソースファイルに裏付けられています。それが、自信を持って申告するのと、祈るような気持ちで申告するのとの違いです。

自分の領収書でこのワークフローを試してみてください。午後いっぱいかかってタイピングしていた領収書の山が、コーヒーを飲みながら検証できるスプレッドシートになるのを実感できるはずです。