フライト旅程データを照合する方法
手入力なしで

航空券の旅程に実際に記載されているもの

Eチケットの旅程領収書には、経費処理に必要なすべての項目が含まれています。問題は、それが旅行者向けにフォーマットされており、スプレッドシート向けではないことです。何かを抽出する前に、航空会社が送付する3種類の書類のうちどれが領収書に該当するかを把握しておくと役立ちます。予約確認書（予約番号（PNR）と搭乗時刻が記載された旅程概要）、Eチケット領収書（運賃の内訳、税項目、13桁のチケット番号）、そして旅行領収書（搭乗後に確定する最終請求額）です。経費精算の観点では、Eチケット領収書が重要です。支払われた金額を裏付ける書類だからです。搭乗券はこれら3つすべてに付随する搭乗当日の書類で、搭乗者名、便名、搭乗ゲート、搭乗時刻、座席番号が記載されており、これらの項目をスプレッドシートに落とし込む必要がある場合は、専用の搭乗券スクリーンショット抽出のチュートリアルがあります。

その領収書に記載されている項目は、ページのレイアウトが異なっていても、航空業界の予約インフラによって標準化されています。各予約には予約番号（PNR＝Passenger Name Recordとも呼ばれる）が付与されます。これは「K7FQ2M」のような6桁の参照コードで、旅程、チケット、支払いを航空会社のシステム間で紐付けるものです。その周囲には、T&Eプロセスが実際に使用するデータ項目が並んでいます。

ここにこのデータが閉じ込められる理由があります。業界標準のページレイアウトが存在しないのです。IATAはPNR内のデータを定義していますが、各航空会社、グローバル配信システム（GDS）、予約ツールがそれぞれ独自の文書を生成します。ユナイテッドの電子チケット領収書はデルタのものとは異なり、デルタのものはConcur Travelの予約で生成される旅程表とも異なります。そのため、「便名は左上にある」という前提で構築されたワークフローは、2社目の航空会社で失敗するのです。

手作業の限界と、そのコスト

手作業は時間を奪うだけでなく、精算に欠かせない監査証跡を壊してしまいます。SAP Concur、Navan、Expensify を利用している場合、予約データは自動で流れ込むことが多いものの、運賃の内訳、チケット番号、税額の行が空白のまま残ることがよくあります。特に、出張が社内の予約チャネル外で手配されたり、個人カードで支払われたりした場合です。誰かがそれらを手入力し直すことになります。そこから照合のトラブルが始まります。

この失敗パターンは、T&Eサイクルを締めたことがある人なら誰でも見覚えがあるでしょう。便名の数字が入れ替わっていたり、複数区間の旅程の別の区間から日付を入力してしまったりすると、経費が予約内容と一致しなくなります。一致しなければ、監査人やカード明細のアルゴリズムがフラグを立て、従業員は再提出を求められます。r/Accounting で繰り返し寄せられる苦情は、まさにこのループを指摘しています。経理部門がシステム間で領収書を紛失し続けたため、従業員が同じフライトを6回も経費申請させられたという内容です。問題は入力速度ではなく、書類が取引に紐づいたデータとして残らないことにあるのです。

コンプライアンス上のリスクを考えれば、これは単なる効率性の問題ではありません。IRSの規則では、会社が実費精算制度を運用している場合にのみ、従業員への払い戻しが非課税となります。この制度では、すべての経費について、金額、日時、場所、事業目的を裏付けることが求められます。IRSはPublication 463でこの点を明示しています。各経費の領収書（またはその他の証拠書類）に加え、経費発生時またはその近くで作成された記録が必要です。運賃の入力ミスやチケット番号の欠落は、何百もの出張にわたって、この裏付けを静かに侵食していきます。そして、T&Eの正確性への圧力は高まる一方です。2025年のDeloitte Corporate Travel Studyでは、出張管理者の54%がコストを出張における上位3つの制約の一つに挙げています。支出への監視が厳しくなるほど、領収書の正確性が求められるのです。

これは出張者にとっても新しい話ではありません。r/SAP の Concur に関するスレッドは、従業員側の体験を率直に語っています。「システムが遅くなりすぎて、どんな経費報告書でも作成するのが苦痛だ」という内容です。解決策はより速いUIではなく、旅程データが構造化された状態で届くように、再入力のステップをなくすことなのです。

列セットの定義：出力テーブルに何を含めるか

出力テーブルは、あなたが指定する列によって定義されます。航空券の旅程の場合、適切な列セットは、予約、運賃、コンプライアンスを1セグメントにつき1行でカバーします。これがカスタム列抽出の核心です。ページ上のどこを探すかをツールに指示する代わりに（2番目の航空会社のレイアウトで機能しなくなるアプローチ）、「予約番号（PNR）」「便名」「支払総額」などの列名を入力するだけで、AIビジョンモデルがフィールドの意味を理解して各値を文書内のどこにあっても特定します。

航空券旅程バッチの場合、完全なT&E精算をカバーする列セットは次のようになります。そのままコピーして使用できます：

これらの列のうち2つは、ページを読み取るだけではありません。計算列は抽出中に計算を実行します。複数区間のチケットの場合、区間別運賃（支払総額 / 区間数）という名前の列が、1つの運賃を自動的に各区間に分割するため、各区間の行を独立して割り当てることができます。また、推論列は文書に明記されていないことを分類します。「出張目的」を「顧客訪問 / 会議 / 社内ミーティング / 研修 / 私用」の選択肢で定義すると、AIが旅程（経路、予約の文脈、関連レポート）を読み取り、各出張に目的を割り当てます。抽出と分類は同じパスで行われます。これが、数字の表と精算可能な記録の違いです。

一度定義した列名は、最終的なスプレッドシートのヘッダーになります。また、同じ列名セットがバッチ内のすべての航空会社、GDS、予約ツールで機能します。各列はページ上の位置ではなく意味で照合されるためです。

旅程を一箇所にまとめる

抽出の前に、収集ステップでバッチが完全かどうかが決まります。そして、このステップは多くのワークフローで計画されていません。旅程は3つの形で届きます。メールから転送されたPDF、航空会社のアプリや予約ツールからのスクリーンショット、企業の出張ポータルからダウンロードした確認書です。旅行者の中には自分でアップロードする人もいれば、カード明細が届くまで忘れてしまう人もいます。収集の設計が両方のケースをカバーします。

2つの仕組みがこのギャップを埋めます。メール受信ボックスはチームに専用の転送アドレスを提供します。旅行者が旅程PDF（または航空会社からのメール）を転送すると、添付ファイルが自動的に処理キューに届きます。アップロードページもログインも不要です。「自動処理」設定と組み合わせることで、バインドされた抽出テンプレートがメールが届いた瞬間に各旅程の読み取りを開始します。1ヶ月分のフライトメールが、月末に慌てて処理するのではなく、届いた時点で次々と変換されます。リンクを好む旅行者には、コレクションリンクが短い認証コード付きの共有可能なURLを生成します。誰でも開いて旅程（スクリーンショット、PDF、何でも）をドロップでき、アカウントは不要です。両方のチャネルが同じキューにフィードされるため、バッチは月の間に継続的に組み立てられます。

ソース品質には単純な順序があります。メールからのPDFが最もクリーンな入力で、旅程ページの平らで明るいスクリーンショットもほぼ同様に機能します。空港の照明の下で斜めから撮影した急いだ電話画面の写真は処理可能ですが、検証パスに値します。現実的な期待値を設定しましょう。クリアなPDFとスクリーンショットは高信頼度の抽出を生み出し、品質の低いキャプチャは作業を「タイピング」から「スポットチェック」に移行させます。

バッチを処理する：1回のパスで1つのスプレッドシート

バッチ処理は、1ヶ月分の旅程を1回のパスで単一のスプレッドシートに変換します。ドキュメントあたり5〜10秒で、列は一度だけ定義します。すべての旅程を一度にアップロードし（PDF、スクリーンショット、アプリのキャプチャ）、出力は1つのExcelファイルで、各行が1つのフライトセグメント、各列が1つの定義済みフィールドです。マージも、列の再調整も、ファイル間のコピーペーストも不要です。ImageToTable.aiは1ページを5〜10秒で処理します。平均的な手動入力は約3分です。100件の旅程では、昼休みと丸一日の違いに相当する有意義な比較です。

これがデータが検証可能になる瞬間です。レビューモードにより、経理レビュー担当者は抽出された任意のセルにホバーして、元のドキュメント上の値の出所（運賃ベース、税行、チケット番号）を旅程画像上でハイライト表示できます。抽出された値をクリックするとソース領域が点灯し、ドキュメント上の領域をクリックすると一致するセルにジャンプします。このレイヤーは航空運賃に特に重要です。誤った税合計はカード照合に直接伝播するからです。処理後に自動注釈をオンにすると、すべての新しい抽出に検証マップがすでに組み込まれて届きます。

スプレッドシートから精算へ：ループを閉じる

抽出はスプレッドシートで終わり、照合はそこから始まります。抽出された行は、経費システムの隣に置かれるのではなく、経費システムに流し込むために作られています。バッチで得られるワークブックは、T&EプラットフォームのOCRがクリーンな領収書に対してのみ生成するであろう構造化バージョンです。運賃、税金、チケット番号、経路、日付、出張目的がすべて列にまとめられています。この構造こそが、締めのステップを速くする鍵です。

ConcurやNavanを利用している企業では、抽出されたテーブルは航空運賃の明細項目に直接マッピングされます。予約番号（PNR）とチケット番号はカード明細との照合の基準となり、支払総額は法人カードの取引に紐づき、運賃の内訳は請求額が表示運賃と一致しない理由を説明します。ExpensifyやZoho Expenseを利用する小規模チームでは、同じワークブックがインポート元として機能します。行が入り、カテゴリが付与され、精算が承認されます。重要なのは、抽出が経費プラットフォームを置き換えることではなく、経費報告書のデータが事前に構造化された状態で届くことであり、誰かが手入力しなければならないPDFとして届くことではないのです。

コンプライアンスの観点も同じように完結します。抽出された各行には、実費精算制度が求める4つの立証要素が含まれています。金額（基本運賃、税金、合計）、時間（搭乗日）、場所（出発空港と到着空港）、目的（推論列）です。多くの企業が食事と宿泊に使用するGSA日当の枠組み（2026会計年度の米国本土（CONUS）標準宿泊費は1泊$110、食事および雑費は1日$68）は、これらのカテゴリを日当ベースでカバーします。航空運賃には日当の代替手段がないため、旅程の領収書は常に本物で、完全で、読みやすいものでなければならない唯一の旅行領収書です。

実際に問題が発生するケース（とその対処法）

実際に起こり得る問題点は特別なものではありません。複数区間の運賃、通貨の不一致、変更手数料などで、それぞれに定義された対処法があります。メールで届くPDFのバッチがきれいな状態なら、ほとんどレビューなしで処理が完了します。例外こそが、このワークフローの価値を発揮する場面です。

複数区間の旅程。往復便は1枚の領収書に2つの便名が載っています。乗り継ぎがある旅程ならさらに多くなります。抽出処理は各区間の行を読み取り、区間ごとに1行を生成し、計算列の「区間別運賃」が単一の運賃を各区間に分割します。これにより、レビュー担当者は2区間と税金の合計が総額と一致することを承認前に確認できます。

旅程の通貨とカードの通貨。フランクフルト発シカゴ行きのチケットがユーロ建てで、カードの請求はドル建てになるケースです。抽出された「通貨」列は元の金額とISOコードをそのまま保持するため、チームは入力者がたまたま使ったレートではなく、ポリシーで定義されたレートで換算できます。これにより、「カード明細と一致しない」という指摘が繰り返し発生する問題を解消します。

総額のみの領収書。一部の予約ツールや航空会社は、運賃の内訳なしで総額のみのサマリーを送信します。抽出処理は表示されている内容を取得し、運賃分割列は空のままにします。これにより、数字を捏造するのではなく、ギャップを明らかにします。対処法は、航空会社のポータルから完全な電子チケット領収書を取得することです（通常、予約番号（PNR）を入力すれば取得可能）。分割を推測する必要はありません。

変更、払い戻し、低品質の画像。変更後は、旅程と旅行領収書が一致しないことがあります。抽出された行は両方を並べて表示するため、差異が埋もれずに可視化されます。また、スマホ画面を斜めから撮影した写真では精度が低下します。正直な期待値としては、きれいな入力はツールの印刷テキスト精度約99%で抽出され、粗いキャプチャはレビューモードでのスポットチェックが必要です。それでも、ゼロから入力するより桁違いに速いです。

よくある質問

航空会社や予約ツールを問わず、どの旅程でも対応できますか？

はい。抽出はテンプレートの位置ではなく意味でフィールドを照合するため、航空会社ごとの設定は不要です。ユナイテッド航空のeチケット控えも、デルタ航空のものも、Concur TravelやNavanなどの予約ツールの旅程も、すべて同じ列定義で処理されます。鮮明なPDFやフラットなスクリーンショットは最も高い精度で抽出されます。航空会社によるレイアウトの違いは抽出に影響しません。

旅程に運賃の内訳がなく、合計金額しか表示されない場合はどうすればよいですか？

このワークフローは、文書に表示されている内容を抽出し、欠落している運賃分割の列は空のままにして、推測ではなくギャップとしてフラグを立てます。完全な内訳を取得するには、予約番号（PNR）を使用して航空会社のポータルからeチケット控えを取得してください。ほとんどの航空会社はオンラインで取得できます。その文書を処理すれば、内訳が得られます。運賃が大きい場合は、基本運賃と税金の分割がカード請求の照合を可能にするため、この手順を実行する価値があります。

抽出したスプレッドシートをConcurやNavanに取り込めますか？

これらと併用できます。経費プラットフォームは承認・ポリシー・払い戻しのエンジンであり、複数航空会社・複数形式の旅程スタックを読み取るようには設計されていません。抽出されたワークブックは構造化された入力です。各セグメントの行には、運賃分割、チケット番号、日付、経路、出張目的が含まれており、手入力ではなく、航空券の明細項目としてインポートまたは貼り付けできます。ExpensifyやZoho Expenseを利用している小規模チームは、同じワークブックを直接使用しています。入力データがクリーンであればあるほど、プラットフォームでの手動修正は少なくなります。

別の通貨で予約した旅行はどう扱えばよいですか？

抽出したテーブルには、元の金額とISO通貨コードを保持してください。「通貨」列はチケットに記載されている内容を保持します。入力者がたまたま使った為替レートではなく、ポリシーで定義された単一のレート（予約日のレートが最も合理的）で換算してください。この一貫性により、複数通貨のバッチをカードフィードと照合できるようになります。

個人で予約し、払い戻しを申請している従業員についてはどうですか？

旅程表は依然として領収書として機能します — 抽出は運賃、税金、チケット番号を同じ方法で取得し、搭乗者名列でチケットが申請者に属していることを確認します。ここで出張スタッフに送信するコレクションリンクが効果を発揮します：従業員は空港でスマートフォンから旅程表をアップロードし、データは数週間後に転送されたPDFから再構築される代わりに、あなたのキューに直接届きます。