Corporate Card Receipt Matcher: Stop Chasing Missing Receipts

The problem this kills

Every month the corporate-card feed lands and the same grind starts. Hundreds of charges, each one needing a receipt that may or may not have been submitted, may have been emailed to the wrong place, or may live in some app nobody checks. Somebody on finance opens two windows — the card statement on one side, the pile of submitted receipts on the other — and starts the eyeball match: this $48.20 Tuesday charge at the airport diner, is that the $48.20 receipt this cardholder uploaded, or the one from the other airport diner the same week?

Then comes the worse half: the charges with no receipt at all. You email the cardholder. They don't reply. You email again. The period-close clock is running, your auditors want every charge substantiated, and unreceipted spend over a certain age may have to be treated as taxable income to the employee or written off — a real decision with real consequences that's currently tracked in your head and a color-coded spreadsheet.

It's slow, it's nag-driven, and it gets sloppiest at exactly the wrong moment: close. You don't need a six-figure expense suite to fix it. You can build the matcher yourself, this weekend.

What you'll build

An internal web tool your finance team logs into. You import two things you already have: the card-transaction feed (cardholder, date, merchant, amount) and the submitted receipts/expenses. The tool lines each charge up against the receipts and does the matching for you — amount, date within a few days, and merchant name, all within tolerances you set — and dedupes on the card's transaction ID so the same charge never gets processed twice.

Everything that matches cleanly lands in one bucket. Every charge with no receipt lands in a missing-receipt list that ages per cardholder (1–7 days, 8–30, 31+) so you can see who's chronically late. The tool emails those cardholders escalating reminders automatically, so you stop being the nag. Then your finance reviewer works the screen: approve the matched set, and for the charges that are still unreceipted at close, decide the treatment — chase further, mark taxable to the employee, or write off — as a deliberate, logged decision. One click exports coded GL entries in the exact columns your general ledger imports, plus a missing-receipt aging report.

What's inside the Implementation Plan

The downloadable plan is a single markdown file you paste into an AI coding agent. It opens by interviewing you about your own card-reconciliation process — your card program and how the feed arrives, your real field names, how cardholders submit receipts, your amount/date/merchant tolerances, your aging buckets and reminder cadence, your rule for taxing vs. writing off old charges, and your GL export layout — and then it reads a short spec back for your thumbs-up before it builds a thing. That's the difference between a tool shaped to your card program and a generic template you have to fight.

From there it walks the agent through the data model (cardholders, transactions, receipts, match results, reminders, and treatment decisions), the importers, the duplicate guard on transaction ID, the amount-plus-date-plus-merchant match engine with tolerances, the per-cardholder aging, the escalating reminder emails, the review-and-approve screen with the leftover-treatment gate, and the final export. Every step ends with a ready-to-copy prompt. There's a full "No API yet?" path: import from CSV, export clean coded entries and an aging CSV, and you never have to touch your card provider's or ERP's API to ship.

The governance it includes (this is the point)

This is finance — the controls are the product. The plan builds them in: a login so only your team can use it; row-level security so each organization only ever sees its own card data; a complete audit trail of who matched, who approved, who reminded a cardholder, and exactly how each leftover charge was treated, and when; a hard human-approval gate so nothing is coded to the GL and no charge is marked taxable or written off until a reviewer signs off; and a duplicate guard on the card transaction ID so the same charge can't be matched, reminded on, or posted twice. The taxable/write-off decision — the one your auditors will ask about — is captured as an explicit, attributable action, not a quiet spreadsheet edit. That's the substantiation story your controller wants.

Who it's for

Finance teams, expense administrators, and controllers who reconcile company-card spend and are tired of chasing receipts by email and tracking missing ones in a spreadsheet. If you can explain to a new hire how a card charge gets matched to a receipt and what happens to a charge nobody ever substantiates, you can build this — no developer required.

You've got this — open the plan, paste the first prompt, answer a few questions about how your card program actually runs, and you'll watch your first feed match itself.