The standard SaaS suite
Fast to start, everything from one provider, operated in their cloud. You extend it where the provider has opened it: interfaces, a marketplace, no-code rules. Xentral is a typical representative.
Why Corelane
The question is not which ERP is best.
It is who decides over your processes, your data and your AI in ten years – when the processes have changed, the data has grown and AI is no longer a project but part of the working day.
Three roads
Every ERP decision is one of three.
They differ less in what they can do today than in who is allowed to change them tomorrow.
The suite with a sealed core
Enormous functional breadth and a large partner ecosystem. SAP asks with S/4HANA that the core is not modified; Microsoft does the same with Dynamics 365 Business Central, where AL extensions hook into events beside an unchanged base app. Modifying the base directly works on-premise only and breaks the upgrade path.
The open-core platform
An open core you can read and extend, operated where you decide. This is the road Corelane takes with Odoo – your own logic inherits from the standard models and runs inside their process instead of beside it.
What follows from it
The three roads answer one question differently: when your process does not match the standard, do you change the process, wait for the provider, or change what the software does?
Coming from SAP: why 2027 is the year the architecture decision should no longer be postponed – extended maintenance included – and which three roads lead out of it
The proof
We did not read this. We did it.
STASTO replaced SAP and runs on this platform today: 13 companies in six countries, 100,000+ products in an integrated B2B store, warehouse automation, 21 languages of product communication – and AI in the daily process with human approval.
The architectural difference
Not opinions. Properties.
Everything in this table comes from the providers' own documentation. We compare architecture, not prices or quality – those you should judge for yourself.
| Property | Standard SaaS | Sealed core (SAP, Business Central) | Corelane |
|---|---|---|---|
| Where it runs | The provider's cloud only | Cloud or your own data centre | Your data centre or EU cloud, your choice |
| How it is extended | Interfaces, marketplace, no-code rules | Released APIs, ABAP Cloud or AL extensions – always beside the core | Your own modules in the same process as the data |
| Is the core modifiable | No | Deliberately not – clean core at SAP, unchanged base app at Business Central | Yes – but you do not fork it: your own modules inherit every class and method and override selectively. LGPLv3. |
| How far the extension reaches | As far as the product provides for | To the extension points provided, page extensions for instance | Into the interface – components patchable, views replaceable |
| Language and ecosystem | Provider-specific | ABAP or AL, plus the respective cloud platform | Python – the language the AI ecosystem is written in |
| Where AI attaches | At the interfaces the provider opens | As a service beside the core | Inside the business object itself |
| Choice of AI model | Whatever the provider uses | Vendor services, or your own beside the core | Configurable per workflow, down to local models |
| Leaving again | Export within the provider's terms | Data exportable, extensions bound to the vendor platform | PostgreSQL, open formats, core source public |
Sources, checked July 2026: Xentral on cloud operation · SAP on clean-core extension · Microsoft on Business Central extensions · Odoo Community licence · ERPNext licence. Odoo is open core, and the distinction matters for every claim on this page: the community core is open source under LGPLv3; the enterprise additions are proprietary – readable and modifiable under a valid subscription, but not free software; our own modules are ours and yours by contract. We say so rather than letting "open" do the work.
Underneath all three roads: which language, which database, which interface – and what each of them costs you in ten years
What it means commercially
Not properties. Consequences.
The table above compares architecture. This one turns it around: the same three roads, read as what they do to your budget and your calendar. No amounts here – those live on the pricing page, together with the assumptions behind them.
| The situation | Standard SaaS | Sealed core (SAP, Business Central) | Corelane |
|---|---|---|---|
| Your process does not fit the standard | You change the process | You wait for the vendor, or build beside the core | You change what the software does |
| Who can make that change | The provider, when it fits their roadmap | A partner, at the extension points provided | You or us – inside the process, not beside it |
| What the next release asks of you | Nothing – you get what arrives | Checking your extensions against a new core | Checking your own modules, on a date you pick |
| What leaving costs | An export within the provider's terms | The data yes, the extensions no | PostgreSQL and open formats – the modules are yours |
Amounts, packages and what they assume: the pricing page
Why this decides the AI question
AI does not dock on. It sits in the process.
This is where the architectural difference stops being academic. Every AI system worth having needs three things: the data, the process context, and permission to act. Closed systems give you all three – through released APIs, extensions and their own agents. What differs is the third one: how deep the permission reaches, who writes what happens next, and whose model it runs on.
Same language
Python
- Model SDKs, orchestration, vector search and MCP are Python-first
- The AI runs where the data is, not behind an interface
- No second system to keep in sync
Inside the record
In context
- The check sits on the invoice, the approval on the order
- People stay in the tool they already use
- Every suggestion is traceable to its source document
Your data stays
In house
- Only the task-relevant excerpt leaves the house
- Providers are swappable per workflow, down to local models
- Not tied to one vendor's AI roadmap
Human decides
Approval
- Nothing is posted without a person releasing it
- Every step logged, budgeted and auditable
- Shadow AI loses its reason to exist
The honest limit of this argument
Closed systems are not incapable of AI. They ship capable features, and for many companies that is enough. The difference is who decides what comes next: with an open core you do, with a closed one you wait – and pay for what arrives.
Why we can claim it
Because it is running. AI order intake, AI invoice checking, email triage and the control plane behind them are in daily productive use at STASTO – not in a lab. You can look at the actual screens.
Two tracks, one core
The process is deterministic. The AI is not.
An ERP has to be able to do arithmetic. A posting is a posting, a stock movement is a stock movement, and the same input gives the same result tomorrow. A language model does something else: it weighs probabilities. Both are useful. They must not run on the same track – and neither of them sits above the other.
One track: Odoo, the guided process
Postings, stock, prices, approvals, audit trail. Repeatable, verifiable, the same today as after the next release. Nothing on this track is decided by a model – which is exactly why the numbers underneath your annual accounts stay defensible.
The other track: the control plane, the AI
Reads documents, classifies mail, extracts, matches, proposes. Every result arrives as a proposal on the record it belongs to: the AI may propose the article, it may not ship it. What leaves the warehouse is what stands on the released order line, never what a model held to be likely – a wrong part number in a customer's mail becomes a line somebody corrects, not a delivery somebody has to fetch back. The probability stays on this track and never leaks into the posting.
And when an agent does change something, it goes through the same MCP interfaces and the same Odoo ORM as any user: the same access rights, the same validations, the same audit trail. There is no path around the business logic – not even one for us.
Four properties make that second track controllable: keys and models outside the ERP, a prompt change measured before it goes live, every call booked and capped, and the release as a stage on the record. How that looks in daily operation
Why this is not the same as Odoo's own AI
Odoo builds AI into the ERP, and it will build more of it with every release. That is a feature inside one product, configured in its interface, on its release calendar. The control plane sits beside it: it serves the ERP, but mail, documents and search as well, and it keeps model, prompt, budget, measurement and log – the parts that decide quality – outside the system they control.
The honest limit
Odoo can build governance too, and partly does already. So the claim is not that it never will. The claim is where that layer sits – inside the ERP and for the ERP, or outside it, portable and answerable to you. And every AI feature Odoo ships underneath makes our layer cheaper, not obsolete.
What an open core buys you
Two connections that go all the way in.
The argument is easy to make in the abstract. These two are running, and both reach deeper into the system than an interface can: one into the catalogue and the shopping session, the other into stock movements and a physical robot.
OCI punch-out: your customers stay in their own ERP
Large buyers order out of their own procurement system. With an OCI punch-out they jump straight into your catalogue, put a basket together and hand it back into their ERP as an order – without leaving their process. That requires control over session handling, catalogue output and the return format, not just an API to call. It is one of the reasons a B2B store either wins the large accounts or does not.
Warehouse automation: the ERP talks to the robot
An automated small-parts warehouse from Servus Intralogistics hangs directly off the stock movements – around 500 picks a day. Reservations, transfers and completion messages move between Odoo and the warehouse in the same process, not through a nightly file. Physical automation is where an interface-only architecture gets expensive.
What it takes besides the ERP
An Odoo partner delivers Odoo. AI in daily operation needs seven more parts.
None of these is exotic, and none of them is optional. Each line is a question an AI project runs into – and what happens when it was not answered before the project started.
| The question you will ask anyway | What answers it | What happens without it |
|---|---|---|
| How does the AI know what is in our documents? | A vector database and six search services – for data sheets, images, 3D models, records and classification | The model answers from general knowledge instead of your inventory: fluent, confident and wrong. |
| Where do hundreds of thousands of documents live? | Object storage beside the database, not inside it | Attachments grow into the database. Backups and copies become unaffordable, search gets slow. |
| Who supervises the agents? | The control plane: runs, budgets, events, audit trail | Scripts run unwatched. Nobody can say what they did, what they cost, or who released it. |
| Does our data stay with us? | Own servers, network separation, models swappable per workflow | Your orders and prices become training material for a provider you never selected. |
| Does the automation reach the warehouse? | Warehouse robotics on the stock movements themselves – around 500 picks a day in our own operation | AI stops at the screen. The hall keeps working from paper and a nightly file. |
| Do the shops survive the load? | A CDN in front of the storefronts | Every bot surge hits the ERP directly, while somebody is invoicing in it. |
| And when we grow or acquire? | Several companies, countries and currencies in one instance | Every new entity becomes its own project instead of a configuration. |
All seven are in productive use in our own group, which is the only reason we list them. What that costs in licences and operation belongs in a conversation, not on a website – it depends on your size, not on ours.
The named products behind each row: which components, which versions, and why these
Once the decision is Odoo
Same architecture. Different evidence.
Everything above stops separating anyone the moment you choose Odoo: every Odoo partner then builds on the same open core, in the same language, under the same licence. So the honest way to pick one is to ask all of them the same four questions – and to expect answers you can check.
Do you run this yourself?
Not a demo and not a reference customer: your own company, on your own platform, every working day. Ours does – 13 companies in six countries, from industrial distribution to a hardware product with its own app, an integrated B2B store, an automated warehouse, AI in the daily process. Every argument on this page was paid for by us before it was offered to anyone.
Who answers when picking stops at seven in the morning?
Introducing a system and being responsible for it are two different trades. Ours does not end at go-live: operation, monitoring, updates and the answer at the other end of the line are an agreed service with response times, not goodwill.
What happens when AI stops being a project?
Sooner or later somebody has to answer who approved what, what it cost and which model saw which data. The control plane that answers it – approvals, budgets, a usage record, an audit trail – exists because we needed it ourselves before we could offer it to anyone.
And how do we get away from you again?
The question nobody likes being asked. What we build belongs to you: Odoo standard, your own modules in readable Python, your database, your server. Changing partner costs effort, not a rebuild. That is deliberate – we would rather be chosen again than be hard to leave.
The whole solution
Everything you need. Not everything from us.
You get a complete solution – strategy, platform, processes, AI and the operation that follows. What we are not ourselves, we bring in: firewall, network, workplaces and security operations are a trade of their own, with specialists of their own. Making one whole out of it stays our job, not yours.
What we do ourselves
Strategy and its implementation: the platform, your own modules, the processes that run inside them, the AI in daily operation – and the operation of all of it afterwards. That is a full discipline, and it is the one you bring us in for.
What we bring in
Firewall, network, workplaces, virtualisation, mail servers, security operations. There is working knowledge in the house – enough to write the requirement and to judge what is delivered. Not enough to be the specialist. In our own group there is one: Cibex, an IT company for infrastructure, network and security – and one that runs Odoo projects itself, so what the platform needs does not have to be translated first.
What everything has to fit
The platform is the decision the rest follows – that is the one commitment we need from you. What you run today is not swept aside for it: the assessment surveys it first, and the route from there is worked out with you rather than handed to you. Where a wish and the architecture genuinely collide, we explain why the architecture wins instead of quietly bending it.
Your IT partner keeps their scope
Most companies your size already have someone they trust for the network and the workplace. We do not displace them, we work with them – on that same architecture. Where there is nobody, Cibex or another specialist we have worked with for years steps in, so the search does not land on your desk either.
The seam, and who owns it
Two trades mean an interface, and interfaces are where projects come apart. So the line is drawn before the project starts and written down: what runs on which side, who is called for which fault, which response time applies. Coordinating across it is our job – including the answer while it is still unclear whose side a fault sits on. The seam is smallest when the other side already knows the platform, which is why Cibex is usually the first call. That Cibex belongs to the same group is something we say out loud rather than leave you to discover, so you can weigh the recommendation for what it is – and your own partner is just as welcome.
When our answer is the wrong one
Two cases, and we name them in the first conversation rather than after the invoice. If you want everything from a single house on a single contract – hardware, clients, firewall and ERP – then two companies in one group is not that, however short the distance between them. And if the platform is not to be the decision the rest follows, the same applies: that principle is what makes everything above true. We bring the whole solution, but not every trade in it from our own hands, and not without that one commitment.
Six fair objections
The questions we get asked back.
Anyone who takes this argument seriously arrives at these within ten minutes. So we answer them here rather than waiting for the meeting.
What about ERPNext?
A fair question, and the honest answer is that ERPNext is more open than Odoo: fully GPLv3, Python on the Frappe framework, self-hostable, without a proprietary tier. On the licence argument alone it wins. What differs is the ground you build on – localisation and accounting depth for German-speaking Europe, and the platform we have already built on top: more than a hundred of our own modules, procurement punch-out, warehouse automation, AI productive in daily operations. The licence is not the difference. What stands on it is.
Odoo now ships AI itself.
Good news, and no accident – it is the platform we bet on. Odoo 19 brings an assistant, configurable agents and document capture, and that list will grow with every release. Which is exactly why our answer is not a longer feature list but a layer: model, prompt, budget, measurement and log live outside the ERP, serve mail and documents as well, and stay yours when a roadmap turns. Whatever Odoo ships underneath makes that layer cheaper to run, not unnecessary – and where its built-in AI already does the job, we say so instead of selling you ours.
Why not just have AI build it for us?
Because AI multiplies output on a substrate; it does not produce one. What you would be asking for is twenty years of domain knowledge cast into software – double-entry accounting, stock valuation, tax logic, an audit trail that survives an audit. The difficulty is not that a model cannot write code. It is that generated software has nothing to be wrong against. A landing page you can check by looking at it; a valuation method surfaces in the annual accounts, months later. And it has no source that keeps maintaining it: no security patches, no e-invoicing mandate, no country localisation, no upgrade path, and nobody else who knows it. We do build with AI – more than a hundred modules of our own, with tests, in a repository, on top of a standard that can prove us wrong. That is the difference: not whether AI writes the code, but whether anything can contradict it.
And what does that cost us at the next Odoo release?
Something – and we say so before the quote rather than after it. Anyone who hooks into standard methods has to check at every major release whether the assumptions underneath still hold. That is the flip side of exactly the depth you choose an open platform for. Two things keep it manageable: the effort sits in your repository, versioned and with tests – you decide when you pay it, not a vendor's release calendar. And we pay it ourselves, for more than a hundred modules, at every release. With a sealed core that bill does not disappear – it only moves to where you wait instead of deciding.
A specialist service already reads our orders.
Then keep it, if the handover works. Reading a document has become the easy part; the money sits in what comes after – matching against your prices, conditions and lead times, the check on the record itself, the approval, and a trail that still holds up in an audit. In a separate system that means a second truth to reconcile and a second login for the people doing the work. Ours writes into the record it belongs to. That is worth exactly what reconciling costs you today – a number your team can put on the table in ten minutes.
We are a Microsoft house.
Most of our customers are, and it changes less than you would think. Odoo replaces the ERP, not the workplace – mail, documents and calls stay exactly where they are. The decision on the table is which system your processes live in, and there the question from the top of this page comes back: who is allowed to change it tomorrow, you or your vendor?
Sources on Odoo's own AI, checked July 2026: Odoo AI documentation · Odoo on AI agents
Honest limits
When you should not choose us.
An open platform is not the right answer to every situation. These three cases are real, and we will say so in the first conversation rather than after the invoice.
You need to be live in weeks
If your processes fit a standard and speed beats fit, a standard SaaS suite gets you there faster and cheaper. A platform earns its keep from the point where the standard stops fitting.
You need worldwide localisation
Where dozens of country localisations and deep regulatory requirements shape the daily work, the large enterprise suites have an ecosystem lead that we will not talk away. Headcount alone is not that line – where the weight sits in companies, countries and processes, we carry it, and how we operate at that size is set out separately.
You do not want the responsibility
An open platform means decisions: architecture, extensions, operations. We carry them with you, but they do not disappear. Whoever wants to leave everything with one vendor is better served there.
How you find out
Exactly this is what the assessment is for. It ends with a recommendation – including the recommendation not to do the project, if that is the honest answer.
The next step