Inferio複数の取引先・複数フォーマットの請求書データを 1 つのテーブルに集計するには?
2026年7月8日 · 6分で読める
請求書データの集計は、あらゆる請求書 — PDF、スキャン、写真、どの取引先のものでも — を共通のスキーマ(取引先、請求書番号、日付、明細行、税率別の税額、合計)に抽出することで実現します。従来はスプレッドシートへの手入力を意味していた正規化のステップを AI OCR が担うため、集計テーブルは月末の追い込み作業ではなく、書類が届くそばから自動的に積み上がっていきます。データが 1 つの構造に揃えば、支出レポート、買掛金の照合、重複請求書の検出はもはや手作業のプロジェクトではなくなります。
なぜ請求書データはこれほど集計しにくいのか?
請求書データは 2 つの軸で同時に分断されています。1 つ目はレイアウトです。取引先はそれぞれ独自の請求書を設計するため、合計金額が右上にあるものもあれば左下にあるものもあり、税区分の内訳は表だったり脚注だったり、そもそも記載がなかったりします。30 社から仕入れている企業は、実質的に「請求書」を名乗る 30 種類の異なる文書フォーマットを読んでいることになります。
2 つ目の軸は受け取りチャネルです。請求書はメール添付の PDF で届き、紙で届いてスキャンされ、最近ではチャットアプリで撮影写真として送られてくることも増えています — 取引先が LINE や Zalo で請求書の写真を送ってくるのは、日本やベトナムの中小企業では日常の光景です。これらのソースはどれも構造化データを生みません。生むのはピクセルだけです。
よくある解決策は人手です。月末に経理担当者がファイルを 1 つずつ開き、取引先、日付、金額、税額をスプレッドシートに 1 行ずつ打ち直します。月 20 件なら回りますが、200 件では破綻します — 人が統合するまでデータは分断されたままなので、レポートは常に数週間遅れ、支払記録との照合は 1 行ずつの突き合わせ作業になります。
あらゆるフォーマットの請求書を 1 つのスキーマに正規化するには?
この正規化のステップこそ、AI OCR が真価を発揮する場面です。vision-language モデル — 人間と同じように文書のレイアウトとテキストを同時に読むモデル — は、位置ではなく意味でフィールドを抽出するため、取引先ごとのテンプレートを必要としません。ソースがネイティブ PDF でも、複数ページの TIFF スキャンでも、斜めから撮影した JPG でも、出力は同じフィールドセットに収まります:取引先名、請求書番号、発行日、明細行、税率別(日本の請求書なら 8% と 10%)の税額、そして合計金額。
この共通の出力スキーマこそが集計の核心です。30 社分のレイアウトが入り、1 つのテーブルが出てくる。システムが見たことのないレイアウトの新規取引先が現れても、セットアッププロジェクトは不要です — モデルは「どの値が合計金額か?」を問うており、「座標 X には何があるか?」を問うているわけではないので、最初の 1 枚から読み取れます。
正規化は数字を信頼できてはじめて意味を持ちます。そのため抽出されたすべてのフィールドには confidence score — その値が正しい確率についてのモデル自身の見積もり — が付きます。閾値(Inferio のデフォルトは 0.75)を下回ったフィールドは、集計テーブルに黙って流れ込むのではなく、修正 UI で人のレビューに回されます。実務上これは、人が確認するのはピンボケ写真や珍しいレイアウトの数枚だけで、全請求書をチェックし直す必要はない、ということを意味します。
正規化されたデータからどんなレポートが作れるのか?
集計済みの請求書テーブルがあれば、かつてスプレッドシートのフィルタ操作に半日かかっていた問いが、単純なクエリになります。取引先別の月次支出、費目別の支出、四半期ごとのコスト推移 — すべての請求書が同じフィールドを共有していれば、どれもグルーピング 1 回の距離です。
照合作業も同じように様変わりします。請求書番号、取引先、金額が構造化フィールドになっていれば、支払記録や買掛金台帳との突き合わせは 1 行ずつの比較ではなく join になります。同じ 3 つのフィールドは重複も浮かび上がらせます。取引先・番号・金額がすべて一致する 2 件は、再送、再スキャン、あるいは同じメールを 2 人が転送したことによる二重提出とみてほぼ間違いありません — データが 200 個のバラバラな PDF に散らばっている限り、ほぼ見えないタイプのエラーです。
日本で事業を行う企業には、もう 1 つ重要なチェックがあります。適格請求書等保存方式(インボイス制度)では、発行者の T 番号(適格請求書発行事業者の登録番号)が有効でなければ仕入税額控除が受けられません。T 番号は抽出フィールドの 1 つなので、国税庁(NTA)の公開 API に対して 1 件ずつ自動検証できます — 集計テーブルに並ぶすべての請求書は、申告時にまとめて監査するのではなく、控除可否を事前チェック済みの状態で届きます。
集計したデータはどこへ渡すのか — Excel、会計ソフト、それとも ERP?
レポート業務がスプレッドシート中心のチームには、エクスポートが出発点です。集計テーブルをファイルとしてダウンロードすれば、手作業で組み上げていた月末のワークブックが、検証済みデータから生成されたものに置き換わります。最も自動化度の低い出力先ですが、多くの場合これが最初の一歩になります — 下流のシステムが依存し始める前に、データが正しいことを証明できるからです。
会計ソフトへは、ファイルより直接同期が優れています。Inferio は freee と MoneyForward に OAuth で接続し、レビュー済みの請求書を CSV インポートを挟まずに仕訳として登録します — 集計は上流で完結し、会計システムはクリーンな仕訳だけを受け取ります。
社内システム — ERP、データウェアハウス、BI 基盤 — へは、REST API が構造化された結果を提供し、signed webhook が処理済みの文書をレビュー通過と同時にあなたのエンドポイントへプッシュします。署名をサーバー側で検証するため、偽造されたペイロードは弾かれます。さらに、電子帳簿保存法が電子取引記録の保存を義務付けているため、原本と抽出データは法令準拠のストレージに 7 年間保管されます — 集計によって、データがその裏付けとなる文書から切り離されることはありません。
よくある質問
- 取引先や請求書が月に何件を超えたら、手入力より自動化すべきか?
- この閾値は多くのチームが思うより低い位置にあります。負担は請求書の件数以上に取引先の数に比例します — 取引先 1 社が 1 つの独自レイアウトであり、人は毎月それを読み直すことになるからです。目安として、取引先が約 10 社、または月 50 件を超えたあたりから、Excel への打ち直しは経理の工数を目に見えて消費し、入力ミスを生み始めます。写真やスキャンで届く請求書が多いほど、手作業での転記が最も遅いソースであるため、この閾値はさらに下がります。
- 日本語・英語・ベトナム語の請求書が混在していても、1 つのテーブルに集計できるか?
- できます。vision-language モデルは英語、日本語、ベトナム語の文書を読み取ります — 英語の明細行を含む日本語の請求書のような多言語混在の文書も、言語ごとの専用エンジンなしで扱えます。すべての文書が言語にかかわらず同じ出力スキーマにマッピングされるため、東京発行の請求書もハノイ発行の hoá đơn も、同じ列構成の同じテーブルに収まります。
- 重複した請求書を検出できるか?
- 構造化データにすることで、PDF のままでは不可能だった検出が可能になります。請求書番号、取引先、金額が 1 つのテーブルのフィールドになっていれば、3 つすべてが一致する 2 行は、再送・再スキャン・同一メールの二重転送などによる二重提出とみてほぼ間違いありません。それを捕まえるのは正規化されたデータへのクエリであって、入力担当者の記憶力テストではありません。
- 手作業で作っている Excel の集計ファイルを置き換えられるか?
- 置き換わるのは手作業の部分であって、スプレッドシートそのものとは限りません。請求書を打ち直して作っていた月末のワークブックは、検証済みデータからのエクスポートになります — 使い慣れたフォーマットのまま、転記の工数と入力ミスだけがなくなります。スプレッドシートの規模を超えたチームは、同じ正規化データを同期や API 経由で会計ソフトやデータウェアハウスに流し込めばよく、請求書の取り込み方を変える必要はありません。