Selection

ERP selection criteria checklist for Australian businesses

A practical ERP selection checklist covering business fit, Australian requirements, security, data, integrations, partners, total cost, and decision scoring.

An ERP shortlist should produce a defensible business decision, not a collection of attractive demos. Before vendors present, the buying team needs agreed outcomes, pass-or-fail requirements, weighted selection criteria, and named owners for finance, operations, technology, data, security, and change.

For an Australian small or medium business, the checklist also needs to test local operating requirements. GST and BAS reporting, payroll and superannuation boundaries, Peppol eInvoicing, privacy obligations, cyber controls, banking, data location, and support coverage can change the implementation design and total cost.

Use this ERP selection criteria checklist to compare the complete programme created by each option: software, implementation partner, integrations, data migration, internal effort, risk, support, and future change.

1. Define the business case and phase-one boundary

• Name three to five measurable outcomes for the first 12 to 24 months, such as faster month-end close, higher stock accuracy, fewer manual orders, cleaner project billing, or better multi-entity reporting.
• Define the processes, entities, sites, integrations, reports, and user groups included in phase one. Record what is deliberately deferred.
• Separate system problems from process, data, capability, and ownership problems so the ERP is not expected to repair every weakness automatically.
• Set budget, timing, risk appetite, and business-resource constraints before the shortlist is scored.

2. Turn requirements into proof scenarios

• Build six to ten end-to-end scenarios using your own products, customers, approvals, exceptions, reports, and volumes.
• Include difficult cases: partial fulfilment, credit holds, returns, stock adjustments, failed integrations, urgent payments, month-end corrections, and approval delegation.
• Give every vendor the same script and evidence request. Score what the system demonstrates, what needs configuration, what needs an add-on, and what remains unproven.
• Require the proposed implementation partner to lead the scenarios so the team can assess delivery judgement as well as product capability.

3. Score product and operating-model fit

• Finance and control: chart design, dimensions, approvals, audit trail, close, consolidation, tax reporting, cash visibility, and management reporting.
• Operations: order-to-cash, procure-to-pay, inventory, warehousing, manufacturing, projects, services, or field operations relevant to the business.
• Architecture: integration methods, API coverage, identity, environments, release management, extension model, reporting stack, and data export options.
• Usability and adoption: role-based workflows, accessibility, mobile needs, training load, exception handling, and the effort required to keep processes consistent.
• Scalability: transaction volumes, entities, locations, currencies, users, acquisitions, and likely phase-two requirements.

4. Test Australian compliance and security requirements

• Confirm how GST, BAS, bank files, payroll journals, superannuation, record retention, and audit evidence will work. Do not accept “Australian localisation” as a complete answer.
• Fair Work says employers must keep time and wages records for seven years and that records must be accessible, legible, and not altered except to correct an error. If payroll or time capture is in scope, test audit history, corrections, access, and retention directly.
• If eInvoicing matters, ask how the proposed design connects to the Peppol network and verify relevant products or service providers against current ATO information.
• Map the personal information held in the ERP, where it is stored, who can access it, overseas support arrangements, retention rules, and how APP 8 and APP 11 obligations are addressed where applicable. The OAIC recommends privacy impact assessments as part of project planning.
• The Australian Cyber Security Centre says cyber supply-chain risk should be considered across procurement, operation, maintenance, and decommissioning. Ask who can access ERP data, which subcontractors are involved, and how those arrangements can change.
• Ask the vendor and partner to demonstrate multi-factor authentication, privileged-access control, patching responsibilities, backup and recovery, logging, incident response, and alignment with the organisation’s cyber baseline. Confirm the shared-responsibility split rather than assuming the cloud provider owns every control.
• Put regulatory or contractual requirements in the scorecard as evidence-based gates, not low-weight preferences that can be traded away.

5. Test AI features as controlled business capabilities

• Define the allowed use cases and the decisions that must retain human review. Do not approve AI capability because it creates an impressive demonstration.
• Ask what data is sent to the AI service, who can access it, whether customer or employee information is used, which features can be disabled, and how generated output is logged and corrected.
• The OAIC says organisations selecting commercial AI products should conduct due diligence on intended use, testing, human oversight, privacy and security risks, and access to personal information.
• Include AI consumption charges, environment and regional availability, licensing, monitoring, and staff training in the operating and commercial model.

6. Assess data migration and integration risk

• Profile customer, supplier, item, chart, asset, project, employee, open-transaction, and historical data before the vendor estimates migration effort.
• Decide what must be migrated, archived, cleansed, reconciled, or legally retained, with a named business owner for each data domain.
• List every integration with source, destination, direction, frequency, volume, error handling, monitoring, security, and support owner.
• Require reconciliation and cutover criteria for opening balances, inventory, receivables, payables, bank positions, orders, and other critical records.

7. Evaluate the implementation partner beside the software

• Score the named delivery team, relevant references, industry and process experience, governance method, local availability, escalation path, and post-go-live support.
• Confirm who owns solution architecture, data migration, integrations, testing, training, change management, cutover, and benefits tracking.
• Ask for an assumptions register and make gaps visible before contract signature. Ambiguous assumptions usually become change requests later.
• Use official vendor partner directories as a verification step, then test the actual people and delivery evidence proposed for your project.

8. Compare total cost and commercial exposure

• Model licences, modules, environments, usage charges, storage, add-ons, implementation, integration, migration, training, travel, support, and internal business time.
• Separate mandatory phase-one cost from optional scope and likely phase-two work.
• Test price changes caused by more users, entities, transactions, API usage, AI consumption, support tiers, or contract renewal.
• Compare contract terms for data access, termination, transition assistance, service levels, subcontractors, intellectual property, liability, and change control.

9. Use gates and weighted scoring

• Set pass-or-fail gates first for legal, security, critical process, data, integration, and commercial requirements.
• Weight the remaining criteria before demos begin. A practical starting model is business and process fit 30%, implementation partner 20%, architecture and integration 15%, data and reporting 15%, total cost 10%, and change and support 10%.
• Record evidence, assumptions, risks, and confidence beside every score. A number without supporting evidence creates false precision.
• Run a final decision workshop that shows why the preferred option won, why the others lost, and which risks must be controlled during contracting and mobilisation.

Common selection mistakes

• Letting a polished generic demo outweigh evidence from real operating scenarios.
• Scoring software first and treating the implementation partner as a later procurement decision.
• Comparing headline licence prices without implementation scope, add-ons, internal effort, support, and future usage charges.
• Ignoring data quality, integration ownership, security, and change capacity until after the preferred vendor is chosen.
• Adding every pain point to phase one and creating a programme the business cannot absorb.

FAQ

• How many ERP vendors should we shortlist? Usually two or three credible options. A larger list often reduces the depth and consistency of evaluation.
• What are the most important ERP selection criteria? Business-process fit, implementation-partner quality, data and integration risk, reporting and control, total cost, security, and the organisation’s capacity to implement change.
• Should we run an ERP RFP? Use an RFP when scope and evaluation criteria are sufficiently clear. If they are not, discovery and scenario-led workshops should come first.
• Should price be a pass-or-fail gate? Affordability can be a gate, but the decision should use total programme cost and risk rather than licence price alone.

Official sources to check

• Australian Cyber Security Centre: Guidelines for procurement and outsourcing, published 9 June 2026.
• Australian Cyber Security Centre: Cloud Shared Responsibility Model guidance and Essential Eight maturity model.
• Office of the Australian Information Commissioner: Australian Privacy Principles guidance, Guide to undertaking privacy impact assessments, and guidance on commercially available AI products.
• Australian Taxation Office: Digital record keeping for businesses and eInvoicing guidance.
• ATO Software Developers: eInvoicing Ready product register.
• Fair Work Ombudsman: Record-keeping requirements for time and wages records.
• Microsoft Dynamics 365 Success by Design implementation guidance for examples of structured solution, data, integration, security, testing, and cutover reviews.