What is an ERP?
An ERP is not a category of software so much as a design decision: put several business functions on one shared database instead of letting each department keep its own tool and reconcile afterwards. Enterprise Resource Planning is the historical name, coined when the systems were sold to manufacturers, and it describes the ambition rather than the mechanism.
The mechanism is the shared record. When a salesperson confirms an order, stock availability, purchasing needs, production planning, the invoice and the accounting entry all derive from that same record rather than from five copies of it typed into five systems. Nothing has to be reconciled because nothing was ever duplicated.
That single property explains both the value and the difficulty. The value is obvious: no re-entry, no month-end hunting for the version that is right. The difficulty is that a shared record forces every department to agree on definitions that were previously allowed to differ. What counts as a confirmed order, when a delivery is complete, which price applies to a long-standing customer. Companies that treat an ERP as a software purchase discover these questions during implementation, at the worst possible moment.
Why an ERP matters
Three developments changed the calculation for mid-sized companies, and one of them is specific to Belgium.
- Administrative time is the real cost being attacked. In most companies without a shared system, a measurable share of administrative work is transcription and reconciliation: retyping an order, checking two stock figures against each other, chasing which invoice matched which delivery. That work produces nothing and is the first thing a shared record removes.
- Cloud deployment removed the entry ticket. The monolithic projects that made ERP a large-company word are no longer the only option. Modular and hosted systems make it reasonable for a company of thirty people, which was not true a decade ago.
- Structured e-invoicing made integration compulsory. Since 1 January 2026 Belgian companies must issue and receive structured electronic invoices for domestic business-to-business transactions. An invoice now arrives as machine-readable data, and the value of that only materialises if something on the receiving side can book it automatically. A shared system is what turns a compliance obligation into a saving.
- Reporting stops being an exercise in archaeology. When figures come from one place, a monthly report is a query rather than a reconstruction, and disagreements move from whose number is right to what the number means.
The strategic consequence is uncomfortable and worth stating plainly. An ERP standardises. That is its purpose and also its cost, because a process that gave a company a genuine advantage may not survive standardisation. Deciding in advance which processes are distinctive enough to protect, and which are simply habits, is the most valuable work in the whole project, and it happens before any vendor is contacted.
How it works
Three layers, and the middle one is where projects are won or lost.
The shared data model holds customers, suppliers, products, stock, orders and accounting entries as single records with defined relationships. This is the actual product. Everything else is an interface onto it.
The functional modules expose that data to each role: order entry for sales, replenishment for purchasing, receipt and picking for the warehouse, invoicing and ledgers for finance. Modules are usually licensed and deployed separately, which is what makes a partial deployment possible.
The integration layer connects the system to everything that stays outside it: the online shop, the payroll package, the bank, the Peppol access point, a machine on the shop floor. This layer is routinely underestimated in budgets and is routinely where the schedule slips.
The cost structure follows the same shape. Licences or subscriptions are visible and easy to compare, which is exactly why they dominate vendor conversations and mislead buyers. Four other lines matter more over five years: implementation and configuration, data migration and cleaning, integration with the systems that remain outside, and internal time, meaning the days your own people spend specifying, testing and learning. On most mid-sized projects the sum of those four exceeds the licence line by a wide multiple. A business case built on subscription cost alone is not a business case.
Implementation
The order below is deliberately unfashionable. It puts the unglamorous work first because that is where the risk sits.
- Describe the processes you have, before choosing anything. Not the ones in the procedure manual, the ones actually followed. This document is what lets you tell a configuration gap from a genuine incompatibility.
- Decide what is distinctive and what is habit. Distinctive processes justify configuration or development. Habits should bend to the standard system, and saying so out loud early prevents a hundred small negotiations later.
- Clean the master data. Customers, suppliers, products. Duplicated and stale records migrate perfectly well and poison every report afterwards. This step has no visible output and is the single best predictor of whether the project will be trusted.
- Deploy one function first, then the next. Sequential beats simultaneous for a mid-sized company, because each phase produces a working result and teaches the team something before the next commitment.
- Plan the integrations explicitly, with a named owner for each one. Shop, bank, payroll, e-invoicing, production equipment. Every connection left implicit becomes an emergency.
- Budget the internal time honestly. Specification, testing and training are done by the people who also keep the business running. A plan that assumes they have spare capacity is a plan that slips.
The most common expensive mistake is the reverse order: selecting a system first, then discovering during configuration that nobody had agreed what a confirmed order means. At that point the discussion is happening under schedule pressure, with a vendor billing by the day, which is the worst context for a decision that will shape the company's operations for a decade.
Related technologies and tools
- Modular ERP suites: systems sold function by function, which allow a company to start with two departments rather than committing to everything at once.
- Custom business applications: for companies whose distinctive process does not fit a standard module, a purpose-built application covering that process and integrating with the rest is often cheaper than bending a suite into shape.
- Integration and API layers: the connections to the shop, the bank, payroll, production equipment and the e-invoicing network, which decide whether the shared record actually stays shared.
- Peppol access points: the route by which structured invoices leave and enter the system, now a legal requirement for Belgian domestic business-to-business trade.
- Reporting and business intelligence: the layer that reads the shared database, and the reason a clean data model pays for itself repeatedly.
Conclusion
An ERP is a shared database with a business process wrapped around it. Judge a project on whether the shared record actually becomes the single reference, because a system that half the company bypasses with a spreadsheet has delivered nothing regardless of what was installed.
The honest counter-position deserves stating: many mid-sized companies do not need an ERP. They need two or three processes properly connected, which is a smaller, cheaper and faster project with most of the benefit. The question worth answering before any vendor meeting is not which ERP, but how many processes genuinely need to share a record. If the answer is two, buying a suite designed for twelve is an expensive way to solve a small problem.
