Budgeting an ERP Project for 2027: The Lines CFOs Leave Out

It is October, the 2027 budget is due in a few weeks, and the ERP project finally has a line in it. You have a quote from the implementation partner and a licence proposal from the vendor. Add them up, add something for contingency, and the number goes to the board. A year later, the project is over budget, and almost none of the overrun is in the partner’s invoice.

An ERP project budget usually goes wrong in the costs nobody sends you a quote for. This article lists them, so you can put them in now as named lines rather than discover them in the second half of 2027.

What the quotes cover, and what they do not

The vendor quote covers licences or subscriptions. The partner quote covers configuration, some development, a defined number of training sessions and go-live support for a set period, all based on assumptions about how ready you are. Read those assumptions carefully. They usually say that your team will be available, your data will be delivered clean, and decisions will be taken on time. Each of those is a cost on your side of the table.

The lines that belong in an ERP project budget

1. Your own people’s time

The key users from finance, sales, purchasing and the warehouse will spend a large share of their week on the project for months: in design workshops, testing, data cleanup and training their colleagues. That time is real even if no invoice arrives for it. Estimate it per person and per phase, and agree it with their managers before the project starts, not when the testing begins and month-end close is the same week.

2. Backfill

If your best accounts payable clerk spends half their week in testing, someone has to process the invoices. Either you budget for temporary help or overtime, or the day job suffers and the project slips. Backfill is the line most often missing, and its absence is the most common reason key users quietly stop showing up for project work.

3. Data cleanup and migration

Partners migrate data; they do not decide which of your customer records is true. Cleaning customers, suppliers, items and prices is business work, and for a company with years of history it is weeks of it. Budget for the people who will do it and for at least two full test migrations.

4. Testing

User acceptance testing needs people who know the processes, real scenarios written down in advance, and time to retest after fixes. If the testing budget is “the key users will do it”, see line 1.

5. Interfaces and reports

Every system that talks to the ERP (webshop, CRM, warehouse system, bank, e-invoicing provider, payroll) needs an interface built or rebuilt, and every report the business relies on needs to exist in the new system. These are often outside the partner’s scope or covered by a single estimate. Make a list of each one and give each a line.

6. Hypercare and the months after go-live

The partner’s go-live support usually covers a few weeks. Stabilising a new ERP takes longer than that: the first month-end close, the first quarter-end, the first inventory count and, above all, the first year-end close all happen on the new system for the first time. Budget for support through those moments, whether from the partner, an application manager or an embedded consultant.

7. Project leadership on your side

Someone in your organisation has to own the project day to day: chase decisions, protect the scope, manage the partner and report to the board. If that is a director doing it on top of their job, the project gets the hours left over. If you do not have that person, budget for one, internal or external, for the whole duration including hypercare.

8. Contingency you actually ring-fence

A contingency line that gets spent on something else in the second quarter is not a contingency. Hold it centrally, decide in advance who can release it and for what, and report against it monthly.

Timing matters as much as the total

An ERP project budget is also a cash-flow plan. Most of the internal cost lands in the build and test months, and the support cost lands after go-live, often in the next financial year. Two timing questions are worth settling in the budget round:

• When is go-live? A January 1 go-live puts the hardest months of the project over the holidays and the year-end close. Pick the date with the budget, not after it.
• Is there a hard deadline driving it? End of support for an old version, an e-invoicing obligation or the end of a transitional services agreement after an acquisition. If so, the budget has to fund the plan that meets the date, not the cheapest plan.

A one-page budget check

Before the number goes to the board, check that each of these has its own line, an owner and a month in which it is spent:

1. Licences or subscriptions, including the year after go-live.
2. Implementation partner, with the list of assumptions attached.
3. Internal key-user time, per person and per phase.
4. Backfill for the people who carry the project.
5. Data cleanup and at least two test migrations.
6. User acceptance testing and retesting.
7. Interfaces and reports, listed one by one.
8. Hypercare through the first month-end, quarter-end and year-end close.
9. Project leadership on your side for the full duration.
10. Ring-fenced contingency with a named owner.

The bottom line

The partner quote is the part of an ERP project budget you can see. The overruns come from the rest: your own people’s time, the work behind clean data and proper testing, and the months after go-live that nobody quoted. Put them in the 2027 budget as named lines now. A larger number approved in November is a much easier conversation than an overrun explained in September.

How to Run a 12-Week ERP Implementation

Should You Go Live With Your New ERP on January 1?

The Hidden Costs of Failing Post-Go-Live Support

Carve-Out ERP Separation: Getting Off the Seller’s Systems Before the TSA Runs Out

Project Management service

Sources

Thomson Reuters: How to budget for an ERP implementation project