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

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

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

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

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

ポリシーチェックを計算列として実装する

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

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

この計算を定義する方法は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つの制限値をチェックすることではありません（それはどのスプレッドシートの計算式でもできます）。同じ列内で、カテゴリごとに異なる制限値を、すべての明細、すべての経費精算書に対して、1回のパスでチェックできることです。AIがまずカテゴリを評価し、対応するしきい値を選択して適用します。1つの列。複数のルール。手動チェックはゼロ。

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

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

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

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