ERP Testing Fundamentals
Master configurations, modules, integrations, and the data migration testing that every ERP implementation lives or dies by.
1 The Hook
A Wellington government agency migrated from MYOB to Oracle Fusion. Finance went live on day 1. Payroll on day 30. A misconfigured cost centre mapping meant that 3,000 employees were paid to the wrong cost centre — CHAP settlement was correct so money reached the right bank accounts, but the GL reporting was wrong. Nobody noticed during UAT because the testers verified payslips, not the journal entries behind them.
The problem was discovered six weeks later during month-end close, when the finance team tried to reconcile departmental spend and the numbers were completely off. Remediation required a manual journal correction across 3,000 records, a re-run of management reports, and an explanation to the Auditor-General. Total cost: $340,000 in consultant time and rework. The project had a test team of five people.
The test team had no ERP-specific test cases. They had functional test cases — “create a payslip, verify the amount” — but not configuration test cases — “verify the cost centre mapping for every department sends postings to the correct GL account.” That is the distinction this lesson teaches.
2 The Rule
Test the CONFIGURATION, not the SOFTWARE. Oracle, SAP, and Dynamics are proven platforms. What fails in NZ implementations is always the configuration — the chart of accounts, the approval workflows, the localised tax rules, the integration mappings. Your test suite must exercise every configuration decision, not just every screen.
3 The Analogy
Testing ERP is like testing a custom-fitted suit, not a suit off the rack.
You are not checking whether the fabric holds together — the manufacturer already did that. You are checking that the tailor’s measurements are correct. Every business has different sizes. The sleeves might be too long. The waist might be set for the previous owner. A cost centre mapping that worked at the last agency may be completely wrong for this one.
Off-the-rack testers check the features. ERP testers check the fit. That is a fundamentally different job, and it requires a fundamentally different test suite.
Senior engineer insight
The hardest mindset shift for testers new to ERP is accepting that the application itself is not the subject under test — the configuration is. On a Dynamics 365 Finance implementation for a NZ Crown entity, our team spent the first two sprints writing test cases for screens and workflows, then realised we had zero coverage of the 2,400 financial dimension combinations that drove all departmental reporting. Rewriting the test suite from scratch cost three weeks. Now I always start an ERP engagement by listing every configuration artefact before writing a single test case.
Most common mistake: treating “transaction completed successfully” as a pass condition without checking where the resulting journal entry actually posted.
4 Watch Me Do It
Here is a worked test case for a Procure-to-Pay approval workflow, the kind of case that would have caught the Wellington agency defect:
Precondition: PO for $15,000 NZD; approver A has delegation limit of $10,000;
approver B has delegation limit of $50,000.
Steps:
1. Create PO $15,000 → verify status “Pending Approval”
2. Route to approver A → verify system auto-escalates (PO exceeds A’s limit)
3. Route to approver B → verify approval notification received
4. Approve via approver B → verify PO status = “Approved”
5. Verify commitment accounting entry created in GL
6. Verify GL account = correct cost centre for purchasing department
Expected: Approval chain follows delegation of authority policy.
GL commitment created against correct cost centre.
No manual override of the escalation rule is possible.
5 Decision Tool
Not every test technique applies equally to ERP. Use this table to choose the right approach:
| Scenario | Use this technique | Not this one |
|---|---|---|
| Verifying setup decisions made during implementation | Configuration testing (checklist-driven) | Feature/functional testing |
| Moving data from legacy system to ERP | Data migration testing (row counts, data quality, mapping) | Standard functional testing |
| Verifying ERP talks to payroll/HR/third parties correctly | Integration smoke + E2E contract testing | Unit testing of ERP screens |
| Business users signing off on a process | UAT with real user profiles and real test data | System testing by the test team alone |
| Checking the ERP behaves correctly after a software upgrade | Regression testing (ideally automated) | Ad-hoc exploratory only |
6 Common Mistakes
🚫 Testing in PROD because “the sandbox is out of date”
Why it happens: Sandbox refresh cycles slip, and testers face pressure to confirm something is working now.
The fix: Never test configuration changes in production. An out-of-date sandbox is a project management problem, not a reason to put test data into production. Escalate the sandbox refresh as a blocker and document the risk.
🚫 Missing the chart of accounts in test data setup
Why it happens: Finance teams own the chart of accounts and testers assume it is correct by default.
The fix: The chart of accounts is the most important configuration artefact in any ERP. Every financial test case must verify the GL account code in the resulting journal entry — not just that the transaction posted, but that it posted to the right account. This is a mandatory step, not optional.
🚫 Not testing month-end close processes
Why it happens: Month-end close is a business process, and test teams focus on day-to-day transactions.
The fix: Month-end close (period close, reconciliation, report generation) is often where configuration errors surface. Include at least one month-end close cycle in SIT. If you cannot test a full close, test the close-related configuration: period statuses, access controls for the close process, and report outputs.
From the field
A large NZ local authority was three weeks from go-live on SAP S/4HANA when the test team discovered their GST tax codes were configured against the wrong tax procedure. The team had run 400+ test cases through accounts payable and receivable — all passing — because they had been testing that invoices posted, not that the GST treatment was correct for NZ Revenue NZ requirements. The fix required a full transport of corrected configuration through DEV, QA, and PROD, a re-run of all financial test cases with a revised expected-values checklist, and a two-week go-live delay. The lesson that generalises: for any ERP with a localised tax engine, build a dedicated tax configuration test suite that validates each tax code against the Revenue NZ rules before touching functional testing.
7 Now You Try
Paste or edit the prompt below, then click Run to get a real AI response.
8 Self-Check
Click each question to reveal the answer.
Q1: What is the most common cause of ERP implementation failures in NZ, and what does that mean for your test focus?
Configuration errors — not software bugs. The platform is proven; what fails is the 10,000 setup decisions made during implementation. Your test focus must be on configuration testing: verifying every chart of accounts entry, approval workflow, tax rule, and integration mapping, not just that the screens function.
Q2: Why must every financial test case verify the GL account code, not just the transaction status?
Because a transaction can post successfully to the wrong GL account. The system will report “Posted” regardless of whether the account code is correct. Verifying only the status tells you the process worked; verifying the GL account code tells you the configuration is correct. The Wellington agency payroll example shows what happens when you skip this step.
Q3: What is the difference between SIT (System Integration Testing) and UAT on an ERP project, and who runs each?
SIT is run by the test team to verify the system works correctly end-to-end across modules and integrations, using representative test data. UAT is run by business users to verify the configured system meets their requirements, using realistic business scenarios and their own data. The test team supports UAT but does not run it. Both are required on any ERP implementation — SIT finds technical and configuration defects; UAT finds process and usability gaps that only real users discover.
Why teams fail here
- Treating ERP test phases like bespoke software phases — writing feature test cases instead of configuration verification checklists, so entire configuration layers (chart of accounts, dimension hierarchies, tax codes) get zero test coverage
- Starting functional testing before master data is stable — every test run produces different GL postings depending on what cost centres or suppliers exist that day, making defects impossible to reproduce or baseline
- Delegating integration testing to the system integrator with no independent verification — on Oracle Fusion and Dynamics 365 projects, the vendor-built integration adapters are routinely the highest-risk artefact and need independent contract testing by the test team
- Skipping a simulated period-end close in SIT — month-end reconciliation is where misconfigured cost centres, locked periods, and incorrect accrual rules surface, and discovering them post-go-live costs orders of magnitude more to fix than finding them in SIT
9 Interview Prep
Real questions asked in NZ QA interviews for ERP roles. Read the model answers, then practise your own version.
“What’s different about testing an ERP versus testing a bespoke application?”
The fundamental difference is that ERP testing is configuration testing, not feature testing. In a bespoke application you are verifying that the development team built what was specified. In an ERP you are verifying that the implementation team configured the platform correctly for this organisation. The software is already proven — Oracle and SAP are not going to have broken their journal posting engine. What breaks is the chart of accounts, the approval delegation rules, the cost centre mappings, the integration file formats. Your test suite must systematically exercise every configuration decision, which requires you to understand the business rules well enough to know what the configuration should produce.
“How would you approach test data for an ERP implementation?”
ERP test data has three layers. First, the master data — the chart of accounts, cost centres, suppliers, customers, employees, and products that every transaction depends on. This must be set up before any functional testing can begin, and it must mirror the production configuration. Second, transaction data for SIT — realistic but synthetic, covering all the main business scenarios and edge cases. Third, migrated data for data migration testing — a sample of the actual legacy data, run through the migration scripts, with row counts and data quality rules verified against the source. The mistake most teams make is starting functional testing before master data is stable, which means every test run produces different results depending on what master data exists at the time.
Key takeaway
ERP testing is not about whether the software works — it is about whether 10,000 configuration decisions made by your implementation team are correct for this organisation, this chart of accounts, and this jurisdiction.