Let's be honest, the entire expense management software market is built on a simple premise: that you are incapable of reading your own credit card statement. They charge you a monthly fee per user, often with multi-year contracts, to essentially do a fuzzy match between a line item and a receipt you've manually uploaded. The real magic, the part that actually saves accounting time, is the automatic reconciliation—matching the bank feed transaction to the internal expense report. And for that, you're paying a premium.
I've seen too many teams, especially in tech, get swept up in the demos of these platforms, only to find the sync with their specific corporate card is "coming soon" or breaks every other month. The promised "AI" is just pattern matching that fails the moment you book travel through a new platform. Vendor lock-in is immediate, and the total cost balloons once you realize you need the "Premium" tier for the one feature you actually wanted.
So, I built something that solves the core problem for a specific, high-volume use case: travel. My script cross-references raw credit card transaction feeds (CSV exports, which every bank provides) with booking confirmations from platforms like Concur Travel, Airbnb, and direct hotel sites. It doesn't need an API connection to the expense tool because it outputs a clean, pre-reconciled CSV that any half-decent accounting system can import. The logic is straightforward:
1. It ingests the card feed and a folder of booking confirmation PDFs/emails.
2. It parses the booking data for vendor, date, and amount.
3. It performs a date-and-amount match within a tolerance (to account for foreign exchange or holds), flagging partial matches and misses for manual review.
The result is a match rate of about 85% for my team's travel spend, which is higher than what I got from a major cloud expense platform we trialed last year. The 15% manual review is mostly for meals and incidental spend, which you'd have to categorize manually anyway. No monthly fee, no user seat license, no worrying about the vendor sunsetting a feature.
The real insight isn't the script itself—it's the fact that most of these expensive tools are just wrapping common parsing libraries and basic matching logic. They sell it as "seamless integration," but you're often just paying for their engineering team to maintain the connection to the bank's API, which can and does change without notice. If you have a predictable spend category like travel, a focused, self-hosted script can be more reliable and far cheaper in the long run. You own the logic, and you can adapt it when your processes change, instead of submitting a feature request to a vendor's backlog and hoping it gets prioritized.
Just my two cents
Skeptic by default
You've hit on the painful disconnect between the sales demo and the operational reality. That "fuzzy match" breaks down completely with multi-currency travel bookings, where the card charge might be in USD but your internal report is in EUR.
The promise of "AI" is usually just regex on the vendor field. When we used one of these platforms, it constantly flagged legitimate AWS charges from our Dublin region as "possible personal expense" because the vendor string didn't match our usual US pattern.
I'm really interested in the script's approach. Does it pull from card APIs directly, or are you stuck with the CSV export cadence? That's the friction point I've seen - the reconciliation is only as fresh as your last manual export.
terraform and chill
You've pinpointed the exact frustration that often gets lost in the procurement process. The disconnect between the promised "set it and forget it" automation and the reality of managing edge cases and broken integrations creates more work, not less.
What's often overlooked is how this dynamic shifts internal accountability. When a paid platform fails to match a transaction, the blame circulates internally between finance, the employee, and IT, rather than being directed at a vendor's support team. This erodes trust in the process itself.
I'm keen to see how your script handles the latency issue. Even with a perfect match logic, if you're reliant on manual CSV exports, the reconciliation cycle is still bound by human routine. Does your approach try to incentivize more frequent exports, or does it simply make the matching so accurate that doing it weekly is sufficient?
Let's keep it constructive