Why ERP Implementations Fail — and Why an API Changes the Odds

Seven failure patterns that recur across ERP projects, the countermeasure for each, and a factual account of which of them an API-first accounting core takes off the table.

ERP implementations fail for a short list of reasons that repeat from project to project: scope that keeps growing, customisation that replaces the standard process, data nobody cleaned, no one with the authority to decide, a single cutover weekend that cannot be undone, dependence on one vendor's roadmap, and tax or filing requirements discovered after go-live. None of these is a technology problem in the narrow sense. Each is a decision made, or not made, before the first screen is configured.

This article goes through those causes one at a time with what to do instead. It then makes a specific, limited argument: when the accounting core of the system is an API that your own software integrates with, several of these causes are removed from the project rather than mitigated, because the work they attach to no longer exists.

The recurring causes

1. Scope that is discovered rather than decided

A project signed for "finance and inventory" absorbs purchasing approvals, project costing, a customer portal and a reporting layer because each one is "nearly the same thing". The budget and date were set for the original scope.

Instead: write the acceptance list first. The list of documents, reports and filings that must come out of the new system correctly for one closed month is the scope. Anything not on it is a second project.

2. Customisation that recreates the old system

The most expensive sentence in an ERP project is "the new system has to do it the way we do it now". Every customisation has to be specified, built, tested, documented and re-tested on every upgrade. Projects that start by replicating the old screens tend to never finish the replication.

Instead: accept the vendor's standard process for every flow where the business is not genuinely different, and keep a written list of the exceptions with the reason for each. If the list is long, the product is wrong, not the configuration.

3. Data nobody cleaned

Duplicate partners, items without units, a chart of accounts with hundreds of dormant codes, open invoices that were settled years ago but never matched. Migration cannot run faster than the cleanup, and the cleanup is done by people who also have month-end to close.

Instead: clean before the project starts. Decide whether to move full history or opening balances plus open items. Validate the migration package until it passes without errors before writing a single row into the new system.

4. No process owner

When every decision goes to a steering committee, decisions take weeks. When nobody owns the sales-to-cash process end to end, the sales module and the receivables module are configured by different people with different assumptions.

Instead: one named owner per process with the authority to decide, and a weekly decision log that the vendor and the team both work from.

5. Big-bang cutover with no way back

Switching every entity and every module on one weekend concentrates all risk at one point. If the first month-end close fails, there is no old system to fall back to and no partial rollout to learn from.

Instead: cut over at a period boundary with a reconciled closing trial balance, keep the old system readable, and where there are several entities, go live with one first.

6. Vendor lock-in that shows up at year three

Data exports that need a professional-services engagement, integrations that only work through the vendor's own middleware, per-user pricing that grows with headcount rather than with the work done, and a roadmap you cannot influence. None of this is visible at signing; all of it is visible at renewal.

Instead: before signing, export everything from a trial tenant and check what comes out. Check whether the API covers every operation the screens do, or only a subset. Read the price list for the next tier, not just the one you are buying.

7. Compliance discovered after go-live

A new VAT registration in another member state, an e-invoicing mandate that starts next January, a filing format the local tax administration changed. In a traditional project each of these is either a partner engagement or a customisation, and each arrives on its own calendar.

Instead: list every filing and every VAT scheme the company is subject to, per country, before selection, and ask the vendor to show the output file for each one from a demo tenant. "Supports country X" is a sales claim; a generated return is evidence.

What an API changes

The argument here is narrow. An API-first accounting core does not make an ERP project succeed. It removes specific pieces of work from the project, and the failure causes attached to those pieces go with them. The following are things Nordlet does today, described as the product behaves rather than as outcomes it promises.

The integration is tested before you sign. A sandbox company is created in one call, behaves exactly like a real company with the same modules and endpoints, and costs the same metered rate as real usage. The pre-production test plan is a reproducible test, not a demo. If the integration does not work in the sandbox, you have learned that before any commitment, which is the opposite order from a traditional implementation where integration is the second-to-last phase.

Retries cannot create duplicates. Every mutating call takes an Idempotency-Key header. The same key with the same payload replays the stored response; the same key with a different payload is rejected with idempotency_key_reuse. A whole class of integration defects, the double invoice after a network timeout, cannot occur, and so cannot be found in hypercare. The idempotency glossary entry covers the mechanics.

Events replace batch syncs. Webhooks are written to a transactional outbox in the same database transaction as the change, so a rolled-back document never emits an event and no event is lost. Your system reacts to sale_invoice.paid when it happens; there is no nightly file to reconcile and no reconciliation logic to write and test.

The ledger catches integration bugs for you. The database refuses an unbalanced journal entry. A posted entry is not edited; corrections are reversals linked to the original. A posting dated into a locked period is rejected with a 409. These constraints are what an immutable ledger means in practice, and they turn silent data problems into loud API errors during development.

VAT rules and filing formats are the vendor's maintenance, not your customisation. The EU VAT engine resolves place of supply, reverse charge, OSS, IOSS and the deemed-supplier rule and returns the legal basis with each answer. Filing formats for 30 countries are registered in the product; the filing support table says for each deadline whether Nordlet sends the file, builds it for upload, or shows the figures to key in. When a format changes, the change ships as a product update to every company, and product changes are listed in the changelog. Compliance discovered after go-live (cause 7) becomes a question you can answer from a public page before selection.

Pricing does not depend on seats. Plans are metered by request, with every module and the full API in every plan and unlimited users and companies. The cost grows with the work the system does, not with the number of people who log in, and there is no feature tier to migrate to later. That addresses one component of lock-in (cause 6); it does not address the others, which is why the next section exists.

Data comes out the way it went in. Reports are generated as XLSX, PDF or JSON. Ledger exports exist in DATEV, FEC and SIE formats for the countries that use them. The web app has no private endpoints, so anything you can see on a screen you can fetch through the API. The export test from cause 6 can be run in the sandbox on day one.

What an API does not change

Master data is still yours to clean. The migration importer validates and refuses bad packages; it does not fix them.
Process ownership is still a staffing decision. An API makes the "who decides" question smaller, because there is less to configure, but it does not answer it.
Someone writes code. The configuration project is replaced by an integration project done by developers. If your team has no developers, this shape of product moves work rather than removing it.
Scope outside accounting is still scope. Warehouse scheduling, manufacturing planning and CRM beyond leads are either separate Nordlet modules you integrate the same way or separate systems next to it, and the integration between those is still your project.
Vendor maturity. Nordlet is in early access in 2026 and onboarding design partners. A young vendor is a risk factor that a sandbox test does not remove; it only makes the product's current state measurable.

A short checklist before you sign anything

Write the acceptance list: documents, reports, filings for one closed month.
Clean master data and decide the history question before the project starts.
Name one owner per process.
Run the integration in a sandbox and keep the test suite.
Export everything from the trial tenant and inspect the files.
For each country, see the generated filing, not the feature list.
Read the price of the tier above the one you are buying, and the price of leaving.

FAQ

What is the single most common reason ERP projects fail?

Scope that grows after the budget and date were fixed, usually through customisation requests that recreate the old system. Data quality is a close second and is the most common cause of a slipped go-live date.

Does choosing a cloud ERP avoid these failures?

Hosting changes who runs the servers. It does not change scope, customisation, data quality or ownership. Cloud products do make upgrades the vendor's job, which removes one long-term cost of customisation.

How does an API-first system reduce implementation risk?

It moves integration to the start of the project where it can be tested in a sandbox before commitment, it makes retries and events safe by construction, and it ships tax rules and filing formats as product features rather than project customisations. It does not clean your data or decide your processes.

Is an API-first accounting core an ERP?

It is the financial core of one: ledger, documents, bank, tax, filings, and in Nordlet's case also inventory, production, payroll, fixed assets and e-commerce orders. The SaaS ERP article goes through the distinction in detail.

What should we test in the sandbox?

Issue an invoice and read the journal entry. Send the same request twice and count the invoices. Post into a locked period and confirm the 409. Issue a credit note and check the reversal. Generate the VAT return for the sandbox company's country. Export the ledger. If those pass, the accounting core works; the remaining risk is in your data and your other systems.