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 which one still fits 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 change, operated where you decide. This is the road Corelane takes with Odoo – and the reason your own logic can live inside the 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 the software?
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; the Odoo core is open under 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 · PYPL index · ERPNext licence. Odoo is open core: the community core is open source, the enterprise additions are not. We say so because it matters for the point below.
The substrate
Two decisions you only make once.
Language and database are the two choices an ERP cannot walk back. Everything else can be rebuilt; these two decide for a decade who can work on your system and what your data costs you.
Python: the language people actually know
Python leads the PYPL index worldwide with 47.5 %, more than four times second-placed Java at 11.4 %. In Germany the gap is wider still: 57.3 % against 13.6 % for C/C++ (July 2026). PYPL measures how often tutorials for a language are searched for, so it is a measure of popularity, not of installed base. For you that is the more useful number: it says how many people you can hire and how alive the ecosystem is.
And the language AI is written in
The same choice pays a second time. Model SDKs, orchestration frameworks, vector databases and the tool protocols around them are written in Python first and ported elsewhere later, if at all. An ERP written in Python does not need a bridge to any of it.
PostgreSQL: no licence on your own data
Your data lives in PostgreSQL – open licence, no database licence cost, and proven far beyond the volumes a mid-sized company produces. Backup, replication, analytics and archiving work with standard tools that any competent administrator already knows.
Why that is not a detail
A proprietary database is a second dependency next to the application: its own licence, its own specialists, its own upgrade calendar. S/4HANA, for instance, runs on SAP HANA. With PostgreSQL the question does not arise – and neither does the bill.
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. A closed system can give you the first two through an interface. The third is where it ends.
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.
And the interface
The layer people actually see.
The AI argument above only works if the result can appear where the work happens. That is a frontend question, so it belongs here.
Why the check can sit on the invoice
Odoo's interface is built on Owl, its own web library – lean, written in TypeScript, borrowing its component model from React and its reactivity from Vue. What matters commercially is not the name but that its source ships with the product. Any component can be patched, any view replaced. The AI-draft ribbon on the order and the check panel beside the invoice PDF exist because of that. Without it, AI results end up in a separate portal – exactly what we argue against.
And the catch, before you ask
Owl is specific to Odoo. The pool of developers who already know it is smaller than for React or Vue – you are buying into one ecosystem. Two things soften it: it is TypeScript with concepts any competent frontend developer recognises, so the ramp-up is short, and it is open source, so nobody can take it away. But it is a trade-off, and we would rather name it than have you find it.
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.
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.
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.
Four 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 for questions, drafts and simple extraction that is often enough. Out of the box it does not run your order intake end to end: matching against your prices and lead times, an approval that has to happen before anything is posted, budgets and an audit trail per workflow, a model you pick per task. That is the part we build – and every feature Odoo adds underneath makes it cheaper, not obsolete.
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 are a group with thousands of users
At that scale, with worldwide localisation and deep regulatory requirements, the large enterprise suites have an ecosystem lead that we will not talk away.
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