Have you ever noticed that month-end close has a way of exposing problems everyone thought were already solved?
Financial statements don't just reflect what happened during the month. They also reveal the cumulative effect of hundreds, or even thousands, of decisions made across the business.
Sometimes those decisions improve efficiency.
Other times, they create extra work, higher costs, and more complexity than anyone anticipated.
Think of it like owning a house. You may not notice a slightly crooked door or a small crack in the foundation the day it appears. But over time, the door sticks a little more, another crack shows up, and eventually you're paying to fix problems that started years earlier.
The underlying issue has been there all along. The repair bill just took longer to arrive.
ERP architecture and operating costs are far more connected than most of us realize. This article explains why those connections eventually show up in financial statements, and what executives can do about them.
In the more than three decades I've spent working with manufacturers and distributors, one observation has held true: Architecture decisions rarely stay in IT.
Those decisions eventually influence operating expenses, financial predictability, business agility, and ultimately the numbers leadership sees in their financial statements.
Whether an organization is evaluating solutions like Microsoft Dynamics 365 Business Central or looking to get more value from an existing ERP environment, the conversation shouldn't begin with features. It should begin with the long-term business impact of the design decisions being made.
That's my focus in this first article of a new three-part executive series. I'll look at why ERP architecture and operating costs are closely connected, how seemingly small design decisions create hidden financial consequences over time, and why architecture may be one of the most important financial decisions an organization makes before implementation even begins.
In the articles that follow, I'll build on that foundation by exploring how those same decisions affect inventory, cash flow, and long-term business performance.
ERP architecture decisions affect profit margins by determining how efficiently work moves through the business. Good architecture reduces ongoing operating costs, while poor architecture creates recurring expenses that gradually erode profitability.
When leaders hear the word architecture, many naturally assume it's an IT discussion:
Servers.
Integrations.
Data structures.
Technical diagrams.
Those things certainly matter, but they're only part of the picture.
The real purpose of ERP architecture is much simpler.
It's to design a system that allows people, processes, and information to move through the business as efficiently as possible.
When that design is done well, employees spend less time correcting data, managers make decisions with greater confidence, and finance can rely on reports without repeatedly validating the numbers behind them.
When it isn't, the business adapts:
Additional approvals get added. Manual workarounds become routine. Departments begin maintaining their own spreadsheets "just to be safe."
At first, each adjustment seems perfectly reasonable. Over time, they become accepted as simply "the way we do things."
Many of the manufacturers and distributors I've worked with believed their ERP systems were performing well because production continued moving, and customers continued receiving shipments. On the surface, everything looked fine.
Then we looked a little closer.
The extra effort wasn't obvious in a single area. It was scattered across the business: in manual reviews, duplicate data entry, spreadsheet reconciliations, and approval steps that had gradually outlived their original purpose.
That's why I encourage organizations evaluating solutions like Microsoft Dynamics 365 Business Central to spend as much time discussing business processes as software functionality. Features are important, but they're only as valuable as the architecture supporting them.
Poor ERP design increases operating expense because small inefficiencies rarely remain small. As employees compensate for design limitations, additional labor, manual processes, and maintenance gradually become permanent operating costs.
One of the biggest misconceptions about ERP implementations is that the real costs are concentrated around go-live.
But implementation costs are usually the easiest costs to identify. The more expensive costs often arrive months, or even years later:
Individually, none of those decisions seem particularly significant.
Together, they create operational friction that the business pays for every day.
It's like pushing a shopping cart that constantly pulls to one side. You still get where you're going, but you spend the entire trip making small corrections. Then after a while, you stop noticing the extra effort because it now feels normal.
Businesses respond the same way.
Employees become remarkably good at working around inefficient systems. They develop checklists, create side spreadsheets, verify reports manually, and establish unofficial processes that help the business keep moving.
Those workarounds solve today's problem. They also create tomorrow's operating expense.
I've even seen businesses reach a point where nobody remembers why a particular process exists. Everyone knows the extra step is required, but nobody can explain what business problem it originally solved.
That's usually a sign that the process is supporting the ERP system instead of the ERP system supporting the business.
Research from Deloitte's Enterprise Resource Planning Transformation team emphasizes that successful ERP programs depend on designing processes that support long-term operational performance—not simply completing a successful implementation.
The challenge isn't that any single workaround is particularly expensive. It's that organizations gradually stop seeing them as workarounds at all.
They simply become part of the cost of doing business.
The most expensive ERP decisions usually aren't the ones executives approve. They're the hundreds of small adjustments employees make afterward.
CFOs can evaluate ERP architecture by looking beyond implementation success and identifying recurring operational costs, manual workarounds, and growing maintenance requirements that quietly affect financial performance.
One of the first questions I ask leadership teams isn't whether they're satisfied with their ERP system. It's whether they've started accepting inefficiencies as normal.
That's an important distinction.
Most businesses don't recognize an ERP architecture problem overnight. The warning signs usually appear gradually, often disguised as everyday operational challenges:
Individually, those issues may not seem significant. Together, they tell a different story.
They suggest the organization is investing more effort to compensate for the ERP environment than benefiting from it. That's where financial risk begins to emerge.
The challenge isn't simply higher operating costs today. It's the growing cost of maintaining an environment that becomes more difficult to modify, integrate, and expand over time.
This is often described as technical debt—the long-term cost of decisions that solved immediate problems but created additional complexity later.
Accenture's research on balancing technology investment with technical debt shows how organizations that continually postpone design improvements often spend more maintaining complexity than addressing the underlying issues.
For CFOs, that complexity eventually shows up in familiar ways:
Those aren't simply IT challenges. They're business costs.
Questions executives should ask:
Organizations that answer "yes" to several of those questions usually don't have isolated operational issues. They have architectural issues with financial consequences.
The goal isn't to build a system that's difficult to change. It's to build one that doesn't become more expensive every time the business changes.
Before approving ERP architecture decisions, executives should evaluate how each decision will affect operating costs, scalability, reporting reliability, and long-term business flexibility, not just implementation timelines.
One of the biggest misconceptions I encounter is that architecture decisions should belong exclusively to the implementation team.
In reality, many of the decisions made during an ERP project have long-term financial implications. While IT and implementation partners provide technical expertise, executive leadership should understand the business tradeoffs behind those choices.
That doesn't mean executives need to review system configurations or technical specifications. It means asking the right business questions before important decisions become permanent.
When reviewing an ERP implementation, I encourage leadership teams to consider questions like these:
None of those questions require deep technical expertise. They require business leadership.
The earlier those conversations happen, the easier it becomes to avoid the recurring operating costs that often follow unnecessary complexity.
After more than three decades working with manufacturers and distributors, I've learned that the most important ERP architecture decisions often seem like the least important at the time they're made.
It's easy to focus on getting through implementation, meeting deadlines, and solving today's challenges. It's much harder to stop and ask how today's decision will affect the business five or ten years from now.
I've seen organizations invest significant time and money improving reporting, streamlining operations, or reducing manual work, only to discover they were compensating for architecture decisions that could have been addressed much earlier.
That's why I encourage leadership teams to view ERP architecture as a business investment rather than a technical exercise.
If an architecture decision makes the business simpler to operate, easier to grow, and more confident in its data, it's usually the right decision. If it adds complexity that employees will have to work around every day, it's probably worth another conversation before moving forward.
ERP architecture isn't something executives see every day.
What they do see are the results.
They see operating costs, reporting confidence, business agility, and the financial impact of decisions made months or even years earlier.
That's why ERP architecture and operating costs are so closely connected. The design decisions made before implementation influence far more than the technology itself. They shape how efficiently the business operates long after go-live.
In the next two articles, I'll explore how ERP technical debt develops over time and how better architecture decisions support long-term business growth.
If you're evaluating an ERP strategy and wondering how today's architecture decisions could affect tomorrow's operating costs, let's start a conversation.