Six Steps to a Defensible Selection
Run in this order. The most common failure is starting at step four by watching demonstrations before anything is written down.
Define the problem
Write down which specific problems you are solving, with evidence: how inaccurate stock actually is, how many hours go into rekeying, what a reporting request genuinely costs in time. Then check which would be solved by better process, by integration, or by a reporting tool. This step regularly reduces the scope of the project, and occasionally it ends the project in the best possible way.
Document requirements
Requirements written by the people who do the work, separated into must have and preferred, and expressed as business outcomes rather than feature names. Include the awkward specifics that characterise your operation: pack sizes and unit conversions, customer contract pricing, consignment stock, multiple entities and ABNs, landed cost, serialised goods, or whatever your business genuinely cannot trade without.
Assess integration fit
For each candidate, establish what its interface actually supports, whether the objects and fields you need are available in both directions, what the rate limits are at your peak volume, whether connectors exist to your commerce platform and point of sale, what those cost, and what real businesses report about integrating it. Include this in scoring rather than treating it as a detail to resolve after signing.
Demonstrate against your scenarios
Provide vendors with your own scripted scenarios using your data and awkward cases, rather than watching a standard demonstration. Ask to see a customer specific price applied to an order with pack rounding, a stock adjustment flowing through to the ledger, and a BAS period produced. Where something requires customisation, get that stated explicitly, because customisation is where budgets and upgrade paths both suffer.
Model total cost
In AUD over five years: licence or subscription at your projected user count and volume, implementation and configuration, data migration, integration development and its ongoing cost, training, internal time which is real and routinely omitted, infrastructure where relevant, and annual support. Then add a contingency, because implementation estimates for projects of this size are optimistic far more often than not.
Evaluate the partner
Named consultants and their actual availability, implementations completed for businesses of similar size and model, references you contact yourself and ask what went wrong, the change control process, and what happens when the project runs over. Also establish what handover looks like: documentation, configuration records and whether you could move to another partner later without starting again.