ERP for SMEs: what it solves, and what it never will

An order goes out with the wrong reference. An invoice sits for three extra days because someone has to double-check a figure that was entered twice, in two systems that don't talk to each other. A client calls back because the promised deadline no longer means anything.

In a Belgian SME of 30 to 150 people, it's rarely a strategic decision that triggers an ERP project. It's one of these three incidents, repeated often enough to become a problem you can no longer ignore.

At that point, the cost stops being purely financial. It becomes time lost every week, a dependency on two or three people who know how things actually work, and growth that starts running into an organization that was never formalized.

The ERP then looks like the obvious answer. A tool, a database, a promise of control. On the ground in Belgium, the reality is more nuanced: an ERP doesn't fix an organizational problem. It makes it visible. Sometimes it amplifies it.

What an ERP does, and what it will never do

An ERP is good at one precise thing: running a framework that's already been defined. It centralizes data, chains order → delivery → invoicing without interruption, and makes visible the gap between what was planned and what actually happened.

What it will never do: settle a rule that nobody, internally, was willing to settle. Bring two teams that have always worked differently into alignment. Decide on your behalf. 👉 The system works, but nobody is really satisfied, and the project gets labeled a failure even though the tool did exactly what it was asked to do.

🔍 Field test. Before folding a process into the ERP, ask one question: if two teams do things differently today, which one is right? If nobody can answer, the ERP won't fix anything. It will just impose a conflict that already existed, and make it more visible.

What actually drives up costs, before you even talk about ERP

An ERP is never a starting point, it's an amplifier. Before installing one, you need to know what you're amplifying.

In an industrial or distribution SME of 50 to 100 people in Wallonia or Brussels, the most expensive processes aren't the ones handling the highest volume: they're the ones generating the most exceptions. Orders corrected by hand, invoices stuck over a dispute, purchases validated three times for lack of a clear rule. The right indicator is never the number of steps in a process, it's the time spent fixing what didn't work the first time.

⚠️ Every workaround you observe today is a signal. If it exists before the ERP, it will exist after, just more rigid and more costly to fix.

What it actually costs in Belgium

Before picking a tool, look at the real cost structure, not the price on the pricing page.

The figure most often missing from quotes is the next one: projects that go beyond the standard scope quickly push the total budget well past the first estimate, precisely because of the custom work that piles up along the way.

📌 Key takeaway. The sticker price of an ERP is never the real budget. The true cost is calculated on implementation, not on the license.

Three cases where an ERP genuinely saves money

1. The end of double data entry

When the same information circulates across three different tools, errors and rework pile up without anyone counting them. A properly configured ERP eliminates this re-entry and makes the data reliable at the source.

Observed results (distribution SME, Walloon Brabant, 60 employees):

• Went from 3 disconnected tools to 1 unified system
• Invoicing time cut in half across the order-to-delivery-to-invoice cycle

2. Fewer operational errors

Wrong reference, wrong price, wrong deadline: every error costs time, sometimes money, and always a bit of credibility with the client. A clear sequence and shared rules measurably reduce these gaps.

Observed results (manufacturing workshop, Liège region, 45 employees):

• Reference-error rate cut by two-thirds in six months
• Zero client disputes tied to a data-entry error since rollout

3. Earlier visibility, so cheaper fixes

Without an ERP, problems are often visible too late: at month-end, at closing, or after a client incident. With indicators running continuously, you fix things before they get expensive.

Observed results (horeca wholesaler, Brussels region, 80 employees):

• Stock discrepancies caught weekly instead of at monthly closing
• Stockouts avoided on fast-moving items, before they ever reached the client

Where ERP projects go off the rails in Belgian SMEs

ERP projects rarely fail because of the tool. They go off track in the gray zones, where nobody really makes a call, but where every decision has lasting weight.

Custom requirements presented as essential. Every project accumulates specific requests: one more field, a rule that applies to a single client, "just this one case." The problem is never a single, isolated tweak. It's the accumulation without governance: costs climb, and every version upgrade gets postponed for fear of breaking something.

Underestimated integrations. An ERP never lives alone: accounting, CRM, e-commerce, an existing line-of-business tool. Every connection is a point of fragility. When these flows aren't properly scoped, the ERP becomes the scapegoat for a problem that actually comes from elsewhere.

No clear owner. Without an identified project owner, decisions get postponed and technical choices turn into internal political battles.

⚠️ An ERP project rarely derails all at once. It gets stuck through a series of small compromises that were never really settled, and it rarely gets back on track without an outside perspective that has no political stake in the decision: that's exactly what we do when a project has driven into a wall.

Standard ERP, custom software, or hybrid: the real question

By this point, many business owners are asking the wrong question: which ERP should we choose? The right question is different: what type of solution can absorb our reality without distorting it?

A standard ERP works well when processes are conventional, when the organization is willing to adapt to the tool, and when reliability matters more than differentiation.

Custom line-of-business software becomes relevant when the company's competitive edge rests precisely on atypical processes: complex pricing, a specific production logic, rules that nobody else applies quite the same way.

A hybrid approach is, in practice, the most common one on the ground in Belgium: an ERP for core functions (accounting, invoicing, purchasing), specific business components wherever the ERP shows its limits, and clear interfaces between the two.

👉 The goal is never to force everything into the ERP. It's to choose what should be standardized, and what definitely shouldn't.

The Nightborn method: filling what the ERP will never cover

In a growing SME, the ERP or CRM in place rarely covers 100% of the actual business. The usual instinct is to keep patching the existing tool with custom additions, which, as we've seen, drives up cost and fragility.

Our approach starts from a different principle: never touch the configuration of the existing ERP, and build alongside it the component that precisely fills the gap it leaves.

1. Mapping the real gap. We identify what the ERP doesn't cover in practice, day to day, not what it should cover in theory.
2. Designing a connected component. We build a system that integrates with what's already there without disrupting it, connected via API rather than through changes to the tool itself.
3. A deliverable owned by the client. The project's specifications belong to the company, not the service provider: the SME stays in control of what it had built.
4. Testing on real data before scaling, to avoid industrializing an exception that wasn't worth industrializing.

This is a concrete process, not a pitch: the goal is never to replace the ERP, but to make bearable what it will never do.

Key takeaways

• An ERP executes a framework. It doesn't define one, and it never decides on your behalf.
• The real cost of a Belgian ERP project sits in implementation (€5,000 to €20,000 for a standard setup), not in the license.
• Projects derail through an accumulation of small compromises, not through a sudden failure of the tool.
• The choice between standard ERP, custom software, and hybrid comes down to one question: does your competitive edge depend on atypical processes, or not?
• Filling a blind spot doesn't mean patching the ERP: building alongside it is often cheaper, and lasts longer.

An ERP doesn't make costs disappear by magic. It exposes, in black and white, organizational decisions that were already made, the good ones and the bad ones. So the question is never "which ERP should we choose", but which decisions you're prepared to own once they become visible.

If your current ERP or CRM is showing its limits and you're not sure whether the problem is the tool or what it doesn't cover, we can look at it together.