Companies buy an ERP expecting efficiency and frequently get a faster version of the process they already had.
The system is a precondition, not an outcome. What actually produces the efficiency is how it is configured, what reporting gets built on it, and what gets built around it. None of that arrives with the license.
What an ERP actually gives you
Three things, and they are genuinely valuable.
One source of record, so the question "which number is right" has an answer. Enforced structure, so transactions cannot be entered in ways that break downstream. And transaction level detail, so any summary figure can be decomposed into the things that caused it.
That is a foundation. It is not efficiency. A company can have all three and still close in fifteen days.
Why implementations underdeliver
Configuring the system to replicate the previous process. This is the most common and most expensive mistake. The previous process contained workarounds for limitations of the previous system. Faithfully reproducing them carries those limitations into a system that did not have them.
An implementation is one of the few genuine opportunities to ask why a step exists. It is worth spending that opportunity rather than deferring every question to after go live, which in practice means never.
Customization that makes upgrades expensive. Every customization is a commitment to maintain it forever. Some are worth it. The test is whether the requirement is genuinely specific to your business or just unfamiliar.
Training that covers navigation rather than the process. People learn which buttons to click and not why the step exists or what a wrong result looks like. Then they produce wrong results confidently.
Reporting is where the time goes
Standard reports answer standard questions. The recurring analysis a specific business actually needs is usually assembled by hand in a spreadsheet, every month, by someone senior enough that it is an expensive way to spend the time.
That monthly spreadsheet is the single most reliable place to find recoverable hours in a finance function. It is recurring, it is well defined by the time it has been built forty times, and nobody enjoys it.
Building those as real reports inside the ERP removes a fixed monthly cost permanently. Most systems have more reporting capability than the people using them realize, and learning what yours can express is worth the afternoon, because the alternative is filing a request and waiting.
The diagnostic question: how many hours a month does the team spend assembling recurring reports by hand? Most teams have never counted, and the number is usually larger than expected.
Configuration decisions that compound
A few decisions are disproportionately consequential because they are hard to change later and they constrain what reporting is possible.
Chart of accounts design. Too granular and every entry becomes a judgment call. Too coarse and the analysis you need is not available without digging into transactions. The shape here determines what questions the system can answer.
Subsidiary and segment structure. Determines what can be reported on without manual allocation, which in a multi entity business is most of the interesting questions.
Item and cost configuration. Standard costing and how costs attach to items. Getting this wrong makes margin reporting unreliable in ways that are hard to trace back to the configuration.
Approval routing and thresholds. Part of the control environment, and easy to set up for convenience rather than for control.
None of these are irreversible. All of them are painful to change once there is history.
Building on top rather than inside
A useful distinction: extend the ERP where the requirement is about the system of record, and build alongside it where the requirement is about how people work.
The system of record should stay clean and close to standard. What surrounds it, dashboards, checklists, workflow automation, can be as specific as the business needs, because changing it does not risk the record and does not complicate an upgrade.
That is where most of the practical efficiency gains have come from in my experience. A close checklist that links each task to its procedure. Dashboards that surface AP, AR, and inventory issues during the period rather than at close. Workflow automation for the clerical steps. None of those require changing the ERP.
Integration boundaries
Where data crosses between systems is where reconciliation problems originate. Almost always.
Design the boundary deliberately: what crosses, how often, what happens when a record fails to transfer, and how you would know. The last one is the one that gets skipped, and it is the reason a broken integration can run unnoticed for a month.
A reconciliation between systems on each side of an integration is not optional overhead. It is the only thing that tells you the integration is still working.
Measuring whether the system helped
Worth tracking, and easy to forget to:
- Days to close, trended
- Manual journal entry volume, which should fall as configuration improves
- Reconciling item age, which shows whether problems are being resolved or carried
- Hours spent assembling recurring reports by hand
The last one is the most revealing and the least measured. It is a direct measure of work the system was supposed to eliminate and did not.
The short version
An ERP gives you a foundation. Efficiency comes from configuring it for the process you want rather than the one you had, building the recurring analysis as real reports instead of monthly spreadsheets, keeping the system of record standard while building freely around it, and treating integration boundaries as the reconciliation risk they are.
The license is the cheapest part of getting value from an accounting system.