Skip to content

Validation Testing

Applies to: All subscriptions

Purpose

Have the customer's own people prove the system works for their actual business — using their documents, their processes and their hands. Everything before this stage was tested by implementers.

Audience

The customer's business users, with the implementation consultant facilitating.

Prerequisites

  • External System Connectivity gate passed
  • A test environment mirroring the intended production configuration, on sandbox credentials
  • Real business users available — not their managers, and not the project team
  • A representative set of the customer's own documents

Steps

1. Test with real users and real documents

The people who will do the work must do the testing. A consultant demonstrating the system proves the consultant can use it.

Use Not
The customer's own documents Constructed samples
The people who will do the job daily Their managers
The customer's real process An idealised one
Their own workstations and network The consultant's laptop

2. Cover every business scenario

Scenario Why it must be covered
Ordinary domestic sale The baseline
Inter-state sale Different tax structure
Export The most commonly missed, and it has its own place-of-supply rule
Reverse charge Different treatment
Credit note against an invoice Different routing and a preceding-document reference
Debit note Same
High-value document Approval thresholds, if configured
Multi-line document Array handling
Document with discount and rounding Where arithmetic fails
Goods movement with an e-Way Bill Including Part-B, by the person who will do it
Cancellation And the understanding that the number stays consumed
Month-end volume The real peak, not an average day

3. Test the failure paths, by the people who will meet them

Scenario Expected
A document with a missing field Quarantined; the user finds it and fixes it themselves
A duplicate number Rejected; the user understands why it is permanent
A wrong classification code Caught; the user corrects the master
A cancelled counterparty registration Rejected; the user knows it is not their fault and what to do
A document outside the reporting window Isolated; the user knows it cannot be recovered

The pattern matters: the user resolves it, not the consultant. If the consultant resolves it, the test has proved nothing about day one.

4. Test the daily routine

Have the operations owner run Daily Checks unaided, on a day with real test activity. This is a rehearsal of the routine, not a walkthrough of it.

5. Test the roles as they will be held

Each user signs in as themselves and performs their own work. This catches role and access problems that a consultant with broad access never encounters.

6. Test the integration end to end, by the business

Raise a document in the ERP, watch it flow through, and confirm the outcome returns to the ERP — with the business watching the ERP screen, not the Complifly screen. That is where they will look in production.

7. Volume test

Process a realistic day's volume, including a month-end peak. Confirm processing completes within the business's window and nothing queues indefinitely.

8. Record and resolve findings

Severity Meaning Before go-live?
Blocker Business cannot operate Must be resolved
Major A significant workaround needed Resolve, or accept explicitly with the workaround documented
Minor Inconvenience May follow go-live, with a date
Observation Improvement Backlog

An unresolved blocker moves the go-live date. That is the point of a gate.

Validation

Gate: this stage is complete when all of these pass.

Check Pass condition
Every business scenario tested By real users, with real documents
Every failure path tested And resolved by the user, not the consultant
Daily routine rehearsed By the operations owner, unaided
Roles verified Each user signed in as themselves
Integration verified by the business Watching the ERP, not Complifly
Volume tested Including a month-end peak
No blockers open Blockers resolved; majors resolved or explicitly accepted
Business sign-off Written, by a named business owner

Rollback

Situation Action
Testing reveals wrong configuration Correct in test, re-test, then apply to production configuration
Testing reveals a mapping fault Correct the template and re-test with real documents
Testing reveals a process gap Fix the process, not the software. Some findings are not software findings
Testing reveals a capability gap Record it, agree a workaround, and decide explicitly whether to proceed

Nothing here is irreversible: everything runs on sandbox credentials. That is precisely why this stage exists before production credentials are issued.

Common mistakes

Mistake Consequence Avoid by
The consultant driving the testing Proves the consultant can use it The users drive; you facilitate
Testing with constructed documents Real documents fail after go-live Use theirs
Skipping export and reverse charge A wave of failures weeks later Cover every scenario
Skipping failure paths Users meet their first failure in production, alone Test them, and let users resolve them
Testing at average volume Month-end fails Test the peak
Managers testing on behalf of users The people who do the work are untrained The actual users
Accepting majors without documenting the workaround Support tickets nobody expected Document what was accepted
Going live with an open blocker Predictable failure Move the date

Troubleshooting

Symptom Cause Action
Users cannot complete their work Role or access, not the software Check the three gates
Documents fail that worked in earlier stages Real documents differ from samples This is the stage doing its job. Fix the mapping or master data
Users cannot resolve a failure unaided The message is not actionable, or training is incomplete Both are findings worth recording
Volume test queues indefinitely Worker, queue, or capacity Diagnose the layer before assuming capacity
The business cannot see outcomes in the ERP Write-back not consumed, or not enabled Check the flag, subscription, then consumer
Findings keep arriving late in the stage Scenarios were not enumerated up front Enumerate them at the start, then test to the list