Expense Policy Automation for a 400-Person Firm

Most Indian companies past roughly 150 employees have an expense policy. Very few have one their software enforces. The document lives in a shared drive, finance interprets it from memory, and every reimbursement becomes a small negotiation between an employee who wants their money back and an approver who wants the receipt to match the line item. The cost lands on the finance team and compounds quietly: slower closes, lapsed GST credit, and a month-end that runs on WhatsApp screenshots.

What does an expense policy look like before anyone automates it?

On paper, a mid-market expense policy is usually four to eight pages of categories, limits and approval thresholds, and almost none of it is machine-readable. The categories are familiar: local conveyance, outstation travel, meals, client entertainment, telecom, software subscriptions, office supplies. The rules are per-claim caps, monthly caps per person, receipt thresholds and an approval matrix based on amount. The problem is the language. Phrases like 'reasonable', 'prior approval' and 'business justification' are judgement calls, and a system cannot evaluate them. The first job is not automation — it is deciding which clauses are rules and which are judgement, then writing each judgement down as a routing decision with a named owner.

Where does the manual claim process actually break?

It breaks in three predictable places: documentation that arrives incomplete, approval ownership that is unclear, and GST input credit that never gets claimed. Take a 400-person firm with roughly 1,150 claims a quarter. At nine minutes of finance time per claim — checking the bill, matching the category, chasing the manager — that is about 165 hours a quarter, most of a full-time person. Around a quarter of claims come back at least once for a missing bill or a wrong category, and each round trip adds two to three days, which is why median payout drifts towards three weeks. Separately, bills carrying GST get filed after that month's return has gone, so the input credit lapses. Nobody notices, because nobody measures it.

How do you turn policy text into rules a system can enforce?

The translation works when every clause is reduced to four things: a condition, a limit, a data field that proves the condition, and a fallback when the proof is missing. A workable first rule set looks like this:

• Category caps: meals at ₹1,500 per claim and ₹8,000 per person per month; local conveyance at ₹600 per day.
• Proof: an itemised bill mandatory above ₹500, with date, vendor and amount extracted rather than typed.
• Tax fields: GSTIN and invoice number mandatory above ₹2,500; below that, the claim is still paid but flagged as no input credit.
• Auto-approval: anything under ₹2,500 that clears every check skips the manager entirely.
• Escalation: ₹2,500 to ₹25,000 goes to the reporting manager; above ₹25,000 to finance and the department head.
• Duplicates: invoice number, GSTIN, amount and date matched against the previous twelve months.

Keep vendor invoices that attract TDS under 194C or 194J out of this flow. They belong in payables, where the deduction and the challan live; mixing the two makes both untrustworthy.

Worked example: one quarter at a 400-person firm

The numbers below are illustrative — a composite of mid-market Indian firms, rounded, not a single client. The company spends about ₹42 lakh a quarter on reimbursable expenses across 1,150 claims. Before automation: 165 hours of finance review, 24% rework, a 21-day median payout, and roughly ₹60,000 of GST input credit missed each quarter because bills surfaced after the return. The first category went live in five weeks. After that: bills are photographed at submission and the vendor, GSTIN, amount, date and tax are extracted automatically — the same document-extraction work we do under AI engineering — 66% of claims clear without a human, finance time per claim falls to about 2.5 minutes, median payout is six days, and missed credit drops under ₹10,000 because the flag now fires at submission rather than at filing. Two things still need a person: foreign travel per-diems and anything above ₹25,000.

What breaks first, and what should you expect?

Master data breaks first, not the rules. Employee-to-manager mapping, cost centre codes, a clean category list and the vendor GSTIN master decide whether the system can decide anything; most companies find their category list has forty values where twelve would do. The second failure is policy drift — limits change in a circular and nobody updates the configuration, so the tool confidently enforces last year's policy. The third is a missing exception path: if the only outcomes are approve and reject, people route around the tool with WhatsApp and cash. Expect three to six weeks to get one category live and another month of tuning before widening. First-pass auto-approval typically lands between 55% and 70%; treat anyone promising 95% with suspicion. And mask card numbers on receipts — the DPDP Act covers employee data too.

Where to start

Pick one category. Local conveyance is usually the best first cut: high volume, small amounts, simple rules. Export three months of claims, mark every one a reviewer touched, and read the reasons — that list is your rule set, in priority order. Then build the narrowest flow that handles it: capture, extraction, limit check, auto-approve or route. Run it alongside the manual process for one full payout cycle before switching the old one off, and keep a visible exception queue from day one, because exceptions are how you learn where the policy is wrong.

Maysan Labs builds this kind of finance plumbing — expense routing, approval chains and GST-aware billing on top of the accounting stack you already run; the GST billing automation work is usually the neighbouring piece teams need next.