How to Budget an ERP Project

An ERP budget is a document, not a number

The first mistake buyers make with ERP cost is to treat a vendor's license quote as the budget. It is not. A quote tells you what the software will cost to rent or own; a budget is the full, governed plan for everything the project will spend across the whole lifecycle — software, the people who build it, the data you move into it, the systems you connect to it, the training that makes staff use it, and the reserve that absorbs the surprises nobody can scope on day one.

The scale of the gap between quote and budget is well documented. A widely cited industry rule of thumb puts total ERP cost at roughly 100%–200% of the license fee — meaning services, training, and infrastructure roughly double the sticker price of the software. If your budget document is the same size as your license quote, you are missing half the project before a single configuration decision is made.

The reason a structured budget matters more than a precise number is statistical. TestHouse reports that 55% of ERP projects exceed their budgets, with under-governed projects averaging roughly 72% in overruns. A budget you can defend is not one that predicts the future exactly — it is one where every line is visible, every overrun has a named cause, and there is a controlled reserve to absorb it.

The six-line ERP budget template

Every defensible ERP budget, regardless of platform, breaks down into the same six lines. Forcing them apart matters because each line is driven by different levers, owned by different people, and blows up for different reasons. A blended lump-sum quote hides all three.

Use this structure as the spine of your budget document and demand that any partner proposal maps cleanly to it. If a quote cannot be decomposed into these six lines, it cannot be compared to another quote, governed during delivery, or audited afterwards.

• →If a partner returns a single lump-sum figure, send it back and ask for it broken into these six lines — comparison and governance are impossible without the breakdown.
• →Lines 1, 4, and the recurring parts of 5 are OpEx; line 2 and the one-off parts of 3 are typically CapEx. Separate them in the document so finance can treat them correctly.
• →The contingency line (6) is the one that separates a defensible budget from a wish — never publish an ERP budget without it.
• →Hypercare belongs on line 2 as a named block of SI hours (often 30–60 days of tapering support after go-live), not as an informal favor after cutover.
• →Year-two support, subscription renewals, report rebuilds, and partner AMS retainers sit outside the project total on a run-rate OpEx line — budget them before go-live or finance will treat them as surprise spend.

Software licenses and subscriptions: the recurring line

Line 1 is the only line most quotes lead with, so it is the one buyers know best — and still get wrong. The job here is not just to multiply users by a monthly rate; it is to model the subscription across the full contract term, because the year-one price rarely equals the steady-state price.

Cloud ERP subscriptions commonly follow tiered, per-user pricing, but the terms that move the number are easy to miss. Thomson Reuters notes that subscription fees cover software updates, security patches, and support, but warns buyers to negotiate long-term pricing agreements to maintain cost predictability and avoid unexpected increases that could strain the budget — because price steps after an initial contract term are normal, not exceptional. Model the subscription at its post-promotional rate, not its introductory one.

2025–2026 list prices make the point concrete. Dynamics 365 Business Central Essentials is $80 per user per month and Premium is $110, with Team Members at $8 (Microsoft list effective November 1, 2025). Dynamics 365 Finance or Supply Chain base full users are commonly $210 per user per month, with most F&O full users needing both apps at about $240 combined via attach licensing. Odoo Standard and Custom are all-apps per-user plans (region-dependent list prices on odoo.com/pricing); the official page is explicit that implementation services are not included. Use those list rates as planning anchors, then reprice with a partner quote — and still treat line 1 as a minority of total project spend.

The practical rule for line 1 is to license for named reality, not optimism. Over-licensing wastes money every month for the contract term; under-licensing disrupts operations and forces an emergency true-up — Microsoft’s stricter F&O assigned-license validation (rolling from January 15, 2026 after renewal) is a reminder that unused or mis-tiered seats still become budget noise. Separate core users from occasional users, decide whether you need the premium tier or whether the standard tier covers it, and add a row for every third-party module or app license the project depends on — those add-ons quietly inflate over time. For per-seat economics across platforms, pair this line with our [ERP cost per user](/learn/erp-cost-per-user) breakdown.

Implementation services: the largest and most variable line

Line 2 — implementation services — is almost always the largest single line and the one with the widest pricing variance. The same platform can cost $25,000 or $250,000+ in services depending on scope, partner rate, and how much custom development is in scope. Business Central implementation for a small business (roughly 10–25 users) often lands around $25,000–$45,000 in services, growing SMBs (25–60 users) around $45,000–$90,000, and mid-market (60+ users) $90,000–$150,000+ depending on multi-entity depth and ISVs. Dynamics 365 F&O implementations commonly sit in a much higher band — partner estimators often cite roughly $500,000 to multi-million-dollar programs once multi-legal-entity, multi-site, and heavy integration enter the SOW. That variance is exactly why this line must be estimated as effort times rate, not accepted as a lump sum.

Split the services line into at least four sub-lines: configuration (setting up the standard product to match your processes), custom development (writing code or extensions where configuration cannot reach), project management plus QA, and hypercare (intensive post-go-live SI support). North American Dynamics 365 partners commonly bill in the $150–$250/hour range, so an effort estimate translates almost directly into the dollar figure. Budget hypercare as 30–60 days of tapering support after cutover — many contracts only include one to four weeks, which is where emergency rate cards and overtime appear. The most useful question to ask a partner is not 'what will this cost?' but 'how many days, at what rate, against what scope, what is fixed versus time-and-materials, and how many hypercare hours are in the SOW?'

The single biggest lever on this line is scope discipline. Cudio's review of ERP implementation challenges finds that scope creep — new features added mid-project without proper planning — routinely pushes teams beyond both budget and deadline. Cap customization explicitly, route every change through change control, and treat each accepted customization as a recurring maintenance liability, not a one-time fee. Align the commercial SOW to the six-line budget so every priced work package maps to a line and an exit criterion — practitioners on X still flag projects that approve multi-million ERP programs with zero contingency and a SOW that never matches the spreadsheet. A fixed-price services line with capped hours and a documented change-control process is far more defensible than an open time-and-materials engagement with no ceiling.

Data migration: the under-scoped line

Data migration is the line most consistently under-quoted at proposal stage and most consistently over-budget at go-live. The reason is structural: the cost of moving data is driven almost entirely by the cleanliness and fragmentation of your source data, and that quality is rarely known until someone audits it. A budget that assumes clean data will be wrong by a multiple.

Cudio identifies data migration — especially transferring from outdated legacy systems — as a primary cost driver. The fix is to give migration its own sub-budget built from a real data audit: count the entities (customers, vendors, items, ledgers, open transactions), assess source quality per entity, and estimate cleansing and reconciliation effort separately from the load itself. Reconciliation — proving the new system matches the old — is usually the longest part and the one most often omitted from quotes.

Budget line 3 as if your data is dirty, because it almost certainly is. Reserve separate effort for pre-migration cleansing, for the migration and reconciliation cycles, and for the cutover weekend. If you are migrating from a legacy system you no longer fully understand, raise the contingency on this line specifically.

Integrations and infrastructure: the recurring hidden line

Line 4 captures everything that connects the ERP to the rest of your stack and everything that runs it. It is hybrid: a one-off build cost and a recurring run cost — and the recurring part is what surprises finance in year two. Middleware connecting ERP to e-commerce, CRM, or payroll commonly adds a fixed monthly fee on top of licensing, and that fee persists for the life of the integration.

Build line 4 as two sub-lines. The first is interface build: for each system the ERP must talk to, estimate the connector effort, the data-volume and real-time requirements, and the testing burden (integration testing is where undocumented legacy dependencies surface, at the most expensive moment). The second is ongoing run cost: middleware subscriptions, sandbox and production environments, hosting for any PaaS components, and monitoring. For self-hosted platforms, add the internal IT staff time to keep environments patched — a real if hidden cost.

The discipline is to enumerate every interface explicitly and resist 'we'll integrate that later' deferrals that turn into unbudgeted change orders. An interface not named in the budget at go-live will not be free — it will be an overrun on someone else's line. Also budget dual-run (parallel operation of legacy and new ERP) as temporary OpEx: double entry, reconciliation effort, and often an extension of legacy licenses or support while you stabilize. Dual-run is not free risk insurance — it is a burn rate you should size in days and people.

Training and change management: the value line

Line 5 is where most budgets are quietly under-funded and where most projects quietly fail to realize their benefits. The research on this is unusually clear. Prosci reports that most organizations allocate roughly 92% of their ERP budget to technical activities and only 8% to change management — yet when 1,618 ERP professionals were asked what they would do differently, 36% pointed to people and change-management factors, a 6:1 ratio of human-to-technical recommendations. The money flows to technology; the success drivers flow from people.

Prosci's guidance on funding change management is to treat it as roughly 10% of project costs in large programs — an explicit, named allocation rather than a rounding error inside implementation services. That allocation covers practitioners, training, communications, support for staff, and contingency for adoption issues. For smaller SME projects the percentage may differ, but the principle does not: training and change management must be a first-class line, funded before go-live, not bolted on after adoption stalls.

Treat line 5 as the value line, not a cost line. Under-funded training drives low adoption, which drives re-work, re-training, extended hypercare, and a system that delivers a fraction of its business case. Budget for role-based training (not generic sessions), documentation that survives staff turnover, and a visibly active sponsor — Prosci's research shows an unengaged or resistant sponsor can derail a program however well the other five lines are funded.

Contingency: the reserve that makes a budget defensible

Contingency is the line that separates a budget from a wish. Given that the majority of ERP projects overshoot, a budget with no reserve is simply a wrong forecast. Cudio's guidance recommends a 25–30% contingency to manage overruns and technical obstacles during implementation. TestHouse's finding that 55% of projects exceed budget, with under-governed projects averaging ~72% overruns, is the empirical case for never publishing an ERP budget without a reserve.

Size the contingency to the project's risk profile, not to a flat number. Use 20% as a floor for a clean-scope implementation; push toward 30% when the data is dirty, the scope is loosely defined, or the legacy environment is poorly documented. Allocate contingency at the line level as well as the project level — data migration and integrations deserve a higher sub-contingency than licenses.

The governance of contingency matters as much as its size. A reserve silently absorbed into overruns is not a reserve — it is a bigger original budget nobody admitted to. Release contingency only against documented change orders, with a named approver and a recorded reason. Track burn against the reserve monthly, and treat the reserve dropping below a threshold as a governance signal, not a reason to quietly ask for more.

CapEx vs OpEx: how to structure the budget for finance

How you classify the spend matters as much as the total, because ERP projects straddle capital and operating budgets. The license subscription, recurring middleware, and ongoing support are operating expense (OpEx) — predictable, recurring, expensed as incurred. Implementation services, custom development, and one-off data migration are typically capital expenditure (CapEx) — capitalized and amortized over the asset's useful life. Under US GAAP (ASC 350-40), preliminary-project costs are generally expensed, many application-development costs (configuration, coding, testing) can be capitalizable, and post-implementation items such as training and maintenance are typically expensed — cloud deployments add nuance, so involve finance early.

Structuring the budget along this axis lets finance model cash flow and tax treatment correctly, and exposes the real multi-year picture. Year one is dominated by CapEx build cost plus the first year of subscription OpEx; steady-state years are mostly subscription OpEx plus a smaller run-cost line. Year two is where under-modeled programs fail: post-promo license steps, partner AMS retainers, report rebuilds that never made the project SOW, integration run fees, and internal admin FTE. Build an explicit year-two OpEx pack next to the project total so the board approves both.

This is why total cost of ownership — not first-year cost — should govern platform selection. The 100%–200% of license rule applies across the asset's life, and a cheaper year-one subscription can produce a higher multi-year TCO once hosting, customization, and maintenance compound. For the full multi-year treatment — upgrades, support, and the ongoing maintenance reserve practitioners often keep near 30–40% of initial build cost on modular platforms — our [ERP total cost of ownership](/learn/erp-total-cost-ownership) guide walks through the model. The day-one budget should be the first slice of that TCO, not a disconnected number.

Stage-gate funding, UAT exit criteria, and rolling re-estimates

A budget set once and never revisited will be wrong; the only question is by how much. The defensible approach is stage-gate funding — an upfront envelope refined at each gate as real data replaces assumptions, with the next tranche of money released only when the prior gate's exit criteria are met. Discovery tightens the scope estimate; the data audit tightens migration; solution design tightens integration and customization; UAT proves the system is fit for cutover. Each gate produces a re-estimate, and the gap between original and re-estimate is itself a governance signal.

Write exit criteria into the funding model, not just the project plan. Examples that finance and delivery both understand: discovery complete when scope, interface inventory, and risk register are signed; build complete when configuration freeze is declared and open defects are below a severity threshold; UAT complete when critical scenarios pass with named business owners, open P1/P2 defects are zero or waived in writing, cutover runbook is rehearsed, and hypercare roster is staffed. No UAT exit, no go-live funding draw — and no silent raid on contingency to paper over failed criteria.

Prosci's change-management structure — Prepare for Change, Manage Change, Sustain Outcomes — applies to the whole budget, not just the people line. Budget all three phases upfront so the project does not arrive at sustain with no funding left for adoption support, but release each phase against the prior gate. Stage-Gate style resource decisions work the same way on ERP: larger bets only as information quality improves.

Govern the budget with four mechanisms: a single accountable owner who signs the budget and every change order; monthly burn tracking against each of the six lines, with variance flagged when any line exceeds its phase allocation; a change-control log recording every scope change, its cost, and its approver; and a contingency burn dashboard that treats a reserve falling below a threshold as a governance event, not a reason to quietly ask for more. Budgets do not fail because they were wrong; they fail because nobody tracked the difference.

A worked ERP budget for a 20-user SME

To make the template concrete, here is how a six-line budget might look for a representative 20-user SME implementing a mid-market cloud ERP over a roughly year-long project. These are illustrative allocations showing how the lines relate — not quotes for any specific platform — and the platform-specific dollar ranges belong in our ERP implementation cost guide. The shape is the lesson: services and contingency together dominate, licenses are a meaningful but minority line, and change management is funded as a real allocation, not an afterthought.

Notice how the contingency is sized to the riskier lines (services, data migration) rather than applied flat, and how line 5 is held to a defensible share of the total rather than the 8% industry average.

• →Services + contingency (lines 2 and 6) are over 60% of this budget — the license is the minority, not the majority, of what you will spend.
• →Line 5 is deliberately held near 10%: budgeting change management at the industry's 8% average is budgeting for the adoption problems that erode your business case.
• →Recurring OpEx (subscription + middleware) is excluded from the project total and tracked on its own run-rate line.

Three mid-market ERP budget scenarios (with assumptions)

The 20-user shape above is the right teaching template; most buyers also need order-of-magnitude ranges at larger seats. The three scenarios below are planning envelopes — not quotes — with assumptions stated so you can re-rate them. License list prices reflect commonly published 2025–2026 figures; services ranges compress partner-published mid-market bands and will move with multi-entity depth, dirty data, and customization appetite. Always recompose the six lines from your own user count, interface list, and data audit.

Read the table left to right: licenses are modeled at post-promo list; services include configuration, limited custom work, PM/QA, and a hypercare block; contingency is applied to lines 1–5 at about 25%. Dual-run overtime and year-two AMS are called out as separate notes because they are the lines that vanish from polished SOWs.

• →Odoo’s official pricing page states hosting/support are included on Online plans but implementation services are not — do not treat list subscription as the project budget.
• →Business Central services for 60+ user mid-market work commonly land $90k–$150k+ and climb with manufacturing, multi-entity, and ISVs; license alone at 80 Premium seats is already ~$105k/year at $110 list.
• →F&O is a different budget class: partner guidance often places full implementations between roughly $500k and multi-million depending on entities, sites, and integration depth — seat count alone under-predicts cost.
• →Re-run every scenario through the six-line template before comparing platforms; a cheap license with heavy custom and dirty data will lose to a dearer license with clean scope.

Hidden costs that break an otherwise clean ERP budget

Even a six-line document fails if the lines omit the spend that surfaces after kickoff. These items are predictable — which means leaving them out is a governance choice, not bad luck. For the deeper catalog of post-quote surprises, see the companion guide on [hidden costs of ERP](/learn/hidden-costs-of-erp).

Build a mini checklist next to the six lines and force a dollar or day estimate for each. If the answer is “we’ll absorb it in BAU,” write the FTE hours anyway — internal overtime is still project cost even when it never hits a partner invoice.

1. 01
   Internal FTE and overtime

   Subject-matter experts pulled into workshops, UAT, and cutover weekends. Budget person-days for process owners, finance close support, warehouse leads, and IT — then convert at fully loaded cost. Boards often approve partner fees and ignore the opportunity cost of their best people.

2. 02
   Dual-run / parallel period

   Running legacy and new ERP together means double entry, reconciliation, and often an extended legacy license or support contract. Size dual-run in calendar days × people × systems; long parallel runs are expensive insurance, not free safety.

3. 03
   Report and form rebuilds

   Legacy reports, customer-facing documents, and operational dashboards rarely migrate cleanly. If Power BI, Excel extracts, or print layouts are in daily use, give them a work package — otherwise they become hypercare tickets at premium rates.

4. 04
   Integrations deferred as “phase two”

   An interface not in the SOW is not free later. Ecommerce, EDI, payroll, banks, WMS, and CRM connectors each need build, test, and a recurring middleware or API cost. Name them on line 4 or fund a real phase-two envelope.

5. 05
   Hypercare shortfalls and emergency rates

   One to four weeks of included hypercare is common; stabilization often needs 30–60+ days. When the included block ends, out-of-hours fixes and war-room support hit rate cards the original budget never saw.

6. 06
   Year-two run rate

   Subscription steps after promo, partner AMS retainers, sandbox environments, storage, Copilot or AI add-ons, and continuous improvement backlogs. Approve a year-two OpEx pack with the project budget so go-live is not the day finance discovers the real steady state.

The five mistakes that make ERP budgets wrong by a factor of two

Most ERP budget overruns are not mysterious — they are the predictable result of a small number of structural mistakes made at scoping time. Each maps directly to one of the six lines and to a specific governance choice.

If your budget contains any of the five patterns below, it is a quote with optimism attached, not a defensible budget.

1. 01
   1. Treating the license quote as the budget

   License is one of six lines. A budget the size of the quote is missing roughly half the project — the 100%–200% of license rule is the reality check.

2. 02
   2. Accepting a blended lump-sum services figure

   A lump sum cannot be compared, governed, or audited. Insist on services broken into configuration, custom dev, and PM/QA, estimated as effort times rate.

3. 03
   3. Under-funding data migration

   Budgeting migration as a simple data load, with no cleansing or reconciliation line, is the most common single source of go-live overrun. Budget it from a real data audit.

4. 04
   4. Allocating 8% to change management

   The industry averages 92% technical / 8% people — and the majority of projects fail to realize their benefits. Hold change management to a 10% floor and fund it before go-live.

5. 05
   5. Publishing a budget with no contingency

   Given that most projects overshoot, a zero-reserve budget is a wrong forecast. Size a 20–30% contingency and govern its release against documented change orders — public project chatter still surfaces multi-million ERP programs approved with no contingency line at all.

Where Flectic fits on ERP budgeting

Flectic is a dual-platform ERP implementation partner for SMEs across Microsoft Dynamics 365 Business Central and Odoo, delivered remote-first across Canada, the UK, and the US. Being platform-neutral matters for budgeting: because we are not incentivized to push one stack, we can size the six lines against the platform that fits your scope rather than inflating a line to suit a preferred vendor.

Our delivery model is designed to compress the largest and most variable line — implementation services — by accelerating the manual-heavy work in requirements capture, documentation, QA, and role-based training generation, with expert consultants accountable for quality. That is a real lever on line 2 and, because training material generation is part of it, on line 5 — a delivery target that depends on scope discipline, clean data, and engaged sponsorship, not an unconditional guarantee. If you are building a budget or pressure-testing a quote, the most useful next step is a short readiness call to map your situation onto the six-line template and the mid-market scenarios above — not a sales pitch.

The ERP budgeting checklist

A defensible ERP budget is the product of a handful of disciplines applied consistently. Build the document as six visible lines (with hypercare and year-two OpEx named), size a governed contingency to the riskier ones, fund the people line properly, stage-gate funding to UAT exit criteria, and re-estimate at every gate. Do that and you are already ahead of the majority of ERP projects that overshoot.

• →Build the budget as six lines: license, implementation services (incl. hypercare), data migration, integrations and infrastructure, training and change management, contingency.
• →Total ERP cost is typically 100%–200% of the license fee — if your budget matches the quote, you are missing half the project.
• →Size contingency at 20–30%, weighted toward services and data migration; release it only against documented change orders.
• →Fund change management at a 10% floor, not the industry's 8% average — under-funding the people line is how business cases evaporate.
• →Stage-gate funding: release the next tranche only when exit criteria (especially UAT) are met; track monthly burn against each line with a single accountable owner.
• →Name hidden lines: internal FTE, dual-run, report rebuilds, deferred integrations, and year-two AMS — not only partner fees.
• →Govern the project on total cost of ownership, not first-year cost — the cheaper year-one subscription can produce the higher multi-year TCO.

Frequently asked questions