Two pitches are landing on accounting firms at the same time right now. Connect Xero to Claude through an MCP server and ask it questions about your ledger. Or install a purpose built AI CFO layer that forecasts, models, and reports on top of the same data. KPMG just embedded Claude Cowork into its global tax and legal delivery platform, and Xero native connectors from LogicGlue and Fuel Finance already let any firm wire Claude straight into their books. The access problem is solved. That does not mean the advisory problem is solved too.
What a Xero MCP Connector Actually Gives You
An MCP server is a translation layer. It lets a model like Claude send authenticated queries to Xero’s API and read back invoices, contacts, and ledger balances in a format the model can reason about. Ask it “what did we spend on subcontractors last quarter” and it will go fetch the answer. That is genuinely useful, and it is also the entire scope of what it does.
It has no persistent view of where cash is heading. It does not sit there overnight recalculating a 13 week forecast when a new invoice lands. It cannot flag that a client’s runway just dropped two weeks because of a bounced payment, because nothing is watching. Every answer requires someone to ask the right question first. That is a conversational interface bolted onto a ledger, not a forecasting engine.
KPMG’s rollout is instructive here. The first use case for Claude Cowork inside a Big Four firm is tax and legal document work, not cash flow forecasting. That is where agentic AI is proving itself first: structured, document heavy, question and answer work. Financial forecasting is a different job, and it needs a different kind of system underneath it.
Ad Hoc Answers Versus Standing Advisory Work
The distinction that matters for a firm’s advisory revenue is standing versus ad hoc. A client conversation built on “let me ask Claude” produces a one off answer. A client conversation built on a live 90 day forecast, updated automatically and flagged when something breaks, produces a recurring reason to meet. One is a party trick during onboarding. The other is billable advisory infrastructure.
| What the firm needs | Xero MCP + Claude | Purpose built AI CFO |
|---|---|---|
| Ad hoc ledger questions | Yes | Yes |
| Standing cash flow forecast | No, must be asked each time | Runs continuously |
| Scenario modelling for a decision | Manual prompt engineering | Built in scenario planning |
| Client facing branded report | None, raw chat output | Formatted report per client |
| Multi client dashboard for the firm | None | Built in |
| Alerts when cash position changes | None, nothing is watching | Automated monitoring |
Read that table as a map of where the effort sits. With an MCP connector, the firm supplies the judgment, the prompts, and the formatting every single time. With a purpose built layer, that work is done once, in the product, and reused for every client.
The Build Versus Buy Math Has Changed
A year ago, wiring an LLM into Xero was a real engineering project. It no longer is. LogicGlue and Fuel Finance’s Fuel MCP have both made the connector itself close to a commodity, and KPMG proves the pattern works at enterprise scale. That is exactly why “we will just connect Claude to Xero ourselves” is a weaker argument today than it was twelve months ago, not a stronger one. If the connector is easy for everyone to build, the connector was never the differentiator.
What still takes real work is the layer above the connector: the forecasting logic, the scenario engine, the client reporting, the alerting. That is where a firm’s evaluation should actually focus.
Four questions to ask before choosing either path
- Who is the output for? If it is just you, ad hoc Q&A might be enough. If it is a client who pays for advisory, they need something to look at, not a transcript.
- Who maintains the prompts? An MCP setup that works well depends on someone writing and refining good prompts indefinitely. That person becomes a single point of failure.
- What happens between conversations? If nothing is monitoring cash position when nobody is asking, risk accumulates silently between check ins.
- Does it scale across your client list? A prompt built for one client’s chart of accounts rarely holds up cleanly across fifty different ones without rework.
None of this is an argument against Claude or MCP connectors generally. It is an argument that the connector is infrastructure, not a product, and firms billing for advisory work need the product layer on top of it.
Why This Matters More as Firms Take On Clients Anywhere
The firms asking this question are not confined to one country’s ledger habits anymore. A bookkeeper in one region and a fractional CFO in another can end up serving the same client roster, connected through the same accounting platform, regardless of where either of them sits. An MCP connector answers questions in whatever language and format you prompt it in, but it does not standardise how a forecast looks across a client base spread across time zones and currencies. A purpose built layer does, because the report format, the categories, and the alert logic are the same regardless of which client file is connected.
That consistency is what actually gets sold to a client, not the novelty of an AI answering a question correctly once. Firms that pick the connector only path usually discover this the first time a client asks for the same report two months running and the answer looks different both times.
Try It With Your Own Client Data
Finoya sits on top of a Xero or QuickBooks connection the same way an MCP server does, except the forecasting, scenario modelling, and client reporting are already built and already running. Connect a client’s file and see the 90 day cash position, not a chat window waiting for the next question.
Create your free Finoya account and see what standing advisory infrastructure looks like next to a one off query.