MCP for Finance Is Not Enough: Why Connecting an LLM to Your ERP Still Gets the Math Wrong

A controller wires up a Model Context Protocol server to NetSuite, asks the AI for trailing-twelve-month gross margin by segment, and gets an answer in four seconds. The number is wrong by 90 basis points. Not because the AI couldn’t reach the data. It reached the data perfectly. It pulled the right GL accounts, the right periods, the right entities. Then it did the division itself, in token space, and quietly fumbled a sign on a contra-revenue account.

This is the trap MCP walks finance teams into. Connection feels like the hard part, so once the pipe is open the work seems done. It isn’t. Retrieval is solved. The math is not.

What MCP actually fixes

Give MCP its due. Anthropic introduced the protocol in late 2024 as an open standard for connecting models to external tools and data, and by the November 2025 specification it had grown real teeth: structured tool definitions, concurrent tool execution, task tracking for long-running work, and browser-mediated flows so a client never has to hold raw credentials. Microsoft ships an MCP server for Dynamics 365 Finance and Operations. There are MCP servers for market data, for accounting platforms, for warehouses.

The genuine win is governance. Before MCP, “connect the AI to our ERP” usually meant a brittle custom integration, an over-scoped API key, and no record of what the model touched. MCP standardizes that access. One protocol, declared capabilities, scoped permissions, an auditable surface. If your alternative was pasting a CSV export into a chatbot, MCP is a serious upgrade on data leakage and explainability.

So when a vendor says “we’re MCP-native,” believe that they’ve solved the plumbing. Just don’t let that claim quietly expand into “and therefore the numbers are right.” Those are different sentences.

The two things MCP does not give you

Here is the gap, stated plainly. MCP is a transport and access layer. It moves context to the model and exposes tools the model can call. It says nothing about two problems that decide whether a finance answer is trustworthy.

It doesn’t reconcile. What comes back over an MCP connection is raw ledger data. Journal lines, account balances, dimension tags, multiple entities each with their own chart of accounts, intercompany entries that haven’t been eliminated, a revenue figure in the GL that doesn’t tie to the figure in the billing subledger. MCP hands the model a faithful copy of the mess. The model now has to decide which “revenue” is the real one, whether to net the intercompany line, how to map four entity charts onto one definition of gross margin. That’s not retrieval. That’s accounting judgment, and an LLM improvises it differently on Tuesday than it did on Monday.

It doesn’t compute deterministically. Even with clean inputs, an MCP-connected LLM still does the arithmetic the only way an LLM can: by predicting the next token. The benchmarks are blunt about where that lands. Top models stall around 82% on financial spreadsheet tasks and roughly 90% on finance QA. A 90% answer rate sounds fine until you remember it means one in ten figures is wrong, with no flag on which one. The protocol moved the right data into the prompt and then left the calculation to the least reliable component in the stack.

You can hand an LLM a pristine trial balance over MCP and still get a wrong margin, because the failure isn’t in the data path. It’s in the math.

”Just give it a calculator tool”

The obvious objection: MCP supports tool calling, so expose a calculate tool and the LLM stops doing arithmetic in its head. Half right, and the half it gets right matters. Routing the actual operation to code instead of token prediction is exactly the correct instinct.

But a bare calculator tool inherits the problem one layer up. The model still has to choose what to feed it: which accounts, which periods, which entities, whether this line is already net of returns. Garbage selection into a perfect calculator is still garbage out. And ad hoc tools drift. The margin definition baked into one tool call won’t match the one the model assembles in the next conversation, so two people asking the same question get two answers and neither can prove which is right. A calculator without a shared, reconciled model underneath is a faster way to be inconsistent.

What sits between the protocol and the answer

The fix isn’t to reject MCP. Use it for what it’s good at and put the missing layers where they belong: between the connection and the language model.

First, a reconciled model. One place where the messy multi-source inputs are mapped to agreed definitions, intercompany is eliminated, entities are consolidated, and every figure ties out to the ledger. This is the single source of truth, the thing a controller would actually sign. The semantic definition of “gross margin” lives here once, not re-derived per prompt.

Second, a deterministic engine. Calculations run as code against that reconciled model, not as predictions inside the LLM. Same inputs, same output, every time, with a path back to source. The model’s job shrinks to what it’s genuinely good at: understanding the question, choosing the right pre-defined metric, and explaining the result in plain language. It retrieves and it narrates. It does not invent the number.

That’s the division of labor Rexfin is built around. Connect your accounting and financial-data platforms, or upload statements. We build one reconciled model that ties to the ledger. Then AI retrieves figures, runs the math through a deterministic engine, models what-if scenarios, and produces insights that trace to source. MCP can be one of the doors data comes through. It is not a substitute for the model and the engine behind that door.

If you’re earlier in the architecture, a spreadsheet is the wrong foundation to put under any of this for the same reason: connecting an AI to a flawed base just automates the flaw. And the standard a board will hold you to is sharper than “it answered”: it’s whether the number is replayable, provable the way a formula is provable. The broader case for treating reliable financial modeling as its own layer is laid out in the pillar.

The takeaway

MCP answers “can the AI reach our numbers?” It does not answer “are the numbers right?” Those are the only two questions a CFO cares about, and a vendor that solves the first while implying it solved the second is selling you confidence, not accuracy. Press on the second one. Ask where reconciliation happens and where the arithmetic runs. If the answers are “the LLM figures it out,” you have a fast pipe to a wrong number.

See the reconciled-model-plus-deterministic-engine architecture against your own messy data: book a demo.