The Complete Guide to Choosing an ERP for Mid-Market Companies

ERP selection is among the most consequential decisions a CFO will make. Unlike a point solution that handles one function, an enterprise resource planning system becomes the central nervous system of a business — touching finance, operations, supply chain, and often HR and manufacturing simultaneously. When selections go well, companies gain years of operational leverage. When they go poorly, the costs are severe: failed mid-market ERP implementations routinely run $500,000 to $2 million or more when you factor in sunk vendor fees, consulting overruns, opportunity cost, and the organizational disruption of starting over.

The reasons selections fail are well documented. Companies talk to vendors before defining requirements. They optimize for price instead of fit. They underestimate implementation complexity. They choose the ERP but ignore the implementation partner, who often determines the actual outcome. This guide is a systematic framework for avoiding those mistakes — walking through the selection process from initial scoping through business case construction, with particular attention to the decisions that most commonly go wrong.

Understanding the Mid-Market ERP Landscape

The mid-market is broadly defined as companies with $50 million to $1 billion in annual revenue, though the operational complexity of a $50M manufacturer can exceed that of a $300M professional services firm. What unites mid-market buyers is a set of shared constraints: they need enterprise-grade functionality, but lack the internal IT resources and budget of a large enterprise. They've outgrown QuickBooks and basic accounting software, but are not yet ready for SAP's full suite complexity.

The primary vendors competing for mid-market ERP share include:

• NetSuite (Oracle): The dominant cloud-native ERP for mid-market, particularly strong in software, services, and multi-entity organizations. Typically $50K–$300K annually in subscription fees depending on modules and user count.
• SAP S/4HANA: SAP's modern cloud ERP, relevant for larger mid-market companies ($300M+) with manufacturing or supply chain complexity. High implementation cost but deep functionality.
• Microsoft Dynamics 365: Strong for companies already in the Microsoft ecosystem. Modular architecture allows phased adoption. Finance and Operations (F&O) and Business Central serve different mid-market segments.
• Oracle Cloud ERP: Competes primarily with SAP at the upper end of mid-market. Strong financial management and planning capabilities.
• Acumatica: Cloud-native with consumption-based pricing (not per-seat), popular with distribution, construction, and manufacturing companies in the $20M–$200M range.
• Sage Intacct: Best-of-breed financial management platform, particularly strong for multi-entity, nonprofit, and professional services. Often positioned as a financial system of record rather than full ERP.

Understanding where each vendor excels — and where they struggle — is essential context before entering any selection process. Vendor strengths are not universal; they are industry- and use-case-specific.

Step 1 — Define Your Requirements Before Talking to Vendors

This is the single most important step in the process, and the one most frequently skipped. Companies schedule vendor demos before they have completed a requirements document, which means they end up evaluating vendors on the vendor's terms rather than their own. Vendors are skilled at making their software look capable of almost anything in a demo. The only way to cut through that is to arrive with documented requirements that force the vendor to demonstrate specific functionality against your actual business processes.

Functional Requirements

Document the functional requirements for each module area that will be in scope. For most mid-market companies this includes: core financial management (GL, AP, AR, fixed assets), consolidations and multi-entity reporting, procurement, inventory and warehouse management (if applicable), manufacturing and production (if applicable), project accounting (if applicable), and HR/payroll (if you want an HCM module or need integration with an existing HCM). For each functional area, identify the specific processes, transaction volumes, and reporting needs that matter most.

Non-Functional Requirements

Non-functional requirements are as important as functional ones and are often underweighted. These include: cloud vs. on-premise deployment preference, scalability requirements (where will this company be in five years?), integration requirements with existing systems (CRM, e-commerce, payroll, bank feeds), security and compliance requirements (SOC 2, HIPAA, government contracting), and performance requirements for report generation and transaction processing at peak periods.

Current Pain Points Inventory

Document the specific pain points driving the evaluation. Are monthly close processes taking longer than two weeks? Are finance teams maintaining parallel spreadsheets because the existing system can't handle consolidations? Is there no real-time visibility into inventory? Explicit pain points become the baseline against which you measure whether a new system solves the actual problem.

Step 2 — Establish Selection Criteria and Weighting

Before evaluating any vendors, define the criteria by which they will be scored and the relative weight of each criterion. This prevents post-hoc rationalization of decisions made for unstated reasons (often price). A standard mid-market ERP weighting framework:

These weights should be adjusted for your specific situation. If your company has a complex technical integration environment, weight implementation complexity higher. If you are in a capital-constrained growth phase, TCO may carry more weight.

Step 3 — Build Your Vendor Longlist and Shortlist

A structured vendor identification process prevents both overlooking strong candidates and wasting time on poor fits. To build a longlist, draw on: analyst reports (Gartner Magic Quadrant, Forrester Wave, G2 reviews), peer networks and CFO communities, industry associations, and formal RFI responses from vendors. An RFI (Request for Information) is a short document you send to 8–12 vendors asking structured questions about their capabilities, typical customer profile, and rough pricing ranges.

From the longlist, narrow to 3–4 shortlisted vendors for in-depth evaluation. The shortlisting process should disqualify vendors that fail any of these criteria: no reference customers in your industry at your approximate revenue scale, inability to meet a must-have functional requirement, pricing that clearly exceeds budget ceiling even at the low end, or deployment model incompatibility (e.g., you require cloud and the vendor is primarily on-premise).

Three to four vendors is the right shortlist size. More than four creates evaluation fatigue for your team and signals to vendors that you are not a serious buyer, which can affect the quality of attention and pricing you receive.

Step 4 — The Demo and Evaluation Process

Generic vendor demos are largely useless for selection purposes. Vendors are practiced at showing their software in the best possible light through carefully sequenced workflows. The only demos that produce useful evaluation data are scripted demos — where you provide the vendor with a specific scenario document and require them to demonstrate your actual business processes, with your actual data where possible.

Scripting the Demo

Provide each vendor with a scenario document two weeks before the demo. The document specifies 8–12 business process scenarios drawn from your requirements document: how a multi-entity consolidation is prepared, how an intercompany transaction is recorded and eliminated, how a purchase order approval workflow is configured, how a manufacturing job order is tracked through the system. The vendor must demonstrate each scenario live — not a slide deck, not a pre-recorded video.

Stakeholder Involvement

Include subject matter experts from each department in the relevant demo sections. Your controller should score the financial management demo, your supply chain manager should score the procurement demo. Decentralized scoring with defined criteria is more reliable than a single evaluator's impressions.

Reference Checks

Require each shortlisted vendor to provide 3–5 reference customers in your industry and revenue range. Ask references: How long did implementation take versus what was scoped? What was the final cost versus initial quote? What has post-go-live support been like? Would you select this vendor again? What do you wish you had known before starting? The answers to the last question are often the most useful.

Step 5 — Total Cost of Ownership Analysis

TCO analysis is the most frequently underestimated component of ERP selection. License fees are visible and easy to compare. Everything else — implementation costs, internal resource costs, training, data migration, customizations, and ongoing support — is often discovered after the contract is signed. Build a five-year TCO model before signing anything.

Cost Components

• License or subscription fees: Annual SaaS fees, per-seat or module pricing. Get quotes for your current user count and a projected count in three years.
• Implementation partner fees: Typically the largest single cost component. Mid-market implementations range from $150,000 to $1 million or more depending on scope and complexity.
• Internal resource costs: The most underestimated line item. An ERP implementation requires significant time from your finance, IT, and operations teams who have other jobs. Assign a dollar value to this time.
• Data migration: Cleaning, mapping, and migrating data from legacy systems is often scoped separately and can add $25,000–$100,000.
• Customizations and integrations: Any deviation from standard functionality carries ongoing maintenance cost. Every custom integration must be maintained through future upgrades.
• Training: Initial training for all users plus ongoing training for new hires and feature releases.
• Ongoing support and maintenance: Annual support fees, upgrade management, and administration. For cloud systems, this is often bundled; for on-premise, it is a separate significant cost.

Step 6 — Selecting an Implementation Partner

In most mid-market ERP implementations, the implementation partner matters as much as — or more than — the software itself. A capable, experienced partner can navigate around product gaps. An inexperienced partner can turn a strong product into a failed project. This is not an exaggeration: the majority of ERP failure post-mortems identify implementation partner deficiencies as a primary cause.

Evaluate implementation partners separately from the software vendor. Just because a partner is certified by the vendor does not mean they are qualified for your specific industry or implementation scope. Key partner evaluation criteria: number of completed implementations at companies of your size and industry, average go-live timeline vs. scoped timeline for recent projects, team stability (will the people who sold you the engagement actually work on it?), and references from clients with similar complexity.

For a more detailed framework on partner selection, see the ERP Implementation Partner Selection Guide.

Red Flags in the ERP Selection Process

Certain vendor and process behaviors predict poor outcomes with reasonable reliability:

• Extreme customization promises: A vendor who assures you that the system can be configured to exactly match your existing processes is selling you a custom development project, not a packaged ERP. Standard functionality should cover 80–90% of your needs; the remaining 10–20% should come from process adjustment, not custom code.
• No industry references at your scale: A vendor who cannot provide three customer references in your industry at your approximate revenue size has not proven the product in your context. References are not optional.
• Implementation timelines that seem too aggressive: A vendor promising a 90-day go-live for a multi-module mid-market implementation is either omitting scope or has not done this before. Ask specifically what is included in the stated timeline and what would push it out.
• Bundled all-in-one pricing with no itemization: You cannot evaluate what you're paying for without an itemized quote. Unitemized pricing makes scope creep and change orders impossible to dispute.
• Excessive focus on features, not outcomes: Vendors who demo features without connecting them to your specific business problems are product-selling, not solution-selling. Ask them: how does this capability address the specific pain point we documented?

Building the Business Case for Your ERP Investment

The business case for an ERP investment must quantify both cost and benefit over a defined time horizon (typically five years). The cost side is covered by the TCO analysis above. The benefit side requires rigorous estimation of specific, measurable outcomes — not vague claims about "operational efficiency."

Common quantifiable benefits in mid-market ERP implementations include: reduction in monthly close cycle time (a close that goes from 15 days to 7 days frees up meaningful finance team hours annually), elimination of parallel spreadsheet maintenance (track hours spent maintaining off-system data and value them), reduction in inventory carrying costs through better visibility (usually 5–15% of inventory value), accounts payable early-payment discount capture that was previously missed due to manual processes, and reduction in external audit fees driven by improved controls and audit-ready financials.

Build the financial model conservatively. Assign probabilities to benefit realizations, discount for time to full adoption, and present a base case, upside case, and downside case to your board or executive team. An ERP investment with a payback period longer than four to five years deserves additional scrutiny of either the cost structure or the benefit assumptions.

Common Mistakes Mid-Market CFOs Make

• Underinvesting in change management: Technology is rarely the reason ERP implementations fail. People and process adoption are. Budget explicitly for change management — communication plans, training programs, superuser networks, and executive sponsorship. Many implementation budgets allocate nothing to change management and then wonder why user adoption stalls.
• Not defining success metrics before go-live: What does success look like at 90 days? At one year? Specific, measurable post-implementation success criteria should be agreed upon before contract signing, not derived after the fact.
• Choosing based on price alone: The cheapest ERP option is almost never the lowest total cost. Cheap license fees are often associated with higher implementation complexity, weaker out-of-box functionality that requires customization, or lower-quality support — all of which increase five-year TCO. Optimize for value, not initial price.
• Letting IT lead the selection without sufficient finance ownership: ERP is fundamentally a financial management system. The CFO and Controller must be the primary owners of the selection process, with IT as a key stakeholder — not the reverse.
• Scope expansion mid-implementation: Every addition to scope after contract signing extends the timeline and increases cost. Maintain a formal change control process and be ruthless about deferring nice-to-have features to Phase 2.