Every ERP vendor now ships an AI assistant, every demo looks convincing, and six months later the finance team is still copying numbers into a chat window by hand. The gap between "our ERP has AI" and "AI carries load in our operations" is where a lot of enterprise AI budget quietly disappears.
Connecting AI to ERP and accounting systems is a regular part of our client work; at Speedinvest, for example, we helped start the integration work with the fund's ERP system (case study). This post is the short list of design patterns we think survive contact with production, and why the most heavily marketed approach usually does not.
Pattern 1: Read freely, write behind approval
This is the most important design decision, and the one worth adopting even if you ignore the rest.
Reads carry most of the value and little of the risk. "Which invoices are overdue beyond 30 days, and what changed since last week?" Answered from live ERP data, in plain language, without anyone exporting a report, that question alone saves real time for the people who currently assemble those answers by hand. A read cannot corrupt the books. So reads should be broad, fast, and unceremonious.
Writes are a different animal. Anything that creates or changes records (postings, payment runs, master data) goes through a human approval step. The agent prepares; a person confirms; the system records. In practice the agent drafts the posting or the dunning run, and an accountant approves it the way they would approve a junior colleague's work.
The asymmetry is the point. Teams that gate reads strangle the value; teams that free the writes eventually have an incident. Free the reads, gate the writes, and both risks shrink at once. It is also a pattern that is easy to explain to external accountants and auditors (in DACH, your Steuerberater), because nothing reaches the books without a named person approving it.
Pattern 2: System-of-record discipline
The ERP is the system of record. The integration must never blur that, and it blurs faster than people expect.
The failure mode looks harmless: the AI layer keeps a cache "for performance", then a summary table, then a working copy that someone treats as truth. You now run a shadow ERP, unaudited and slowly diverging. Every reconciliation problem you hired AI to remove has been reintroduced one layer up.
The discipline: the AI layer holds no state that matters. It reads from the ERP at the moment of the question and writes back through the ERP's own supported interfaces, so every business rule and validation the ERP enforces still applies. If the ERP would reject an entry from a human, it must get the chance to reject the same entry from an agent. AI is a layer over the system of record, never a system of record.
Pattern 3: An audit trail for everything
Every AI-initiated action, reads included, should land in a log: which agent, which tool call, which arguments, which user approved, what changed. This is not compliance theatre. It is the mechanism that makes the first two patterns enforceable, and it produces an underrated result.
Done properly, AI integration improves your audit posture. Today's manual reality (numbers copied between windows, decisions living in inboxes and heads) is largely invisible to any audit. An integration layer that logs every action makes the automated share of the work more traceable than the manual work it replaced. Bookkeeping rules such as Germany's GoBD expect entries to be traceable and verifiable; a complete action log meets that expectation by construction rather than by after-the-fact archaeology. When the auditor asks "where did this posting come from?", the answer is a log entry, not a shrug.
Why "AI inside the ERP UI" underdelivers
Now the heavily marketed approach: the assistant panel inside the ERP interface. It demos well and disappoints structurally, for three reasons.
Work does not live in one system. A real process, say from customer email to credit check to order to invoice to dunning, crosses the CRM, the ERP, accounting, and a mailbox. An assistant embedded in the ERP sees exactly one station of that journey. It can summarise what is already in front of the user; it cannot run the process, because the process is bigger than its window.
The wrong direction of travel. Embedded assistants make people come to the ERP and chat with it. Most of the value runs the other way: the answer appearing where the person already works (their approved AI tool, their inbox, their workflow), with the ERP consulted in the background.
Vendor coupling, twice. The embedded assistant uses the model the vendor chose, improves at the pace the vendor ships, and speaks only to that vendor's system. You inherit their roadmap as your ceiling, and everything you configure deepens the lock-in.
The alternative is an integration layer: your systems exposed through the Model Context Protocol (MCP), so any approved AI tool (ChatGPT, Claude, Copilot, Gemini, or your own agents) can reach the ERP and its neighbours through connectors you own. One layer, every system, any model; swap the model without touching the connectors. We explain the protocol itself in MCP explained for the enterprise. The layer can run on your own infrastructure or on a managed service such as our MCP platform. Either way, make sure the connectors and their configuration are yours under the contract, so changing hosts later does not mean rebuilding them.
To be fair: if your need truly ends at summarising the screen in front of an ERP user, the embedded assistant is fine and cheaper. The disappointment starts exactly where the value starts, the moment a process crosses a system boundary.
Where to start
Not with a platform programme. Pick one process that hurts weekly, whose data lives in the ERP, and where today a person is the integration. Accounts-receivable questions are a reliable first candidate. Stand up the integration layer for that one process: free reads, gated writes, everything logged. Ship it in weeks, let the finance team use it on real work, and keep the patterns.
That first process does the strategic work: access, approvals, and audit get answered concretely, once, and every process after it inherits the answers. For finance teams specifically, our AI workshops for finance teams start from exactly this setup, on your own ERP.
Talk to us
If you have an ERP (DATEV, BMD, Navision, Business Central, SAP, or something older) and a process where a person is currently the integration, talk to us. We will tell you which first process we would pick and why.