Order to cash
- Quote and sales order with pricing and discounts
- Credit check and order release
- Shipment and invoice
- Cash receipt and application
- Customer statement and aging
ERP Testing
ERP testing services
Cloud ERP vendors ship updates on their own schedule, and each one can change the order, invoice or journal your business runs on. Agnotic Technologies tests your ERP around those dates: business process regression, customizations and integrations, migration reconciliation, roles and period-end close.
Vendor update regressionOrder to cash and procure to payMigration reconciliationSegregation of duties tests
Trusted by global innovators
ERP software testing
What is ERP testing?
ERP testing is proving that an enterprise resource planning system still runs the business after every change: vendor updates, customizations, integrations, data migrations and role changes. Agnotic Technologies runs ERP software testing for the client around business processes such as order to cash and procure to pay, with key users signing off each result.
ERP is different from a custom app because the riskiest changes are often not yours. A cloud ERP vendor updates the platform on its schedule, and your configuration, extensions and integrations have to keep working through each update.
We test ERP systems; we do not sell licences or advise on which product to buy. Test design techniques and acceptance testing in general are on our functional testing page.
Regression pack
Which business processes does an ERP regression pack cover?
We build the pack from your processes, not from screens. Each process runs end to end across modules and checks the documents and postings it should produce.
Procure to pay
- Requisition and approval
- Purchase order to the vendor
- Goods receipt
- Three-way match of order, receipt and invoice
- Payment run and remittance
Record to report
- Journal entry and approval
- Intercompany postings
- Accruals and reversals
- Period close
- Trial balance and financial statements
Plan to produce
- Demand and supply planning
- Production order and material issue
- Production receipt and costing
- Inventory valuation
Hire to retire
- Employee record and position
- Time and expenses
- Payroll postings to the ledger
- Leaver and access removal
ERP release test calendar
What runs before each ERP change, and who signs off?
The calendar we agree with finance and operations at the start, so every change has a test window and a named approver.
| Event | Tests that run | Who signs off | When, relative to the event |
|---|---|---|---|
| Vendor update preview | Full business process regression on the sandbox that receives the update first, plus integrations and key reports | Process owner for each area | From the day the update reaches the sandbox, finished before the production date |
| Client customization release | Tests for the changed extension, the processes it touches and a short smoke pack | The process owner who asked for the change | Before the release is approved for production |
| Integration change | Interface tests with the connected system, including rejected and repeated messages | Owners of both systems | Before either side deploys the change |
| Data migration rehearsal | Load, then reconciliation of counts, control totals and open items | Finance controller and data owners | Every rehearsal, with the last one run as a dress rehearsal |
| Period-end close | Close task tests, report totals and role checks for close tasks | Financial controller | Before the first close on a new release or a new system |
| Role or organization change | Segregation of duties checks and access tests for the changed roles | Internal control or audit owner | Before the roles are assigned in production |
For cloud ERP, the vendor's preview window sets the pace. We plan the regression run from the date the update reaches your sandbox, not the production date.
Data migration
How do we reconcile an ERP data migration?
A migration is only finished when the numbers in the new system match the old one. This is the order we reconcile in.
Agree the reconciliation rules first
Finance and data owners agree what must match, at what level and with what tolerance, before any data is loaded.
Check master data
Customers, vendors, items, the chart of accounts and bank details: record counts, mandatory fields, duplicates and the mapping of old codes to new ones.
Check open transactions
Open sales and purchase orders, open receivables and payables by customer and vendor, and inventory on hand by item and location.
Check balances
General ledger balances by account and period, and each subledger tied back to its control account.
Run processes on migrated data
Ship an open order, pay an open invoice and post a journal on migrated records, because loaded data can match and still fail in use.
Repeat on every rehearsal
The same reconciliation scripts run on each rehearsal and at cutover, so the final sign-off compares like with like.
Roles and segregation of duties
Which role conflicts do we test for?
We test that one user cannot carry out both sides of a sensitive task, in the roles as configured in the system, not only as designed on paper.
01
Create a vendor and approve its payment
Example: One user adds a vendor with their own bank details and pays an invoice to it
Approach: Test that vendor maintenance and payment approval sit in separate roles, and that bank detail changes need a second approver.
02
Raise a purchase order and post the goods receipt
Example: A buyer confirms receipt of goods that never arrived
Approach: Test that receipt posting is blocked for the user who created the order.
03
Post a journal and approve it
Example: A manual journal moves revenue between periods without review
Approach: Test journal approval limits, and that the poster cannot approve their own entry.
04
Change a credit limit and release an order
Example: A sales user raises a limit to push their own order through
Approach: Test that credit management and order release sit in separate roles.
05
Change pay and approve payroll postings
Example: A payroll user changes a salary and posts the result
Approach: Test separation between employee pay changes and payroll posting approval.
06
Broad access in production
Example: A support account keeps wide rights after go-live
Approach: Test that emergency access is time-limited and logged, and list every user who holds conflicting rights.
Period-end close
What do we check before the first close on a new release?
Close is where a broken posting rule finally shows up. We test it before the real close, not during it.
- Accruals post and reverse in the right periods
- Currency revaluation uses the right rates and accounts
- Intercompany balances eliminate to zero
- Subledgers agree with their general ledger control accounts
- Period controls stop postings to closed periods
- Trial balance, balance sheet and income statement totals match figures worked out from the test data
- Tax reports pick up the right transactions and codes
How do customizations and integrations survive each update?
Each update is tested against what you built on top of the ERP, not only the standard product. We keep a register of every extension, report, workflow and integration, each linked to the business process tests that cover it.
Integrations get their own checks: messages to and from MES, warehouse, CRM, banking and tax systems, including rejected and repeated messages. When a vendor update changes a standard API or data entity, these tests are where it shows.
Automated UI tests suit the stable core of the regression pack. We choose the framework with your team, and where the vendor offers its own regression tooling we use it for the standard tasks it covers well.
Failure points
Where do ERP releases go wrong?
Problems we see in ERP change projects, and the test that prevents each one.
Challenge
The vendor update reached production before anyone tested it.
Agnotic approach
A release calendar that starts regression the day the update reaches the sandbox.
Challenge
Tests pass on screen, but postings land in the wrong accounts.
Agnotic approach
Each business process test checks the ledger entries and documents it creates, not only that the screen saved.
Challenge
Migrated balances match, yet the first payment run fails.
Agnotic approach
Process tests on migrated records in every rehearsal, not only count checks.
Challenge
Test users have full rights, so role problems never appear.
Agnotic approach
Tests run as users with the real production roles.
Challenge
An integration fails quietly and orders stop flowing.
Agnotic approach
Interface tests for rejected and repeated messages, and checks for queues that stop moving.
Challenge
Only IT tests, and key users find problems after go-live.
Agnotic approach
Key users own sign-off for their processes, with test scripts written in their own terms.
Situations
Which ERP situations do we test?
Common reasons an ERP testing project starts.
Cloud ERP on a vendor update schedule
Microsoft Dynamics 365, Oracle Fusion Cloud or SAP S/4HANA Cloud customers who need a repeatable regression run for each update.
Moving to a new ERP
Migration rehearsals, reconciliation and process tests before cutover, alongside your implementation partner.
Mergers and new entities
New companies, currencies and intercompany flows added to an ERP that is already live.
Public companies with control reviews
Evidence that role changes and system changes were tested before they reached production.
Manufacturers with shop floor links
ERP, MES and warehouse system flows tested together, so production and stock stay in step.
ERP testing for startups and growing companies
A first ERP or a first major upgrade, with a small regression pack the team can keep running.
Scope
What changes the size of an ERP testing project?
We do not publish prices. These drivers set ERP testing cost, and we size them on the scoping call.
Processes and modules in scope
Which of order to cash, procure to pay, record to report and the rest are included.
Customizations and reports
How many extensions, workflows and custom reports sit on top of the standard product.
Integrations
How many connected systems exchange data with the ERP, and in which directions.
Entities and currencies
Legal entities, currencies and intercompany flows that each need their own checks.
Migration volume and rehearsals
How much master and open transaction data moves, and how many rehearsals are planned.
Roles to test
The number of roles and the conflict rules that apply to them.
Engagement
How does an ERP testing engagement start?
Three stages, each with an output your finance and operations teams can review.
1.
Process and change review
We list your processes, extensions, integrations and the vendor's next update date, and agree the release test calendar.
Plan2.
First regression pack
Business process tests for the highest-risk areas, run as real roles on your sandbox, with key users signing off.
Build3.
Every change after that
The pack runs for each vendor update and client release, and grows with each change you make.
RepeatFacts and sources
What do Microsoft, Oracle and the SEC rules say?
Vendor documentation and US securities rules that shape when and how ERP changes are tested, each linked to its primary source.
Microsoft describes service updates for Dynamics 365 finance and operations apps in four steps (configure, notice, update and validate), and customers in its First release program can update a sandbox before general availability.
Source: Microsoft Learn: One Version service updates overviewMicrosoft has marked the Regression Suite Automation Tool for Dynamics 365 finance and operations apps for deprecation and says it won't be supported after 15 May 2027.
Source: Microsoft Learn: Regression suite automation tool (RSAT)Oracle publishes a What's New document for each Oracle Fusion Cloud ERP update, such as update 26D for Financials and Procurement, to explain new features and help customers plan the upgrade.
Source: Oracle Cloud Applications Readiness: Enterprise Resource PlanningManagement of a US public company must evaluate any change in internal control over financial reporting during each fiscal quarter that has materially affected, or is reasonably likely to materially affect, that control.
Source: 17 CFR 240.13a-15(d) (eCFR)Internal control over financial reporting includes procedures that give reasonable assurance that receipts and expenditures are made only in line with authorizations of management and directors.
Source: 17 CFR 240.13a-15(f)(2) (eCFR)
Rules and frameworks
Which rules and frameworks shape ERP testing?
The control rules and testing references behind the calendar and role tests above. Your auditors confirm which apply to you.
17 CFR 240.13a-15ISO/IEC/IEEE 29119Vendor update policiesSegregation of dutiesGAAP and IFRSVersion control
Frequently Asked Questions
It depends on the processes in scope and how much of the pack is automated. We fit the run into the window between the update reaching your sandbox and its production date, and agree the scope for that window on the scoping call.
Yes. We test messages between the ERP and the systems around it, such as MES, warehouse, CRM, banking and tax services, including rejected, late and repeated messages, and check the postings each one creates in the ERP.
Where they fit. Vendor tools are good at replaying standard tasks in their own product. We add process tests across modules and integrations, ledger checks and role tests that those tools do not cover.
No. We test the ERP you run or are moving to, and work alongside your implementation partner. We do not sell licences or rank ERP products.
Key users explain how each process really runs, review the test scripts for their area and sign off results. We write and run the tests, so their time goes on decisions rather than clicking through screens.
Yes. A common start is the regression pack for one process, such as order to cash, run against the next vendor update, plus a segregation of duties check for the roles in that process.
It can draft test steps from your process documents and task recordings. A test engineer and the key user check every step against how your business actually runs, and expected financial results are always worked out independently.