Where ERP Implementation Money Actually Goes

The quote you are looking at has two numbers. The licence is the one you compared across vendors, because it is easy to compare, while implementation is the number that often determines whether the project was actually affordable in the first place.

Published ERP cost research consistently shows that the software itself is only part of the first-year cost. ERP Research puts software at roughly 20% to 30% of total first-year spend in typical implementations, with implementation commonly running one to three times the first-year software fee. For smaller businesses, published estimates commonly put a full implementation somewhere in the tens of thousands of dollars, with more complex projects going considerably higher. ERP Research's ERP implementation cost breakdown

Then there is the other number nobody likes putting next to the licence price: what happens when the project takes longer or costs more than planned.

Panorama-derived figures reported in the ERP industry put average budget overruns at 189% overall and 215% for discrete manufacturing, while the same research is commonly reported as finding that 68% of implementations miss their original objectives, rising to 73% for discrete manufacturing. Those figures come from a particular research methodology and should not be treated as a universal prediction for every ERP project, but they illustrate how much of the risk sits outside the software subscription itself. Godlan's ERP implementation research summary

The usual advice is to get a fixed-price quote, control scope, clean your data early, and manage the project carefully. None of that is bad advice. It also treats implementation cost as something you can only manage rather than something the software industry could fundamentally change.

What the Money Is For

Look at where the work actually goes in a traditional ERP project and a large part of it is not software. It is people learning how your company operates, deciding how those operations should be represented in the ERP, configuring the system, migrating your existing data, testing the result, finding what was misunderstood, changing the configuration, testing again, and eventually training everyone who has to use it.

That work is real. A manufacturing company cannot simply install a generic ERP and expect it to understand which of its fields represent customer commitments, which suppliers require approval, how its production stages work, or what its employees mean when they refer to a particular internal process.

The problem is what happens to all of that knowledge.

Someone interviews your employees and learns how the company works. Someone maps that knowledge onto the ERP. Someone turns the mapping into configuration. The project closes, the consultants leave, and the next customer starts the same process from the beginning.

You are paying for expertise, but much of the expertise is acquired specifically for your company and then remains tied to that one implementation.

That is a strange way to build software.

The Expensive Part Is the Mapping

Your company already has a model of how it works, even if nobody has written that model down in one place. There is probably a spreadsheet with customers, another with products, a system for orders, a purchasing spreadsheet, a production schedule, and a handful of people who know how all of those things fit together.

The ERP has its own model.

Someone has to map one onto the other.

Take something as simple as a column called Delivery Date. Does that mean the date the customer requested, the date your company promised, the date the goods leave the factory, or the date they are expected to arrive? Your employees know because they have been using the spreadsheet for years. The consultant does not, so someone has to ask.

Multiply that by hundreds of fields, relationships, business rules, exceptions, and historical records and you have the beginning of an implementation project.

The decisions themselves are not the problem. A business system has to know what your data means.

The problem is that the first draft of those decisions is produced manually for every customer.

Then You Have to Move the Data

The same thing happens during migration.

Your old customer list has duplicates. Some customers appear under slightly different names in different files. Some products have SKUs and some do not. Dates use different formats. Old orders contain fields that do not exist in the new system. Somebody has to determine what each field means, where it belongs, which records should be merged, and what should happen to information the new system does not understand.

That is why migration is not simply an export-and-import operation. It is another mapping exercise, and it can become one of the larger sources of implementation effort because the new system has to receive clean, structured data while the old system rarely provides it in exactly the shape required.

The work is legitimate, but again, much of it is performed from scratch for every customer.

Why Traditional ERP Has to Cost This Much

There is a straightforward reason ERP vendors rely so heavily on implementation partners: the software cannot know how your company operates before someone tells it, while the customer usually cannot configure a complex ERP alone because they do not yet know what all of the ERP's objects, relationships, and configuration options mean.

So a third party sits between the two.

The consultant learns how your company works, learns how the ERP represents a business, and then builds the mapping between them. That is useful work, and it requires people with enough experience to understand both sides.

But it is also expensive because the work is largely repeated for every customer.

The next manufacturer pays someone to learn how its purchasing works. The next distributor pays someone to learn how its inventory works. The next company starts another discovery process, another data-mapping exercise, and another configuration project.

The industry has become very good at delivering these projects.

We think the process itself can be changed.

The Inversion We Are Building

The basic idea is simple: read the company first, propose the configuration, let the people who actually run the company correct it, and keep those corrections.

That changes where implementation begins.

Instead of starting with a consultant asking you to explain your business and then translating the answers into configuration, the system starts with the information your business already has.

You start with the data you already use

You can upload the spreadsheets that already contain your customers, products, open orders, suppliers, inventory, or other operational data. The files do not have to have been created specifically for Loopency; the current import system accepts common formats including .csv, .xlsx, .xlsm, and .xls.

The point is not to make you spend two weeks preparing your data for the importer before you can find out whether the importer understands it.

Start with what you have.

You get a proposal before anything changes

Loopency examines the structure of the data and proposes what it thinks the tables and columns represent. It might identify a customer table, suggest which column contains the company name, identify a product identifier, and distinguish an order date from a delivery date.

The important part is that a proposal is only a proposal. Reading your spreadsheets and describing what they appear to contain does not create, modify, or delete business records. Applying the proposal is a separate operation, and you decide whether to do it.

That gives you something concrete to review instead of asking you to trust an invisible interpretation.

You correct it where it is wrong

Suppose the system interprets Delivery Date as the customer's requested date when your company uses it for the date you actually promised to ship. You correct the mapping.

Maybe Product Code is your internal SKU rather than the manufacturer's part number. You correct that too.

The first proposal is a draft, and it will get things wrong because your company has terminology, conventions, and exceptions that the system cannot know on day one. A consultant does not know those things on day one either. The difference is that you are correcting a concrete proposal rather than spending another round of meetings explaining the same business to someone who will eventually turn those explanations into configuration.

Your Corrections Should Not Disappear

This is the part that changes the economics.

When you correct a mapping, the correction can become knowledge about the kind of business you operate. If similar businesses repeatedly use a particular term or column in a particular way, that information can improve future proposals.

A consultant also learns during an implementation, of course. The difference is that the consultant's learning usually stays in the consultant's head, project notes, or the configuration created for that one customer.

A product can retain it.

The first implementation can make the next implementation better.

That is not the same thing as saying the system magically understands every company. It means that the system has a way to accumulate useful knowledge from the corrections people make instead of throwing that knowledge away when an implementation project closes.

What Happens When the System Does Not Know?

This part matters because an implementation system that confidently invents configuration is worse than one that asks for help.

If you request something that already exists, the system can provision it.

If you request a new entity, field, vocabulary, or capability that the current configuration does not support, the request should be recorded rather than partially executed and left in an ambiguous state. A build request can then be routed through the appropriate process instead of pretending that the system successfully built something it could not safely build.

The same principle applies to classification. If a fresh installation does not have enough information to classify a business confidently, the classifier should not invent an answer simply because the interface expects one. It should refuse or ask for more information.

That is less impressive in a demo.

It is much more useful in a real implementation.

The First Proposal Is a First Draft

This is where the difference between a product and a consulting project becomes clearest.

The first proposal will not understand your company perfectly. Your spreadsheets have conventions that were never documented, employees use terminology that makes sense only inside the company, and some important business rules may exist entirely in people's heads.

A consultant has the same problem on the first day of a project.

The difference is what happens after the first mistake.

In a traditional implementation, the cycle is discovery, interpretation, configuration, correction, another discussion, another configuration change, and more consulting time.

The model we are building is data, proposal, correction, configuration, and retained knowledge.

You are still involved because you should be. You are the person who knows what Delivery Date actually means in your business. But you are reviewing a proposed interpretation rather than paying someone to discover every interpretation from scratch.

That is a different implementation model.

What This Does Not Mean

It does not mean ERP implementation becomes a button.

Real companies have messy data. Processes have exceptions. Some configuration decisions require people who understand the business. Some capabilities need to be built, and some migrations will require serious cleanup.

We are not trying to pretend those things do not exist.

The goal is to move the repetitive first-pass work into the product: let the software examine the data, produce a proposal, let the customer correct it, retain those corrections, and make it clear when something has reached the boundary of what the software can safely configure.

That is a much narrower claim than "AI implements your ERP."

It is also a much more useful one.

What to Ask the ERP Vendor You Are Getting Quotes From

If you are currently getting ERP quotes, ask how much of the initial configuration happens before you start paying a consultant for discovery. If the answer is essentially none, most of the mapping work is still a professional-services project, regardless of how impressive the software looks.

Then ask what happens when the first configuration proposal is wrong. Do you correct something concrete, or do you go through another round of discovery before someone changes it?

Finally, ask where the knowledge about your business lives after implementation. Is it part of the system, part of the configuration, part of the project documentation, or primarily in the people who implemented it?

Those questions tell you more about the real cost of an ERP than the licence number on the first page of the quote.

The Implementation Should Be the Product

This is what we are trying to change with Loopency.

We are not trying to make ERP consulting slightly cheaper. We are trying to make less consulting necessary by moving more of the implementation work into the software itself.

The system should be able to look at the company before someone has to spend weeks explaining the company to it. It should propose how the business maps onto the system, let the people responsible correct that proposal, retain what it learns, and use the resulting configuration as the foundation the company actually runs on.

That also means the implementation work does not disappear when implementation ends.

Your customers, products, orders, suppliers, inventory, processes, terminology, relationships, permissions, and rules become part of the same operational model.

The work done during setup becomes part of the product rather than a pile of consulting hours that exists only to get you through the setup phase.

That is the inversion.

Traditional ERP starts with software and sells implementation around it.

Loopency is trying to make implementation itself part of the software.

Start With Your Own Data

You do not have to take our word for it.

Take the spreadsheets you already use. Your customers, products, open orders, suppliers, inventory, or whatever else currently holds the operational knowledge of your business.

Put them into Loopency.

See what it proposes.

Correct it where it is wrong.

Then see how much of the initial configuration can happen inside the product rather than through a consulting engagement.

Try Loopency

The free Community tier supports up to three people, with access to the platform and no credit card required.

If you are looking at ERP because spreadsheets and disconnected systems are starting to break down, the interesting question is no longer only:

How much does the ERP cost?

Ask the second question:

How much of the implementation am I buying with it?