ERP for Mid-Size Companies The Conversation You Actually Need

What 'ERP for mid-size company' really means

ERP for a mid-size company is not a product category — it is a conversation about a specific operating band, and that band behaves differently from both ends of the market it sits between. Analyst and vendor material converges on a working definition: mid-market ERP is enterprise-grade software scaled for organisations too large for entry-level accounting tools but too lean for Tier 1 suites. ERP Research frames the core as the 251–1,000 employee band, while noting that searchers describe the mid-market as anywhere from 50 to 5,000 employees; by revenue, Panorama Consulting's tier model places the bulk of this group in Lower Tier II ($10M–$250M) bleeding into Upper Tier II ($250M–$750M). The exact threshold matters less than the implication: these companies carry real operational complexity across multiple departments, real regulatory obligations, and a real need for cross-functional visibility, yet rarely have the budget or change-management capacity of a Fortune 500.

That combination — real complexity, lean capacity — is precisely why the generic ERP conversation fails here. The small-business playbook ('lowest entry price, fastest start') under-weights the multi-entity and integration problems a mid-size firm already has today. The enterprise playbook ('governance, customisation depth, global consolidation') over-engineers the decision, inflates the timeline, and commits a mid-market budget to complexity the organisation may never absorb. A 300-person manufacturer with two subsidiaries, an e-commerce channel, and a payroll integration is not best served by either neighbour's script.

This guide is deliberately scoped to the framing question: what makes the mid-size ERP conversation different, and which three lenses should dominate it. If you want the structured selection process and weighting scorecard, that lives in our SME ERP selection guide. If you want the technical capacity limits and scaling triggers of specific platforms, our ERP scalability guide covers that. Neither re-asks the question this page answers: why the mid-market is its own conversation in the first place, anchored on multi-entity reality, the process-maturity gap, and integration load.

The three lenses that define the mid-market conversation

Across analyst guidance, implementation-partner consensus, and the failure patterns that recur at this size, three lenses separate a mid-market ERP conversation from a generic one. The first is multi-entity reality: by the time a mid-size firm replaces its ERP, it is frequently running several legal entities, locations, or currencies — sometimes across borders — and that is a here-and-now requirement, not a future 'enterprise' need. The second is the process-maturity gap: mid-market firms have processes that are documented just enough to expose where they are inconsistent, but rarely standardised or clean enough to configure directly into a new system. The third is integration load: a mid-market ERP does not live alone, and the cost of connecting it to CRM, e-commerce, payroll, EDI, and reporting tools quietly becomes one of the largest line items in the project.

These three are not the only things that matter — total cost of ownership, functional and industry fit, ease of adoption, and partner quality all belong in a complete evaluation, and several are covered in depth elsewhere on this site. But for the mid-market band specifically, these three lenses are where the conversation is won or lost, because they are the ones that compound over the system's life and the ones mid-market buyers most consistently under-weight when they import a playbook built for a different size band. A system that demos beautifully but cannot consolidate a second subsidiary, that demands customisation for processes that were never standardised, or that turns every integration into a one-off build is a mid-market failure waiting to happen.

The rest of this guide works through each lens in turn, then shows why both the SMB and enterprise scripts misfit the middle, how the vendor tiers map onto this band, and how to brief a mid-market ERP project so the conversation starts in the right place.

Multi-entity is the default state, not a future enterprise need

The first thing that breaks the small-business script at mid-market scale is that multi-entity is no longer hypothetical. ERP Research is blunt on this: growing mid-market companies are frequently multi-entity by the time they replace their ERP — several legal entities, locations, or currencies, sometimes across borders. That means native multi-entity consolidation, intercompany transactions, multi-currency, and local tax and statutory reporting are selection requirements on day one, not features to evaluate against a distant growth roadmap. The practical test is whether the platform handles these natively through a shared data model, or whether cross-entity reporting has to be custom-built — because the bolt-on path is exactly where mid-market agility goes to die.

Panorama Consulting's independent analysis of ERP scalability lands the same point from the opposite direction: while most vendors claim to support multi-entity operations, the way they deliver it varies widely, and in some systems cross-entity reporting requires custom development. Their case work shows organisations 'patching their systems with manual workarounds that reduce the very agility the ERP was supposed to enable' — and crucially, they locate the failure not in infrastructure but in how the system was originally configured for future-state complexity. For a mid-size buyer, the implication is operational, not technical: insist on a shared vendor and customer master across entities, real-time consolidation rather than a manual roll-up, and intercompany and multi-currency that work out of the box.

This lens also determines when the conversation stops being 'mid-market ERP' and starts being a two-tier question. A single-entity mid-size firm is well served by a Lower Tier II platform; a mid-size group with a complex parent and several disparate subsidiaries may genuinely need a Tier 1 backbone at HQ and a lighter Tier 2 layer at the edges. Our two-tier ERP guide covers that architecture in depth, but the framing point matters here: do not let a vendor sell a single-instance enterprise suite to a firm whose real need is a well-configured mid-market platform with genuine multi-entity headroom, and do not let a lightweight tool under-serve a group that is already a small enterprise. Naming where you sit on that spectrum is the first honest act of a mid-market ERP conversation.

• →Multi-entity, multi-location, and multi-currency are day-one requirements at mid-market, not future enterprise features
• →Insist on native consolidation, intercompany, and shared master data — not custom cross-entity reporting
• →Scalability failures surface in configuration for future complexity, not in the underlying infrastructure
• →A complex parent-plus-subsidiaries structure may be a two-tier question, not a single-instance one

The process-maturity gap: documented enough to expose, not clean enough to configure

The second lens is the one mid-market buyers most often discover mid-implementation, and it is the one that decides whether the project becomes a configuration exercise or a customisation treadmill. Mid-size firms occupy a specific process-maturity band: their workflows are usually documented just enough to expose where they are inconsistent — different order-to-cash steps across sales channels, two ways of closing the month in two entities, a quoting process that lives in a founder's head — but they are rarely standardised or clean enough to configure directly into a new system's standard flows. That gap is not a failing; it is the normal state of a company that grew faster than its process discipline. But it becomes decisive the moment an ERP forces a choice between adapting the process and bending the system.

Independent practitioner guidance from consultants who work with mid-sized manufacturers is consistent on the right call: look for solutions that deliver roughly 90% of the needed functionality out of the box, plus a personalisation layer to bridge the gaps, rather than demanding a perfect functional match. The reasoning is that if you are evaluating solutions built for your industry, they will be a good fit in many ways, and something during implementation will inevitably surface that you are not crazy about — that is normal, not a fatal flaw. The mid-market discipline is to standardise the inconsistent processes against the system's best-practice flows before you customise the system to replicate the inconsistency. NetSuite's own ERP primer reinforces the same principle: the prebuilt functionality in modern ERP is based on best practices gathered from thousands of companies, and it is a best practice to minimise customisations.

Why this lens is specifically mid-market is a matter of capacity. An enterprise can afford to maintain a heavily customised system because it has a dedicated IT function and the budget to regression-test bespoke code on every upgrade. A small business rarely has the inconsistent-process problem at scale because its processes are simpler. The mid-market firm has the complexity and the inconsistent processes but the thin team — which means every line of custom code becomes a permanent dependency on the implementer and a tax on every future upgrade. ERP Research notes that business-process re-engineering is typically part of a mid-market project and that these projects fail more often from weak user adoption and change management than from technology. Framed correctly, the process-maturity conversation is not 'how do we replicate what we do today' but 'which of our processes should we standardise before we configure, and which genuinely deserve customisation.'

Integration load is the hidden cost that dominates the project

The third lens is the one that most reliably blows a mid-market budget, because the cost lives in architecture rather than licensing and therefore hides until it is too late. A mid-market ERP does not stand alone: it has to connect to CRM, e-commerce, payroll, EDI, a BI or reporting layer, and frequently a specialist manufacturing or logistics tool. Integration specialists observe that most organisations only ask the architecture question once the third or fourth integration is already on the planning — by which time two have been built without a shared philosophy, and the bill arrives eighteen months later in support that becomes too expensive and in connections that break every time a vendor bumps an API version.

The reason this lens is especially sharp at mid-market is that the firm has enough connected systems to feel the pain but rarely the integration maturity to architect around it. The dominant failure pattern is point-to-point integration: one system talks directly to another through a bespoke script or connector, which is quick and cheap for the first twelve months but grows complexity quadratically — four systems need six lines of upkeep, five need ten. The threshold where a central middleware or iPaaS layer starts to pay for itself is roughly four to five connected systems, at which point each source connects once to a hub rather than N times to peers, and monitoring collapses into one place. For a mid-market estate that is already at or past that threshold, treating integration as an afterthought is the single most expensive framing error available.

The scale of the problem is visible in the broader integration data. MuleSoft's Connectivity Benchmark, cited in 2026 integration reporting, puts the average enterprise at 897 applications with only 29% integrated — meaning the majority of business applications remain disconnected, creating the manual workarounds and data silos that mid-market operators recognise instantly. The three-year cost picture is equally instructive: practitioner pattern-recognition across many engagements puts integration build at only about 30% of three-year TCO, with support and monitoring at 30–40%, repair after API changes at 15–20%, and indirect costs — data issues, double bookings, productivity loss — at the remainder. An integration that looks 15% cheaper on the initial quote can end up 40% more expensive over three years if the architecture does not fit the estate. Our ERP integration patterns guide works through the models in detail; the framing point for the mid-market conversation is that integration must be scoped, costed, and architected before the licence is signed, not after go-live.

• →A mid-market ERP connects to CRM, e-commerce, payroll, EDI, and BI — and that work dominates project cost
• →Point-to-point integration grows complexity quadratically; the iPaaS threshold is roughly 4–5 connected systems
• →Integration build is only ~30% of three-year TCO; support, API repair, and indirect costs are the rest
• →Scope and architect integration before the licence is signed, not after go-live

Why both the SMB and enterprise playbooks misfit the mid-market

A recurring source of mid-market errors is importing a framework built for a different size band, and the three lenses explain exactly where each neighbour's script breaks. The small-business playbook optimises for lowest entry price and fastest start — which is correct when the alternative is spreadsheets and the budget is genuinely thin — but it under-weights all three mid-market lenses simultaneously. It treats multi-entity as a future problem, treats process standardisation as unnecessary because the owner knows the processes, and treats integration as a single CRM sync. A mid-size firm that imports that script lands on a tool that fits the demo and breaks the business within three years.

The enterprise playbook misfits in the opposite direction. It optimises for governance, customisation depth, and global consolidation — correct for a multinational with a dedicated IT function — but it over-engineers every lens for a mid-market operator. It tolerates heavy customisation because the enterprise can staff the upgrade treadmill; it defaults to a Tier 1 instance because consolidation complexity is assumed; and it treats integration as a multi-year program with a full middleware stack. For a mid-size firm, that commits a constrained budget and a thin team to complexity the organisation may never need, and it stretches a project that should take months into one that takes years.

Recognising where you sit on this spectrum is itself a selection decision. A 50-person single-entity services firm may genuinely be closer to the small-business cut; a 700-person multi-subsidiary manufacturer may genuinely need enterprise-grade thinking. But the broad middle of the mid-market band is best served by a conversation that starts from the three lenses above, calibrated to the firm's actual entity structure, process maturity, and integration estate, rather than by borrowing either neighbour's playbook wholesale.

Mapping the mid-market onto the vendor tiers

Once the three lenses are settled, the vendor conversation becomes far more tractable, because Panorama Consulting's tier model maps cleanly onto the mid-market band and tells you which shortlist is even relevant. Tier I systems — SAP S/4HANA, Oracle Fusion, Infor CloudSuites at the top end — are designed for large corporations above roughly $750 million in revenue with complex entity structures and consolidation needs; they are scalable, but they carry enterprise economics and complexity that most mid-market firms cannot absorb. Upper Tier II — Microsoft Dynamics 365 Finance & Supply Chain, IFS, Epicor Kinetic — serves the $250M–$750M band and is the natural home for upper-mid-market manufacturers and multi-entity operators who have outgrown Lower Tier II.

The core mid-market density sits in Lower Tier II, which Panorama defines as $10M–$250M revenue, and which is where NetSuite, Microsoft Dynamics 365 Business Central, and the bulk of mid-market demand actually live. ERP Research reinforces this from the vendor side, noting that mid-market companies face the most competitive ERP vendor field because virtually every major vendor targets the segment: they carry real operational complexity yet rarely have the budget or change-management capacity of a Fortune 500 enterprise. The practical consequence is that a mid-market shortlist is unusually wide — Odoo, Business Central, NetSuite, Acumatica, Sage X3, Epicor, SYSPRO, and SAP Business One all legitimately compete here — and the differentiator is not the brand but how each platform handles the three lenses: native multi-entity depth, configuration-versus-customisation posture, and integration architecture.

The tier map also tells you when to stop evaluating and start architecting. A firm firmly in Lower Tier II with a single entity and a light integration estate is a clean mid-market platform decision. A firm straddling Lower and Upper Tier II — multiple entities, manufacturing complexity, a growing integration estate — may be choosing between a powerful mid-market platform configured for scale and a deliberate two-tier architecture. Crossing into Tier I is rarely the right call for a true mid-market firm, because the licence economics, implementation ratio, and change-management load are calibrated for a different scale of organisation. The discipline is to let the lenses, not the brand, set the shortlist.

The economics that shape a mid-market ERP decision

The three lenses drive the qualitative conversation, but the quantitative one is governed by economics that vendors have little incentive to surface. Software licensing typically accounts for only 20–30% of total ERP spend; the remaining 70–80% sits in implementation services, data migration, internal staff time, training, ongoing support, infrastructure, and upgrade work. Independent 2026 cost research puts full mid-market implementation (discovery through stabilisation, excluding ongoing subscription) roughly in the $150,000–$750,000 band for 100–500 employee firms with moderate complexity, with upper mid-market multi-site projects often $500,000–$2,000,000. Implementation usually runs 1x to 3x the first-year software fee, and five-year TCO commonly lands at 3x to 5x the licence once support and internal effort are counted. Organisations that anchor only on the per-user subscription still routinely underestimate total cost of ownership by large margins.

Spending is heavily front-loaded, which is what strains a mid-market cash plan most. Year 1 typically absorbs 45–65% of a five-year TCO through implementation, migration, and training. Vendor-level 2026 implementation-only benchmarks (excluding licence) illustrate the spread: Odoo often $10,000–$100,000 over 2–6 months; Acumatica $30,000–$200,000 over 3–9 months; Dynamics 365 programmes $50,000–$500,000 over 4–12 months depending on footprint; NetSuite $100,000–$400,000 mid-market over 3–6 months driven by subsidiaries and data migration; upper-tier manufacturing or multi-site stacks higher still. Practitioner staffing data for mid-market NetSuite projects shows year-one all-in in the mid-hundreds of thousands with a large internal-people column that never appears on a partner quote—budget that column explicitly or the project steals capacity from the business.

Team capacity is the constraint most mid-market boards under-model. A defensible 50–500 employee ERP programme needs a named executive sponsor, a full-time or near-full-time internal project lead, subject-matter owners for finance and operations, and protected time for UAT and training—not 'we'll do it after hours.' Systems-integrator fees alone often represent 40–60% of implementation cost; boutique partners with senior consultants on the actual delivery team frequently outperform large firms that sell with principals and staff with juniors. Ask who staffs the project versus who sold it, get rate cards in writing, and treat the partner decision as weighted as the licence. Training and change management are chronically underfunded at 5–10% of budget when 15–20% is the range associated with real adoption—cut that line and you are buying software people will work around.

The failure modes that are specific to the mid-market

Mid-market ERP projects fail in characteristic ways, and almost every failure traces back to a mis-weighted lens or an under-invested human system. The multi-entity failure is the most expensive to unwind: choosing a single-entity configuration because that is the immediate need, only to discover that the first subsidiary requires manual consolidations or a parallel second system because the platform's cross-entity reporting was bolt-on rather than native. The process-maturity failure is the most chronic: bending the system to replicate inconsistent legacy flows rather than standardising first, which turns the ERP into a bespoke system that only the original implementer can maintain and inflates every upgrade cycle. The integration failure is the most budget-destruct: building point-to-point connections ad hoc until the estate is past the iPaaS threshold, at which point support and repair costs dwarf the original build.

Two failure modes deserve explicit naming because practitioners and partners surface them constantly in 2025–2026 delivery work. The first is over-customisation: configuration (chart of accounts, workflows, parameters) should be the default; custom code is a multi-year ownership liability—documentation, release regression testing, and knowledge transfer long after go-live. Limiting customisations to the genuine competitive differentiators or regulatory requirements—often framed as keeping custom work well under roughly 10–15% of requirements—can save a large share of implementation cost and upgrade pain. The second is under-invested change management: mid-market projects fail more often from weak adoption than from technology. If training is a one-week classroom dump, super-users are unpaid heroes, and leadership stops sponsoring after kickoff, the system becomes a data-entry tax people route around with spreadsheets.

Partner risk is the third structural trap. Boutique regional SIs with senior people on the delivery team often fit mid-market economics better than global firms that bid with principals and execute with juniors. Mid-market NetSuite and Business Central programmes frequently show a large internal-people cost column that never appears on a partner quote; hybrid functional-plus-technical single-hire fantasies stall projects. Ask for named resources, industry references at your size, and a written native-first customisation policy. What unites these failures is that none are pure technology problems—they are briefing, configuration, partner, and adoption problems. Brief from the three lenses before demos, standardise before you customise, fund change management, and staff the partner decision as a first-class choice.

• →The multi-entity failure: single-entity config that forces manual consolidation or a parallel system later
• →The process-maturity / over-customisation failure: custom code that becomes permanent upgrade tax
• →The integration failure: ad-hoc point-to-point builds past the iPaaS threshold
• →The change-management failure: training and sponsorship underfunded, adoption collapses after go-live
• →The partner failure: junior-heavy delivery, unnamed resources, no native-first policy

Fit patterns by industry: distribution, manufacturing, services, multi-entity

Once the three lenses are clear, industry fit narrows the shortlist faster than brand marketing. A mid-market distributor lives and dies on multi-location inventory, EDI, warehouse depth, and order-to-cash speed. A discrete manufacturer needs BOM/MRP, shop-floor or MES interfaces, quality and traceability—and pays more for those integrations. Professional services firms weight project accounting, utilisation, and revenue recognition over plant scheduling. Multi-entity groups, regardless of industry, must treat consolidation, intercompany, and shared masters as hard filters before any demo theatre begins.

Independent 2026 mid-market roundups converge on a practical shortlist rather than a universal winner: NetSuite, Dynamics 365 Business Central, Acumatica, and SAP Business One dominate many 50–500 employee evaluations; Odoo appears when modular breadth and cost control matter and a capable partner is available; Dynamics 365 Finance & Supply Chain (F&O) enters when complexity is genuinely upper-mid-market or enterprise. Distribution and wholesale shortlists often lead with NetSuite, Acumatica, Business Central, or industry CloudSuites; discrete manufacturing adds Epicor, SYSPRO, or Infor; services lean NetSuite, Sage Intacct, or project-centric suites. Use the table as a starting pattern, not a prescription—score against your written requirements.

The mid-market trap is buying an industry 'logo' without matching entity structure and integration estate. A manufacturer that is still single-entity and lightly integrated may be better on a configured Business Central or Odoo manufacturing stack than on an enterprise F&O programme. A multi-subsidiary group with light manufacturing may need NetSuite OneWorld or a deliberate two-tier design more than a deep shop-floor package. Industry depth matters; so do the three lenses.

When to choose Business Central, Odoo, NetSuite, or F&O—in plain language

Feature matrices rarely decide mid-market outcomes; fit patterns do. The four names that keep appearing in mid-market conversations—Microsoft Dynamics 365 Business Central, Odoo, Oracle NetSuite, and Dynamics 365 Finance & Supply Chain Management (F&O)—occupy different points on complexity, ecosystem, and cost curves. Use plain decision rules, then validate with scripted demos against your entity, process, and integration briefing.

Choose Business Central when you are a Microsoft-centric mid-market firm (typically well under a few hundred concurrent ERP users for a clean fit), mostly single-country or few-country, with standard finance, distribution, light-to-moderate manufacturing, and a need to go live in months rather than years. BC is the mid-market product in the Dynamics family: broad enough for most $10M–$250M+ operators, deployable with AppSource extensions, and cheaper to own than F&O when you do not need enterprise depth. Choose Odoo when modular breadth (CRM through manufacturing and e-commerce) and licence economics matter, you accept that outcomes track partner quality as much as product, and you will enforce a configure-first discipline so open-module flexibility does not become endless customisation. Choose NetSuite when you want a mature multi-tenant cloud suite with strong multi-entity (OneWorld), financials, and growth path for multi-subsidiary or multi-channel operators—and you are prepared for mid-market implementation economics that often run six figures before the internal labour column. Choose F&O (Finance + Supply Chain) when complexity is truly upper mid-market or enterprise: many legal entities, advanced production scheduling, deep warehouse automation, multi-country statutory regimes, or a trajectory that already looks like a small multinational. For most pure mid-market firms, F&O is the over-buy; BC (or NetSuite/Odoo/Acumatica peers) is the right curve.

Acumatica deserves a mention as the unlimited-user / resource-based pricing alternative for firms with many occasional users; Sage Intacct when finance-led multi-entity is the centre of gravity. None of these rules replace a scored requirements document. They stop you from spending six months demoing the wrong tier. If you need the structured selection scorecard after this framing, use our SME ERP selection guide; if you are on the BC-versus-F&O knife edge inside Microsoft specifically, that comparison has its own guide on this site.

Ten discovery questions before any vendor demo

Demos without a briefing produce theatre. Answer these ten questions internally—with finance, operations, IT, and an executive sponsor—before you invite a salesperson. The answers become the demo script: every vendor walks the same scenarios, with your data shapes and entity structure, scored against the same weighted criteria.

If you cannot answer a question cleanly, that is the work of the discovery phase, not something to invent during a demo. Incomplete answers on entities, integrations, or process exceptions are exactly how mid-market projects buy the wrong tier or authorise customisation they cannot own.

Bring the written answers into partner interviews as well. A strong mid-market partner will pressure-test them; a weak one will nod and custom-code around every gap.

1. 01
   1. Entities, locations, currencies

   How many legal entities, sites, and currencies do you run today, and what will you add in three years? Native consolidation required on day one?

2. 02
   2. Close and consolidation pain

   How long is the month-end close, and how much of it is spreadsheet consolidation or intercompany cleanup?

3. 03
   3. Process exceptions that break tools

   Which three processes (order-to-cash, procure-to-pay, plan-to-produce) differ by channel, site, or salesperson today?

4. 04
   4. Configure vs customise boundary

   What is genuinely a competitive differentiator versus habit? Where will leadership refuse to change the process?

5. 05
   5. Integration estate map

   List every system the ERP must talk to (CRM, e-commerce, payroll, EDI, WMS, 3PL, BI). Count exceeds four or five?

6. 06
   6. Data readiness

   How clean are customers, items, open orders, and balances? Who owns cleansing before cutover?

7. 07
   7. Budget band and cash timing

   What is the five-year TCO ceiling, and can Year 1 absorb 45–65% of that spend without starving operations?

8. 08
   8. Internal capacity

   Who is the full-time-equivalent internal lead? Which SMEs are backfilled so workshops and UAT are real?

9. 09
   9. Partner model

   Will you lead in-house with a coach, or hand delivery to an SI? What proof do you require of named senior resources?

10. 10
    10. Success metrics at 90 days post go-live

    What operational KPIs must improve (close days, inventory accuracy, OTIF, quote cycle)? If you cannot name them, demos will optimise for flash.

Your mid-market ERP briefing checklist

Pulling the three lenses into a sequence, a disciplined mid-market ERP conversation starts with a briefing, not a shortlist. First, map your entity structure honestly—current entities, locations, and currencies, plus the ones you will realistically add in three to five years—and treat native multi-entity consolidation, intercompany, and shared master data as day-one requirements. Second, audit your process maturity: list the workflows that are inconsistent across channels or entities, and decide which to standardise against best-practice flows before you configure, reserving customisation for genuine exceptions. Third, inventory your integration estate—every system the ERP must talk to today and within three years—and decide architecturally whether you are below or above the four-to-five-system iPaaS threshold before any connection gets built.

Fourth, place yourself on the vendor tier and platform-fit map: Lower Tier II versus Upper Tier II, and whether Business Central, Odoo, NetSuite, Acumatica, or F&O matches your industry pattern and complexity curve. Fifth, build a year-by-year five-year TCO model that includes the hidden lines—internal staff time, training at 15–20% of project budget, escalation caps, customisation maintenance, and integration support—and weight the implementation partner as a separate decision from the licence. Sixth, answer the ten discovery questions above in writing, then only run scripted demos, weighted scoring, and references against that briefing—not a generic feature tour.

This is the work Flectic does with mid-market companies across Canada, the UK, and the US as a platform-neutral implementation partner for both Microsoft Dynamics 365 and Odoo. Because we implement both platforms rather than selling one, the briefing is genuinely neutral: we help you pressure-test the three lenses for your specific entity structure, process maturity, and integration estate, then deliver whichever system fits without vendor bias. If you are ready to frame the conversation correctly before you shortlist, the ERP Readiness Call is the right starting point.

1. 01
   Map your entity structure

   List current and likely-future entities, locations, and currencies. Treat native multi-entity consolidation, intercompany, and shared master data as day-one requirements, not future enterprise features.

2. 02
   Audit process maturity honestly

   Identify the workflows that are inconsistent across channels or entities. Decide which to standardise against best-practice flows before configuring, and reserve customisation for genuine exceptions only.

3. 03
   Inventory and architect the integration estate

   List every system the ERP must connect to today and within three years. Decide architecturally whether you sit below or above the four-to-five-system iPaaS threshold before any connection is built.

4. 04
   Place yourself on the vendor tier map

   Decide whether you are Lower Tier II, Upper Tier II, or genuinely two-tier territory. Let the three lenses rather than the brand set the shortlist.

5. 05
   Build a 5-year TCO model with hidden lines

   Include internal staff time, training, escalation caps, customisation maintenance, and integration support and repair costs. Model cash flow, not a lump sum, and weight the implementation partner separately.

6. 06
   Answer the ten discovery questions in writing

   Lock entity, process, integration, budget, capacity, and partner answers before any demo. Use them as the shared script every vendor must walk.

7. 07
   Run the process with calibrated lenses

   Execute team, requirements, scripted demos, weighted scoring, and references using the lens-based briefing, not a generic checklist. Reach a defensible decision in months, not years.

Frequently asked questions