For many IT and operations leaders, choosing the right ERP system is only half the battle. The harder task is often convincing the board to release the budget. Board members think in terms of risk, return and strategic priorities, not features and functionality. If your business case reads like a product brochure, it is unlikely to land.
This guide sets out a practical approach to building an ERP business case that speaks the board’s language, along with the objections you are likely to face and how to answer them credibly.
Why ERP Business Cases Often Stall at Board Level
ERP projects are large, visible and disruptive by nature, which makes boards understandably cautious. In our experience working with Irish professional services and mid-market organisations, business cases tend to stall for a handful of recurring reasons:
- The case is framed around technology rather than business outcomes
- Costs are clear but benefits are vague or unquantified
- There is no clear owner accountable for delivering the value
- Risk and change management are treated as an afterthought
- The timeline underestimates the effort required from internal teams
Addressing these points early, before the proposal reaches the boardroom, significantly improves your odds of approval.
6 Steps to Build a Board-Ready ERP Business Case and Secure Approval
1. Start With the Business Problem, Not the System
Boards approve solutions to problems, not software. Before any conversation about platforms or vendors, be precise about what is actually broken today. Is finance closing the books late every month because of manual reconciliation? Are project margins hard to see until a job is already over budget? Is customer service response time slipping because agents lack a single view of the customer?
Framing the investment around a named, felt problem gives the board something concrete to weigh against the cost. “Our current system cannot give us real-time project margin visibility, so we discover overruns after the fact” is a far stronger opening line than “we need to modernise our ERP.”
2. Build the Financial Case Around Metrics the Board Already Tracks
Boards are typically already monitoring a set of metrics: revenue growth, margin, cash conversion, headcount efficiency, compliance exposure. Your business case should map ERP benefits directly onto these existing metrics rather than introducing new ones.
Useful categories to work through include:
- Cost reduction: Lower licensing and maintenance costs from consolidating legacy systems, reduced manual processing time, fewer errors requiring rework.
- Revenue enablement: Faster quote-to-cash cycles, better visibility into project profitability, improved ability to bid on larger or more complex contracts.
- Risk reduction: Improved audit trails, stronger compliance posture, reduced dependency on unsupported legacy systems or key individuals holding institutional knowledge.
- Working capital: Faster invoicing, improved debtor days, better inventory or resource utilisation.
Where possible, tie each benefit to a rough estimate and be transparent about your assumptions. Boards are generally comfortable with reasonable ranges and clearly stated assumptions. What tends to undermine credibility is precision that cannot be defended under questioning, so avoid presenting speculative figures as guaranteed outcomes.
3. Address Total Cost of Ownership Honestly
One of the fastest ways to lose board trust is an incomplete cost picture. Beyond licensing, a credible TCO should include implementation and consulting fees, data migration, internal staff time, training, and ongoing support. Cloud ERP platforms such as Business Central typically shift much of this cost from large upfront capital expenditure to predictable operating expenditure, which is often a point in favour of the business case, but it should still be presented in full rather than understated.
If you are migrating from an on-premises system nearing end of support, the cost of inaction is also worth quantifying. Continuing to run an unsupported platform can carry hidden costs in security exposure, integration limitations and the difficulty of finding staff or partners willing to support ageing infrastructure.
4. Anticipate the Objections You Will Get
Board members tend to raise a fairly predictable set of concerns. Preparing answers in advance signals that you have thought the project through.
- “Why now?” Tie the timing to a specific trigger: end of vendor support, a compliance deadline, a growth plan that the current system cannot support, or a competitor gap.
- “What if it goes over budget or over time?” Reference how the implementation partner scopes and phases the project, and what contingency has been built in. A phased rollout, rather than a single big-bang go-live, is often easier for boards to approve because it limits exposure at any one stage.
- “What is the disruption to the business?” Be candid about the change management effort required, including training time and the likelihood of a short-term dip in productivity during go-live. Boards tend to trust cases that acknowledge disruption rather than ones that promise a seamless transition.
- “Who is accountable for the benefits being realised?” Name an internal owner, ideally someone with both the authority and the incentive to see the project through to value realisation, not just implementation.
5. Bring the Right Evidence
Wherever possible, support your case with reference points rather than assertions. Case studies from similar organisations, vendor benchmarks, and input from your implementation partner on typical timelines and outcomes all help. If you cite statistics or specific outcomes from other projects, make sure they are sourced and can be verified if a board member asks.
A short pilot, proof of concept, or vendor demonstration tailored to your own data can also be more persuasive than any slide deck, since it lets the board see the system working against a problem they recognise.
At Yes Dynamic, we typically bring this evidence into the boardroom conversation directly, sharing comparable Microsoft Dynamics 365 implementations from other Irish organisations, so the board is weighing a proposal grounded in precedent rather than projection.
6. Structuring the Proposal Itself
A board paper for ERP investment generally works best when it follows a tight structure: the business problem, the proposed solution and why it was selected, the financial case including TCO and expected benefits, the implementation approach and timeline, key risks and how they will be managed, and a clear recommendation with next steps. Keep the paper itself concise, with supporting detail available in an appendix for anyone who wants to go deeper.
Final Thought
Getting board buy-in for ERP investment is less about the strength of the platform and more about the strength of the argument. A business case built around a clearly defined problem, benefits tied to metrics the board already cares about, an honest cost picture and a credible plan for managing risk gives your proposal the best possible chance of approval.
If you’re preparing a board case for ERP investment, Yes Dynamic can help build the financial model, TCO breakdown and implementation plan that gives your proposal credibility from the outset. Get in touch to talk through your specific situation.
Get in touch