ホテル明細書を
GLコード付き経費報告書に変換する方法

ホテルフォリオと通常のレシートの違い

ホテルフォリオとは、チェックインからチェックアウトまでにゲストアカウントに発生したすべての料金と支払いを明細化した継続記録です。レストランのレシート（1取引、1事業者、1カテゴリ）や小売店のレシート（複数商品、1税率）とは異なり、フォリオはホテル運営の複数部門にまたがります。各部門には独自の料金コード、税務処理、会計上の振り先があります。

1926年以降、ほぼすべてのブランドホテルが採用する会計基準であるUSALI（全米宿泊産業統一会計システム）では、ホテルの収益と費用は部門別勘定（客室、飲食、通信、駐車場、ヘルスクラブ/スパ、その他運営部門）で管理されます。2025年2月にHFTP、AHLA、グローバルファイナンス委員会が発行したUSALI第12改訂版は、この部門別構造を強化し、ゲストロイヤルティプログラム費用やフルタイム相当労働力追跡のための新しい費用カテゴリを追加しています。ゲストが夕食代を客室に請求すると、その取引は飲食部門に計上されます。駐車料金は駐車場部門に計上されます。フォリオはホテル内部の勘定科目表を反映したものであり、ゲスト側のものではありません。

この構造の不一致こそが、精算問題の核心です。ホテルの会計システムは各料金を自社の部門コードで記録します。一方、ゲストの会社は同じ料金を全く異なるカテゴリ（宿泊費（GL 6400）、飲食費（GL 6500、通常50%控除対象）、交通費（GL 6600）、および場合によっては別途の税負担勘定）に振り分ける必要があります。5つのUSALI部門にまたがる47明細のマリオットの4ページのフォリオは、3つのGLコードにわたる4行の経費報告書エントリに変換されなければなりません。この「ホテル会計ロジックから法人経費ロジックへの変換」こそ、既存のレシートスキャンアプリでは対応できなかった処理です。

さらに、フォーマットはプロパティ管理システムによって異なります。主要なホテルPMSであるOracle Operaは、特徴的な明細行構造のフォリオを生成します。マリオットのLightStay、ヒルトンのOnQ、そしてCloudbeds、RoomRaccoon、INNsightなどのシステムを運用する独立系ホテルでは、すべてレイアウトが異なります。同じデータでも、配置が違います。特定のホテルチェーンのフォーマットで学習されたテンプレートベースのOCRツールは、次のチェーンでは機能しません。

経費精算に本当に必要な明細データ

抽出の前に、どのデータが重要でその理由を明確に定義する価値があります。宿泊明細書は4～5ページに及ぶことがあり、そのすべてが経費報告書に関連するわけではありません。すべてを同等に扱うと、2分の作業が20分の作業に変わってしまいます。

以下は、法人経費報告書のための最小限の抽出セットであり、一般的な総勘定元帳（GL）の処理に対応しています。

税の行だけでも複数の階層があることに注意してください。シカゴのホテルに一泊するだけで、イリノイ州宿泊税（6%）、シカゴ市ホテル税（5.8%）、そしてコンベンションセンター近隣の物件にはマコーミック・プレイス拡張税（2.5%）がかかる場合があります。経費システムが「宿泊料合計：287ドル」としか記録しない場合、基本料金とこれらの税金を分離する方法はありません。これは、クライアント契約が基本料金は払い戻すが税金は対象外の場合や、自社のポリシーがその都市のGSA日当レートに宿泊費の払い戻しを制限している場合に問題となります。

ここで、IRS Publication 463のアカウンタブル・プラン規則も関連してきます。アカウンタブル・プランでは、従業員は各経費の日時、場所、事業目的、および金額を立証する必要があります。払い戻しシステムが宿泊明細書の合計金額のみを記録し、その合計のうち340ドルが従業員が最終日に追加したスパ料金だった場合、雇用主は税制優遇措置のある経路を通じて個人経費を払い戻していることになります。IRSの立証要件はまさにこれを防ぐために存在しており、明細項目抽出ワークフローこそが、立証を大規模に実践可能にするものです。

ステップ1 — 宿泊明細書のクリーンで完全なコピーを入手する

抽出の品質は、取得する情報の品質に依存します。ホテルの宿泊明細書は3つの経路で届き、それぞれに落とし穴があります。

運用上の注意：一部のホテル（特に独立系や小規模チェーン）では明細書を自動メール送信しません。フロントで1部印刷され、それが唯一のコピーです。旅行者が紛失した場合、再発行には電話、自動音声案内の操作、ファックスやメールの待機が必要で、届かないこともあります。出張者に「駐車場を出る前に明細書を撮影する」よう徹底することで、後工程のボトルネックを防げます。

ステップ2 — 列を定義し、明細をすべて抽出する

従来のOCRがホテルの明細書で失敗する理由は構造にあります。テンプレートマッチングに依存しているからです。「ルームレートはページの(x,y)座標にある」とソフトウェアに教え、毎回その場所を読み取ります。しかし、ヒルトンとハイアットではルームレートの位置がまったく異なります。あるチェーン用のテンプレートを作っても、次のチェーンでは使えません。

代わりとなるのがカスタム列抽出です。ツールに「どこを」見るかではなく「何を」探すかを指示します。「ルームレート」「宿泊税」「レストラン料金」「駐車料金」といった列名を入力すると、AIビジョンモデルが明細書を読み、各料金の意味を理解し、ページ上の位置に関係なく対応する値を抽出します。入力した列名が、出力スプレッドシートのヘッダーになります。

実際のワークフローは次のとおりです。

具体例を挙げると、コンサルティング会社のQ2出張経費を処理する経理担当者が、6つの異なるホテルチェーンから14枚の明細書を受け取ったとします。うち3枚はマリオット系列からメールで送られたPDF、4枚は個人経営のホテルの明細書をスマホで撮影した写真、2枚はヒルトン・オナーズのアプリのスクリーンショット、1枚はかすれ始めた感熱紙の明細書をスキャンした画像です。抽出項目は一度定義するだけ——同じ15のフィールド名が、形式やチェーンに関係なく14枚すべての書類に適用できます。

精度の期待値について一つ注意点があります。この抽出を支える視覚言語モデルは、書類全体——レイアウト、文脈、同じ行にある料金説明と金額の関係——を理解することでテキストを読み取ります。印刷されたきれいなホテル明細書であれば、高い精度を発揮します。しかし、折れ曲がった感熱紙を悪い照明で斜めから撮影したような場合は、精度が低下します。難しい画像については、簡単な確認作業をワークフローに組み込むことをお勧めします。ただし、スプレッドシートで外れ値をスキャンするだけの確認作業でも、47行の明細をゼロから手入力するよりは桁違いに速いのです。

ステップ3 — 各明細を正しいGLコードに割り当てる

データを抽出すれば問題は半分解決です。残りの半分は、各費用を手作業で確認・分類することなく、適切なGL勘定に振り分けることです。ここで鍵となるのが推論列です。AIが費用の説明文に基づいてカテゴリを判断し、抽出した値と一緒にそのカテゴリを出力できるようにします。

推論列は、AIに有効な選択肢のセットを与え、文書の文脈に基づいて適切なものを選ばせる仕組みです。ホテルの明細書の場合、次のように定義できます。

実際の成果：抽出ワークフローを1回実行するだけで、すべての明細項目が正しいGLコードに割り当てられ、税務処理もフラグ付けされたスプレッドシートが生成されます。経理レビュー担当者の作業は、データ入力（「駐車場はどのGLコードか？」）から、例外処理（「この明細書に180ドルのスパ費用が宿泊費として分類されている→非償還対象に上書き」）に変わります。

旅費をクライアントに請求するプロフェッショナルサービス企業では、この割り当てレイヤーは顧客向けになります。案件単位で請求を行う法律事務所では、宿泊料金と税金は請求可能、食事と駐車場は非請求可能と指定する場合があります。同じ抽出実行で、社内精算用の経費報告書と、クライアント請求書用の請求可能経費サマリーの2つの出力を生成できます。同じ元データから、カテゴリでフィルタリングするだけです。

複数の宿泊明細を一括処理

個別の明細処理も便利ですが、時間を大幅に節約できるのは一括処理です。ニューヨーク、シカゴ、ダラスを巡る出張から戻った従業員は、3つの明細書を持っています。個別に処理すると、3回の抽出、3つのスプレッドシート、手動での統合作業が必要です。一括処理なら、1回のアップロード、1回の列定義、1回のエクスポートで完了。3行のデータが入った1つのスプレッドシートが、すぐに確認できる状態で出力されます。

この一括ワークフローはチーム単位でも威力を発揮します。20人の出張者から経費報告書を処理する少人数の経理チームは、特定の週や月の明細書をすべて集め、一括アップロードするだけで、すべての宿泊を網羅した1つのスプレッドシートを入手できます。月末の精算作業が、従業員一人ひとりに個別の領収書を追跡する作業から、明細書を集めて一括処理し、出力を確認して帳簿を閉じるだけの作業に変わります。

経理プラットフォームを利用していない出張者から明細書を集める必要があるチームには、コレクションリンクが直接アップロードの手段を提供します。共有可能なリンクを生成して出張者に送るだけで、リンクを受け取った人は誰でも、ログインやアカウント登録、ソフトウェアのインストールなしで、明細書を直接処理キューにアップロードできます。明細書はバッチに追加され、他の書類と一緒に抽出処理の準備が整います。

よくある質問

ホテルの明細書に外貨建ての請求がある場合はどうなりますか？

AIは明細書に記載されている数値をそのまま抽出します。通貨換算は別のステップです。多くの経理チームは、取引日の為替レートを使用して経費システムやERPでこれを処理します。抽出ワークフローが提供するのは、明細書の元の通貨での明細ごとの元の金額であり、これは監査担当者がクレジットカードの明細と照合するために必要なものです。

私用と業務用の請求が混在している明細書はどのように処理しますか？

ここで推論列が真価を発揮します。従業員が業務上の夕食（経費精算対象）と客室内の映画（経費精算対象外）の両方をルームチャージした場合、両方とも明細書に表示されます。経費カテゴリの推論列は、映画を「経費精算対象外」としてフラグ付けします。最終的な判断は経理担当者が行いますが、システムが「ルーム合計」という一つの項目に埋もれさせるのではなく、その区別を明確にします。これは、税制適格プランを通じて私的費用を精算すると雇用主と従業員の両方に責任が生じるため、IRSのアカウンタブルプランへの準拠にとって重要です。

複数泊の宿泊料金の内訳など、細かい部分にも対応できますか？

はい、明細書に1泊ごとの料金が記載されていれば可能です。ビジネス向けホテルの多くは、各泊の宿泊料金と税金を個別の行に記載しています。抽出機能は各行を個別に取得します。明細書に「Room Charge: 3 nights × $189 = $567」のように1行だけ記載されている場合は、その内容が抽出されます。AIはページに記載されている内容を抽出するのであって、あなたが望む内容を抽出するわけではありません。

マリオット・ボンヴォイやヒルトン・オナーズなどのアプリのデジタル明細書はどうですか？

ホテルアプリのスクリーンショットも使用できます。AIはPDFや紙の印刷物の写真と同じようにスクリーンショットを読み取ります。ただし、一部のホテルアプリではアプリ内で簡略化された明細書を表示し、詳細版はPDFダウンロードのみ提供する場合があります。抽出には詳細PDFの方が適していますが、表示されている項目についてはスクリーンショットでも機能します。

これはConcur、Expensify、Navanの代わりになりますか？

これらを補完するものです。エンタープライズT&Eプラットフォームは、予約、承認ルーティング、ポリシー適用、払い戻しといった経費ライフサイクル全体を処理します。しかし、複数ページにわたるホテル明細書を構造化された明細データに変換することは、必ずしも得意とはしません。この抽出ステップにより、クリーンで分類されたスプレッドシートが生成され、構造化された入力として経費システムに取り込まれます。プラットフォームのOCRが明細書の合計を読み取り、従業員が手動で内訳を入力する代わりに、従業員が明細書を一度アップロードすれば、明細項目が自動的に入力されます。

明細書1件あたりの抽出時間はどのくらいですか？

標準的な3ページのホテル明細書は5～10秒で処理されます。制限要因は抽出速度ではなく、確認速度です。つまり、出力の正確性を確認し、エッジケース（誤読された金額、曖昧な請求内容の説明）に対処する時間です。10件の明細書のバッチは、通常2分未満の処理時間と、確認担当者が出力の検証に費やす時間で完了します。

設定する価値を得るために必要な明細書の最低数はありますか？

いいえ。設定はゼロです。テンプレートの作成、トレーニング用ドキュメントのアップロード、希望する列名を入力する以外の設定は一切必要ありません。1件の明細書を処理する場合でも100件の場合でも、ワークフローは同じです。価値は量に応じて拡大しますが、設定コストは変わりません。