One MCP server, your whole ERP stack in plain language
The Maesn MCP server is the access point for AI agents for financial data. It connects Claude and other assistants to 30+ ERP and accounting systems, so your team can query, analyse and update financial data by asking. Securely, with no data stored, hosted in Germany.
ClaudeDesktop and API
Questions that used to be an export and an afternoon
The MCP server is the technical part. What it enables is agentic access to your finance data: an assistant that can be asked a question about the numbers in an ERP or accounting system and answer it from the records themselves. Teams work in questions rather than queries, and the assistant does the reasoning on what it retrieves: the trend, the total, the flag. Seven of these are reads and the last one is a write.
“Show me revenue per customer for the last six months and highlight the three customers with the strongest growth.”
“List all open items for supplier Müller GmbH and total the outstanding payables.”
“Based on our journal entries, which accounts moved the most this quarter, and by how much?”
“Pull the debtor and creditor balances and flag anything overdue by more than 30 days.”
“Summarise our last ten transactions and tell me what changed against the ten before them.”
“What are this customer's payment terms, and how reliably have they paid against them so far?”
“Take the last four quarters of revenue and expenses and give me a forecast for the next two.”
“Create a draft invoice for customer Acme for these three line items.”
The write case is not an afterthought. The server is bilateral, so an assistant can act on your numbers as well as report them, across the resources below. Depending on the target system a write is processed directly or handed to asynchronous processing with confirmation once it is done, so a prompt that creates an invoice is not a fire and forget action. For anything recurring, an approval step between the assistant and the write is the sane default.
Two settings get the most out of this. In-house finance teams stop waiting on an export to answer a question about their own numbers, which is what the solution for financial teams is built around. And groups running several entities can ask one question across all of them, because every entity reaches the assistant through the same normalised model rather than through its own system, which is the whole point of a multi-entity enterprise.
What is an MCP server
The Model Context Protocol is an open standard for letting an AI assistant reach tools and data in a structured way, so a model does not need a bespoke integration for every system it should be able to see. The assistant is handed a set of callable functions, it calls them, it gets structured responses back. Simple, and it holds one assumption: that whatever sits behind those functions can be queried synchronously and answers in a structure.
The Maesn MCP server speaks that standard on one side and the Maesn Unified API on the other. What it bridges to is the part that matters: a single connection reaches every system Maesn supports, with the same authentication, the same normalised data model and the same compliance guarantees you get from the API itself.
That is a different proposition from connecting an assistant to one system. Adding one more MCP server means an assistant can see one more system. Putting an MCP server on a unified layer means it reaches an entire European stack through the same functions, with the same field names, however differently each of those systems works underneath.
A data lake is the wrong fix for agents
The standard answer to giving AI access to enterprise data is to copy that data somewhere central first. For analytics that works. For agents it creates five problems and solves none of the important ones.
Access in the source system is controlled by roles and credentials. Copy the data out and that context is gone, so fine-grained control has to be rebuilt centrally.
Queries run against the source under the credentials the customer authorised, so the original restrictions still apply.
Lineage and auditability are hard to maintain in a copy. Proving controlled access, or honouring a deletion request, becomes a project of its own.
Every request is authenticated, authorised and recorded at the API layer, which is where the audit trail belongs.
Exported data loses the relationships, constraints and process logic it had in the source. Teams then spend months writing mappings and still get inconsistencies.
Normalised endpoints arrive with the meaning intact, so an agent reads invoices and contacts rather than table dumps.
Batch pipelines mean an agent reasons about yesterday. In finance that is not a detail, it is the difference between a correct answer and a confident wrong one.
The call goes to the source when the question is asked, so the answer reflects the system as it is now.
Pipelines, governance layers and the people to run them are a permanent engineering line item, while the return on the AI work stays speculative.
Nothing is duplicated, so there is no second stack to operate alongside the one you already have.
A data lake is not a bad idea in general. For reporting and analytics it earns its place: historical, aggregated, stable. Agents want the opposite. They work in the present, on one customer's records, under that customer's permissions, and they need the meaning of a field as much as its value.
It is also the honest explanation for why so much enterprise AI work never leaves the pilot stage. The blocker is rarely the model. It is that nobody can show how the data reaches it in a way that survives a compliance review. An access layer where every call is authenticated, runs under the customer's own connection and leaves a record of the transfer answers that question without building a second copy of the business to govern.
One MCP server, 30+ systems
A DATEV MCP server, an Exact Online MCP server and a Visma eAccounting MCP server are not separate products. They are this one, pointed at a different system.
- One agent integration per system
- Exports, mappings and merges by hand
- File-based systems out of reach
- A separate report per entity
- One interface to the whole stack
- Structured data a model can use
- The file-based systems included
- One question across subsidiaries
Because the server runs on the Unified API, one connection reaches 30+ ERP and accounting platforms across Europe, among them DATEV, Exact Online, Xero, QuickBooks, Sage, Lexware Office, sevdesk, Pennylane, Visma e-conomic, Microsoft Dynamics 365 Business Central, Odoo and Fortnox. The integration directory is the current list, and it is the same list the rest of the platform runs on.
The practical consequence is that there is nothing to install per system. Connect Claude once and you can work with DATEV today and Xero tomorrow without changing anything in your setup. And because the data arrives through the Unified API it arrives normalised, so customers, suppliers, invoices, bills, journal entries, accounts and payments follow one consistent model regardless of source system. The answers an assistant gives are comparable across entities and clients rather than shaped by the quirks of each platform.
A sentence in, the right call out
You do not structure an API call and the assistant does not learn an ERP schema. The server does that part.
“Show me revenue per customer for the last six months and highlight the three customers with the strongest growth.”
Example. This is the shape of an answer, not live figures: the assistant reads the records through the Unified API and explains what it finds, with the identifiers, amounts and dates included.
The middle step is where the work is. The server validates the input, applies the filters the question implies, injects the credentials and makes the correct call against the Unified API. That last part matters more than it sounds: the assistant never handles a customer's credentials, because the connection the customer already authorised is what the server uses.
What comes back is structured data, which the assistant then explains in words, with the record identifiers, amounts and dates included. Almost every resource of the Unified API is reachable this way, and the current list lives in the repository README rather than in a table here that would go stale.
It inherits the controls you already trust
Security is the reason most teams hesitate to connect AI to financial data, and the reason this is built the way it is.
No-storage architecture
Your data is not persisted, so there is no second copy to govern.
ISO 27001 certified
The same certification that covers the rest of the platform.
GDPR compliant
Processing under European data protection law, not adapted to it.
Built and hosted in Germany
EU hosting for the MCP server exactly as for the Unified API.
Every request runs through the Unified API under the established, authenticated connection to the source system. Maesn operates a no-storage architecture: your data is not persisted, so there is no second copy of your financials sitting somewhere waiting to be governed. ISO 27001, GDPR and building and hosting in Germany apply to the MCP server exactly as they apply to the rest of the platform.
Giving an assistant access through Maesn does not widen your attack surface and does not weaken your compliance posture. What is recorded is that a call happened, with the endpoint, the target system, the account key and the timestamp, which is a record of the transfer rather than of the data.
Two ways to run it, depending on who asks
Remote, hosted by Maesn
- No local installation, connect your assistant and start
- Runs under the same EU hosting and the same guarantees
- Access on request, so a short conversation gets you set up
Local, on your machine
- Clone the repository and install the dependencies
- One entry in your agent's configuration file
- Start the server and point Claude Desktop at it
For teams the fastest path is the hosted server: no local installation, connect your assistant and start. Ask us for access and an API key and we will set you up.
For developers who want to self-host: clone the repository, install the dependencies and start the server with npx nx serve maesn-mcp. Then point your agent at it, which for Claude Desktop is one entry in claude_desktop_configuration.json, shown here as it appears in the documentation.
{"mcpServers": {"maesn-mcp": {"command": "node","args": ["<ABSOLUTE_PATH>/apps/maesn-mcp/dist/main.js"]}}}
The teams who live in this data every day
The clearest value is internal. Controlling and FP&A get ad-hoc revenue, margin and cash-flow questions answered in seconds, across every client or entity, without waiting for a report. Accounts payable get open items, supplier balances and due dates on demand, with the ability to draft and update records. Accounts receivable get overdue receivables and customer balances flagged conversationally instead of dug out of a dashboard. At month-end, journal-entry and account movements can be explained in plain language, which is how anomalies get spotted early rather than after the close.
The same capability is a foundation for product builders. Instead of building and maintaining an integration per system to expose accounting data to their own AI features, they connect once and inherit the full system coverage and the security model. Skip the exports and the one-off integrations, and give the assistant a direct line to the data instead.
Common questions
What is an MCP server?
What does the Maesn MCP server do?
Is there a DATEV MCP server, or an Exact Online MCP server?
Why not point an assistant straight at the accounting system?
How many systems can the assistant reach?
Can it write, or only read?
Do we have to install anything?
Is our financial data safe if an assistant can reach it?
Why not load the data into a data lake for our agents?
Do agents get the same permissions the customer has?
Which assistants work with it?
How do I get started?
Build once on the Unified API.
See how the MCP server works for your integration, or dive into the technical reference.