Before Budget Season Begins: Why ERP and Finance Systems Need a Process Review First

Budget season is often when the problems behind an ERP system implementation become easier to see, especially when a finance process that has been “good enough” for months suddenly stops being good enough.

Leadership asks for a revised forecast by Friday, but finance cannot produce it until several spreadsheets are updated. A hiring decision depends on current cash flow, but the latest numbers are still being reconciled. Department leaders submit different assumptions, and nobody is completely certain which version of the budget is current.

That is usually when the ERP conversation starts. The assumption is understandable. If the numbers are difficult to produce, the system must be the problem. Sometimes that is true. Just as often, the system is exposing a finance process that has not kept pace with the business. That distinction matters because replacing technology without understanding the operating problem can leave leadership with the same slow reporting, the same workarounds, and a much larger implementation bill. It can also consume months of finance capacity without improving the quality or speed of the information executives rely on.

Before an ERP system implementation begins, the real question is not whether the current platform feels outdated. It is whether the business understands what is slowing finance down, what needs to change, and what the next system must enable.

Key takeaways

• An ERP should solve a defined business constraint, not compensate for unclear workflows, weak ownership, or inconsistent data.
• Budget season exposes finance problems because leadership needs faster, more reliable information when the team is already under pressure.
• The right sequence is to understand the current process, separate process issues from system issues, design the future state, define technology requirements, and establish measurable outcomes.
• A system migration should improve how finance operates rather than simply move existing workflows into a new platform.
• ERP success should be measured by better reporting, less manual work, stronger controls, and greater confidence in the numbers.

Why do ERP problems often start before the ERP is selected?

One of the most expensive ERP mistakes is solving the wrong problem. Leadership sees slow reporting, spreadsheet dependency, manual reconciliations, disconnected systems, or difficulty forecasting and concludes that the accounting platform has become the bottleneck. The technology may genuinely be limiting the business. However, a new platform does not automatically fix the processes that developed around it.

A company can implement a new ERP and still carry forward unclear approvals, inconsistent account coding, duplicate data entry, unnecessary handoffs, weak reporting practices, and spreadsheets that compensate for gaps elsewhere in finance. That is where implementation spend gets wasted. The business pays for new technology, but leadership still waits too long for reports, finance still corrects information manually, and employees continue working around the system.

The financial mechanism is straightforward: weak processes create manual work, manual work consumes finance capacity, and reduced finance capacity leaves less time for analysis, forecasting, and decision support. The first executive decision is therefore not which ERP to buy. It is whether the constraint sits in the technology, the operating model, or both.

What should happen before an ERP system implementation?

The ERP decision becomes clearer when leadership works through five questions in order. Review the current process → separate process issues from system issues → design the future state → define technology requirements → establish measurable outcomes.

Each step should narrow the problem before the business commits more money, time, or complexity to the solution.

Step 1: Where does the finance process actually break down?

Growing businesses rarely design every finance workflow at once. Processes develop incrementally. A spreadsheet is created to answer a new reporting request. An approval is added after an error occurs. Someone builds a reconciliation outside the accounting system because the existing process is too slow. A new entity introduces another variation.

Each decision may be reasonable on its own. Over time, however, the finance function can become dependent on processes that no one intentionally designed.

The review needs to follow the workflows that determine whether leadership receives timely, reliable financial information. These typically include procure-to-pay, order-to-cash, record-to-report, month-end close, reconciliations, cash management, payroll, and budgeting and forecasting.

For each process, leadership needs clear answers. Who owns it? Where does the data originate? Where are approvals required? Which systems are involved? Where is information being re-entered? What should the final output look like? If those answers are difficult to obtain, that is already telling. A process that depends on institutional knowledge rather than defined ownership becomes harder to scale, harder to control, and more vulnerable when key employees are unavailable or leave.

A structured finance and accounting diagnostic can help create that wider view instead of evaluating one system in isolation.

The most revealing approach is often to work backward from the visible problem. If a report is late every month, the reporting software may not be the cause. The delay may begin earlier because departments submit information late, coding requires correction, reconciliations remain incomplete, or finance has to combine data manually before reporting can begin. If finance spends two days fixing the inputs, a faster reporting module will not recover those two days. The practical consequence is slower reporting, less time for analysis, and leadership making decisions with information that may already be outdated.

That is the distinction leadership needs before approving a technology project.

Step 2: Is the problem the process or the finance system?

A process problem exists when the way work is performed needs to change. Responsibilities may be unclear, approvals excessive, controls inconsistent, or departments may follow different procedures. A system problem begins where a well-designed process reaches the limits of the current technology. That distinction matters because software should remove a real constraint, not compensate for an undefined operating model.

A growing company may genuinely require multi-entity consolidation, stronger access controls, integrations with operational systems, better audit trails, scalable departmental reporting, or workflow automation. Those are legitimate technology requirements because the current platform may no longer support the business efficiently.

By contrast, an ERP cannot decide who should approve a transaction when accountability is unclear. It cannot create a consistent chart of accounts unless the business first determines how accounts should be structured. It cannot correct poor data discipline if teams continue entering information differently. For executives, getting this distinction wrong has real consequences. Misdiagnosing a process problem as a software problem can mean months of implementation work, higher consulting and customization costs, and continued frustration without materially improving close speed, reporting confidence, or decision-making.

Step 3: What should the future finance function look like?

Once leadership knows what is actually broken, the conversation can move from diagnosis to design. The goal is not to preserve the current finance function inside a new system. It is to decide how finance should operate when the business is larger, reporting expectations are higher, and leadership needs answers faster.

The question should not be, “What can the ERP do?” It should be, “How should this process work for the company we are becoming?”

Consider a company that has added departments, locations, or legal entities. Its original approval structure may have worked when the organization was smaller, but it may now require too many people to review routine transactions. The future-state process could use defined approval thresholds, department-level accountability, role-based permissions, standardized account coding, and clear exception procedures. That reduces unnecessary handoffs and gives finance more capacity to focus on reporting, forecasting, and analysis.

Reporting deserves the same scrutiny. Instead of recreating every spreadsheet distributed each month, leadership should determine which reports support an actual decision, who needs them, what information they require, and how quickly they need to be available. This is why accounting system implementations should include needs assessment, chart of accounts design, and process mapping before migration and configuration.

A cleaner chart of accounts, clearer ownership, fewer unnecessary approvals, and more consistent reporting are not merely implementation details. They are improvements to the finance function that should continue creating value after the ERP project is complete.

Step 4: What does the ERP actually need to support?

Once the future state is defined, technology requirements become much more specific. For a growing business, those requirements may include automated approval routing, multi-entity consolidation, department-level financial reporting, payroll or CRM integrations, role-based access, automated reconciliations, improved audit trails, and better budgeting and forecasting information.

At that point, vendor demonstrations become more useful. A generic demonstration answers, “What can this software do?” A well-prepared evaluation answers a more important question: “Can this system support the way our finance function needs to operate?”

That difference also protects the economics of the project. Unclear requirements often lead to unnecessary customization. Unnecessary customization leads to more configuration, testing, training, and maintenance. Those costs can turn an otherwise sensible system investment into a larger and more difficult project than the business actually needed.

Leadership needs a clear reason to reject complexity that does not improve reporting, controls, efficiency, or decision-making.

Step 5: How will leadership know the ERP investment worked?

The final step should happen before implementation begins, not after the system goes live. Leadership needs to define what improvement will look like and capture a baseline against which the project can be measured. An ERP system implementation should have measurable operational objectives tied to the problems that justified the investment.

If the problem is a slow close, measure days to close. When reporting consumes excessive finance time, measure the hours required to produce it. For manual work that is driving errors, track manual journal entries, reconciliation time, corrections, or data transfers between systems. Where forecasting is the issue, establish the current level of forecast reliability where it can be measured consistently.

Leadership does not need a long implementation scorecard. It needs a small number of measures tied directly to the problems that justified the investment.

Going live only proves that the new system was launched. The stronger test is whether the business closes faster, produces reports with less manual intervention, reduces recurring errors, improves forecast reliability, and gives leadership greater confidence in the numbers. If none of those outcomes improve, the implementation may have changed the technology without materially strengthening finance.

Why does budget season make these problems harder to ignore?

Budget season raises the cost of weak finance processes because leadership needs more information when finance has less capacity to produce it. A team that already spends significant time consolidating spreadsheets, correcting coding, chasing approvals, or reconciling inconsistent information now has to collect assumptions, prepare forecasts, model scenarios, answer management questions, and revise budgets. The consequence is predictable. Manual work consumes capacity, less capacity is available for analysis, and leadership waits longer for answers.

For executives, the bigger issue is confidence. When leadership is uncertain about the accuracy or timing of the numbers, budget discussions shift away from hiring, investment, pricing, and growth. Time is spent reconciling versions, questioning assumptions, and validating information that should already be dependable.

Budget season is therefore more than a planning deadline. It is a practical test of whether the finance function can give leadership reliable information quickly enough to make decisions with confidence.

What warning signs should leadership take seriously?

The warning signs usually appear before leadership formally decides to review finance systems. The month-end close keeps slipping. Reports require repeated manual adjustments. Cash forecasts are rebuilt instead of refreshed. One employee becomes the only person who knows how a critical reconciliation works. Leadership receives numbers but still hesitates to rely on them.

When those patterns become normal, the issue is no longer simply efficiency. It is whether the finance function can support timely decisions as the business grows. A finance systems audit can help determine whether those symptoms point to process gaps, system limitations, or both.

When is an ERP system implementation not the right next step?

A company can outgrow its current system and still not be ready for an ERP implementation. That happens when the larger constraint is unclear ownership, inconsistent procedures, poor data discipline, missing controls, inadequate finance capacity, or reporting requirements that have never been clearly defined.

In those situations, targeted process improvement may create more immediate value while also making a later system implementation more effective. “We need something better” is a sign of frustration, not a system requirement.

A fractional controller may be appropriate when the underlying issue involves close discipline, reconciliations, reporting consistency, financial controls, or accounting oversight. The broader principle is that the solution should follow the constraint. A business should not force an operational problem into a technology project simply because the current platform is frustrating.

How does tFG approach ERP and finance systems reviews?

tFG approaches these projects as finance-function improvements, not simply software implementations. The starting point is understanding what leadership needs from finance, where the current function is falling short, and whether the constraint sits in workflow, reporting, controls, team capacity, technology, or some combination of those areas.

A finance and accounting diagnostic can establish that current-state view. If a system change is necessary, accounting system implementation support can then address process mapping, system requirements, migration, configuration, integrations, training, and post-implementation support.

The real objective is not a successful go-live. It is a stronger finance function that produces more reliable information, uses finance capacity more effectively, and gives leadership greater confidence when making decisions.

Fix the operating model before you invest in the platform

An ERP can improve the way a growing business operates, but it cannot decide how finance should operate on the company’s behalf. Before budget season begins, leadership should know why reporting is slow, where finance is absorbing unnecessary manual work, and which limitations are preventing the function from scaling. Those answers make an eventual ERP system implementation or system migration easier to evaluate because leadership knows what improvement should look like.

The question is simple: Do you know exactly which business problem the new system needs to solve? If the answer is not yet clear, the ERP decision is probably ahead of the diagnosis.

What should you do next?

If reporting delays, spreadsheet dependency, manual work, or disconnected finance systems are already creating problems, start by identifying where finance is losing the most time, where information becomes unreliable, and which decisions leadership cannot make confidently. That will usually reveal whether the next move is process improvement, a system change, or work that needs to happen before either one.

If it is difficult to make that distinction internally, speak with tFG about what is happening in the finance function today. The goal should be to clarify what is creating the friction and what practical change should come next.

Frequently asked questions

What should a business do before an ERP system implementation?

Before an ERP system implementation, a business should document current finance workflows, identify where errors and delays originate, separate process problems from technology limitations, define the future operating model, and establish measurable requirements. This reduces the risk of recreating existing inefficiencies inside a different platform.

What is the difference between process improvement and ERP implementation?

Process improvement changes how work is performed, while ERP implementation introduces technology that supports that work. If responsibilities, controls, data standards, or workflows are unclear, those issues should generally be addressed before or alongside system configuration.

When does a growing business need new finance systems?

A growing business may need new finance systems when its current technology cannot support defined requirements such as multi-entity consolidation, integrations, reporting complexity, access controls, transaction volume, or workflow automation.

Should a company redesign processes during a system migration?

Yes. A system migration creates an opportunity to determine which processes should remain, which should be standardized, which can be automated, and which should be eliminated. Recreating every historical workflow can transfer unnecessary complexity into the new environment.

How does financial reporting affect an ERP decision?

Financial reporting can reveal whether a problem originates in the reporting technology or earlier in the finance process. If reports are delayed because data arrives late, coding is inconsistent, or information must be manually consolidated, those root causes should shape ERP requirements.

What can finance consulting contribute before ERP selection?

Finance consulting can help leadership determine whether operational problems originate in processes, reporting, controls, staffing, data, or technology. That assessment gives the business a clearer basis for defining ERP requirements and identifying improvements that should happen before implementation.