ERP buying guide · Practical demo scenarios
The ERP Demo Test: Bring Us Your Most Complicated Transaction
The order that arrived in three deliveries. The invoice that was partly paid before goods came back. The discount that needed approval while the manager was away. These are the transactions we want to discuss in an ERP demo.
By Craft Interactive · Published 29 October 2026
What should you test in an ERP demo?
A useful ERP demo test follows one of your real business transactions from its starting point to its operational and financial outcome. Include an exception, use the roles your employees will have, and inspect the resulting stock, balances and document links. Ask which steps are standard, which need configuration and which require additional development.
A feature presentation can help you understand the software. A transaction test helps you decide whether it fits the work. “We have inventory management” is a starting point. “Show us what happens when five items are returned after a partial payment” gives everyone something specific to evaluate.
Ask for evidence: Show us the transaction, the exception, the person authorised to handle it and the records left behind.
Bring a small transaction pack, not your entire database
Choose a recurring situation that causes delays, corrections or arguments between departments. The best test is often an ordinary transaction with one awkward detail.
- A short story: what the customer or employee requested, what changed and how your team handled it.
- Sample documents: a quotation, order, receipt, invoice or credit note relevant to the journey.
- Starting conditions: quantities, warehouses, prices, payment terms and any existing balances.
- People and permissions: who creates, approves, receives, dispatches and posts the transaction.
- The expected result: the remaining quantity, balance, report or decision you need to see.
Use anonymised data and remove bank details, personal information and commercially sensitive terms that the demonstration does not need. Share the scenario ahead of time so the demo environment can be prepared. You are testing suitability, not how quickly someone can invent sample data in a meeting.
THE MAIN TEST
One order, two deliveries, a payment and a return
Imagine Harbour Tools Trading, a fictional distributor, sells 100 valve kits at AED 250 each. Sixty kits are available now; the remaining 40 must be purchased. The customer accepts two deliveries and one invoice per delivery.
After receiving and being invoiced for the first 60 kits, the customer pays AED 10,000. Five of those kits are then returned for credit, with no replacement requested. The remaining 40 kits arrive from the supplier and are delivered and invoiced later.
All figures are illustrative and exclude taxes, freight, discounts and other transactions. The five returned kits are accepted into saleable stock. The credit is allocated to the first invoice. A live demonstration should also test your applicable taxes and accounting policy.
AED 25,000
Original order value: 100 kits × AED 250.
AED 1,250
Credit for five returned kits.
AED 13,750
Remaining receivable after the credit and AED 10,000 payment.
Ask the demonstrator to complete the whole journey
- Create the order and show the shortage without treating incoming stock as already received.
- Purchase the missing 40 kits and retain the relevant source references.
- Dispatch and invoice the first 60 kits for AED 15,000.
- Record the AED 10,000 receipt and allocate it to that invoice.
- Return five kits and issue the AED 1,250 credit, recording the physical stock movement once.
- Receive the purchased 40 kits, then dispatch and invoice them for AED 10,000.
- Show the final stock position, outstanding invoices and treatment of the quantity that will not be replaced.
Ask to see submitted records and the resulting reports, not only completed entry forms. A draft document does not prove the downstream effect.
| Check | Expected result in this example |
|---|---|
| First invoice outstanding | AED 15,000 − AED 10,000 payment − AED 1,250 allocated credit = AED 3,750. |
| Second invoice outstanding | AED 10,000, with no payment yet allocated. |
| Total customer receivable | AED 13,750 across the two invoices. |
| Stock remaining | 60 opening + 40 purchased − 100 dispatched + 5 returned = 5 kits. |
| Net quantity retained by the customer | 95 kits. The five returned kits are not automatically a new delivery commitment. |
| Order follow-up | Demonstrate the supported closure or adjustment process so the agreed no-replacement return does not leave an unexplained fulfilment task. |
ERPNext supports partial deliveries, sales returns and payment and credit allocation. The test is whether the proposed configuration handles your complete sequence correctly. A stock return and a credit have different effects; the demonstrator should explain which documents update each record.
Five more scenarios worth bringing to the demo
Select the ones that matter to your business. Two well-tested scenarios will usually give you more useful evidence than rushing through every module.
1. A discount crosses the approval limit
Scenario: A sales user prepares a quotation within the agreed discount authority, then changes it to exceed the limit.
Ask to see: the correct escalation, an attempted submission by the sales user, rejection and resubmission, and what happens if the value changes after approval. Repeat the test immediately below, exactly at and above the boundary.
Evidence to keep: the rule, the authorised roles and the observed result. ERPNext Workflows can use conditions, but your specific approval policy still needs configuration and testing.
2. The supplier delivers less than it invoices
Scenario: You order 50 items, receive 45 acceptable items and receive a supplier invoice for 50.
Ask to see: the receipt for the actual quantity, the five-item discrepancy, who investigates it and whether the proposed process blocks, warns or permits the invoice. Then show the correction.
Evidence to keep: the remaining quantity and the control used. Do not assume a particular mismatch rule is enabled merely because purchasing and accounts share a system.
3. A foreign-currency invoice is settled at a different rate
Scenario: An invoice is issued in a foreign currency and paid later when the relevant exchange rate differs. The bank also charges a fee.
Ask to see: the invoice currency, company-currency values, payment allocation, exchange difference and separately recorded fee. Ask who can change the exchange rate.
Evidence to keep: the final outstanding balance and the ledger treatment. ERPNext provides multi-currency setup; test the accounts, currencies and policies your business will use.
4. One branch needs stock from another
Scenario: A customer order belongs to one branch, while the required goods are held elsewhere.
Ask to see: availability, reservations where applicable, the actual stock movement and who can view each warehouse. If branches belong to separate legal companies, ask for the intercompany route rather than assuming a warehouse transfer is sufficient.
Evidence to keep: ownership, quantities, permissions and financial consequences. “Multi-branch” needs a precise definition in the proposed scope.
5. An external system sends the same order twice
Scenario: A website or marketplace sends an order, times out and retries the same message.
Ask to see: duplicate detection, the external reference, failure visibility and how an authorised person safely retries a failed transaction.
Evidence to keep: one intended business transaction and a clear record of the retry. This is an integration acceptance test; duplicate prevention should not be assumed to be a built-in feature of every connector.
Switch users during the demonstration
A transaction completed by an administrator can hide permission problems. Ask the demonstrator to switch between the proposed sales, warehouse, purchasing and finance roles.
Can warehouse staff record their work without seeing restricted commercial information? Can a sales user change a submitted financial document? Can a person approve their own request when the policy prohibits it? Test both permitted and prohibited actions.
ERPNext has role-based permissions, but those permissions must reflect the responsibilities agreed for your implementation. A feature being available does not establish that the access model is correct.
Use an evidence sheet instead of a general impression
For each scenario, record the expected outcome, what was demonstrated, the evidence reference, any gap, the person responsible and the next test date. Ask each vendor to use the same starting data and acceptance criteria.
| Result label | What it means | Next action |
|---|---|---|
| Demonstrated | The agreed outcome was shown in the demo environment. | Record the version, settings and evidence for later acceptance testing. |
| Configuration needed | The route depends on settings, roles, fields or workflow changes not yet proven. | Agree the configuration and request a repeat demonstration. |
| Development or integration needed | The outcome depends on additional work. | Document scope, cost, dependencies, maintenance and acceptance criteria. |
| Unresolved or unsuitable | The requirement was not demonstrated, or the proposed route does not fit. | Decide whether to investigate, change the process or treat it as a selection blocker. |
A verbal “yes” is not the same as a demonstrated result. Equally, a configuration gap is not automatically a product failure. The useful outcome is knowing what is proven and what remains to be delivered.
Mark business-critical requirements separately. A high overall score should not hide a failure in payment controls, essential reporting or another requirement you cannot operate without.
End the demo with implementation questions
Once the transaction works, ask what it will take to make it work with your people and data:
- Which item, customer, supplier and opening-balance data must be prepared?
- Which parts of the demonstration are standard, configured or custom?
- Who owns any external connector, and how will failures be supported?
- Which reports, print formats and approval rules are included in the proposal?
- How will staff practise the process and prove readiness before go-live?
- How will custom work be tested after upgrades?
A successful demo is evidence for selection, not final implementation acceptance. Re-run the critical scenarios in the configured environment with representative migrated data and the actual user roles before go-live.
What we want you to bring to an ERPNext demo
Bring the transaction your team explains with “it depends”. Tell us where the exceptions happen, which information people re-enter and what management struggles to verify.
When we discuss ERPNext for businesses in Dubai and across the UAE, those details help us assess the fit and define the work. We can distinguish a standard document flow from a configuration decision, an integration requirement or a process that needs simplifying first.
The goal is to leave you with a clear view of how your work would run, what needs further testing and what belongs in the implementation scope.
Frequently asked questions
Should we send our ERP demo scenarios in advance?
Yes. Share anonymised sample data, the transaction sequence and expected results so the provider can prepare a representative environment. During the session, ask to see both the process and its resulting records.
How many transactions should we test?
Start with one important end-to-end transaction and one or two relevant exceptions. Give the team enough time to inspect the results and record unresolved requirements.
What if a feature needs custom development?
Ask for a written description of the work, dependencies, cost, maintenance responsibility and acceptance test. Keep it marked as unproven until the agreed result is demonstrated.
Who should attend the ERP demo?
Include the people who carry out the selected transaction, a process owner and a finance representative when stock or accounting is involved. Bring an IT or integration owner when external systems form part of the scenario.
Does a successful demo mean the software is ready for go-live?
No. Implementation still requires data preparation, configuration, training and acceptance testing. Use the demo scenarios as a starting point for tests in your own configured environment.
Bring us your most complicated transaction
A split delivery. A return after payment. An approval that keeps getting stuck. Let’s use your everyday work to make the ERPNext discussion practical.
Product references
The scenarios are illustrative buyer tests. Explore the official ERPNext documentation for Delivery Notes, Sales Returns, Payment Reconciliation, Multi-Currency Setup, Workflows and Permissions.
