It is the third week of close, and a controller is working through the last few open items. A handful of reimbursement requests are sitting in an inbox because a receipt is missing. A batch of card transactions needs account coding before they can post. An employee who submitted a mileage claim two weeks ago is still waiting to hear whether it was approved. None of this is a travel problem. It is a control problem that happens to involve travel.
That distinction is the real decision in front of most CFOs evaluating expense software. The question is not which platform has the most features for booking flights and building itineraries. It is whether expense controls live inside the same process finance already uses for accounts payable (AP) and the enterprise resource planning (ERP) system, or whether they create a second process that finance has to reconcile with the first one later.
The T&E Category Solves a Different Problem
Traditional travel-and-expense platforms were built around travel administration: booking, itineraries, per diem rules, global travel policy. That is a legitimate need for companies whose primary expense-management problem is managing travel at scale.
It is a different problem from the one most finance teams are actually trying to solve. They need employee spend, card activity, and supplier invoices governed by the same approval logic, the same chart of accounts, and the same audit trail, not three separate ones that happen to feed the same close. A T&E suite optimized for travel administration was not built to answer that question, and it shows up as friction: employees submit in one system while AP works in another, coding gets re-mapped after the fact, and audit evidence ends up split across tools instead of attached to the transaction it describes.
One Control Model for Two Different Starting Points
Card expenses and reimbursements begin differently. A card expense starts with a swipe. A reimbursement starts when an employee pays out of pocket, drives their own car, or covers a per diem cost, and only becomes a company obligation once someone reviews and approves it.
They also tend to have different owners further down the chain. Card programs are usually set up and monitored by finance or AP. Reimbursement approvals often start with a people manager who is judging whether the expense was reasonable, not whether it is coded correctly. Treating those as the same decision, made by the same person, is where a lot of expense processes break down.
What both paths need in common is the same finance-grade record: supporting documentation, a business purpose, correct coding, an approval history, and a clear next step. For a company operating across multiple entities and dimensions, that consistency matters more, not less. The control model needs to adapt to different expense types without forcing them through identical payment mechanics.
What "Ready for AP" Actually Means
A submitted expense report is not the end of the work. For AP, it is the start. The real question at that handoff is narrower than a full documentation checklist: is this expense complete enough to move forward without a follow-up email, or does it need to come back?
That means checking whether an exception is documented, whether the approval came from the right person, and whether the coding matches the entity, department, and project it should. When expense controls run through AP review as part of the same workflow, that judgment happens while the transaction is still open. When they run through a separate system, it happens during close, which is a worse time to discover it.
Merchant Category Is Not GL Coding
An ERP is the system of record. It holds the chart of accounts, entities, dimensions, vendors, and period rules that make an expense mean something to the business, not just to the employee who submitted it.
This is where a lot of expense tools quietly fall short. A merchant category code can tell you a purchase happened at a hotel. It cannot tell you which entity should carry the cost, which project it belongs to, or which period it needs to land in. A manager’s approval confirms intent, not readiness for posting. Connecting expense management to the ERP’s accounting structure closes that gap without turning the ERP into something it is not: the workflow still runs where the expense happens, but the coding it produces is already usable by accounting instead of something AP has to reconstruct.
Reimbursements End at Payroll, Not AP
Employee-paid spend has its own boundary, and it is one that’s easy to blur. An employee has already spent their own money, so the review has to happen before that becomes a company obligation, not after. It still needs documentation, policy review, coding, and an approval trail like any other expense.
Where it differs is the finish line. In Stampli, an approved reimbursement is prepared for the company’s payroll process rather than placed in AP’s vendor-payment run. That keeps employee reimbursements separate from supplier payments while preserving the original approval trail. The practical test for a CFO is simple: can finance see and review an employee-paid expense before it becomes an obligation, without pulling it from a separate inbox or spreadsheet someone maintains by hand?
Card Guardrails Stop at the Swipe
Card limits and merchant restrictions are useful. They are also incomplete by design: they govern what can be spent, not whether the resulting expense is finance-ready. After the swipe, someone still has to attach a receipt, confirm the policy fit, code it, route it for approval, and get it into the ERP.
The better frame is spend management, not spend encouragement. A card should be a payment method inside a governed workflow, not a substitute for the workflow. Stampli Card is built around that distinction, and it works alongside how Stampli helps teams take control of T&E expenses more broadly, connecting the card itself to the same review process as everything else.
The Decision CFOs Are Actually Making
Adding a T&E suite is rarely the wrong call because it lacks features. It is the wrong call when it creates a second employee-spend process that finance has to assemble the truth from later, on top of the one that already exists for AP.
Before adding one, it’s worth asking:
- Do card expenses and reimbursements go through the same finance-review process, or two different ones?
- Can finance see policy context, coding, and exceptions in one place instead of stitching systems together?
- Does the workflow use the ERP’s accounting structure while leaving the ERP as the system of record?
- Can AP resolve issues before period-end, instead of during it?
- Do approved reimbursements route to payroll without losing the original audit trail?
For a controller, that last question is worth bringing into the next leadership conversation on its own. A reimbursement process with a clean payroll handoff is one fewer manual reconciliation at every close, not just a tidier flowchart.
Expense Management Where Finance Already Works
Stampli Expense Management brings card expenses and employee-paid reimbursements into one workflow, the same one AP already uses: policy review, coding, approvals, payroll preparation, ERP sync, and exception handling in one place. Stampli AI can help prepare expense details and suggest coding, but finance makes the final call and the ERP stays the system of record. The goal isn’t to automate the judgment away. It’s to stop making finance reconstruct it after the fact.
See how Stampli supports controllers with workflows that keep accounting context, approvals, and audit evidence connected from the transaction to the ERP.
