Architecture you can check, not a promise
IT does not choose an ERP by its module count but by what it will have to maintain for five years: whether an API exists or integration goes through the database, whether customisation lives in the core or beside it, whether tenant isolation is architecture or a column, and whether the exit exists as a feature or as a quotation. NG One answers those questions with decisions that sit in the foundation, because none of them can be added later without rewriting the core — REST with OpenAPI over everything, clean-core extensions with versioned configuration, RLS multitenancy at database level, and a tenant export that is a button. Every one of those claims is checked from a terminal, not from a slide.
- REST + OpenAPI over everything
- Clean-core extensions
- RLS multitenancy
- OIDC / OAuth 2.1
- On-prem, cloud or hybrid
- MCP server on the same API
What IT inherits when the decision was made without them
These costs do not appear in the proposal and are paid every year — usually in the hours of the people who leave because of them.
An ERP with no API — integration through the database or a file at midnight
When the API does not exist, or covers five endpoints out of fifty, integration means writing directly into someone else's tables or exchanging a file on a nightly job. The first breaks with every upgrade; the second means the data is twelve hours late and the error surfaces in the morning. IT is then not an integrator but a permanent on-call rota, and every new connection widens the surface that can fail.
Every change is a “custom” that locks the version
Customisation happens in the core, so two years later an upgrade means retesting everything and renegotiating the price. The system stays on the version it is on, legislation is handled with a patch, and every subsequent change costs more than the last. The company ends up paying to stay where it is — and calls that stability.
Vendor lock-in discovered only on the way out
The data is yours, says the contract. And then exporting all of it — with structure, attachments and history — becomes a project with a quotation and a deadline. When the exit is expensive, every negotiating position is weak, and both sides know it. A system you cannot leave is not a partner but a position.
On-prem is a requirement and the product only knows cloud (or the reverse)
For some companies on-prem is not a whim but a requirement — proprietary data, a public-sector contract, an internal policy. For others cloud is the only sensible choice because they have no team. A product that knows only one solves this with an exception: a special installation maintained by hand that falls behind version by version.
Multitenancy reduced to a column and a hope
Isolation that rests on every query being written carefully is not isolation but an agreement. One forgotten `where` and one client's data appears at another — and that is discovered at the worst possible moment. On top of it, the ERP often keeps its own user list that knows nothing about SSO, so the account of someone who left six months ago still works.
How NG One answers
With decisions that cannot be added later without rewriting the core — so they were made in the foundation, before the first line of business logic, not in the proposal. Behind each one sits an endpoint, a screen or a policy in the database.
REST + OpenAPI over everything, not over a selection
API-first is the foundation of the system: REST with an OpenAPI description over the whole of it — all nine business spaces and the roughly sixty technical domains beneath them — a job queue for long-running work, and a notification layer (email, SMS, Viber, push). Alongside it: an import/export framework with a template builder, column-to-attribute mapping, a dry-run diff and per-row errors, plus Excel export from every list. Integration does not go through the database because it does not have to — and an OpenAPI description means the client is generated rather than hand-written.
Clean-core extensions and versioned configuration
Customisation lives beside the core, not inside it — one of five decisions that cannot be retrofitted, which is why it sits in the foundation. Settings carry UI metadata, config sets and a config audit, so a consultant provisions without a developer. Configuration is versioned with validity dates, and a transaction references the rule version it was created under — a posting from two years ago is explained by the rule that was in force then, not by today's. The consequence measured in money: an upgrade does not mean retesting every customisation.
RLS multitenancy and a hard control/data boundary
Isolation is enforced through row-level security in the multi-tenant core, at database level — not through an application filter. The Platform Control Center is a separate product with a hard boundary between the control and data planes: platform staff do not see business data. Support access exists, but only with the client's approval and under audit. Above it sits six-layer authorisation — roles, data scope, approval limits, SoD, maker-checker and delegation — and it applies to every channel equally: to the UI, to the API and to the AI.
Identity: OIDC on the Spring Authorization Server
Identity rests on the Spring Authorization Server with OAuth 2.1 and OIDC, JWKS, and a QR login grant for terminals and handheld devices. Users come from your identity source rather than from the ERP's parallel list that does not know somebody left. For warehouse and shop-floor work this is not a formality: a device shared between shifts needs a login that is as fast as it is secure.
On-prem, cloud or hybrid — with no separate branch
The on-prem licence is part of the licensing and entitlement framework, together with packages, licences per user type, feature entitlements, AI credits, usage metering and the trial/expiry/grace cycle. Integrations are configured per tenant and legal entity through the console — secrets vault, demo and production profiles, connection tests, health — so a consultant configures without a developer. On-prem is not an exception maintained by hand but a delivery mode: same version, same configuration, same upgrade.
An MCP server and AI that can be audited
The MCP server exposes the same API-first layer our own UI uses, under the same permissions and the same tenant isolation that apply to a person — an agent gets no side door. Beneath it sits a model gateway that supports local models, RAG over pgvector inside your tenant, and AI audit with guardrails: every model call carries a trace, a permission and a visible cost. The AI evaluation framework runs in CI with golden sets, tenant-isolation tests and prompt-injection checks — evaluation is part of the build, not of demo day.
Implementation from IT's side
The order we propose and the artefacts you get at each step. None of it depends on you staying with us.
- Step 1
Assessment
Before any module demo — architecture, data and security. This is the conversation where numbers are asked for, not slides.
- Data model, dimensions and chart of accounts
- Inventory of integrations and data-flow directions
- Threat model and the ASVS frame of the security programme
- Encryption of sensitive data and anonymisation
- Step 2
Environments and configuration
Tenants and environments are set up through the console rather than through a request to the vendor.
- Tenants and environments via the Platform Control Center
- Config sets and provisioning without a developer
- Secrets vault, demo and production profiles, connection tests
- Feature flags and per-tenant configurability
- Step 3
Integrations
Connected in the domain, separated at the integration layer. When one service changes, the whole chain does not fall.
- REST + OpenAPI over everything; a job queue for long work
- Adapters per service with their own lifecycles
- SEF, invoice registry, banks, central bank rates, fiscalisation
- Notifications: email, SMS, Viber, push
- Step 4
Extensions
What is specific to you lives beside the core — so that upgrading stays a routine rather than a project.
- Clean-core extensions instead of changes in the core
- Settings with UI metadata and a config audit
- Versioned rules with validity dates
- Document framework: type registry and state machines
- Step 5
Migration and cutover
Migration is its own step with its own artefacts — and with a rollback that is part of the plan, not an improvisation.
- Templates: partners, items, opening balances, stock by lot
- Mapping of old codes and a trial migration
- Reconciliation with control totals before cutover
- Rollback as part of the plan, not as an improvisation
- Step 6
Operations and exit
Production operations and, just as importantly, the way out. An exit that exists is the only proof there is no lock-in.
- OTel telemetry, backup and PITR with a restore drill
- Antivirus, legal hold, support access on approval and audited
- Tenant export and tenant shutdown as a feature
- Penetration testing plan
The spaces that carry this solution
A solution is neither a separate product nor a separate licence. It is the same system seen from one angle, and these business spaces carry most of the work this page describes.
Documents and processes
One document kernel, one approval path and one decision trail — underneath every document in the system.
30 capabilitiesInsights, automation and AI
The command center for decisions — evidence behind every insight, a trail behind every automation.
30 capabilities
Questions about this solution
Scope, boundaries, and the rules this entry point works by.
Is there an API for everything, or only for what is convenient?
API-first is the foundation of the system, and that means REST with an OpenAPI description over the whole of it — all nine business spaces and the roughly sixty technical domains beneath them — rather than over selected modules. Alongside it come a job queue for long-running work and a notification layer, an import/export framework with a template builder, column-to-attribute mapping, a dry-run diff and per-row errors, and Excel export from every list. The practical consequence: the client is generated from the OpenAPI description instead of hand-written, and integration need not go through the database because an alternative exists. The check that is worth more than any claim: our own UI runs on that same API — there is no private channel you cannot call.
Does custom development block upgrades?
That is exactly what clean core prevents, and it is one of five decisions that cannot be retrofitted — not because it sounds good, but because the decision about where customisation lives cannot be changed once half the system is written in the core. Customisations live beside the core, configuration is versioned with validity dates and has its own audit, and settings carry UI metadata so a consultant provisions without a developer. The consequence measured in money: an upgrade does not trigger retesting of every customisation, so the system does not stay locked on a version somebody once wanted.
Can NG One run on-premise?
Yes — the on-prem licence is part of the licensing and entitlement framework, together with packages, licences per user type, feature entitlements, AI credits, usage metering and the trial/expiry/grace cycle. What matters is that this is not an exception maintained by hand but a delivery mode anticipated in the foundation: integrations are configured per tenant and legal entity through the console (secrets vault, demo and production profiles, connection tests, health), and the AI layer runs through a model gateway that supports local models — usually the decisive question for on-prem. Hybrid follows from the same framework rather than being a third branch of code that falls behind version by version.
What does leaving look like — is there a tenant export?
There is, and it deliberately sits inside production operations and the security programme rather than as a line in a professional-services price list. Tenant export and tenant shutdown stand in the same series as backup and PITR with a restore drill, legal hold, anonymisation, and support access on client approval and under audit. The position behind it is simple: an exit that exists is the only proof there is no lock-in, and a system you cannot leave is not a partner but a position. The restore drill is there for the same reason — a backup that has never been restored is not a backup but a belief.
How is data isolated and who on your side can see it?
Isolation runs through row-level security in the multi-tenant core — at database level, not through an application filter that depends on every query being written carefully. The Platform Control Center is a separate product with a hard boundary between the control and data planes: platform staff do not see business data. Support access exists, but with the client's approval and under audit, and every platform action carries its trace and maker-checker. Above it sits six-layer authorisation — roles, data scope, approval limits, SoD, maker-checker and delegation — plus an immutable journal and a change log. The same holds for AI: the copilot sees nothing the user who asked it could not see themselves.
What about MCP and AI — does our data go to an external model?
It goes where you say it goes. Beneath the AI layer sits a model gateway that supports local models, so the choice of model is your decision rather than our assumption — for on-prem that is usually the only acceptable answer. The MCP server exposes the same API-first layer our own UI uses, under the same permissions and the same tenant isolation that apply to a person: an agent gets no side door. The control is visible — AI audit, permissions and consumption are a screen in the insights, automation and AI space, RAG runs over pgvector inside your tenant, and the AI evaluation framework runs in CI with golden sets, tenant-isolation tests and prompt-injection checks. And one rule that settles most of the worry: an AI suggestion enters as a draft a human confirms, with its evidence and a jump to the source record — never as a posting that happened while you were not looking.
Check the architecture before you look at modules
Book a technical review. We walk the API and its OpenAPI description, the isolation model, clean-core extensions, the delivery mode and the migration plan — from the system, not from a deck. Bring your list of integrations: that is the one we open first.