Your ERP already ships AI. Sage has it wired into the finance workflows, Business Central has it inside the record, Odoo built it in natively with version 19 and Holded sells it on the dashboard. If you pay for any of the four, the question you're asking is fair: I already have AI included — why would I buy anything on the outside?
The thesis in one line: the vendor copilot handles what happens inside a screen very well — summarise, suggest, fill in, explain the record in front of you — and handles none of what crosses systems, which is exactly where the expensive work lives. And the point isn't that it doesn't do it yet: it isn't built to. That's an architectural boundary, not a pending row on their roadmap.
Native ERP AI vs external agent: the boundary isn't features, it's architecture
Look at what native copilots actually do and they all share one shape. In Odoo 19, AI stopped being a separate module: the official documentation describes agents built from topics — the instructions telling the agent what to do — and tools attached to those topics. In Business Central, the feature finance teams cite most is assisted bank reconciliation: it proposes matches between imported statement lines and ledger entries, and suggests the posting account for the ones that don't match. In Sage, the copilot lives inside the finance workflows and its import agent cuts the manual data prep in migrations and recurring imports.
It's good product. Notice what they have in common: all three work on data already inside the system, on the screen the user is already on, with that user's permissions, while that user is watching. The ERP isn't where the copilot lives — it's the whole of its world. That's the boundary, and it explains both what it does well and what it will never do.
Three things the native copilot gives you, and you should be using
- Explaining a record you already have open. Summarising a customer's history, telling you why this invoice sits where it sits, turning a journal entry into plain language. Instant context over data the system already holds and you already have rights to.
- Proposing inside a form, using the system's own rules. Bank reconciliation, suggested posting account, product description, quote copy. The vendor plays at home: nobody knows their data model better, and the suggestions respect their own validations.
- Asking your data a question without building a report. What used to mean asking someone for a list and waiting two days is now a sentence. That's not small: it's the difference between deciding on data and deciding from memory.
All of this comes inside what you already pay, so switching it on and training people is one of the cheapest calls you'll make this year. Anyone who tells you otherwise is selling you something. So are we — which is why we say it first.
Three it will never give you, and why that's architecture, not roadmap
Now the other side. There are three kinds of work the vendor copilot doesn't do, and none of the three gets fixed by waiting for the next release.
- Work that crosses systems. The invoice arrives by email, the delivery note is a supplier PDF, the order lives in the ERP and the dispute got settled over WhatsApp. Squaring those four is the work that costs money, and three of the four sit outside the ERP. A copilot that only sees one of them cannot close it, however good it is.
- Work that waits on somebody outside. An estimate that needs the customer's yes, a supplier who doesn't reply, an approval that's been parked for four days. The bottleneck there isn't understanding the data: it's chasing a person who doesn't have your ERP open and isn't going to.
- Work that happens when nobody is watching. Processes that run overnight, hit an exception and have to decide whether to escalate. The copilot needs a user in front of it asking for something; its unit of work is the session, not the process.
The underlying reason is the same in all three. The native copilot inherits three limits from the system hosting it: the data limit (it only sees what's inside), the permission limit (it acts as the user who invoked it, no more and no less) and the clock limit (it starts when somebody types and ends when that person closes the screen). An agent that runs across processes needs precisely the opposite: its own identity, its own permissions scoped to its task, and its own clock. That isn't a feature Sage or Microsoft can add in the spring release: it's a different object.
Where the outside option starts paying off
The question isn't "how much AI do I need", which has no answer. It's a far more boring one that you can actually measure: how many times a day does somebody have to leave your ERP to finish a piece of work? That number decides it, and you can count it this week without buying anything.
- Count the hops. Take three processes that hurt and log every time someone leaves the ERP to complete them: opening email, hunting for the PDF, messaging on WhatsApp, logging into the supplier portal. Every hop is work the native copilot can't see.
- Measure the wait, not the typing. The real cost is almost never the minute spent typing: it's the time the work sits still waiting on somebody. An estimate that waits four days doesn't cost four minutes of admin, it costs four days of cash.
- Price the late error. Errors caught inside the screen are cheap; errors caught three weeks later, at close or on the customer's invoice, are not. Count how many of your last ten were caught late.
If all three numbers come back low, congratulations: switch the copilot on, train the team and spend nothing more. If they come back high — and in most mid-sized companies running several systems they do — you've pinpointed, with names attached, exactly where you need something the vendor doesn't sell.
| Dimension | Native ERP copilot | Agent that crosses systems |
|---|---|---|
| Unit of work | The screen / the session | The process end to end |
| What data it sees | Whatever is inside the ERP | ERP + email + documents + messaging |
| Permissions it acts with | Those of the user invoking it | Its own identity, scoped to its task |
| When it starts | When somebody asks it to | When the event happens, audience or not |
| Who answers when it fails | The vendor, inside their product | You: rota, trace and procedure |
The expensive mistake: paying twice for the same thing
There's a way to get this wrong in each direction. One is the one this piece opens with: assuming the included copilot covers everything, and spending another year with three people squaring documents by hand. The other runs the opposite way and gets spotted less: building outside what the vendor already gives you inside, so you end up paying twice for a bank reconciliation and maintaining a brittle integration the ERP was doing on its own.
The right order is the boring one: first switch on and squeeze what's already included; then measure what still walks out the door; and only then build outside, and only there. When that moment comes, the technical call isn't "which AI do I buy" but how you bridge to the systems you already run — API, orchestration layer or MCP — which is what the guide on integrating AI with your systems without rebuilding anything is about. And the second call, the one that sinks most projects by arriving late, is which surface that agent lives on: inside the ERP itself, in Teams, in email or on WhatsApp, depending on where the person using it already is. That comparison is in which channel to put an AI agent on.
What we do, with no decoration
We don't sell another ERP and we won't ask you to swap the one you have. We build on top of it the slice of the process your ERP can't cover because it sits outside it: the document arriving by email, the approval somebody has to give from their phone, the exception that shows up at three in the morning. With a concrete name depending on where you live: AI on Sage, on Business Central, on Odoo or on Holded. And when the work crosses several systems at once, that's operations automation in the literal sense: the whole process, not the screen.
The summary fits in one line and it's worth having straight before your next call with your partner: the copilot is a feature of your ERP; the agent is a process that crosses your ERP. Confusing the two costs you in both directions — either you pay twice, or you wait two years for a release that isn't coming, because what you need doesn't fit inside the product.