NetSuite user acceptance testing should prove that people can complete important business processes and that the resulting records, balances and controls are correct. Testing individual screens is useful during build, but business acceptance needs connected scenarios from the initial event through its operational and financial outcome.
Create a test script for each material process and exception. Use the business roles intended for production, realistic data and an expected result approved before execution. A test that says only “transaction saved successfully” is too narrow when the transaction also drives inventory, approvals, billing or reporting.
Each script should identify its business objective, role, prerequisites, input data, steps, expected outcomes, evidence and approver. Record the environment and configuration version. Separate the expected result from the observed result so the tester cannot redefine success after seeing what happened.
Use evidence proportionate to risk. Capture record identifiers, relevant statuses, quantities, accounting entries and report parameters. Screenshots can help, but they should not be the sole evidence when a saved report or transaction reference provides a clearer audit trail.
Testing requires a suitable account. Oracle distinguishes development accounts and sandbox needs, including the need for distinct environments for some concurrent UAT projects. Confirm the chosen environment's features, data and external connections before assigning scripts to users.
Begin with a standard approved order, fulfillment, invoice and receipt. Ask the operations tester to confirm quantities and status transitions; ask finance to confirm the resulting receivable and settlement. The expected posting depends on the approved design and enabled features, so have the controller define it rather than copying generic debit-and-credit examples.
Add a partial fulfillment and partial billing case. Confirm how remaining quantities appear and how users locate unfinished work. Include a cancellation, a credit and a return. Test whether freight, tax and discounts follow the approved treatment, especially when a return covers only part of an order.
For connected ecommerce or CRM systems, trace the original source identifier through NetSuite and back to the source where acknowledgements are required. Test a rejected message and its correction. Confirm that retrying does not create an unintended duplicate and that the business owner can see unresolved exceptions.
Test a purchase request or order through approval, receipt, bill and settlement using the process actually in scope. Include an approver who should reject or be unable to approve the transaction. Check that an ordinary requester cannot bypass the approved control through another form or route.
Add partial receipt, quantity discrepancy, price difference and supplier credit scenarios. Verify how the team identifies received-but-unbilled activity or other relevant reconciliation populations under its design. A successful bill entry does not prove that the receiving and accounting records agree.
Use a test for duplicate or invalid supplier references. Confirm that users know the approved correction route and that a workaround does not silently create another supplier. Keep payment execution in a safe test arrangement; do not send real payments as an incidental UAT step.
Where inventory is in scope, test receipts, transfers, fulfillment and adjustments for representative items. Include units of measure, locations and any lot, serial or bin requirements. Compare on-hand and available quantities where those concepts matter to the approved workflow.
Test an exception that the business genuinely faces: short stock, a damaged receipt, an unexpected return or a transaction crossing the cutoff. Ask warehouse users to demonstrate what they would do without consultant prompting. Capture the downstream valuation or financial review required by the scenario.
An integration-heavy operation should also test interrupted processing and out-of-order events. The expected result can be a clear rejection and an assigned exception rather than automatic completion. Visibility and controlled recovery are legitimate acceptance outcomes.
Build at least one complete reporting cycle using the test transactions. Reconcile selected control accounts to their supporting detail. Check report filters, posting periods, subsidiaries and currencies. Confirm that the person responsible for each reconciliation can retrieve the required evidence with their intended access.
For multi-entity projects, test the relevant intercompany flow and consolidated output, including mismatches that require investigation. Local and group finance should approve their respective results. Do not assume agreement at a consolidated total proves every entity is correct.
Oracle's workflow-based test-plan guidance is written for Release Preview, but its coverage of reports, customizations, integrations and SuiteApps is a useful reference when designing implementation tests. Adapt the coverage to your project rather than presenting release testing as a substitute for implementation UAT.
Consider a distributor selling ten units in one currency, with only six ready to ship. The script starts with an approved ten-unit order and follows the agreed partial-fulfillment and billing design.
The tester records the shipment of six, checks that four remain open, reviews the intended invoice and validates stock movement. Finance verifies the approved receivable, revenue and inventory accounting outcomes. The script then retries the shipment confirmation from the external system and confirms that the retry does not ship another six units.
The scenario passes only when the operational state, accounting result and duplicate-handling behavior meet the predefined expectations. A saved order alone would not establish any of those conclusions.
Classify defects by consequence and availability of a safe workaround. Record the affected requirement, owner, fix version and retest result. Distinguish failed tests from tests that could not run because data or access was missing. Neither should be counted as passed.
Before signoff, confirm that critical scenarios passed, material fixes were retested, business owners accepted residual issues and procedures reflect the final design. Ask the sponsor to approve any remaining launch risk explicitly.
UAT is most valuable when it changes decisions before production is affected. Start with the scenarios that would cause the greatest disruption if wrong, and retain the scripts for later regression testing and new-user practice.