Our ERP Selection Checklist: What Should Your Business Do?
Choose an ERP with a practical checklist covering requirements, demonstrations, data, costs, partners and the evidence needed before signing.
What is the quick answer?
Start ERP selection with the business problem, decision owners and measurable outcomes. Turn important processes into testable requirements, separate essential gates from preferences and ask suppliers to demonstrate the same scenarios. Compare the complete solution and cost, including data, integrations, training and support. Make the final decision using documented evidence, clear responsibilities and an explicit view of remaining risk.
What should an ERP selection checklist help you decide?
An ERP selection checklist should help you choose a workable operating solution, understand the effort required to introduce it and make a defensible investment decision. A long list of ticked features is not enough. You need evidence that the proposed combination of software, configuration, people and services can support the processes that matter to your business.
The checklist should produce a clear decision trail: why change is needed, what the solution must achieve, which options were examined, what was demonstrated and which risks remain. It should also show what you have decided to postpone. Without those boundaries, a shortlist can gradually become a promise to solve every operational frustration at once.
Use this guide as a sequence of decision questions. Adapt the depth to your organisation, but do not skip an important question merely because a preferred supplier has already emerged. The strongest selection process can explain both why the chosen solution fits and where the business will need to change to make it work.
↑ Back to contentsWhy are we considering ERP now rather than improving the current system?
Describe the business trigger in observable terms. Orders may need repeated rekeying, stock figures may not reconcile, or management may struggle to compare several companies. Explain the effect on work and decisions. “We need a modern system” leaves too much room for people to imagine different outcomes.
Examine whether process changes, better administration or a smaller extension could address the problem. The answer may still support a new ERP, but testing the alternative prevents software replacement becoming the automatic response to poor ownership. Our guide to moving from Xero to Business Central discusses a common point at which growing businesses reconsider the boundary between accounting and operations.
Agree the consequence of waiting and the consequence of changing. Both involve risk. Use a small number of actual examples to support the case, then identify who will verify the expected benefit. The investment discussion should begin with those business needs, before demonstrations and supplier relationships start influencing the shortlist.
↑ Back to contentsWho should own the selection and make the final decision?
Appoint a business sponsor with authority to resolve priorities and a lead who can coordinate the work. Involve finance, operations, relevant commercial teams and the people responsible for technology and data. Users should contribute evidence about the work, while managers remain accountable for decisions about policy and process.
Separate advice from approval. A technical specialist can explain integration constraints without deciding the acceptable commercial risk. A finance director can approve the investment without being the best person to evaluate a warehouse exception. Give each major decision an owner and identify which matters must return to the sponsor.
Protect time for the people whose judgement you need. If they attend demonstrations between normal duties without preparing scenarios, the supplier’s agenda will dominate. Agree how conflicting scores will be resolved and who can change the requirements. A clear decision process is particularly valuable when a persuasive demonstration creates enthusiasm before the business has investigated the details.
↑ Back to contentsWhat outcomes should we define before writing requirements?
Choose outcomes that describe better business performance without promising a result before the causes are understood. For example, the business may want a reliable view of available stock, a more controlled approval process or management reports that do not require several competing spreadsheets. Define the users and decisions each outcome supports.
Record the starting position using information you can reproduce. If the concern is reporting effort, identify the activities included and the people performing them. If the concern is order accuracy, decide what counts as an error. A vague baseline makes later claims of improvement difficult to assess and encourages selective reporting.
Give each outcome an owner, a proposed measure and an explanation of what could influence it beyond the ERP. Do not attribute every improvement to software or assume the system can remove a commercial constraint. Use these outcomes to guide demonstrations and scope choices, then carry them into the implementation and post-launch review.
↑ Back to contentsHow do we turn business processes into useful requirements?
Map a manageable number of important processes from trigger to outcome. Include the people involved, information required, approvals, exceptions and connected systems. Concentrate on the points where the current process becomes difficult or risky. Avoid spending most of the selection effort documenting routine steps that every plausible solution can perform.
For finance, a requirement might concern how an invoice is checked, approved, recorded and reconciled, rather than simply asking whether accounts payable exists. Our Business Central finance implementation services provide context for the design questions behind that process. Apply the same level of specificity to operations and commercial workflows.
Write each important requirement so it can be demonstrated or checked. Identify the business owner and why it matters. Distinguish a required outcome from a familiar way of achieving it. That leaves suppliers room to show a simpler standard process while preserving your ability to reject an approach that does not meet the underlying need.
↑ Back to contentsWhich requirements should be gates rather than weighted preferences?
Some requirements are conditions of proceeding. Others are advantages that can be balanced against cost or effort. Keep these separate. A high total score should not conceal failure to meet an essential operating, contractual or regulatory need. Equally, avoid declaring every preference essential, because that removes the value of prioritisation.
Have the relevant owner confirm each proposed gate and the evidence needed. For a UK finance process, this may include an approved approach to VAT reporting; our Making Tax Digital for Business Central guide explains one area to investigate. The selection team should not invent legal interpretations or assume a product badge settles all compliance questions.
Ask suppliers to identify whether a gate is met through standard functionality, configuration, an additional application or development. Record dependencies and limitations. If evidence is incomplete, mark it unresolved. Do not convert an encouraging sales statement into a confirmed pass simply because the team wants to keep the preferred option on the shortlist.
↑ Back to contentsHow should industry requirements change the checklist?
Investigate the operating detail that distinguishes your business. A manufacturer may need to demonstrate how production differences are investigated. A distributor may need to demonstrate stock handling across locations. A retailer may need a dependable connection between selling channels, returns and finance. Similar module names can hide different practical requirements.
Use the relevant context from our Business Central manufacturing services, supply chain and distribution services and retail ERP services to prepare specific questions. These are starting points for investigation, rather than evidence that every requirement is automatically covered by one product.
Ask experienced staff to supply realistic exceptions and volumes for the demonstration. Include physical equipment, specialist applications and third-party responsibilities where they affect the process. Have the team explain which variations are essential to the business and which are historical habits. Industry fit should be assessed through your work, not inferred from a supplier’s list of sectors.
↑ Back to contentsHow do we build a shortlist without choosing by brand alone?
Begin with a small number of plausible operating approaches and investigate their fit. Consider the business model, organisational structure, process complexity, existing technology and ability to manage change. Company headcount alone is a weak shortcut. Two organisations of similar size may need very different systems and delivery arrangements.
Our Business Central introduction and Business Central versus NetSuite comparison can support early research. NetMonkeys focuses on Microsoft business applications, so a buyer should still require evidence of fit rather than treat a partner recommendation as a substitute for evaluation.
Record why each shortlisted option deserves further examination and why other options were excluded. Keep the reasoning proportionate and reviewable. Do not add more vendors simply to make the process look thorough, or exclude a credible option only because it is unfamiliar. The objective is enough comparison to make a confident decision, with time left for meaningful validation.
↑ Back to contentsWhat should we ask suppliers to demonstrate?
Issue the same core scenarios to each supplier, using representative information and an agreed explanation of what the business needs to see. Include a normal transaction, a relevant exception, a control and the resulting report or evidence. Give suppliers enough preparation time to show a coherent solution rather than testing their ability to improvise.
During the demonstration, ask who performs each action, what is configured and what remains to be built. Have process owners attempt or explain the task where practical. Note the difference between a completed transaction and a statement that something could be developed. Record unanswered questions while the discussion is fresh.
Evaluate the proposed operating process, not presentation confidence. A shorter route is helpful only if the right controls and evidence remain. Ask what happens when information is missing, a connection is delayed or someone is unavailable. Finish with an agreed list of evidence supplied, gaps identified and follow-up actions needed before the supplier receives a final score.
↑ Back to contentsHow should we assess standard features, add-ons and development?
Create a fit-and-gap record for the important requirements. State how each is met, the responsible supplier, any additional licence and the implementation work involved. Avoid a single “yes” that combines standard functionality with an unscoped development idea. Those routes can create different costs and support responsibilities.
An additional application can be a sensible choice when it solves a specialist problem well. Our Business Central ISV add-ons guide describes this part of the ecosystem. Investigate the actual application, its dependencies, maintenance arrangements and compatibility commitments rather than assuming all extensions behave in the same way.
For development, ask why a standard process or supported application is insufficient. Define the desired outcome, acceptance tests and future ownership. Do not reject development automatically, but recognise that it creates something the business must maintain. Make those responsibilities visible in the decision instead of leaving them for the implementation team to discover after the contract is signed.
↑ Back to contentsWhat data and migration questions belong in selection?
Identify the data needed to operate the new solution and the information retained for reference or other obligations. Include master records, opening positions, open transactions and relevant history. Ask who owns quality decisions and how the business will reconcile the result. “The data will be migrated” is not a sufficiently defined deliverable.
Legacy changes can require more investigation than the current system’s name suggests. Our NAV 2013 migration guide provides an example of the wider questions involved. In your selection, establish which source systems, custom fields and integrations need assessment before a supplier can confirm its proposed scope.
Request a realistic explanation of trial migrations, correction cycles and acceptance evidence. Keep the business involved in deciding which records should move and how mappings should work. A supplier can provide migration expertise, but it cannot reliably determine the meaning of every historical record without help from the people who own the process.
↑ Back to contentsHow should integrations and reporting affect the decision?
List the connections needed for critical work, including the information exchanged, frequency, responsible systems and failure handling. Confirm whether each connection exists in the proposed solution, needs configuration or requires additional work. A named connector is not proof that your entire business scenario has been designed.
For reporting, start with the questions users need to answer and the definitions behind the measures. Identify where data originates and who approves the calculation. Ask the supplier to show how users investigate a total or exception. A polished dashboard can be a useful interface, but it cannot resolve conflicting business definitions by itself.
Bring these dependencies into the discussion with a Business Central implementation partner before finalising scope. Agree who coordinates third parties and who accepts the end-to-end result. Otherwise, the selected ERP may work correctly in isolation while an essential operating process remains incomplete between applications.
↑ Back to contentsHow do we compare total cost rather than headline licence prices?
Use a common cost model covering the agreed evaluation period. Include subscriptions, implementation, data work, integrations, applications, training, internal staff time and ongoing support. Separate confirmed amounts, assumptions and items awaiting discovery. A detailed-looking spreadsheet can still mislead if it treats uncertain costs as fixed.
Read the relevant current licensing terms for the proposed roles and usage. Microsoft’s Business Central licensing guidance is one reference for a Microsoft shortlist. Do not infer licence rights from a demonstration login or assume a limited-access licence permits every task an employee intends to perform.
Run a small number of business scenarios through the model, such as adding a location, increasing users or introducing an additional application. Ask what changes commercially and operationally. This is not a prediction of future prices; it is a way to expose assumptions. Present the likely cost drivers and remaining uncertainty alongside the comparison so management understands what it is approving.
↑ Back to contentsWhat should we evaluate about the implementation partner?
Assess the proposed delivery team and working arrangements as well as the company presentation. Ask who will lead discovery, make design recommendations, coordinate dependencies and remain available during launch. Relevant experience is useful, but the buyer still needs a credible plan for its own processes and constraints.
Discuss how the partner challenges unsuitable requirements, records decisions and handles changes. Ask what it needs from your employees and how it will identify a missed decision. A proposal that assigns every difficult dependency to the customer without explaining the effect may transfer risk without helping the business manage it.
Request references or examples through appropriate channels and ask questions connected to your concerns. Confirm support ownership, documentation and handover arrangements before signing. Keep a record of promises that influenced selection and ensure the final agreement reflects them. A constructive relationship depends on clear responsibilities, not on assuming both parties attach the same meaning to broad phrases such as end-to-end delivery.
↑ Back to contentsHow should we score options and manage uncertainty?
Agree the scoring approach before final demonstrations. Weight requirements according to their importance to the business and have the relevant owners explain their scores. Keep mandatory gates separate. Record the evidence behind a result and distinguish a confirmed capability from an assumption or a promise awaiting validation.
Use the score to organise judgement, not replace it. If two options finish close together, examine the differences and unresolved risks rather than manufacturing false precision. Ask how the decision changes if an uncertain assumption proves wrong. A small numerical advantage may matter less than a dependency the business cannot realistically manage.
Give significant risks an owner, a proposed response and a decision date. Some may require further discovery or a limited proof of concept. Others may be accepted explicitly. Do not bury uncertainty in a positive overall score. Management should be able to see what is known, what is still being tested and which consequences it is agreeing to carry forward.
↑ Back to contentsWhat must be agreed before we sign and begin implementation?
Bring the selection evidence into a clear scope, delivery plan and commercial agreement. Confirm outcomes, assumptions, exclusions, responsibilities, acceptance evidence and change handling. Ensure the first phase is practical for the business and identify decisions that must be completed before detailed delivery can proceed.
Microsoft’s Success by Design guidance describes a framework for addressing Dynamics 365 implementation risks. A framework can inform your questions, but it is not a guarantee of results or a replacement for a plan suited to your organisation.
Close the selection with a decision record that names the chosen approach, reasons, rejected alternatives and unresolved actions. Assign ownership of benefits and carry the agreed scenarios into implementation testing. The best checklist does not disappear after purchase. It becomes a set of commitments the business and delivery team can use to check that the solution being introduced still answers the needs that justified the investment.
↑ Back to contentsWhat else do businesses ask?
Should we choose the ERP or the partner first?
Evaluate the proposed product and delivery arrangement together. A plausible product still needs a partner and internal team capable of delivering the agreed processes, integrations and support model.
How many ERP suppliers should we compare?
Use a manageable shortlist of credible options. There is no universal ideal number. Preserve enough time for realistic demonstrations and investigation rather than collecting many superficial presentations.
Can the cheapest ERP quote be the best choice?
It can, if the scope, responsibilities and continuing costs meet your needs. Compare the same operating requirements and assumptions before treating a lower headline amount as better value.
Does a high feature score prove that an ERP will work for us?
No. Check mandatory requirements, evidence quality, implementation capacity and unresolved dependencies. A weighted score supports judgement; it should not conceal a critical gap or replace a realistic delivery plan.
Who wrote this guide, and how was it checked?
Written by Caleb Adoh, Growth Marketing Manager at NetMonkeys. Reviewed on 2 November 2026 using the linked Microsoft licensing and implementation framework references. The checklist, evaluation methods and examples are original editorial guidance. Verify current terms and obtain appropriate advice on specific contractual or regulatory requirements.
How can NetMonkeys help your business?
Talk to our team about your priorities and agree a practical next step.
Speak to NetMonkeys
