Accounting and Expense Management: The Three Paths

Accounting software and expense management are two systems that have spent fifteen years pretending to be separate products, and the seam between them is one of the most expensive parts of running finance at scale. Every transaction that an employee swipes, every receipt that gets photographed, every reimbursement request — eventually needs to land in the general ledger with the right GL code, the right department, the right project, and the right entity. How that journey happens determines whether your close is clean or chaotic.

This piece is about the architectural choice underneath that journey. There are three paths. They are not all equally good, but they are all defensible — depending on where you are.

Why expense is its own product category in the first place

You'd think accounting software would just handle expenses. Most early accounting platforms did, in a basic way — type the expense in, get it on the books. The reason expense management became a distinct category is that the workflows are genuinely different from general ledger work. Expenses involve:

• Card programs (issuing physical and virtual cards, setting per-card spend limits, blocking categories).
• Mobile-first capture (employees photographing receipts in airports, not sitting at a desk in Excel).
• Real-time policy enforcement (auto-flagging that this hotel is over policy, this vendor is non-preferred).
• Approval workflows that depend on amount thresholds, project ownership, and reporting lines.
• Reimbursement payment rails (ACH push to employees, often within hours not weeks).

That's a different product than "post a debit and credit to the GL." So a whole category emerged — Concur first, then Expensify, then the card-and-expense generation (Brex, Ramp, Airbase, Navan/TripActions). They got really good at the employee-facing job. What they're not always good at is the part where the data has to land in your accounting system without breaking.

The three paths

Path 1: Standalone expense tool bolted onto accounting software

The dominant pattern. You run QuickBooks Online or Xero or Sage Intacct for accounting, and you run Ramp or Brex or Expensify for expense management. Once a day (or once a week, in many setups), expense transactions sync over to the GL via an API integration. Both products are best-of-breed in their lane.

The upside: you get genuinely good employee experience on the expense side — fast card issuance, slick mobile app, real reimbursement times. You get a familiar accounting product. Each vendor is incentivized to be excellent at its specific job. You can pick freely between expense vendors when one annoys you.

The downside: the seam between the two systems is where the problems live. The integration is a one-way data push, usually nightly. Categorization mismatches between the two products' schemas have to be reconciled. When an employee leaves and is removed from HRIS, their record has to be deactivated in both expense tool and accounting system separately. When your chart of accounts changes, you update it in two places. When you spin up a new entity, you onboard it in two systems. The integration tax — covered in detail in our SMB spending report — lives here.

Path 2: Enterprise consolidated suite

You buy NetSuite, Workday, or SAP and use their native expense module. One vendor, one data model, one login. NetSuite Expense Management, Workday Expenses, SAP Concur (which Workday and SAP both partially own, depending on which way the wind blows).

The upside: the integration problem genuinely disappears at the GL level. Employee records are the same record in HRIS, accounting, and expense. Cost centers and dimensions flow through. Approval workflows can be unified. Audit trail is end-to-end.

The downside: the employee experience is generally a step behind the best-of-breed leaders. NetSuite Expense Management is functional, not delightful. Workday Expenses is workable but won't get raves. You pay for the consolidation, both in license cost (enterprise platforms charge enterprise prices) and in implementation complexity (you're implementing it as part of a multi-month ERP rollout). And you're locked into one vendor's roadmap on every module.

Path 3: MCP-native sibling products

This is the newer option, and it's what we've been building toward at Velo. The idea is that accounting (VeloLedger), expense (Velo Expense), HRIS (VeloPulse), and CRM (Velo CRM) are separate products with their own focused UX — but they share the same data model and communicate natively via MCP. The same employee record exists once. The same GL coding flows through. The same approval rules apply. There's no nightly sync because there's nothing to sync — it's already the same data.

The upside: you get the best-of-breed employee experience of standalone products and the consolidated data model of an enterprise suite. The integration tax doesn't exist because the integration is the architecture. AI assistants can work across the entire stack natively (the close assistant sees expense, payroll, and AP all at once because it's all one graph). And you keep the modularity — you can still use just one product if you want.

The downside: the products are newer (and we are honest about that). The ecosystem of niche integrations is smaller than NetSuite's marketplace. And if you've already spent two years building processes around QuickBooks plus Ramp plus Bill plus a sync tool, the migration question is real even if the destination is better.

The trade-offs, side by side

The integration tax math

Here's the math that drives this decision. Take a typical 120-person company running Path 1:

• QuickBooks Online Advanced: $235/mo
• Expense management (Ramp/Brex/equivalent): $0–$8/user, call it $480/mo for the team
• Bill.com or equivalent AP automation: $180/mo
• Sync tooling or middleware: $150/mo
• Document capture (Dext/Hubdoc): $80/mo
• Close software (FloQast/Numeric/equivalent): $300/mo
• FP&A (Mosaic/Cube/equivalent): $400/mo
• Total: ~$1,825/mo of finance software, of which ~$430/mo is purely "moving data between other things" (sync tooling + part of Bill.com + part of capture).

That ~$430/month — about 23% — is the integration tax. It buys nothing except connectivity between systems that should already be connected. Over five years, that's roughly $26,000 of cumulative spend that exists only because your stack is fragmented. And that's before counting the staff hours spent reconciling categorization mismatches every month-end.

The Path 3 alternative collapses most of that into one platform's pricing. The same 120-person company on the Velo stack pays for accounting and expense as part of one subscription, and the AP queue and document capture are features of the platform, not separate SKUs. The integration tax disappears because there is no integration to maintain.

When to consolidate vs. stay specialized

Consolidate (Path 2 or 3) when:

• You're over 50 employees and spending more than 15% of finance software budget on integration glue.
• You have multiple entities and reconciling them at month-end is consistently painful.
• You're hiring an in-house bookkeeper or controller and want to give them a clean platform to start on.
• You're heading toward an audit, fundraise, or acquisition — the integrated audit trail will pay for itself in due diligence.
• Your finance team is spending more time on tool-wrangling than on analysis.

Stay specialized (Path 1) when:

• You're under 25 people, single entity, and your needs are simple.
• Your existing point tools are excellent and your team loves them.
• You have a specific niche need (e.g., construction job costing, complex billing) that an integrated suite would underserve.
• The migration cost in calendar time would interfere with something else more important right now.

The wrong answer is to be on Path 1 by inertia after you've outgrown it — paying the integration tax for years because no one wants to do the migration. That's the most common finance ops mistake we see, and it's almost always more expensive than people realize.

What changes when expense and accounting are MCP-native siblings

Most concretely, three things:

One employee record. When you onboard someone in VeloPulse HRIS, they exist immediately as a person who can submit expenses in Velo Expense, as a vendor record in VeloLedger for reimbursement, and (if you grant access) a user in the relevant systems. When they leave, they're deactivated everywhere at once. No CSV exports, no orphaned records.

One coding hierarchy. The cost center, department, project, entity, and other dimensions live in one place and are referenced by every product. When an expense is coded to "Engineering / Project Apollo / US Entity / Q3," that's not a separate coding inside Velo Expense that has to be mapped to a separate coding inside VeloLedger — it's the same dimension graph.

One audit trail. The expense submission, the manager approval, the policy check, the card transaction, the GL posting, the close cutoff, the reconciliation — all of it on one timeline, queryable in one place. When the auditor asks how a specific expense moved from receipt to financial statement, you can show them in 30 seconds.

This isn't a feature. It's a different shape of finance stack. And in 2026, the case for that shape — for any company in the 20-to-500-employee band — is increasingly hard to argue against on cost or capability grounds.