Selection

ERP selection criteria checklist for Australian businesses

Decide whether your small business needs ERP, then test scope, readiness, Australian requirements, partners and total cost with a practical selection checklist.

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.

Short answer: which ERP is best for a small Australian business?

The best fit is the smallest workable scope that supports your critical transactions, reporting and controls, with a delivery team you can support. Start with operating complexity rather than employee count or a product ranking. An accounting system with a focused add-on may be enough when one workflow is the problem; a broader ERP becomes worth evaluating when several connected processes need shared data and consistent controls.

Decide whether you need ERP before choosing a brand

Use this original decision table to frame discovery. These are evaluation paths, not product endorsements or automatic triggers to replace your current system.

A small team can have complex inventory or entity requirements; a larger team can still have simple transactions. Do not use a turnover threshold, a licence discount or the promise of future growth as the sole reason to buy ERP.

Small-team readiness: proceed, narrow the scope or pause

If these checks expose gaps, commission a bounded discovery exercise with written outputs before committing to the full implementation. A narrow first phase should still complete a usable business process; leaving its critical reconciliation or integration for later can make the apparent saving misleading.

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.
• Australian Cyber Security Centre procurement guidance calls for data portability to be documented in service-provider contracts. Ask for an export demonstration and agree the formats and assistance needed for backup, migration and exit, alongside access and subcontractor responsibilities.
• 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. An illustrative 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%. These are example weights, not an industry benchmark; adjust them to your risks after applying the mandatory gates.
• 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.

Questions to ask before accepting a shortlist recommendation

• Which requirement makes this option a better fit than improving our current system, and can you demonstrate it with our data?
• Which parts of the proposed process are standard, configured, an add-on or custom work, and who maintains each part after an upgrade?
• Which Australian tax, payroll, banking and eInvoicing steps sit outside the ERP, and who is accountable for reconciliation?
• What are the named delivery roles, our internal workload and the written acceptance criteria for phase one?
• What would make you advise us to postpone this project or choose a smaller scope?

Use the linked product comparisons and pricing guides after this scope is clear. Give each shortlisted partner the same demo script and budget assumptions, then compare the evidence rather than the presentation style. If you need help setting that boundary, use the guidance enquiry below.

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

• What is the best ERP for a small business in Australia? There is no universal winner. Decide whether you need broader ERP or a targeted improvement, then compare the options against the same critical workflows, Australian requirements, delivery capacity and total cost.
• When should a small business delay ERP? Narrow the scope or pause final selection when nobody owns the processes, sample data cannot be reconciled, staff cannot test the system, or essential delivery costs remain unquoted.
• How many ERP vendors should we shortlist? A practical approach is two or three credible options that pass the mandatory gates, leaving enough time to test each in depth.
• 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.

Sources and review note

Reviewed by ERP Search editorial on 2 November 2026. The fit table, readiness checks, scoring example and vendor questions are original buyer guidance. They do not rank products or establish legal compliance. Confirm applicable obligations with your advisers and verify the proposed configuration with the delivery partner.

Official references checked for the Australian requirements above are linked below:

• Australian Cyber Security Centre: Guidelines for procurement and outsourcing, including contractual data portability and service-provider responsibilities.
• Office of the Australian Information Commissioner: APP 8 cross-border disclosure, APP 11 security, privacy impact assessment guidance, and guidance on commercially available AI products.
• ATO Software Developers: eInvoicing Ready product register.
• Fair Work Ombudsman: Record-keeping requirements for time and wages records.