Why ERP gets expensive later (not at go-live)

Most ERP projects don’t fail on day one. They fail quietly after go-live — when the business starts changing faster than the system can follow. The first year looks fine: documents exist, roles are set, reporting “kind of” works. Then reality arrives: new discount logic, new sales channels, new approval routes, new contract types, new profitability views, new operational constraints.

The uncomfortable pattern is simple: in many ERP setups, every meaningful business change becomes a software project. And if a change requires a project, it also requires timeline, budget, testing cycles, and someone “who knows how it works”. That’s the real cost driver — not the license line.

What “ERP that doesn’t break when business changes” actually means

Founders don’t need buzzwords — they need predictability. A change-friendly ERP is not a prettier UI. It’s an ERP where business rules live as rules (clear dependencies, constraints, calculations), not as scattered custom code, hidden processing steps, and fragile report formulas.

  • Bad ERP experience: change a rule → break three reports → patch integrations → discover edge cases → repeat.
  • Good ERP experience: change a rule → the system recalculates consistently → reporting stays aligned.

Comparison: what typically happens in 1C / SAP / Dynamics / Odoo

This is not a “best ERP” ranking. It’s a reality check: what often happens after 12–24 months in real projects, once customizations accumulate and “business-as-usual change” becomes routine.

Quick note on SAP: yes, SAP has been moving towards extension models (BTP, side-by-side, modern UI layers). But in practice, many real landscapes still depend heavily on legacy customization patterns — and the cost of change remains a core management issue.
Criteria 1C (typical) SAP (classic) Dynamics (typical) Odoo / open-source ERP
Time-to-start Fast Slow Medium Fast / Medium
Cost of entry Low / Medium High High Low / Medium
Where business logic ends up Custom modules & “processing” layers Config + custom extensions Configuration + extensions Custom modules
Change cost after 2 years Often rising quickly Often high Often high Depends: upgrades can be painful
Vendor / team lock-in risk High (key people) Very high (ecosystem + cost) High High (custom code owners)
Can “AI as a junior” help maintain it? Hard if logic is scattered Hard without deep context Medium Medium (if modular discipline exists)

Mini-cases: the changes that look small but cost real money

Case 1 — discounts with 5 conditions (and they change weekly)

The business asks for pricing rules based on client tier, region, product group, volume, payment terms — and exceptions. In many ERP setups, this turns into a chain of special cases. Reports drift. Managers “work around” the system.

A change-friendly design keeps pricing as explicit rule logic — consistent across documents, calculations, and reporting.

Case 2 — approvals that reflect real management (not the UI)

“If amount > X → CFO approval. If the client is new → risk review. If overdue > N days → accounting approval.” These are normal operational rules. Yet many systems implement approvals as UI workflows disconnected from data and constraints. Result: stuck statuses, unclear responsibility, invisible bottlenecks.

Robust design treats approvals as policy rules tied to data conditions — not a fragile layer of buttons.

Case 3 — profitability that matches reality (not just reports)

This is the founder moment: “Why does the report show profit but cash says otherwise?” The root cause is usually scattered logic: partial cost allocation, inconsistent discount handling, logistic costs applied elsewhere, retroactive adjustments, or “re-post to fix”.

If core calculations are consistent and derived from the same rules, profitability becomes explainable — and fixable.

Case 4 — adding a new entity (subscription / service contract / bundle)

“Just add a new document type” sounds easy. In practice, a new entity must participate in reporting, pricing, approvals, KPIs, constraints, and audit logic. If logic is scattered, every new entity triggers a cascade of changes.

The AI angle founders actually care about

Not “a chatbot in ERP”. The useful AI story is simpler: business logic should be readable enough that an analyst — assisted by AI (acting like a junior engineer) — can implement and validate many changes without becoming hostage to a single developer or integrator.

Reality check: AI can’t reliably help when your ERP rules are scattered across custom code, hidden processing steps, one-off report formulas, and undocumented “special cases”. AI becomes useful when logic is structured as explicit rules and dependencies.

Founder checklist: are you already in the danger zone?

Tick what matches your situation:

  • Meaningful changes take 2–6 weeks “for some reason”.
  • Numbers differ across reports, exports, and dashboards.
  • The team avoids touching rules (“it might break something”).
  • 1–2 people “know everything” and become a bottleneck.
  • Changes require full-cycle retesting across unrelated areas.
  • Integrations duplicate logic and create data drift.
  • Part of operations works outside ERP because it’s faster.
  • New business ideas quickly turn into “not possible”.

If you have 4+ items: you don’t have a “bad ERP”. You have a system where the cost of change is becoming your hidden tax.

What to do (without buzzwords)

1) Evaluate ERP by the cost of change, not by feature lists

The right question isn’t “does it support feature X”. It’s: how fast can we change business rules safely in six months?

2) Ask for three live demos of “hard changes”

  1. Add a new discount rule with a new condition.
  2. Change an approval route based on policy logic.
  3. Add a new entity that must appear in reports and KPIs.

If the answer is always “we need a separate project / discovery / a developer for that” — treat that as a real signal.

3) Avoid lock-in by demanding explicit business logic

Ask: where do rules live? How are dependencies tracked? How do we ensure reports and calculations remain aligned? If nobody can explain it simply, you’re buying opacity.

Sources & further reading

Keep exploring:

More practical notes about ERP architecture, modular systems, and change-friendly automation.