Functional acceptance is not the ceremony that closes an ERP, CRM or business application project. It is the point at which the company verifies that the system can support real operations, including imperfect data, user errors and failed integrations. Signing on the strength of a polished demonstration means accepting risks the supplier has carefully avoided showing.
The promise you hear everywhere: “a successful demo is enough”
The usual story is reassuring: development is complete, technical tests are green and the consultant knows the demonstration script perfectly. A few users review the main screens, the managing director signs the acceptance report and the project moves into production without further delay.
Under this model, acceptance is an administrative formality. The supplier has already tested the solution, so business users supposedly need only confirm that it resembles the approved designs and that the buttons respond.
This argument confuses three different activities:
- A demonstration proves that the supplier can execute a prepared scenario.
- Technical testing checks the behaviour of a component, interface or infrastructure.
- Functional acceptance establishes whether users can perform the expected business operations under the conditions defined for the project.
A demonstration may therefore look flawless while access rights remain incorrect, accounting exports are incomplete or partially delivered orders cannot be invoiced.
What is true: business teams must make the decision
Yes, users must take part in acceptance. A developer can confirm that a calculation follows the programmed rule; only the business owner can decide whether that rule reflects the way the company approves discounts, blocks orders or handles disputes.
The ISTQB acceptance-testing framework explicitly brings together business analysts, product owners and testers to define acceptance criteria, design tests and monitor their execution. It also distinguishes user, contractual and regulatory acceptance.
However, user involvement does not mean placing employees in front of the application and asking them to “try it and tell us whether it works”. They need:
- a precise journey to execute;
- controlled starting data;
- a verifiable expected result;
- a rule for classifying defects;
- evidence to retain for every test.
These elements must come from the project requirements. If those requirements remain ambiguous, acceptance will not repair them: every defect will become a debate about interpretation. Acceptance should extend the work completed during project scoping and specification writing, not attempt to replace it at the end.
What is false, or only true under specific conditions
“If the happy path works, the system is ready”
The happy path is familiar: create a customer, enter an order, deliver it, issue the invoice and record payment. It is necessary, but it rarely reveals the most disruptive problems.
Acceptance must also cover genuine exceptions: duplicate customers, out-of-policy discounts, partial deliveries, credit notes, rejected invoices, unavailable products, absent approvers, missing mandatory data and interrupted synchronisation. Where CRM and ERP systems exchange information, the project must verify not only that data leaves one application, but that it arrives once, in the correct location and with an understandable status. Our guide to CRM and ERP integration explains this continuity risk.
“No bug appeared during the session, so quality is proven”
No. The ISTQB Foundation Level syllabus states that exhaustive testing is impossible except in trivial cases. It also warns that a system with no detected defects may still fail to meet users’ actual needs. The useful question is not “did we test everything?” but “did we prioritise what could stop, distort or disorganise operations?”.
Testing effort must reflect business risk. An incorrect icon colour and an incorrect tax calculation cannot receive the same priority.
“The supplier can write and approve all tests”
The supplier can prepare the repository, configure data and provide technical evidence. It should not be the only party deciding whether the outcome is acceptable.
| Item under review | Validation owner | Expected evidence |
|---|---|---|
| Business journey | Process owner | Actual outcome compared with expected outcome |
| Roles and permissions | Application and business owners | Verified access matrix |
| Interfaces and data | Project manager | Reconciliation between source and destination |
| Defect correction | User who reported the issue | Retest and recorded result |
| Recovery or rollback | Supplier and internal owner | Procedure executed in the intended environment |
“We will use a production copy because it is more realistic”
Only under tightly controlled conditions. The French data protection authority recommends using fictitious or anonymised data for development and testing. If real data is genuinely required in pre-production, that environment must receive appropriate protection and access must be restricted to authorised people. Freely copying customer, employee or banking data into test environments increases both access and storage locations.
What it costs when you proceed without preparation
The first cost appears after go-live: users discover that a step is missing and create a parallel spreadsheet. The application remains the official system of record, while actual operations become fragmented across the ERP, spreadsheets, emails and manual controls.
The second cost is technical debt. To correct a design gap quickly, the supplier adds a specific parameter, script or exception rule. These adjustments make later changes harder to test and increase dependence on the people who remember why they were introduced.
The third cost is contractual. The exact effect of an acceptance report depends on the agreed clauses, but it may trigger payment, start a warranty period or record acceptance of a defined scope. Signing with poorly classified defects makes it harder to distinguish a correction already owed by the supplier from a new chargeable request.
Finally, improvised acceptance consumes employee time without producing a reliable decision. The same issue is reported repeatedly, others disappear into email threads and nobody knows which version was actually tested. This is a recurring consequence of running an IT project without a clearly assigned IT leadership role.
The reasonable way to proceed
Set the decision rules before acceptance starts
The sponsor, project manager and business owner establish an acceptance matrix before the first session. The deliverable states which defects block production, which allow conditional approval and which belong in the future enhancement backlog. The decision must not be improvised under deadline pressure on signing day.
Test business chains, not a collection of screens
Each process owner executes the journey from its triggering event to its commercial, accounting or operational outcome. The acceptance window covers a complete business cycle relevant to the application. The deliverable is a traceable test book linking every scenario to a requirement, expected outcome and item of evidence.
For illustration, accepting an order-to-cash process does not stop when an order is created. It also covers modification, delivery, invoicing, possible credit notes and accounting transmission, using different user profiles.
Prepare the environment, permissions and data
Throughout the acceptance window, the application owner provides an identified software version, accounts representing real roles and a representative fictitious dataset. The deliverables include the tested version, permission matrix and dataset description. Quietly changing versions during acceptance invalidates evidence already collected.
Retest after every significant correction
The supplier fixes the defect; the user who identified it reruns the scenario; the project manager launches regression tests on potentially affected functions. A defect is not closed because a developer says it is resolved. It is closed when the expected result has been reproduced and recorded.
Separate functional fitness from regular service
A solution may pass prepared tests and still degrade during ordinary use. Without automatically applying public procurement rules to a private contract, companies can usefully adopt the distinction made by the French General Administrative Clauses for Information and Communication Technology contracts between fitness verification and regular-service verification. This public framework uses a thirty-day observation period; a private contract should choose a period aligned with the relevant business cycle and define availability, performance and correction criteria.
Our position at D1 Consulting
We reject both extremes: symbolic acceptance organised immediately before go-live and a documentation factory that attempts to test every theoretical combination. An SME needs proportionate acceptance focused on actual operational risks and connected to contractual commitments.
Our IT Project Management service covers acceptance strategy, scenario design, user coordination, defect tracking, preparation of the acceptance report and production transition. We can act as project leadership or shared IT management so that the supplier is not simultaneously responsible for delivery, testing and declaring its own work accepted.
👉 Book a free 30-minute diagnostic to identify your critical journeys, sign-off criteria and the blind spots in your next acceptance phase.
