経費精算書の明細を抽出し、
ポリシー制限違反を自動検出する方法

ポリシーチェックの実態——なぜいまだに手動なのか

経費管理プラットフォームは、特定のシナリオにおいてポリシーを自動適用できる。それは、従業員が企業のエコシステム内でコーポレートカードを使うケースだ。Expensify、Ramp、Navanは、経費報告書が作成される前の取引時点で、ポリシー違反を検知する。GBTAの調査によると、1件の経費報告書の処理にかかる平均コストは58ドルで、19%の報告書にエラーが含まれ、修正にさらに52ドルと18分を要する。取引時点でのポリシー適用は、企業に大きなコスト削減をもたらす。

しかし、このモデルが機能するのは、すべての経費がプラットフォームを通る場合に限られる。実際には、多くの組織はプラットフォーム外の人物から経費報告書を書類として受け取る。現場作業員が提出する紙の申請書、出張経費を請求する契約社員の請求書、コーポレートカード制度がない企業の従業員からの報告書などだ。ポリシーは適用される。基準は就業規則に明記されている。しかし、チェックはいまだに手動で行われている。

そのワークフローは次のようなものだ。経理担当者が各経費報告書のPDFを開き、明細を読み、各金額をポリシーと照合し、違反項目にマークを付けてフォローアップし、データをスプレッドシートやERPに入力する。データ抽出とコンプライアンスチェックは別々の工程であり、どちらも人手が必要だ。1時間に10件の報告書を処理しても、そのうち8件には違反がまったくない。問題がないことを確認するために時間が費やされているのだ。

ポリシーチェックを計算列で実現

計算列とは、ドキュメントから直接値を取得するのではなく、AIが抽出時に計算して値を生成する列のことです。「金額」列が経費報告書から生の数値をそのまま取得するのに対し、計算列はその数値にルールを適用し、結果を出力します。ルールは算術、条件、またはその両方で構成でき、抽出と同じパスで実行されるため、出力時にはすでに答えが揃っています。

ポリシーチェックの場合、計算は条件分岐です。金額がポリシー上限を超えていれば「FLAG」、そうでなければ「OK」を出力。 ポリシー上限（例：食事代75ドル）は、ドキュメント上ではなく列定義に設定された固定パラメータです。AIが経費明細から金額を抽出し、ルールに埋め込まれたしきい値と比較して結果を書き込みます。別途コンプライアンスチェックは不要。手動での突き合わせも不要。フラグは出力スプレッドシートの単なる1列です。

この計算を定義する方法は2つあります。列名方式は、ログイン不要ですぐにデモで試せます。計算の説明を列名フィールドに直接入力します。ルール形式方式は、列名をクリーンに保ち、計算をJSONルールに格納し、プリセットとして保存して繰り返し使用できます。どちらも同じ結果を生成します。「ポリシーフラグ」列が、どの明細に注意が必要かを示します。

方法1：列名方式 — チェックを列ラベルで定義

列名フィールドに、抽出したいフィールドと、計算列の場合はそれを変換するルールの両方を入力します。AIが指示を読み取り、抽出時に適用します。設定不要、テンプレート不要、ログイン不要で試せます。

標準的な経費報告書（食事代上限75ドル、ホテル代上限250ドル、IRSマイル率適用）の場合、列名は次のようになります。

ポリシーフラグ列の各条件は同じパターンに従います。AIがカテゴリ列を読み取って適用すべきしきい値を判断し、金額列から実際の値を読み取って比較します。「食事」経費は75ドルチェックをトリガー。「ホテル」または「宿泊」経費は250ドルチェックをトリガー。「走行距離」経費は0.70ドルチェックをトリガー。定義されたカテゴリに一致しないものはすべて「OK」となり、未分類の経費による誤検出は発生しません。

しきい値は列定義に埋め込まれています。ドキュメント上には一切表示されません。これが計算列の重要な機能です。固定パラメータ参照。AIはルールの理解としてポリシー上限を保持し、ページから抽出したものに適用します。来四半期にポリシーが変更され（食事代が75ドルから80ドルになるなど）、列定義の数値を1つ変更するだけで済み、スプレッドシートのすべての数式を修正する必要はありません。

手書き金額が含まれる経費報告書（現場社員が紙のフォームに記入することが多い）には、Precision+を有効にしてください。追加の推論ステップにより、条件ロジックを適用する前にモデルが手書きの数字を正確に読み取れるようになり、誤読による誤検知や、さらに悪い場合には違反の見逃しを減らします。

方法2: ルール形式 — クリーンなヘッダー、再利用可能なルール

列名方式は簡単なチェックに適しています。しかし、経費報告書を定期的に処理する場合（同じポリシー、同じカテゴリ、毎月）、ルール形式は列ヘッダーを読みやすく保ち、ロジックを保守しやすくします。列名はシンプルに（「ポリシーフラグ (カテゴリに...が含まれ、金額...なら...と異なるしきい値...)」ではなく「ポリシーフラグ」）、計算ロジックはプリセットとして保存可能なJSONルールに記述します。

ルール形式では、カテゴリ列も経費タイプを正規化します。AIが「夕食」「昼食」「朝食」をすべて「食事」に、「宿泊」「滞在先」「Airbnb」を「宿泊」に統一します。この正規化はポリシーフラグが正しく機能するために重要です。従業員がカテゴリ欄に「Dinner with client」と書き、ルールが「Meal」をチェックする場合、標準化がなければフラグは見逃します。ルールがマッピングを定義し、AIが条件チェックの前にそれを適用します。

複数の部門から経費精算書が提出され、それぞれに微妙に異なるポリシーのしきい値がある場合、ルールフォーマットを使用して個別のプリセットを作成できます。営業部門のプリセットでは、顧客接待のための食事制限額を高く設定できます。現場業務のプリセットでは、トラックと乗用車で異なる走行距離単価を設定できます。各プリセットは適切なしきい値に調整された「ポリシーフラグ」列を生成し、ワンクリックで切り替えられます。

カテゴリごとに異なるポリシーしきい値を処理する

条件付き計算列の真価は、1つの制限値をチェックすることではありません（それはどのスプレッドシートの数式でもできます）。同じ列内で、カテゴリごとに異なる制限値を、すべての明細、すべての経費精算書に対して、一度の処理でチェックできることです。AIがまずカテゴリを評価し、対応するしきい値を選択して適用します。1つの列。複数のルール。手動チェックはゼロ。

以下は、上記のルールフォーマットプリセットで処理された、典型的な経費精算書明細バッチの出力例です。

上記6件の経費明細のうち、2件がフラグされ、それぞれどの制限値を超過したかが正確に表示されています。経理担当者はスプレッドシートを開き、ポリシーフラグ列をフィルタリングして「フラグ」行のみを表示し、2件の違反を確認します。残りの4件は、「OK」がポリシーに照らして既に検証済みであるため、レビュー時間はゼロです。これが6件をチェックするのと2件をチェックするのとの違いであり、バッチ内の経費精算書が増えるごとに複合的に効果を発揮する、67%のレビュー時間削減です。

上記のしきい値は参考値です。貴組織のポリシーでは、地域ごとに異なるGSA日当レート（GSA Per Diem Rates 2025）や、IRS Publication 463のIRS標準走行距離レートを使用する場合があります。列の定義は指定した数値に応じて調整されます。「$75」を食事制限額に、「$250」を宿泊上限額に変更すると、出力がポリシーを反映します。

IRSのアカウンタブル・プラン規則（Treas. Reg. §1.62-2）に準拠する必要がある組織にとって、ポリシーフラグ列は文書化という二次的な目的を果たします。ポリシー制限を超えるとフラグが立てられた金額は、従業員の課税所得として扱うか、従業員が60日以内に超過額を返還する必要がある場合があります。抽出出力でポリシー違反が明示的にフラグ付けされることで、コンプライアンスに準拠した払い戻し処理をサポートする監査証跡が作成されます。これは、多忙な財務チーム間で一貫性なく行われる手動チェックでは頻繁に満たせない要件です。