A strategic look at why MCP for business expenses is becoming the default interface between AI and finance systems — and the five decisions every CFO should make in the next 90 days.
The shift that's already underway
For the last decade, the conversation about CFO technology has been about integration: how do you stitch your expense tool to your GL to your bank feed to your project system? The answers have improved — iPaaS platforms, embedded fintech, vendor-built connectors — but the fundamental shape stayed the same. You added more wires between more systems.
Something more interesting is happening now. The wires are being replaced by a protocol. And a lot of the heavy lifting that used to require humans or custom code is being absorbed by AI agents that read across every system in the stack through a single, standardised interface.
That protocol is MCP — the Model Context Protocol, introduced by Anthropic in late 2024 and adopted across the industry at a speed that's hard to ignore. Microsoft has shipped it for Dynamics 365 Finance & Operations. Google Cloud has written about it as part of its enterprise AI guidance. Intuit has partnered with Anthropic to bring MCP integrations across QuickBooks, TurboTax, and Credit Karma. The pattern is clear: MCP isn't an Anthropic feature; it's becoming the way AI talks to finance.
If you're a CFO, controller, or finance ops lead, the question isn't whether MCP matters. It's whether your stack is positioned to benefit when the rest of your peers start compounding the gains.
The integration problem MCP actually solves
Every CFO has lived some version of this story: you adopt a best-in-class expense tool, a best-in-class procurement tool, a best-in-class GL, a best-in-class HRIS. Each one was bought to solve a real problem. Each one has its own API. Each one was supposed to integrate with the others, eventually.
The result is the modern finance stack: a constellation of excellent point solutions connected by Zapier flows, scheduled syncs, vendor partnerships of varying maturity, and at least one Google Sheet that nobody is allowed to touch. The integrations work — until they don't, at which point the discovery happens during close, three days before board reporting is due.
The reason integration is hard isn't technical. It's combinatorial. N tools means up to N × (N−1) point-to-point integrations, each of which is somebody's job to maintain. The industry has tried iPaaS (good, but adds another vendor), embedded ERPs (good if you accept lock-in), and one-vendor-to-rule-them-all suites (good if you can stomach the compromise on best-of-breed).
MCP is structurally different. It replaces the N×(N−1) integration mesh with a hub. Each tool exposes its data through one MCP server. AI clients connect to the servers they need. The "integration" — the cross-tool reasoning that used to require code — happens inside the AI, dynamically, in plain language.
MCP doesn't make integration easier. It changes who does the integrating, and when. It moves the work from the build phase (developers, scheduled syncs) into the moment of use (an AI agent, in conversation).
Why traditional APIs aren't enough anymore
"But we have APIs," every CFO is right to think. "What's different here?"
Three things:
1. APIs are read by developers; MCP is read by AI.
A REST API is a contract between two pieces of code. Using it requires someone to write the code on both ends, deploy it, monitor it, and update it when the API changes. MCP servers are self-describing in a way AI agents can ingest directly. The AI sees the available tools, picks the right one, calls it, handles the response. The build step compresses to near-zero.
2. APIs route around the user; MCP keeps the user in the loop.
Classic API integrations are silent. Data flows in the background; the user finds out at month-end if something broke. MCP is conversational by design. When the AI needs to take an action, it can ask. When it returns a result, the user sees the path it took. The audit trail is a feature, not an after-thought.
3. APIs are static; MCP is composable in real time.
Want to cross-reference expenses with calendar events for the offsite, then check against the travel policy, then write a draft note to Slack? With APIs, that's a build project. With MCP, that's a single conversation across three servers — and once it works, you save the prompt as a workflow. Composition happens at the user layer, not the engineering layer.
The FinOps Foundation's MCP working group has documented similar advantages for cloud cost management. The lesson generalises: anywhere you've got specialised data and a need for cross-system reasoning, MCP changes the unit economics.
The strategic case for an MCP-ready expense tool
Expense management is one of the most MCP-flattering categories in the finance stack, for three reasons:
- High frequency, low value per event. A typical mid-market company processes thousands of expense events a year, almost none of which require human judgement individually. This is the textbook profile for AI delegation.
- Cross-tool by nature. Expense data is meaningful only in context — alongside the GL, the budget, the policy, the project. MCP's cross-server composition is exactly what this category needs.
- Compliance-sensitive. Expense records are evidence. They get audited. The permissioning, logging, and consent model that MCP enforces is well-suited to the compliance posture a finance org already needs.
The strategic implication: if you're picking or re-evaluating an expense tool in 2026 or 2027, MCP-readiness is the single most important capability that wasn't on the RFP a year ago. Tools that ship a robust MCP server compound with every other AI investment your company makes. Tools that don't will quietly become harder to use over the next 18 months as your team's expectations shift.
ExpenseMonkey was designed for this shift. The Claude integration is the most visible expression of that — but the deeper bet is in the schema design, the audit logging, and the permission model. Every customer-facing surface that an MCP client might use was built to be safe under autonomous access.
A scorecard for evaluating MCP-readiness in vendors
If MCP is the new integration layer, you need a way to assess it during vendor selection. Here's the scorecard ExpenseMonkey customers (and prospects evaluating us against alternatives) tend to land on.
CapabilityWhat to askMCP server availabilityDo you ship an official MCP server today, or only on a roadmap? Hosted or self-host?Tool coverageWhich read and write operations are exposed via MCP? Is it parity with your REST API, or a subset?Permission scopeAre MCP tokens scoped per-user, per-purpose, time-limited, and revocable from admin UI?Audit loggingIs every MCP call logged with user, AI client, tool, and timestamp? Exportable for SOC 2 evidence?Write-action consentDo state-changing operations require explicit user confirmation by default?Schema qualityAre tool schemas typed, well-documented, and stable across releases?Client compatibilityTested with Claude Desktop, Claude.ai, IDE clients, and at least one agent framework?Roadmap transparencyPublic commitment to MCP feature parity and version-tracking?
Score each vendor 0–2 per row. Anything below 10/16 is not yet MCP-ready in any meaningful sense. The honest answer for most categories of B2B SaaS today is "below 10." That gap will close, but it will close unevenly — and the vendors that close it first will compound an advantage that's hard to catch.
What this means for finance ops headcount
The temptation, every time a productivity shift like this lands, is to model it as a headcount reduction. The historical evidence is less tidy. ATMs didn't reduce bank teller employment as much as predicted; the role shifted toward judgement-heavy work. Self-service BI didn't shrink analyst teams; it changed what analysts spent their time on.
Expect the same shape here. The boring middle of finance ops — reconciliation, categorisation, status-checking, report assembly — is the part MCP-powered AI absorbs first. The headcount that gets re-pointed isn't gone; it moves toward:
- Vendor strategy and procurement. Doing the work that finance ops never had time for.
- Policy design and exception review. The judgement layer the AI surfaces but doesn't replace.
- Internal tooling and prompt design. A new craft skill that's already emerging in finance teams.
- Business partnership. Embedded finance support for product, sales, and ops leaders.
The teams that handle this transition well are the ones that name it explicitly. The teams that struggle are the ones that pretend nothing is changing, then suddenly skip a generation of capability when the rest of the market has been compounding for two years.
A reasonable counter-position: MCP is not a finished product, and the AI clients consuming it are not infallible. Early adopters have hit real issues — schema drift, ambiguous permissions, AI clients making confident-sounding errors on ambiguous prompts. The right strategic posture is not "go all-in tomorrow." It's "start in read mode this quarter, get fluent, expand the surface area carefully." See our practical workflow guide for the read-first approach.
What CFOs should do in the next 90 days
- Audit your stack for MCP-readiness. Use the scorecard above. Note which vendors are shipping MCP servers today, which are on the roadmap, and which are silent. The silent ones are the strategic risk.
- Pick one workflow and run it. Don't try to MCP-ify your whole finance ops in week one. Connect one tool (expenses is a strong candidate), one AI client, one team, one workflow. Watch what happens.
- Establish a permissioning and audit baseline. Before you let an AI client touch live data, define what scoped tokens look like, how revocation works, and what the weekly audit-log review looks like.
- Name an internal owner. Not necessarily a new hire — someone existing — but someone whose job description includes "the AI-on-finance-data layer." This is the role that will look obvious in retrospect.
- Run a quarterly review. What workflows did the team adopt? Where did MCP fall short? Which vendors moved on the scorecard? The compounding only happens if the review happens.
The 18-month outlook
Predicting 18 months in AI is a fool's errand at the best of times. But the shape of the next year and a half in MCP-for-finance is clearer than usual, because the protocol's adoption is being driven by structural forces rather than fashion.
By mid-2027, expect three things to be true:
- MCP support will be a buying criterion, not a differentiator. The same way "has a REST API" became table stakes around 2015, "has an MCP server with audit-grade logging" will be a default RFP question. Vendors that lag will need to compensate elsewhere or face churn.
- Expense workflows will be predominantly initiated in chat, not in app. The UI doesn't go away; the centre of gravity moves. Most teams will still open the expense tool for approvals and detailed review; the daily entry, categorisation, and reporting will increasingly happen in conversation.
- The audit trail will become an asset, not a chore. Every MCP call is logged. Over time, that log becomes the most complete record of how decisions were made in your finance org. Smart CFOs will start mining it the way smart engineering leaders mine their pull-request history.
None of this requires a leap of faith. The shift is being built in the open, on a published protocol, by vendors with their roadmaps visible. If you read our plain-English MCP guide and our practical workflow playbook, you can hold the whole picture in your head this afternoon and make a credible 90-day plan tomorrow.
The CFOs who do that this year are setting up for a much easier 2027 than the ones who don't.
