ERP Finance UAT: Test Scenarios From Supplier Invoice to Financial Statement

Quick answer

Finance UAT should prove that business users can complete a transaction and produce the correct accounting, approvals, settlement and financial reports. Start with one traceable supplier invoice, follow it through payment, and reconcile its effect on the financial statements. Then test what must not happen: unauthorized approval, posting into a restricted period and payment of a rejected invoice. Agree expected results before execution, retain evidence and retest defects before sign-off.

1. Define the product scope and readiness requirements

This guide provides a linked test design for Microsoft Dynamics 365 Finance, using version 10.0.45, build 10.0.2345, as its reference baseline. Microsoft identifies that release with September 2025 general availability. It is not presented here as the latest release or a deployment recommendation. Record your actual application build, enabled features and customizations before adapting these scenarios. Microsoft Learn procedures are maintained independently of an individual implementation. (learn.microsoft.com)

The transaction route is a non-purchase-order service invoice entered through the vendor invoice journal, with journal workflow enabled. Do not reuse its navigation or expected entries unchanged for purchase-order invoices, inventory purchases or the invoice-register route: Microsoft documents these as different invoice-entry processes. (learn.microsoft.com)

Microsoft describes UAT as business-user testing in a dedicated, integrated test environment, using customer data, including migrated data. Users should receive training before testing, and business acceptance precedes deployment. (learn.microsoft.com)

Before starting, confirm:

• Configuration, migration and integration testing have reached the project’s agreed entry criteria.
• Vendors, payment terms, accounts, dimensions and opening balances are available.
• Workflow processing and reporting dependencies are running.
• Test users have intended production-like permissions.
• External banking connections cannot transmit real payments.
• A recovery plan exists for test data and configuration changes.

Keep transactional testing separate from the golden configuration environment. Microsoft’s implementation guidance reserves that environment for configuration, not transactions or test data. Source: configuration and migration guidance.

2. Assign owners and make every test reproducible

Use named owners rather than asking “finance” to approve the entire result.

Role	Responsibility in this test
AP clerk	Enter the invoice, submit it and correct rejected information
Business approver	Review coding and supporting evidence; approve or reject
Payments specialist	Select the invoice, prepare payment and verify settlement
GL accountant	Check vouchers, reporting dimensions and reconciliation
Controller/process owner	Accept the accounting results and residual risks
Functional consultant/test lead	Investigate defects and coordinate retesting

Execute with the relevant business-user accounts, not an administrator account. Microsoft’s testing guidance specifically includes role-based security and negative testing in process tests. (learn.microsoft.com)

For each test, record:

Test ID → requirement → prerequisites → user → steps → expected result → actual result → evidence → defect → retest result.

Include the legal entity, environment, application build, configuration revision and execution date. Save journal numbers, invoice references, voucher numbers and workflow instance IDs.

A screenshot saying “posted successfully” is insufficient evidence for the accounting checks. Retain the posted voucher and downstream reports as well.

3. Prepare one worked example with expected accounting

The following is illustrative test data, not a customer result or a prescribed account structure.

Assume:

• Accounting and transaction currency: USD.
• Service expense invoice: $1,000.
• Invoice reference: UAT-SVC-001.
• Expense dimension: an approved test department.
• Invoice and payment post within the same open test period.
• No sales tax, withholding, discounts, foreign exchange, fees or payment-clearing account.
• Controller-approved configuration posts directly to the expense, AP control and bank ledger accounts.

Approve this expected accounting before execution:

Checkpoint	Debit	Credit
Invoice posting	Service expense $1,000	AP control $1,000
Payment posting	AP control $1,000	Bank $1,000
Net effect after settlement	Service expense $1,000	Bank $1,000

These entries are the test oracle: the result your configured scenario is intended to produce. If your design uses clearing accounts or additional postings, replace the table before testing.

Link the scenarios as follows:

FIN-01 Entry → FIN-02 Rejection and correction → FIN-03 Approval and posting → FIN-04 Payment and settlement → FIN-05 Reporting.

Use separate invoice references for other negative tests. Otherwise, a successful negative-test correction can contaminate the balances used for the worked example.

Also expand the suite for actual business scope: tax, credit notes, partial payments, foreign currency, migrated open invoices and purchase-order matching where applicable. Passing this simple example does not establish readiness for those variations.

4. Test invoice entry, rejection and approval as one chain

FIN-01 — Enter the invoice

Microsoft’s documented starting route is Accounts payable > Workspaces > Vendor invoice entry > New invoice journal. Create the journal and enter its lines, including vendor, posting date, invoice reference, credit amount and offset account. With vendor invoice journal workflow enabled, submit through Workflow > Submit. (learn.microsoft.com)

For UAT-SVC-001:

1. Confirm the legal entity and journal name.
2. Enter the $1,000 service invoice.
3. Check expense coding, dimensions, currency and calculated due date.
4. Attach or reference sanitized supporting documentation.
5. Submit as the AP clerk.

Expected: the journal follows the configured approval route. No posted invoice voucher should exist yet under this test design.

FIN-02 — Reject, correct and resubmit

Have the approver reject the invoice because its test department is incorrect. Record a clear reason.

Microsoft documents rejection as ending the current approval process; the originator can subsequently resubmit the document. Available approval actions depend on configuration. (learn.microsoft.com)

Expected: rejection is recorded, the invoice remains unposted, and no posted payable for this invoice is available for settlement. Correct the department and resubmit using the permitted process. Check that the renewed approval addresses the corrected version.

FIN-03 — Approve and post

Complete every required approval, then post using the authorized role. Compare the voucher with the expected accounting table.

Retain workflow evidence from Common > Inquiries > Workflow > Workflow history, including the instance, workflow version, work items and tracking details. (learn.microsoft.com)

Pass only when the approved document, posted voucher and $1,000 vendor liability agree.

5. Test controls, especially the closed-period exception

Negative tests need precise expected outcomes—not simply “the system should show an error.”

Test	Action	Pass condition
Unauthorized approval	Sign in as an unassigned user and attempt approval	The user cannot complete an approval outside the approved security/workflow design
Self-approval	Have the submitter attempt to approve their own invoice	Behavior matches the organization’s approved self-approval rule
Rejected invoice payment	Search the payment selection for the rejected, unposted invoice	No posted payable from that rejected invoice is selectable for settlement
Invalid coding	Use a dimension combination prohibited by the configured account structure	The transaction cannot complete with prohibited coding
Restricted-period posting	Attempt posting with a date in a restricted period	No voucher is posted into that restricted period

Do not assume self-approval is automatically prohibited. Microsoft documents Disallow approval by submitter as a configurable setting, with a default of No. If your policy prohibits self-approval, verify both the setting and actual behavior. (learn.microsoft.com)

Closed-period testing requires two separate cases.

First, test a posting attempt into an On hold period with the intended user permissions. Capture the period status, attempted date, message, final date and voucher search.

Second, test workflow approval when the journal’s original posting date is no longer open. Microsoft’s vendor invoice journal procedure states that approval advances a posting date falling in an On hold or Closed period to the first day of the next open period. Therefore, “an error must appear” is not a reliable universal expectation for this route. (learn.microsoft.com)

The control objective is no posting into the restricted period, plus an approved treatment of any date movement. Escalate a mismatch with the business’s cutoff policy.

Use On hold for reversible test restrictions. Microsoft warns that a permanently closed period cannot be reopened. Source: period-end procedures.

6. Test payment selection, posting and settlement separately

FIN-04 — Pay the approved invoice

Microsoft documents the route Accounts payable > Payments > Vendor payment journal, followed by journal lines and Payment proposal > Create payment proposal. Proposal selection can use due dates, discount dates and additional query restrictions. (learn.microsoft.com)

For the worked example:

1. Restrict selection to the test vendor and eligible invoice.
2. Preview the proposal.
3. Confirm invoice reference, $1,000 amount, payment date, method and bank account.
4. Complete the configured payment authorization and posting process in the sandbox.
5. Inspect the payment voucher.
6. Verify that the payment settles UAT-SVC-001.

Check settlement through the vendor’s Transactions > View settlements. Microsoft documents this view as showing settlement history and related accounting. (learn.microsoft.com)

Expected under the example assumptions: AP is debited $1,000, bank is credited $1,000, and the invoice has no remaining open amount.

Keep three results distinct: payment prepared, payment posted and invoice settled. Retain evidence for each. An ERP payment test also does not, by itself, demonstrate successful processing by a real bank.

7. Reconcile the invoice through to the financial statements

FIN-05 — Demonstrate reporting completeness

Take snapshots before invoice posting, after invoice posting and after payment. Compare movements rather than assuming the test environment has zero opening balances.

Measure	After invoice posting	After payment
Test invoice’s open amount	$1,000	$0
AP control movement attributable to this chain	$1,000 credit	Net $0
Service expense movement	$1,000 debit	$1,000 debit
Bank ledger movement	$0	$1,000 credit

Run vendor aging with a recorded Balance as of date and date criterion. Microsoft distinguishes aging by transaction date, due date and document date; changing the criterion changes the report basis. Source: Vendor aging report.

Reconcile the relevant vendor subledger balances to AP control using the same legal entity, cutoff and accounting currency. Investigate differences rather than adjusting the expected result to match the output.

Generate the configured income statement and balance sheet. Financial reporting supports financial statements and dimensions, but the implementation’s report definitions still need acceptance testing. (learn.microsoft.com)

Confirm that:

• The expense reaches the intended income-statement line and department.
• AP increases before payment and clears afterward.
• The bank balance reflects the payment.
• Report totals reconcile to ledger balances.

If a statement omits the transaction, investigate its date, account mapping, dimension filters and reporting data availability before declaring a posting defect.

8. Classify defects, retest and sign off on evidence

Adopt severity definitions before execution. The following is a suggested project convention, not a Microsoft standard:

Severity	Suggested meaning
Critical	Unauthorized posting/payment, material accounting error or loss of transaction integrity
High	Required workflow or reconciliation cannot complete without an unacceptable workaround
Medium	A supported workaround exists, but operational handling or reporting is impaired
Low	Cosmetic or documentation issue without an accounting or control impact

Keep severity separate from fix priority.

Every defect should include reproduction steps, expected and actual results, affected build, business impact, evidence and the linked test ID.

After a fix:

1. Record the deployed change.
2. Repeat the failed case with the intended user.
3. Rerun affected downstream scenarios.
4. Repeat related negative tests.
5. Preserve the original failure and retest evidence.

Retesting proves the particular defect is fixed; regression testing checks whether the change disrupted other behavior. Microsoft documents regression testing after solution changes or updates. (learn.microsoft.com)

For sign-off, require completed critical business chains, accepted reconciliations, resolved release-blocking defects and explicitly approved residual risks. Record blocked tests separately from passes.

The useful acceptance question is not “Did users finish the scripts?” It is: Can finance explain, authorize and reconcile what the configured system did?