What ERP Actually Is

The one-sentence definition

An ERP (Enterprise Resource Planning) system is one shared transactional database plus the business logic that keeps it consistent, so that every department records the same event once and sees the same numbers.

That’s it. Everything else — modules, screens, workflows, reports — is decoration on top of that idea.

The developer’s definition

If you strip the marketing away, an ERP is:

Layer What it really is
Data model A few hundred to a few thousand tables, heavily normalised, with strict referential integrity
Posting engine Code that turns a business event into immutable accounting entries
Document flow A chain of linked documents (order → delivery → invoice → payment) with status propagation
Master data Slowly-changing reference entities everything else points at
Configuration Behaviour expressed as data, not code, so one codebase serves many companies
Extensibility Sanctioned hooks so customers can change behaviour without forking
Reporting Read models over the transactional truth

The single defining constraint

In an ERP, the database is the product.

In a typical web app, you can drop a table, rename a column, or backfill data on a Sunday night. In an ERP you often cannot, because:

  • Posted financial documents are legally immutable in most jurisdictions.
  • Auditors need to reconstruct the state of the books as of any past date.
  • A wrong number is not a bug, it is a misstatement — potentially a regulatory event.
  • Downstream systems (banks, tax authorities, customers) already consumed those numbers.

This constraint drives almost every unusual pattern you will meet: reversal instead of delete, effective-dated master data, period locks, document numbering rules, audit trails on everything.

What “enterprise resource” means

The “resources” being planned are the classic four:

  1. Money — cash, receivables, payables, capital
  2. Materials — inventory, components, finished goods
  3. Capacity — machines, work centres, production hours
  4. People — labour, skills, time

ERP’s original promise was to plan those four together instead of in four separate silos. That’s why the finance module and the manufacturing module talk to each other: a production order both consumes capacity and creates accounting entries.

The integration promise

The whole value proposition is: enter data once, use it everywhere.

A single goods receipt:

  • Increases inventory quantity (Inventory)
  • Increases inventory value and creates a GR/IR liability (Finance)
  • Closes the open quantity on the purchase order (Procurement)
  • Enables the supplier invoice to be matched (Accounts Payable)
  • Updates the material availability date (Planning)
  • Triggers a quality inspection lot (Quality)
  • Feeds the warehouse put-away task (Warehousing)

One user action, seven consequences, all in one transaction. If you understand why those seven things must happen atomically, you understand ERP.

What makes ERP different from other software

Normal SaaS ERP
Fast iteration, ship daily Quarterly/annual release trains, regression-heavy
Delete/update freely Append-only, reverse-don’t-delete
One tenant’s bug is one tenant’s problem One posting bug can misstate a year of accounts
Product decides the workflow The customer’s legal and audit reality decides
Feature flags Configuration tables, thousands of them
Devs own the domain A functional consultant owns the domain, you implement it
Data migration is a one-off Data migration is a project phase with its own team

The three ways companies get an ERP

  1. Buy a suite and configure it — SAP, Oracle, Dynamics, NetSuite, Odoo. Most common. You become a platform developer.
  2. Buy a suite and heavily customise it — the danger zone; you inherit an upgrade problem forever.
  3. Build one — rare, usually for a niche vertical where no product fits, or as a SaaS product for a market segment.

Your career looks very different in each. See Who Works on ERP.

The uncomfortable truths

  • Most ERP projects fail to hit their original scope, time, or budget. The failure is almost always organisational, not technical.
  • The hardest part is not code, it is agreement. Getting finance, ops, and sales to agree on one definition of “customer” or “revenue” takes months.
  • Customisation is debt with compound interest. Every custom field, screen, and hook is something you re-test and possibly re-write at every upgrade.
  • “The system is wrong” almost always means “the process is wrong” or “the data is wrong.”

Why this is a good career

  • The domain knowledge compounds and does not expire. Double-entry accounting has been stable since 1494.
  • Barriers to entry are real — you need both engineering skill and business literacy, and few people have both.
  • Contracts are long, budgets are large, and the work is recession-resistant because companies cannot switch off their ERP.
  • The skills transfer: an engineer who understands order-to-cash can build billing, marketplaces, fintech, logistics.

Next