ERP Demos & Vendor Selection: The Right Questions

The right ERP demo questions don't emerge on the spot during the meeting — they come from your real processes, prepared in advance: you hand the vendor concrete scenarios, have them run those live in the system instead of showing a polished standard tour, check references of the same size and industry in parallel, and clarify contract, pricing, and exit questions in writing before you sign. Whoever sits through a demo passively ends up buying the sales team's presentation skills — not the software. This guide shows you how to structure demos and the entire ERP selection so your decision rests on facts rather than gut feeling.

Why the right ERP demo questions decide the outcome

An ERP demo is a sales conversation, not a neutral product test. By default the vendor shows exactly the workflows their ERP system handles particularly well, and steers around the difficult spots. Your job is to take over that direction. That only works if you know beforehand what you want to see.

The basis for this is a clean requirements specification: the solution-neutral description of your must-have, should-have, and nice-to-have requirements. From these requirements you derive the demo scenarios. Only after the vendor has shown what they can do does the functional specification take shape on their side — the concrete answer to how they'll implement your requirements. Without that foundation, you'll end up comparing apples with oranges.

Budget at least half a day per candidate and invite the people who will work with the system every day later on — not just management. Your key users can tell within minutes whether a click path holds up in daily practice or only looks good on a slide.

Scenario-based test cases instead of a standard tour

The most effective lever is the scripted demo: you send every vendor the same three to five test cases in advance and have them click through them live during the meeting. That makes the candidates directly comparable, and the software has to reflect your reality — not the other way around.

Good test cases capture your critical and your awkward processes, for example:

• Order with a special case: A customer order with partial delivery, a subsequent quantity change, and a return — from entry through to invoice.
• Procurement under pressure: A purchase proposal when the reorder point is breached, including a supplier switch and goods receipt with a discrepancy.
• Month-end close: Exporting the postings to DATEV, handling a credit note, and traceability via the audit trail.
• Volume data: How does the system behave with your real volume of items, orders, and documents — not the demo dataset with 20 records.

Insist that the vendor doesn't skip cases. A "we'll follow up on that" is a legitimate interim step, but note it down. If the follow-ups pile up, that's a signal.

Questions on standard, customizing, and updates

For every scenario, clarify whether you get what's shown in the standard product or only through customizing. Adaptations aren't bad per se, but they cost money, extend the project, and can become a problem with every release update. Concrete questions:

• Is this function standard, configuration, or programming?
• Do our adaptations stay upgrade-safe, or must they be reworked with every release?
• How often do updates come, and can we control their timing and scope?

Questions on integration and data migration

Hardly any ERP stands alone. Ask specifically about the interface and API: is there a documented REST API, ready-made connectors to your shop or marketplace, and how does the data migration of your master data work? Have them show a test migration with an extract of your real data instead of relying on promises. How to set up the data transfer cleanly is covered in depth in our piece on data integration.

Checking references the right way

References are valuable, but only if you talk to the right ones and ask the right questions. Demand reference customers that resemble your company size, industry, and process complexity — not the showcase client from a different segment.

In the reference call, ask about what's missing from the glossy brochures:

• How did the go-live go, and what went wrong?
• How realistic were the original time and cost estimates?
• How does support respond to critical incidents — with reliable response times?
• Would you choose the same vendor again? Why, or why not?

As a complement, a look at the neutral ERP directory and the comparison overview helps you weigh vendors' self-reported claims against the market.

Clarify contract and pricing questions early

The license list price is rarely the relevant number. What matters is the total cost over the term — the TCO. It covers license or subscription, rollout, data migration, training, operations, and ongoing adaptations. Clarify these points in writing before you negotiate:

Pay particular attention to vendor lock-in: the harder it is to get out again if things go wrong, the greater the dependency. An exportable, open dataset and documented interfaces are your most important protection.

Also clarify the mandatory compliance topics in the DACH region. The ERP must operate in a GoBD-compliant way (immutable, traceable records with an audit trail) and handle the e-invoice per EN 16931. To place the deadlines in context: the B2B receiving obligation for e-invoices has applied in Germany since 1 January 2025. The issuing obligation is staggered — from 1 January 2027 for companies with more than 800,000 euros in prior-year revenue, and from 1 January 2028 for everyone else. Have them show you how the system generates and processes formats like XRechnung and ZUGFeRD.

Recognizing vendor warning signs

Some signals in the selection process are reliable early warnings. If you encounter several of them, a closer second look is worthwhile:

• Dodging test cases: Your scenarios get sidestepped or waved off as "doable" in general terms, without being shown.
• Everything is possible: No vendor can meet every requirement in the standard product. Whoever never says "no" is selling you expensive customizing.
• Pricing only at the very end: Opacity on price usually carries over into the project.
• No access to references: A vendor who can't or won't name suitable customers may not have any satisfied ones.
• Pressure and artificial deadlines: "This week only" discounts belong in sales training, not in a multi-year investment decision.
• Vague contracts: If binding SLAs, response times, and exit clauses are missing, you carry the risk alone.

The question catalog at a glance

Take these core questions into every demo and contract meeting:

1. Show me my process X live in the system — not your standard process.
2. What of this is standard, what is configuration, what is programming?
3. Do adaptations stay upgrade-safe?
4. How does the data migration work, and may I see a test migration?
5. Which reference customers of my size and industry can I speak to?
6. What does the total package cost over five years, including operations?
7. Who owns my data, and how do I get out again?
8. How do you ensure GoBD compliance and the e-invoicing obligations?

The fit-gap analysis as the outcome of the demos

After the demos, you condense your observations into a fit-gap analysis: you match every requirement from the requirements specification against what each standard product actually delivers. You rate each gap by effort, risk, and dispensability. That turns a diffuse "good feeling" into a traceable matrix that holds up even in front of management.

This analysis is at the same time the bridge to implementation: the rated gaps produce the scope for the later ERP rollout and the right consulting. The more honest you are here, the fewer nasty surprises you'll face in the project.

Conclusion

Good ERP demo questions are no accident — they're preparation. Whoever hands the vendor their own test cases, checks references critically, clarifies pricing and contract questions early and in writing, and watches for warning signs turns a sales conversation into a genuine product test. Capture your findings in a fit-gap analysis and decide based on the total cost over five years — not on the prettiest presentation. That way you end up buying the software that fits your processes, not the best show.