Licensing, Editions, and Why It Constrains Your Code
Licensing sounds like a procurement problem. It is not — it regularly determines what you are allowed to build. Developers who ignore it create six-figure audit liabilities.
The main licence metrics
| Metric | How it’s counted | Used by |
|---|---|---|
| Named user | Every distinct human with credentials, by role tier | SAP, Dynamics, NetSuite |
| Concurrent user | Peak simultaneous sessions | Older on-prem, some Tier-3 |
| Full vs limited/self-service user | Full = create transactions; limited = approve/view/enter time | SAP, Dynamics 365, NetSuite |
| Consumption / metered | Documents, orders, transactions, revenue processed | Some cloud ERPs, tax engines |
| Revenue-based | % or band of company revenue | SAP “digital access” partly, some mid-market |
| Module / SKU | Per functional module activated | Nearly all |
| Core / capacity | CPU cores, HANA memory GB | Databases, on-prem infra |
| Indirect / digital access | Documents created by non-human access via API | SAP notably |
The indirect access trap (learn this one)
Scenario: You build a customer portal. Customers log in to your portal, not to the ERP. Your portal calls the ERP API to create sales orders.
The claim: Those customers are “using” the ERP indirectly. Historically vendors billed for named users. SAP’s 2018 model changed this to Digital Access, charging per document created by non-human/indirect means — sales documents, purchase documents, invoices, material documents, service documents, etc.
What it means for you:
- Every API integration you build may have a licence cost per document.
- Batching 100 line items into one document may be cheaper than 100 documents.
- An over-chatty integration that creates helper documents can be an expensive mistake.
- Read-only integrations are usually free; creation is what’s counted.
Always ask the commercial owner before designing a high-volume write integration.
Editions and functional gating
Vendors gate features by edition. Two consequences:
- A feature you see in docs may not exist in the customer’s tenant.
- A demo environment may have modules production does not.
Examples of typical gating:
| Product | Edition split |
|---|---|
| Dynamics 365 | Business Central Essentials vs Premium (Premium adds Manufacturing + Service) |
| NetSuite | Starter / Mid-market / Enterprise + SuiteApps per module |
| Odoo | Community (LGPL, free) vs Enterprise (studio, accounting depth, apps) |
| SAP S/4HANA Cloud | Public vs Private edition; huge difference in extensibility |
| Acumatica | Resource-based (transaction volume) rather than per-user — unusual, and a selling point |
Open-source ERP licensing
| Product | Licence | Catch |
|---|---|---|
| Odoo Community | LGPLv3 | Many valuable apps are Enterprise-only; hosting on odoo.sh is paid |
| ERPNext / Frappe | GPLv3 | Copyleft — if you distribute a modified version, you must publish. SaaS use generally isn’t “distribution”, but check |
| Dolibarr | GPLv3 | Smaller ecosystem |
| Apache OFBiz | Apache 2.0 | Permissive, but the project is a framework more than a product |
| Tryton | GPLv3 | Fork of early OpenERP, clean codebase |
If you are building a product on an open-source ERP, get legal advice on copyleft before committing. The difference between LGPL (Odoo) and GPL (ERPNext) matters a great deal for a commercial derivative.
Support tiers and end-of-life
Every ERP has a maintenance lifecycle. Two dates matter:
- End of mainstream maintenance — no more new features or standard support
- End of extended maintenance — no more security patches; you are on your own
The one everyone talks about: SAP ECC mainstream maintenance ends 2027, with extended support to 2030 at a premium. This is driving the largest coordinated ERP migration in history.
Practical rule: know your product’s EOL date. If it’s inside 3 years, every architecture decision should ask “does this survive the migration?”
Sandbox and non-production licensing
- Non-prod environments usually need licences too, often at reduced cost, sometimes counted against your total.
- Some SaaS vendors allocate a fixed number of sandboxes per tier; extra sandboxes cost money.
- This is why you rarely get “just spin up an environment” in ERP land. Environment scarcity shapes the delivery process — see Environments and Release Management.
Licence audits
Vendors audit. Common findings:
- Users sharing credentials (also a SoD/audit violation)
- Users assigned a Full licence who only approve timesheets
- Service/integration accounts creating documents without digital-access licences
- Test users left active in production
- Modules activated in config but not licensed
Developers create three of those five. Keep integration accounts named, documented, and minimal.
Practical rules for developers
- Ask what licence metric the customer is on before designing an integration.
- Never create a document you don’t need. Helper/staging documents can carry cost.
- Batch where the domain allows — fewer, larger documents.
- Read-first, write-minimal integration design is also cheaper.
- Use one named service account per interface, not a shared “API user”.
- Don’t activate modules to “see what they do” in a licensed tenant.