Cards vs. reimbursements vs. centralized AP

The real question behind corporate cards vs reimbursements

Every purchase your group makes travels one of three rails, and the rail is chosen at the moment of purchase by whoever is standing there.

That is the whole problem. You do not choose the rail in a policy meeting. Your site manager chooses it at 4pm on a Friday when a compressor fails, and picks whichever one will not get them into trouble or leave them out of pocket. If the approved path is slow, they take the fast one and you find out later.

So the useful exercise is not comparing three products. It is deciding in writing which categories belong on which rail, then making the correct rail the easiest to use.

What each rail actually is

A corporate card is company credit in an employee's hands: money leaves a company account and the record is created by the merchant. A reimbursement is an employee's own money spent on the company's behalf, out of their account first and back later. Centralized AP is a vendor invoicing the company directly, where you control the timing and approval sits before payment.

Three differences follow.

Who is exposed. On a card, the company. On a reimbursement, the employee. On AP, nobody until the invoice is approved.

When approval happens. On cards and reimbursements, after the money is gone. On AP, before, which is the only point where approval can prevent anything.

Who decides the coding. On a card, whoever reviews the statement, usually late and guessing. On a reimbursement, the claimant. On AP, the person holding the invoice.

When are reimbursements the right answer?

Reimbursements are correct for small, infrequent, genuinely personal-first purchases, and should be a small share of total spend.

There is a real category here. Someone's own car for a client visit. A meal at a place that will not take a company card. A tool bought on a personal account at a weekend because the site was down. The employee's payment method was the only one available, and the reimbursement exists to make them whole.

Be honest about the cost. Reimbursements are slow and unpopular with the person who fronted the money, correctly so: a form, a receipt, an approval cycle, and a payment run two weeks out. Someone on a normal salary who puts several hundred on a personal card and waits three weeks will start declining to do it. That is a reasonable response to a bad process, not an attitude problem.

So pay reimbursements faster than you pay vendors, and treat rising reimbursement volume as a signal that the other two rails are not reaching the people who need them.

When do corporate cards win?

Cards win where the purchase is small, frequent and made by a person rather than a process, and where you would rather the transaction land in your system automatically than chase a document. Three categories qualify.

Recurring subscriptions. Software billed monthly produces a clean, predictable transaction, and the card gives you a kill switch that email negotiation does not. The catch is that the same convenience makes subscriptions easy to start and forget, so cards without a periodic review create a slow leak.

Field spend. Fuel, parts, materials, a same-day courier. Anyone running locations or crews needs a payment method in the vehicle. The alternatives are a reimbursement, which pushes the cost onto the employee, or a delay, which pushes it onto the customer.

Per-location purchasing. Where a site buys consumables inside a small monthly envelope, a card per site with a hard limit beats a shared account and password.

The card weakness is documentation. A card transaction arrives with a merchant name, an amount and a date, and nothing about what was bought, why, or for which entity. That missing context is the work you inherit at month end.

When does centralized AP win?

Centralized AP wins whenever the amount is large, the vendor is contracted, or the commitment needs approval before it exists.

Large invoices belong here because approval before payment is the only control that actually stops spend. Contracted vendors belong here because the invoice has to be checked against terms you negotiated, and that check needs a document and a person, not a statement line. Anything creating an obligation beyond this month belongs here because you want a second signature first.

There is a control argument too. The ACFE's Occupational Fraud 2024 report, covering 1,921 cases, found organizations losing an estimated 5% of revenue annually to fraud, median loss $145,000, and over half of cases traced to weak or overridden internal controls. The controls that catch payables fraud, matching to an approved commitment and separating whoever approves from whoever pays, only exist on the AP rail. Cards and reimbursements have limits and reviews, which is not the same thing.

The cost of AP is speed and administration. Ardent Partners research puts cost per invoice at $2.88 best-in-class against $12.88 average, and processing time at 3.1 days against 17.4 days. Putting a $60 purchase through that machinery is bad economics, which is why the other two rails exist.

The four questions that decide the rail

Ask these in order and the answer falls out.

Is the amount large enough that you would want to stop it before it happens? If yes, AP. This question overrides the other three.

Is there a contract, a renewal or a negotiated price to check against? If yes, AP, because somebody has to compare the invoice to the terms.

Is a person standing at the point of purchase with no time to wait? If yes, card. If a card cannot reach them, reimbursement, then fix why the card cannot reach them.

Does it recur predictably every month? If yes, card for small amounts, AP for large ones, with a review date either way.

Edge cases default to AP. Slow and documented beats fast and unexplained.

What each rail does to your coding and your close

Every rail leaves a different mess behind, and in a group the mess is about which entity the spend belongs to.

Cards leave you coding after the fact. The transaction is in your ledger within days, but the entity and the account are inferred from a merchant name. If one card is used across two entities, you have created an intercompany balance without anyone deciding to. The fix is one card per entity, never shared, with the entity fixed by the card rather than the reviewer's judgement.

Reimbursements leave you with timing problems. The purchase happens in one month and the claim arrives in the next, so either expenses sit in the wrong period or you are accruing for claims you have not seen. The claimant also picks the entity, and will often pick the one that employs them rather than the one that benefited.

Centralized AP leaves the cleanest record and the most upfront work. The invoice names the entity, states what was bought and carries an approval, which is why AP spend is the easiest to close and the slowest to execute.

American Express and PYMNTS research has found AP teams spending roughly half their time collecting invoices and paying suppliers, with automation saving about 9.9 hours a week. In a small group that is one person's afternoons, and the way to reduce it is to stop routing $40 purchases through it. Related reading: the accounts payable process.

Why most groups end up running all three

A group runs all three rails deliberately, and the ones that run smoothly wrote the split down.

The unsuccessful version is running all three by accident, where the rail is chosen by whoever is closest to the purchase and nobody has stated the rules. That produces the worst of each: card spend nobody can explain, reimbursements resented by staff, invoices arriving for commitments you never approved.

The successful version is a single page saying, by category, which rail applies. Software and fuel on cards. Materials over a threshold and professional services through AP. Personal mileage reimbursed. It takes an afternoon to draft and removes most of the ambiguity, because most spend falls into fewer than twenty recurring categories. Check it twice a year, because categories migrate: a reimbursement category that keeps recurring means somebody needs a card.

A worked example

Take a group of nine entities: six operating locations, one holding property, one shared services company employing the back office, one holding company.

Cards: one per operating location, issued in that location's entity name, with a monthly limit slightly above normal consumables spend, plus one in the shared services entity for the software estate. Seven cards, none shared, each tied to one set of books.

Reimbursements: mileage, occasional meals, emergency purchases outside card acceptance. Paid weekly, claimed against the entity that benefited.

Centralized AP: rent, insurance, professional fees, utilities, every contracted supplier, and any materials purchase above a set threshold. Intake to one address for all nine entities, coded to entity at intake, approved by the location lead plus group finance above the threshold, paid in two runs a week from each entity's own account.

The interesting part is the boundary. A location buying $200 of consumables uses the card. The same location buying $9,000 of equipment raises a request and goes through AP, even though the card would work. The threshold holds only because the AP route is fast enough not to be worth evading. If your AP route takes three weeks it will be ignored, and you will have learned more about your process than about your people.

Can QuickBooks or Xero do this?

Both record all three rails competently within one entity, and neither decides the rail or holds the group-level view.

Take the rails one at a time. Cards work best: feeds arrive automatically and rules handle repeat merchants, so most coding takes care of itself. But rules are configured per file, so nine entities means nine rule sets to maintain and drift between. Bills work too: due dates, attachments and basic approval, thresholds likewise set file by file. Claims are serviceable, with phone receipt capture, enough where reimbursements are genuinely rare; neither tool will tell you a claim should have been a card purchase.

Two limits sit above all three rails. There is no group-level spend view, so what the group bought from one vendor has to be assembled by hand, and where a card or claim crosses entities the intercompany balance is yours to spot. Neither tool has an opinion about policy either: a $9,000 purchase on a card is booked cleanly and silently.

Payments and spend management sit on cruisr's roadmap rather than in what it ships today. What cruisr delivers now is current books, a fast close and group-level consolidation on top of QuickBooks Online or Xero, and cruisr does not move or hold money.

The rule set worth writing down

Cards are per entity and never shared. Reimbursements are paid faster than vendors and reviewed for patterns that mean somebody needs a card. Anything above a stated threshold, contracted, or committing the group beyond this month goes through AP, approved before payment. Every purchase resolves to the entity that consumed it, decided by the person who knows.

For what happens downstream of these choices, the month-end close from an owner's perspective covers the rest. If the harder problem is that your books are too far behind to see which rail your spend is taking, that is the part cruisr works on. Start a conversation.