Automating Expense Approvals Without Turning Reimbursements Into Wages

Expense approval is the easiest stage of the workflow to automate and the least useful. Routing a submitted report to a manager, waiting for a click and passing it to payables is the kind of thing every platform on this site is built to do. The work that decides whether the automation is worth building happens before the approver ever sees the request: whether the record that arrives already carries what a reimbursement has to carry.

Get that wrong and the automation does not merely fail to help. Under the Treasury regulations, payments under an arrangement that is not an accountable plan "are included in the employee's gross income, must be reported as wages or other compensation on the employee's Form W-2, and are subject to withholding" (26 CFR § 1.62-2). A fast approval on a thin record is a slow payroll problem.

The approval click is the last thing to automate

An expense workflow has five stages, and only one of them is the approval:

1. Capture. A receipt image or a card feed becomes a row with fields.
2. Substantiate. The row acquires the elements the regulations ask for — or it does not.
3. Route. The request reaches someone with authority to approve it and no conflict in doing so.
4. Decide. Approve, reject, or send back for the missing element.
5. Settle. Pay, and recover anything advanced in excess of what was substantiated.

It is tempting to start at stage three, because that is the stage that feels slow. Approvals sit in inboxes, the queue is visible, and a routing rule makes the queue move. But a faster stage three just moves incomplete records to a decision point sooner. Stage two is where the value is, and stage five is the one a build can quietly omit, because nothing visible breaks when you leave it out.

Three things have to be true, or it is payroll

The accountable plan rules in § 1.62-2 are three tests, set out in paragraphs (d), (e) and (f).

Business connection. The arrangement provides money "only for business expenses that are allowable as deductions by part VI (section 161 and the following), subchapter B, chapter 1 of the Code". In automation terms: the category on the row has to mean something, and "Other" is not a category.

Substantiation. The arrangement "requires each business expense to be substantiated to the payor … within a reasonable period of time". Note the direction — to the payor. A record sitting on an employee's phone has not been substantiated to anyone.

Return of excess. The arrangement "requires the employee to return to the payor within a reasonable period of time any amount paid under the arrangement in excess of the expenses substantiated". This is the stage-five gap. If you issue advances or corporate cards and never reconcile the unspent balance, the test fails on a clause that has nothing to do with approval speed — which is exactly why it is easy to leave out of a build aimed at approval speed.

The IRS sets out the same three requirements for employers in plainer words in its Fringe Benefit Guide. Failing them has one consequence, stated flatly: payments under a nonaccountable plan "are taxable wages subject to all withholding when paid."

Three of the four elements come off the receipt. One does not.

The elements depend on the category of expenditure. For travel away from home, the temporary regulation at § 1.274-5T(b)(2) lists four. Set them against what capture software can actually supply and the whole design problem appears in one table.

Element	What the regulation asks for	Can capture software supply it?
Amount	Amount of each separate expenditure, with daily meals and incidentals allowed in reasonable categories	Yes — the field parsers are built to read
Time	"Dates of departure and return for each trip away from home, and number of days away from home spent on business"	Partly — the receipt date, not the trip
Place	Destinations or locality of travel, by name of city or town	Usually — inferable from the merchant
Business purpose	"Business reason for travel or nature of the business benefit derived or expected to be derived"	No. It is not on the receipt.

Business purpose exists only in the submitter's head, and no amount of model quality will extract it from a photograph of a bill. That inverts the usual design. Instead of an approval form that asks for everything and leaves purpose as a free-text box nobody fills, the useful build is a submission step that will not proceed without one, pre-populated from the calendar entry or the project code when either exists. The field extraction itself is the same job covered in invoice data entry, with the parsers compared in document AI compared.

Automated capture also satisfies a timing requirement for free. Under § 1.274-5T(c)(2)(i), adequate records mean "an account book, diary, log, statement of expense, trip sheets, or similar record" together with documentary evidence, and (c)(2)(ii) asks that "each recording of an element of an expenditure or use is made at or near the time of the expenditure or use." A phone capture at the till beats a shoebox reconstructed in April, and that is an argument for automating capture that has nothing to do with saving time.

The $75 line is narrower than the policies built on it

If your expense policy has a $75 threshold in it, it is worth reading the sentence it came from. § 1.274-5(c)(2)(iii)(A) reads: "Except as provided in paragraph (c)(2)(iii)(B), documentary evidence, such as receipts, paid bills, or similar evidence sufficient to support an expenditure, is required for—(1) Any expenditure for lodging while traveling away from home, and (2) Any other expenditure of $75 or more except, for transportation charges, documentary evidence will not be required if not readily available."

Three things in there rarely survive the trip into a policy document. It is a rule about documentary evidence, not about records — the four elements are a separate requirement and do not move with the threshold. "Receipts, paid bills, or similar evidence" is broader than a receipt. And lodging while travelling away from home is listed separately from the $75 floor rather than under it. The sentence also opens with an exception in paragraph (B), which you should read before writing a blanket rule in either direction.

Per diem is the other place policy and automation meet. Publication 463 describes the standard meal allowance as a method that "allows you to use a set amount for your daily meals and incidental expenses (M&IE), instead of keeping records of your actual costs" — then adds that "If you use the standard meal allowance, you must still keep records to prove the time, place, and business purpose of your travel." For a build that is a clean split: per diem removes the amount problem for meals and leaves the other three elements exactly where they were. It is a policy decision that changes what the software has to collect.

Three timers, and each one hangs off a date you already store

"Reasonable period of time" sounds like the kind of vague standard automation cannot act on. It is not. § 1.62-2(g) supplies a fixed date method with three numbers in it.

Clock	Runs from	Treated as reasonable if within
Advance issued	The date the expense is paid or incurred	30 days before
Expense substantiated to the payor	The date the expense is paid or incurred	60 days after
Excess returned to the payor	The date the expense is paid or incurred	120 days after

The regulation's own words: an advance, a substantiation or a return inside those windows "will be treated as having occurred within a reasonable period of time." There is also a periodic statement method — statements no less frequently than quarterly listing amounts paid in excess of what the employee has substantiated, with 120 days from the statement to substantiate or return.

This is the most automatable requirement in the whole area, and it is easy to leave out, because nothing visible breaks when it is missing. A workflow that nags at day 45, escalates at day 55 and flags the arrangement at day 61 is a scheduled job over a date column — the same machinery as a weekly report that fails loudly. Without it, the day the company learns it missed a window is the day an accountant tells it, months later.

Where a human still decides, and a first month you can follow

Three decisions do not belong to the automation. Business purpose, because it is a judgement about whether a stated reason is a real one. Policy exceptions, because an exception a rule can grant is not an exception. And anyone approving their own spend — a routing rule that sends a request to the submitter's manager will, sooner or later, send an executive's report to someone who reports to them. Encode the conflict check, not just the hierarchy.

Week	Do this	What it tells you
1	Do not build. Count how many of the last three months of travel reports carry all four elements as submitted, and how many advances were never reconciled	Your baseline, not a vendor's
2	Fix the submission form before the routing: purpose required and pre-filled where possible, a short category list, and a documentary-evidence rule written against the text of (c)(2)(iii)	Whether the gap was capture or policy
3	Build the three timers. Day 60 and day 120 are the ones that hang off consequences; day 30 only matters if you issue advances	How many open items are already past a window
4	Run the routing in parallel. The automation proposes; a person still clicks. Self-approval and missing-purpose stay hard stops no confidence score can override	How often the proposal is wrong

Whether the hours saved justify the build is the arithmetic in how to calculate automation ROI. The point of the first month is a different question, and the one that decides the rest: is the automation producing complete records, or fast incomplete ones?

One caveat worth stating plainly. This describes what the cited regulations and IRS publications say, read in September 2026. It is not tax advice, the rules have exceptions and categories this article does not cover, and the person who should sign off on your expense policy is your accountant, not your automation vendor.