Selection

ERP software demo script: scenarios, scorecard, and questions for buyers

Use this ERP software demo script to run comparable process scenarios, test exceptions and controls, expose implementation effort, and score vendor evidence.

An ERP software demo should produce evidence the buying team can compare, not just a favourable impression of the presenter. The script needs to make every shortlisted vendor work through the same business outcomes, process scenarios, exceptions, controls, reports, and implementation assumptions.

Use your own realistic examples wherever possible: products, approval levels, entities, warehouses, projects, customer terms, reporting dimensions, and transaction volumes. The strongest demos show how work moves from the initial trigger to the financial and operational result, including the difficult hand-offs between teams.

The goal is a defensible decision record. By the end of each demonstration, the team should know what was proven in the live product, what requires configuration, what depends on an add-on or customisation, what changes the implementation estimate, and what remains unproven.

What to prepare before vendors receive the script

• Agree the phase-one scope, measurable business outcomes, pass-or-fail requirements, and the five to eight processes that carry the most operational or financial risk.
• Map each process from its real trigger to its final outcome. Microsoft's current Dynamics 365 business process catalog uses the same end-to-end principle and describes scenarios in business terms rather than software terminology.
• Name a business owner for each scenario and include finance, operations, technology, data, security, and change representatives where their decisions are affected.
• Give every vendor the same script, preparation time, data assumptions, evidence request, scoring method, and time limit so the comparison remains fair.
• Decide which information can safely be used in a vendor environment. Use representative or de-identified data unless the organisation has approved the privacy and security arrangements for real records.

A practical ERP software demo agenda

• 10 minutes — confirm the proposed solution, modules, add-ons, implementation partner, environment, version, and any capabilities that are mocked or not generally available.
• 15 minutes — show role-based navigation, search, approvals, audit history, accessibility settings, mobile use where relevant, and how users move between daily tasks.
• 60 to 90 minutes — run the agreed end-to-end scenarios, including at least one realistic exception for every critical process.
• 20 minutes — show management reporting, drill-down to source transactions, security roles, integration monitoring, data export, and the operational evidence needed after go-live.
• 20 minutes — review configuration, extensions, custom work, data migration, integrations, licensing, implementation assumptions, and unresolved requirements.
• 15 minutes — allow the buyer team to score independently before discussion. Record follow-up evidence with an owner and due date.

Scenario 1: order, fulfilment, invoicing, and cash

• Create an order using customer-specific prices, credit limits, tax treatment, delivery terms, and an approval threshold that reflects the business.
• Introduce an exception such as a partial shipment, backorder, price override, return, damaged stock, or disputed invoice.
• Show inventory availability, warehouse action, customer communication, invoice creation, general-ledger impact, receivables, and cash allocation.
• Require the vendor to identify every manual step, add-on, integration, and role hand-off rather than skipping directly to the final document.

Scenario 2: purchasing, inventory, and supplier control

• Raise demand, obtain approval, create the purchase order, receive part of the order, record a price or quantity mismatch, and resolve the supplier invoice.
• Show landed cost, serial or lot tracking, quality hold, stock adjustment, inter-warehouse transfer, or replenishment logic where these are material.
• Test who can change supplier bank details, who approves payment-related changes, what audit history is retained, and how segregation of duties is enforced.
• Show the operational and accounting result together. A warehouse workflow is not proven if finance cannot reconcile its effect.

Scenario 3: finance, reporting, and period control

• Run a month-end task that includes an accrual or correction, approval, bank or subledger reconciliation, and a management report.
• Ask the presenter to drill from a board-level number to the transaction, approval, user, and source document without preparing a special report after the session.
• Test entity, branch, department, project, product, customer, and other reporting dimensions that leaders actually use.
• Include an error or late adjustment and ask how the period is protected, reopened, corrected, and documented.

Test security, privacy, accessibility, and resilience

• Ask the vendor and implementation partner to show role design, privileged access, multi-factor authentication, audit logs, environment separation, backup and recovery responsibilities, security monitoring, and incident escalation.
• The Australian Cyber Security Centre's June 2026 procurement and outsourcing guidance treats supplier and outsourced-service security as an ongoing risk-management responsibility. Record which controls belong to the software provider, implementation partner, managed service provider, and customer.
• If personal information is in scope, test access, export, retention, deletion, overseas support, subcontractors, and data-location assumptions. OAIC guidance says organisations must take reasonable steps to protect personal information and may retain accountability for some overseas disclosures.
• Include keyboard navigation, screen-reader compatibility, contrast, zoom, error messages, and the needs of actual users. Australian Government digital guidance says accessibility requirements should be included in procurement rather than treated as a later fix.
• Demonstrate an integration failure, unavailable service, duplicate message, or interrupted workflow. Ask how users detect the problem, recover safely, prevent double processing, and prove that the records reconcile.

Questions that expose implementation effort

• Is this capability standard, configured, supplied by an add-on, customised, or still proposed? Ask the vendor to label it during the demonstration.
• Which design decisions, licences, environments, integrations, data fields, security roles, and partner services are required to reproduce what was shown?
• Which parts of our current process would need to change, and which exceptions would still require manual work outside the ERP?
• What assumptions are being made about data quality, transaction volume, user discipline, local requirements, and the availability of our subject-matter experts?
• Which demonstrated items are included in the written scope and price? Put unresolved items into the assumptions and risks register before commercial evaluation.
• Microsoft's Success by Design guidance emphasises finding technical and project risks before they derail implementation. Use the demo to surface those risks while there is still competitive pressure to answer them clearly.

Use an evidence-based ERP demo scorecard

• Set pass-or-fail gates for critical process, legal, security, privacy, data, integration, and commercial requirements before adding weighted scores.
• Score each scenario across business fit, user effort, control and auditability, reporting, implementation complexity, partner confidence, and evidence quality.
• Use a simple evidence scale: 0 not shown, 1 stated only, 2 partly demonstrated, 3 demonstrated with assumptions, 4 demonstrated end to end with required evidence.
• Record the exact proof, assumptions, gaps, risks, follow-up owner, and due date beside the number. A score without evidence creates false precision.
• Keep product fit and implementation-partner fit separate. A strong presenter or preferred platform should not hide weak delivery judgement.

What to avoid

• Letting each vendor choose different scenarios, data, or definitions of success.
• Spending most of the session on dashboards, AI, or happy-path navigation while critical exceptions remain untested.
• Accepting slides, screenshots, roadmap statements, or a partner's reassurance as equivalent to demonstrated capability.
• Using confidential production data in an unapproved demo environment.
• Combining licence, implementation, add-on, integration, and internal effort into one vague commercial estimate.
• Allowing group discussion before individual scoring, which can cause senior voices or presentation quality to distort the evidence.

FAQ

• How many vendors should receive the ERP demo script? Usually two or three credible finalists. More vendors often reduce the depth of preparation and evaluation.
• Should vendors receive the script in advance? Yes. The goal is a fair test of fit and delivery judgement, not a surprise examination.
• How long should an ERP demo take? Allow enough time to complete the critical end-to-end scenarios and exceptions. Two focused sessions are often more useful than one generic half-day tour.
• Who should score the demo? The process owners who will live with the result, supported by finance, technology, security, data, and the programme lead.
• Should AI features be included? Include them only where they support a defined business scenario. Ask about data use, human review, availability, licensing, consumption cost, monitoring, and how incorrect output is corrected.

Official sources to check

• Microsoft Learn: About the Dynamics 365 business process catalog and Base the implementation lifecycle on processes.
• Microsoft Learn: Introduction to the Success by Design framework and Dynamics 365 implementation guidance.
• Australian Cyber Security Centre: Guidelines for procurement and outsourcing, published 9 June 2026.
• Office of the Australian Information Commissioner: APP 8 cross-border disclosure guidance and APP 11 security of personal information guidance.
• Australian Government Digital Inclusion Standard: Criterion 4 — Make it accessible, including accessibility in procurement.