There’s a lot of pressure to keep an ERP implementation moving, especially when one decision is holding up everything behind it.
Deadlines matter. Budgets matter. And sometimes making the practical choice and moving on really is the right thing to do.
The problem is that the cost of an ERP decision isn’t always obvious when you act on it.
You pay once at implementation. Then you pay every day.
That's the part of ERP implementation cost over time that's easy to underestimate.
A decision that saves a few days during implementation can create hours of recurring work every month.
A customization that solves an immediate problem can complicate the next upgrade.
A local exception that seems harmless for one entity becomes considerably less harmless when there are five.
I've seen companies make perfectly understandable ERP decisions because they were trying to hit a deadline, complete an acquisition, open a new location, or get a new line of business running quickly. The system goes live. The business keeps moving. Everyone considers that a win. And sometimes it is.
But speed has a way of sending the invoice later.
In the first article in this series, I looked at how ERP decisions show up in financial performance over time. One reason this happens is that early shortcuts rarely remain one-time events. They become processes people repeat, exceptions people manage, and costs the business absorbs month after month.
I see this often with growing companies. The software can support another entity, location, or line of business. But if master data standards, intercompany rules, reporting structures, and ownership haven't kept pace, finance inherits the consequences.
The system works. It just needs a surprising amount of help to keep working.
That's an important distinction for companies evaluating SAP Business One. The question isn't simply whether the system can support where the business is going. It's whether the decisions made along the way will still make sense when the business gets there.
That's what I want to look at here: how rushed ERP decisions turn into recurring work, higher support costs, greater risk, and financial drag that compounds over time.
The long-term costs of a rushed ERP implementation usually show up as recurring labor, added support, more difficult upgrades, and business processes that require more intervention than anyone expected when the original decisions were made.
One of the clearest examples I've encountered involves companies adding entities quickly after an acquisition, expansion, or new line of business.
From a system perspective, adding the entity may be entirely manageable. The trouble starts when speed takes priority over the decisions surrounding it:
The first consolidation may require a few adjustments. The next one requires the same adjustments.
Eventually, nobody calls them adjustments anymore. They're just "month-end."
That's how ERP implementation cost over time starts to grow. The original decision isn't necessarily expensive.
Repeating the work it created is.
The same pattern applies beyond multi-entity environments.
And then there's customization.
Customizations aren't inherently bad. Sometimes they solve a legitimate business problem that standard functionality can't address. The problem is treating customization as the quickest answer without considering who will maintain it, test it, document it, and eventually upgrade it.
PwC makes an important point about ERP customization: solving an immediate business need can also create maintenance expense, upgrade complexity, technical debt, and dependence on specialized knowledge over the life of the system.
That's the real ERP customization risk. The cost isn't just what you pay to build something. It's what you commit to supporting afterward.
ERP hidden costs rarely announce themselves. They just become part of payroll, consulting invoices, reconciliation time, delayed projects, and all the little exceptions employees learn to manage as if they were always supposed to be there.
Individually, they can look harmless.
Collectively, they create drag.
ERP problems compound because every workaround, exception, customization, and disconnected process creates something else the business has to maintain.
Think about a shortcut taken during implementation. Maybe a team needs a process the ERP doesn't handle exactly the way employees are accustomed to handling it, so a workaround is created.
It works.
Then another process depends on it. An integration is built around it. A report assumes the data will be structured that way. Employees are trained to use it.
Five years later, changing the original workaround means touching a bunch of other things nobody was thinking about when the first decision was made.
That's ERP technical debt.
SAP describes technical debt as the future rework and maintenance created when quick fixes are chosen over more sustainable approaches. In ERP environments, SAP specifically points to extensive customizations, poorly documented integrations, redundant data structures, and modifications that make upgrades and modernization more difficult.
You don't have to be a former CPA to see the financial parallel. Debt is manageable when you understand why you're taking it on, what it's costing you, and how you plan to pay it back.
ERP debt isn't much different. The problem comes when nobody remembers taking it on.
That's when several things begin happening at once:
None of those developments alone may justify an executive meeting. And that's exactly why ERP implementation cost over time is so easy to miss.
The curve doesn't necessarily look dramatic at first. It bends gradually as each new decision inherits the complexity of the decisions that came before it.
Rushed ERP decisions affect financial performance by increasing overhead, making reporting less consistent, and creating costs that become harder to predict as the system grows more complex.
This is where the CFO lens becomes especially useful.
The ERP financial impact isn't confined to the ERP budget.
That's why I think executives should pay attention to exception labor. Most companies can tell you what they spend annually on ERP software and outside support.
Far fewer can tell you how many employee hours are spent correcting, reconciling, re-entering, or validating information because of decisions embedded in the system.
That labor can become invisible because it's distributed across departments. Ten minutes here. An hour at month-end there. A report someone checks manually because "we always check that one."
Multiply that across people, entities, months, and years, and the ERP implementation cost over time looks considerably different.
Predictability matters too. CFOs don't expect every cost to disappear. But they do want to understand where costs are coming from and how they'll behave as the business grows.
A system that requires progressively more intervention every time the company adds an entity, changes a process, or completes an upgrade makes that harder.
Growth should create scale, not a corresponding collection of exceptions.
The answer isn't to slow every ERP decision to a crawl. It's to be deliberate about the decisions that will be expensive to reverse.
I encourage executive teams to focus on five disciplines:
These are not glamorous ERP decisions.
And that's probably part of why they're so valuable. They create discipline before the business is forced to pay for the lack of it.
When I say "slow down early," I don't mean ERP implementations should move slowly.
I mean the opposite.
Spend more time on the decisions that are difficult to undo so the business can move faster afterward.
There will always be pressure to hit an implementation date, integrate an acquisition, add an entity, or solve an immediate operational problem.
Sometimes accepting a short-term compromise is the right business decision. But if you make that trade-off knowingly, assign ownership to it, and have a plan to revisit it, you've made a very different decision from simply assuming you'll clean it up later.
The problem with “later” is that by the time it arrives, something else is usually more urgent.
The best way to control ERP implementation cost over time is to recognize that the implementation budget is only the beginning of the financial story. The decisions made during the project determine how much reconciliation, support, maintenance, and exception management the business will carry afterward.
Stay tuned for the final article of this series where I'll explore why ERP architecture matters more than many leaders expect, and why decisions that can look technical at first deserve executive attention.
ERP mistakes don't usually result in one large invoice. They arrive as a bunch of small ones.
Slow down early. It's a lot less expensive than spending years paying for decisions you made in a hurry.
If you're evaluating an ERP decision and want to understand what it could cost the business over time, let's talk before the short-term solution becomes a long-term expense.