Dynamics 365 Finance & Operations UAT: What to Validate Before Go-Live

Dynamics 365 Finance & Operations (F&O) is the most technically demanding module in the Microsoft Dynamics 365 suite to get into production safely. Unlike CRM or Field Service — where failures are visible to users almost immediately — Finance & Operations failures are often invisible at go-live and only surface at month-end close, at the first payment run, or during an external audit. By then, unravelling the root cause in a live production system is painful, expensive, and sometimes impossible without a restatement.

The challenge is that Finance & Operations configuration is inherently legal-entity-specific. Chart of accounts, tax codes, posting profiles, currency settings, payment formats, and intercompany rules must all be configured correctly for every legal entity in scope. A setting that works in one entity silently produces incorrect results in another. Automated testing — which typically runs against a single entity with synthetic data — cannot surface these discrepancies. Only UAT that mirrors real business workflows, run by people who understand both the Dynamics 365 configuration model and the business's financial operations, can close that gap.

1. General ledger and posting profile validation

The general ledger is the foundation of Finance & Operations, and posting profiles are the configuration layer that determines which account a transaction hits when it's posted. Posting profile errors are particularly damaging because they produce incorrect financial data from the first transaction — and often go undetected until Finance attempts to reconcile subsidiary ledgers to the trial balance.

In UAT, posting profile validation should cover every transaction type in scope for each legal entity:

• —Accounts payable posting — vendor invoice posting, payment journals, prepayment handling, and credit notes all hit different profiles; validate each against the chart of accounts
• —Accounts receivable posting — sales order invoicing, customer payment application, and write-off postings validated per customer group and payment method
• —Inventory posting — goods receipts, inventory adjustments, standard cost variance postings, and WIP entries tested with representative item groups and warehouse configurations
• —Fixed asset posting — depreciation runs, asset acquisition, disposal, and revaluation postings tested for each asset group in use
• —Per legal entity — every posting rule replicated in each entity and tested independently; don't assume a setting that works in the primary entity carries across to subsidiaries

2. Tax configuration per legal entity

Tax configuration in Finance & Operations is one of the most common sources of post-go-live defects — and one of the most costly to remediate, because incorrect tax postings require manual journal adjustments, potential HMRC or ATO submissions, and reconciliation work that can run into weeks. The complexity arises from the interaction between sales tax groups, item sales tax groups, and the posting definition for each combination.

• —Sales tax group assignment — validate that customers and vendors are assigned the correct tax groups, including exemptions and zero-rated classifications
• —Item sales tax group — each item or service category mapped to the correct item tax group, with correct tax rate and ledger account assignment
• —Cross-border VAT — for multi-entity or international deployments, test triangular transactions, EC acquisitions, and reverse-charge VAT scenarios explicitly
• —Withholding tax — if in scope, validate that withholding tax calculates correctly on vendor payments and that the certificate process is supported
• —Tax period mapping — each legal entity's tax settlement period correctly defined; test that the tax report runs cleanly for a sample period with realistic transaction volume
• —Tax reporting — run the tax reconciliation report and verify it agrees to the trial balance before sign-off; discrepancies at UAT are manageable, at month-end in production they are not

“The tax configuration errors that reach production are almost always legal-entity-specific. The primary entity gets tested; the subsidiaries get assumed. That assumption is where the month-end variance lives.”

3. Intercompany transaction flows

Intercompany transactions — sales, purchases, and financial journals between legal entities in the same Dynamics 365 environment — are among the highest-risk areas in a multi-entity Finance & Operations deployment. The intercompany accounting framework requires posting accounts, intercompany relationships, and currency settings to be configured symmetrically across both entities. A mismatch in any one of these creates unbalanced intercompany entries that are correct from the originating entity's perspective but produce posting errors or incorrect balances in the receiving entity.

• —Intercompany sales orders — create a sales order in the selling entity, fulfil from the buying entity's warehouse, and validate the intercompany purchase order, invoice, and accounting entries in both entities
• —Intercompany purchase orders — mirror the sales order test from the buying entity's perspective; confirm goods receipt and supplier invoice entries match expectations in both directions
• —Intercompany financial journals — test intercompany journal posting for cost allocations, management charges, and loan interest; verify the netting entries eliminate correctly in consolidation
• —Currency translation — for entities trading in different functional currencies, test that exchange rate application, rounding, and translation gain/loss postings are correct in both entities
• —Elimination rules — if consolidation is in scope, run the elimination process after completing intercompany transaction tests and verify that the consolidated result is clean

4. Bank reconciliation and payment formats

Bank reconciliation in Finance & Operations depends on the correct configuration of bank accounts, statement import formats, and matching rules. Payment format files — the electronic files sent to banks to initiate payments — are another frequent failure point. A malformed payment file produces a bank rejection, which delays supplier payments and potentially triggers late payment penalties.

• —Bank statement import — import a realistic bank statement file in the production format (MT940, CAMT.053, BAI2, or bank-specific) and confirm correct parsing and transaction matching
• —Automatic reconciliation rules — test each matching rule with representative statement lines; confirm matched, unmatched, and partially matched scenarios each resolve correctly
• —Payment journal and file generation — run a payment run for a representative vendor population, generate the payment file, and verify format compliance against the bank's specification
• —BACS, SEPA, or ABA — depending on the payment geography, validate the specific file format against a test bank environment before go-live; format errors that reach production often only emerge when the bank's system processes the file overnight
• —Electronic reporting configuration — validate that the electronic reporting (ER) format for payments, remittances, and bank statements matches the production bank's current specification, not an outdated template

5. Period-end close process

The period-end close is the ultimate integration test for Finance & Operations — it exercises every posting profile, every tax settlement, every bank reconciliation, every intercompany elimination, and every consolidation rule in a single coordinated sequence. Running at least one simulated month-end close during UAT is one of the highest-value tests an organisation can perform before go-live.

A simulated close in UAT should include:

1. 1.Post all open journals and invoices for the period
2. 2.Run the automatic payment proposal and generate payment files
3. 3.Complete bank statement import and reconciliation
4. 4.Run the depreciation proposal for all fixed asset books
5. 5.Run inventory closing (if standard or weighted average cost is in use)
6. 6.Run the tax settlement for each legal entity and each tax period
7. 7.Run the currency revaluation for foreign currency balances
8. 8.Post intercompany invoices and financial journals
9. 9.Run the consolidation (if applicable) and apply elimination rules
10. 10.Generate the trial balance report and reconcile to subsidiary ledgers

This sequence should be run by Finance team members using production-representative data, not synthetic test data. The volume, character, and completeness of the data matters — a month-end close that passes with ten transactions in UAT and fails with ten thousand in production is a UAT failure, not a production failure.

6. Financial reporting and Power BI integration

Finance & Operations financial reporting — whether via Management Reporter, Financial Reporting, or Power BI — must be validated against known source data before go-live. Report rows that produce incorrect figures, subtotals that don't match account rollups, or Power BI datasets that lag the ledger by more than the expected refresh interval all need to be identified and resolved before Finance relies on these reports in production.

• —Financial statement rows — validate each row definition in your P&L, balance sheet, and cash flow reports against manually calculated figures from the trial balance
• —Dimension filtering — reports that filter by department, cost centre, or project tested with representatives from each dimension to confirm correct data isolation
• —Power BI dataset refresh — if Power BI is connected to Finance & Operations via the entity store or direct query, test a full dataset refresh and validate figures agree with the Finance & Operations trial balance at the same point in time
• —Drill-through — confirm that drill-through from report totals to source transactions works correctly and produces the expected transaction detail

7. Role-based access in Finance & Operations

Finance & Operations uses a role-based security model built on duties, privileges, and security roles. The model is flexible but complex — a user assigned to a role inherits every duty and privilege associated with that role, and role assignments can be scoped to specific legal entities, organisations, or record-level conditions. Security gaps in Finance & Operations are high-risk because they can expose financial data across entities or allow a user to perform transactions they shouldn't be able to initiate.

• —Segregation of duties — validate that users who can create vendor invoices cannot also approve payments; users who can request purchase orders cannot also receive goods against them
• —Legal entity scoping — confirm that users assigned to a specific legal entity cannot access the journals, transactions, or reports of another entity they shouldn't see
• —Accounts payable and receivable clerks — test end-to-end AP and AR workflows as named test users with production-equivalent role assignments; don't test as system administrators
• —Financial controller access — validate that financial controllers have access to all reports and journal correction capabilities their role requires, without having edit access to transaction sources
• —Audit trail — confirm that the audit log captures the correct user identity and timestamp for high-value transactions (large invoices, payment runs, journal deletions)

The case for independent Finance & Operations UAT

Finance & Operations implementations are delivered by Microsoft partner teams who have spent months in the configuration. They know the system deeply — which posting profiles were set up conservatively and which were approximated, which tax codes were configured from specification and which were carried over from a legacy system migration. That institutional knowledge is what makes their UAT testing unreliable.

Independent UAT specialists approach Finance & Operations the way your Finance team will on day one: with a real business process to complete, no knowledge of implementation decisions made under time pressure, and no incentive to declare a scenario 'good enough.' That perspective consistently surfaces the configuration gaps that internal testing misses — posting profile mismatches, legal-entity-specific tax errors, intercompany netting failures — before they become month-end problems in a live production system.

For a Finance & Operations deployment where the first month-end close in production will be reviewed by an external auditor, the UAT cycle is not overhead. It's the only independent validation between your configuration and your financial statements.