AIで領収書・経費データを整理する方法｜入力作業を減らす

領収書やレシートの入力を減らすには、画像から文字を読むだけでなく、抽出結果を台帳へ渡す前に確認する工程まで決めます。先に列と入力ルールを固定し、日付・支払先・金額・通貨を証憑に照らしてから登録してください。OCRは読み取り、勘定科目の決定は会計ルールに沿った別判断です。

まず決めるのは台帳の形

処理を始める前に、会計担当者が受け取る列を決めます。たとえば、証憑ID、利用日、支払先、摘要、税抜金額、税額、税込合計、通貨、経費科目、部門、証憑ファイル名、確認状態です。既存の会計ソフトが要求する列がある場合は、その名称と形式を優先します。

表は横にスクロールできます

項目	入力ルールの例	確認元
利用日	YYYY-MM-DD。年月日が読めない場合は空欄でなく「要確認」	レシートの日付
支払先	店舗・会社名。店舗名と決済代行名を混同しない	レシート上部
合計	税込合計と税額を別欄へ。通貨も記録	合計欄・税欄
科目	AIは候補まで。確定は社内ルール・承認者	社内の科目表
証憑ID	元画像または保存ファイルと一意に結び付ける	ファイル名・ID

この段階で、数字の小数点、税込・税抜、負数、日付のタイムゾーンなど、台帳で許容する形式も決めます。異なる形式を後から自動変換すると誤差が見つけにくいため、抽出時点で「原文値」と「正規化値」を分ける設計が有効です。たとえばレシートに「¥1,100」とあれば、原文値はそのまま保管し、金額列に1100、通貨列にJPYを置きます。税区分を読み取れないときは推定せず空欄・要確認にします。

OCRと分類を一つの正解にしない

OCRは紙面上の文字や数字をデータ化する処理です。支払先から勘定科目を決めること、利用目的を推測すること、税区分を確定することは別の処理です。領収書に「コーヒー」と書かれていても、会議費か福利厚生費かは購入状況や社内基準で変わります。AIに科目を提案させる場合は「候補」と明示し、確定者と確認履歴を残してください。

Google Cloud Document AIのExpense Parserは、日付、支払先、合計金額、通貨などの領収書情報を抽出する専用processorです。公式のprocessor一覧では日本語が対応言語に含まれますが、対応状況はprocessorの版や実行条件に依存します。日本語対応だけで、自社の帳票・撮影条件で精度が保証されるわけではありません。導入前に対象帳票を使った検証を行い、試験結果と人手修正率を記録してください。Invoice Parser等の別processorと混同せず、利用するprocessor名・版・regionの条件を公式一覧で確認します。

入力を一定にして抽出する

スマートフォン撮影では、レシート全体を画面へ収め、文字にピントを合わせます。影、反射、斜めの歪み、折れ、複数枚の重なりは、数字や小さな文字を読み違える要因になります。撮影画像を加工する場合も、端を切り落として合計や日付が欠けていないかを確認します。

Chat AIへ画像を渡す場合は、抽出対象と返却形式を指定します。以下はプロンプトの骨格です。

添付した領収書から次の項目を抽出し、JSONで返してください。

利用日、支払先、摘要、税抜金額、税額、税込合計、通貨、税区分。

読み取れない項目は推定せず null にし、確認が必要な理由を別欄に記載してください。

原文の表記と正規化値を区別してください。勘定科目は決定しないでください。

出力後は、必須項目、日付形式、数値型、通貨コードを機械的に検証します。金額が数値でない、税込合計が税抜と税額に合わない、日付が未来になるなどの異常値は登録せず、人の確認キューへ回します。税計算には丸め方や端数処理があるため、単純な合計一致だけで会計処理の正しさを断定しません。

人が見る箇所を決める

すべてを同じ濃さで目視する必要はありませんが、少なくとも金額、日付、支払先、税額、通貨、証憑との対応は原画像に戻って照合します。低解像度、複数税率、手書き、返品・取消、外貨、項目の欠落は優先確認にします。信頼度スコアを使える場合も、それは誤りの可能性を並べ替える材料で、会計上の正しさを保証する値ではありません。

表は横にスクロールできます

判定	例	次の処理
自動で下書きへ	必須欄が揃い、形式検査を通過	人が原画像を照合して承認
要確認	金額・日付・税欄の欠落や複数候補	登録を止め、担当者が補う
取込失敗	画像が欠ける、別書類、読み取り不可	再撮影または手入力へ戻す

読み取りに失敗した時は、同じ画像を何度も別モデルへ渡すより、まず証憑の向き・解像度・切れを確認します。文字選択できるPDFと画像だけのスキャンも区別します。画像を見直しても重要欄が確定しない場合は、AIが埋めたように見える値を採用しないでください。

重複登録と監査記録

同じ領収書を再撮影したり、メール添付とスマートフォン画像の両方から取り込んだりすると、二重計上の可能性があります。ファイル名だけでなく、画像ハッシュ、日付・支払先・金額の組み合わせなどを重複候補の検出に使えます。ただし同じ店で同日に同額の購入もあり得るため、自動削除ではなく候補表示にします。修正前の抽出値、修正後の値、確認者、日時、元証憑の参照先を記録します。

個人名、カード情報、取引先情報を外部AIサービスへ送る前に、会社の情報管理ルール、契約、アカウント設定を確認します。業務で利用が許可されていないサービスへ、証憑をそのままアップロードしてはいけません。必要なら氏名やカード番号をマスキングし、許可された環境だけで処理します。

導入前に小さく評価する

本番台帳へ直結させず、代表的な証憑で試験データを作ります。通常のレシートだけでなく、長いレシート、薄い印字、複数税率、外貨、手書き補記、返品のような例外を含めます。評価時は「読み取れた枚数」だけでなく、必須項目の正確さ、要確認率、人が修正した項目、重複検知の誤警告、1件の確認にかかる手間を分けて記録してください。母数や評価方法を示さずに「精度が高い」と結論付けるのは避けます。

試験後は、どの書類なら自動で下書きにできるか、どの条件では手入力へ戻すかを決めます。処理の入口には再試行上限や失敗ログを設け、同じ書類が繰り返し登録されないようにします。出力Schemaを変えた場合は、過去データへの影響を確認してから運用へ適用します。

AIものさしの判断

領収書整理の完了条件は、画像が読めたことではなく、証憑に結び付いた台帳行を作り、重要項目を人が確認し、重複や不明値を安全に扱えることです。少量で書類形式も一定なら、まず台帳の列と確認手順を整える方が先です。定型書類が大量にあり、取り込み後の修正率まで測れる場合に限り、専用Parserや自動連携の検証へ進みます。

抽出結果を台帳へ渡す例

次は会計結果を示すものではなく、出力設計を説明する仮の入力例です。実際の証憑から読み取れない値は埋めません。

{

  "receipt_id": "R-2026-001",

  "document_date_raw": "2026/10/08",

  "document_date": "2026-10-08",

  "supplier_raw": "サンプル商店",

  "amount_total_raw": "¥1,100",

  "amount_total": 1100,

  "currency": "JPY",

  "tax_amount": null,

  "category_candidate": null,

  "review_status": "needs_review",

  "unresolved": ["税額の内訳を証憑で確認"]

}

この例のように、金額が読めても税額が明示されていない場合は、税額や科目を合計から勝手に計算・推定しません。自動処理の下流では、review_statusがneeds_reviewの行を会計ソフトへ確定登録しないようにします。必須fieldが欠けている場合の動作を先に定めておくと、空欄が誤って「0円」や「対象外」として扱われる事故を減らせます。

例外処理の行き先

• 同じ画像が再送された：既存候補を表示し、人が同一証憑か確認する

• 日付が読めない：証憑を再撮影するか原本から入力する

• 合計と税欄の関係が判断できない：会計担当へ回し、OCR工程で補わない

• 通貨が記載されていない：通貨を推定せず、取引の登録条件を確認する

• 支払先が決済代行会社のみ：店舗名を証憑と取引明細で確認する

• AI出力がSchemaに合わない：変換して通さず、修正・再処理ログを残す

エラー対応には、処理を止める条件、再試行する条件、担当者へ渡す条件を持たせます。誤った値を自動で正常データに直す補正ロジックは、十分な検証なしに追加しません。

作業の引き継ぎ条件

抽出工程の担当者と会計承認者を分け、行単位で「未確認」「確認済み」「差戻し」を管理します。差戻し理由は、数字の不鮮明さ、分類根拠不足、原画像の欠落など具体的に記録します。修正後も元の抽出値を消さず、誰がどの値を変更したか追えるようにします。会計年度、科目表、税処理ルールが変わった時は、古い分類候補を新しい基準へそのまま流用せず、適用日と担当者を明示して再確認します。