How to Extract Expense Report Line Items and
Flag Policy Limit Violations

Where Policy Checks Actually Happen — and Why They're Still Manual

Expense management platforms have solved policy enforcement for one specific scenario: the employee who swipes a corporate card inside the company's ecosystem. Expensify, Ramp, and Navan flag out-of-policy spend at the point of transaction — before the expense report is even created. According to GBTA research, the average cost to process a single expense report is $58, and 19% of reports contain errors requiring an additional $52 and 18 minutes to correct. Policy enforcement at the transaction level saves organizations significant money.

But that model only works when every expense flows through the platform. In practice, many organizations receive expense reports as documents — PDFs, scanned paper forms, spreadsheets — from people who are not inside the platform: field technicians submitting paper forms, contractors invoicing expenses from trips, employees at organizations where a corporate card program does not exist. The policy still applies. The thresholds are still in the handbook. But the checking is still manual.

The workflow looks like this: a finance team member opens each expense report PDF, reads the line items, cross-references each amount against the policy handbook, marks violations for follow-up, and enters the data into a spreadsheet or ERP. The extraction and the compliance check are two separate steps that both require human attention. One person might process 10 reports in an hour — and 8 of them have no violations at all. The time is spent proving the absence of a problem.

The Policy Check as a Computed Column

A computed column is a column whose value is calculated by the AI during extraction, rather than pulled directly from the document. Instead of "Amount" giving you the raw number from the expense report, a computed column applies a rule to that number and outputs the result. The rule can be arithmetic, conditional, or both — and it executes in the same pass as extraction, so the output arrives with answers already in place.

For policy checking, the computation is a conditional: IF amount exceeds the policy limit, output "FLAG"; otherwise output "OK." The policy limit — say, $75 for meals — is a fixed parameter that lives in the column definition, not on the document. The AI extracts the amount from the expense line, compares it to the threshold embedded in the rule, and writes the result. No separate compliance step. No manual cross-referencing. The flag is just another column in the output spreadsheet.

Two ways to define this computation exist. The column name method works immediately in the demo with no login — the calculation description goes directly into the column name field. The Rule Format method keeps column names clean and stores the computation in a JSON rule, which can be saved as a preset for recurring use. Both produce the same result: a "Policy Flag" column that tells you which lines need attention.

Method 1: Column Name Approach — Define the Check in the Column Label

In the column name field, you type both the field you want to extract and, for computed columns, the rule that transforms it. The AI reads the instruction and applies it during extraction. No setup, no templates, no login required to try it.

For a standard expense report with a $75 meal limit, $250 hotel limit, and IRS mileage rate, the column names look like this:

Each condition in the Policy Flag column follows the same pattern. The AI reads the Category column to determine which threshold applies, reads the Amount column for the actual value, and compares. "Meal" expenses trigger a $75 check. "Hotel" or "Lodging" expenses trigger a $250 check. "Mileage" expenses trigger a $0.70 check. Anything that does not match a defined category gets "OK" — no false positives from unclassified expenses.

The thresholds are embedded in the column definition. They do not appear anywhere on the document. This is a key capability of computed columns: fixed parameter references. The AI holds the policy limit in its understanding of the rule and applies it to whatever it extracts from the page. If the policy changes next quarter — meals go to $80 instead of $75 — you change one number in the column definition, not every formula in a spreadsheet.

For expense reports with handwritten amounts — common from field employees filling out paper forms — enable Precision+. The additional reasoning steps help the model correctly read handwritten numbers before applying the conditional logic, reducing the chance that a misread amount produces a false flag or, worse, a missed violation.

Method 2: Rule Format — Clean Headers, Reusable Rules

The column name approach works well for quick checks. But if you process expense reports regularly — the same policy, the same categories, month after month — the Rule Format keeps column headers readable and the logic maintainable. Column names stay simple ("Policy Flag" instead of "Policy Flag (IF Category contains... then... with different thresholds for...)" ) and the computation lives in a JSON rule that can be saved as a preset.

With Rule Format, the Category column also normalizes expense types — the AI standardizes "Dinner," "Lunch," "Breakfast" all to "Meal," and "Lodging," "Accommodation," "Airbnb" to "Hotel." This normalization is critical for the Policy Flag to work correctly. If the employee wrote "Dinner with client" in the category field and the rule checks for "Meal," the flag would miss it without standardization. The rule defines the mapping, and the AI applies it before running the conditional check.

For finance teams processing expense reports from multiple departments — each with slightly different policy thresholds — the Rule Format supports creating separate presets. The Sales department preset might allow higher meal limits for client entertainment. The Field Operations preset might have different mileage rates for trucks versus passenger vehicles. Each preset produces a Policy Flag column tuned to the right thresholds, and switching between them is one click.

Handling Different Policy Thresholds Per Category

The power of a conditional computed column is not checking one limit — any spreadsheet formula can do that. It is checking different limits for different categories in the same column, on every line item, in every expense report, in a single pass. The AI evaluates the category first, selects the corresponding threshold, and applies it. One column. Multiple rules. Zero manual checking.

Here is what the output looks like for a typical batch of expense report line items processed through the Rule Format preset above:

Of the six expense lines above, two are flagged — and both show exactly which limit was exceeded. The finance reviewer opens the spreadsheet, filters the Policy Flag column to show only "FLAG" rows, and reviews the two violations. The other four lines required zero review time because the "OK" is already verified against the policy. This is the difference between checking six lines and checking two — a 67% reduction in review time that compounds with every additional expense report in the batch.

The thresholds shown above are illustrative. Your organization's policy may use GSA per diem rates (GSA Per Diem Rates 2025) which vary by location, or IRS standard mileage rates from IRS Publication 463. The column definition adapts to whatever numbers you specify — change "$75" to your meal limit, "$250" to your lodging cap, and the output reflects your policy.

For organizations that must comply with IRS accountable plan rules (Treas. Reg. §1.62-2), the Policy Flag column serves a secondary purpose: documentation. Amounts flagged as exceeding policy limits may need to be treated as taxable income to the employee or require the employee to return the excess within 60 days. Having policy violations explicitly flagged in the extraction output creates an audit trail that supports compliant reimbursement processing — a requirement that manual checking, done inconsistently across busy finance teams, frequently fails to meet.