Finance ERP Procurement UAT: The Budget Control and Purchase Order Checklist

The purchase order approval workflow is one of the most configured — and most under-tested — processes in any ERP rollout. Finance leads know the risks in the GL and period-end close. They know the risks in payroll integration. But procurement and budget control scenarios are where configuration errors tend to hide: quiet failures that don't surface as system errors, only as incorrect spend commitments, blocked invoices, or budget reporting that doesn't match actuals.

This checklist covers the procurement and budget UAT scenarios that matter most before an ERP go-live — and the failure modes that standard test scripts miss.

Why procurement UAT is a finance problem

In most ERP programmes, procurement UAT is owned by the operations or supply chain workstream. Finance is consulted on approval hierarchies and gets a copy of the test results. That structure misses the finance-critical aspects of procurement: how purchase commitments interact with budget availability, how goods receipts drive accruals, how three-way match determines whether an invoice gets paid or blocked, and how the entire procure-to-pay cycle closes into the ledger at month-end.

Finance leads who treat procurement UAT as someone else's problem inherit all its failures. A misconfigured tolerance on three-way match doesn't block the system — it quietly pays invoices that should be queried, or blocks invoices that should be paid. A budget control check that fires at the wrong point in the approval chain doesn't prevent overspend — it frustrates users until someone works out how to bypass it. These aren't operational inconveniences. They're financial control failures that appear in the accounts at month-end.

“Procurement and budget control failures rarely look like system errors. They look like invoices paid at the wrong amount, budget positions that don't match commitments, and period-end accruals that need manual correction. By then, the UAT window has closed.”

Purchase order approval workflow UAT

The purchase order approval workflow is a decision tree with financial consequences. Every threshold, every approver assignment, every escalation path is a configuration choice that determines who can commit the business to spend — and at what level. UAT should confirm all of the following:

• —Purchase requisitions route to the correct approver at each configured threshold — including edge cases at exact threshold values (a £10,000 requisition should route identically to a £10,001 one where they sit in different approval tiers)
• —Approver delegation and absence cover work as configured — a requisition that can't be approved because the approver is on leave is a controls failure, not a process failure
• —Purchase orders are only created from approved requisitions — and that the approval status is correctly inherited or re-triggered on the PO as configured
• —PO amendment workflows trigger correctly when quantity, price, or delivery terms are changed after initial approval — re-approval should be required for changes that exceed configured tolerances
• —Emergency or single-source procurement routes that bypass standard approval are auditable — requisitions processed via exception should be flagged in approval reporting
• —Multi-entity purchasing — where a purchase order is raised in one legal entity for goods or services used by another — routes correctly across entity boundaries and generates the correct intercompany entries

Budget availability check UAT

Budget control in an ERP system operates at the point of commitment — the purchase requisition or purchase order — not just at the point of posting. The purpose is to prevent the business from committing to spend that exceeds approved budget before the invoice arrives. UAT must validate that this check actually fires where it's supposed to, and behaves correctly when it does:

• —Budget availability is checked at requisition creation, not just at PO creation or invoice posting — a commitment that creates a budget breach should be caught at the earliest possible point
• —Transactions that would exceed budget limits are blocked, routed for exception approval, or flagged as warnings — depending on how budget control has been configured for each cost centre or budget group
• —The committed position shown in budget reporting updates in real time as requisitions and POs are created — not just when invoices are posted or payments are made
• —Budget transfers between cost centres or budget lines update availability correctly across the system — including any downstream approval workflows the transfer may trigger
• —Period-end budget carryforward handles both committed (open POs) and actual spend correctly — the distinction between encumbrance carryforward and appropriation carryforward is a common misconfiguration
• —Budget control behaviour is consistent across purchasing document types — a manually-entered PO and a system-generated PO from a blanket agreement should both trigger the same budget check

Three-way match UAT: where invoices fail or get paid incorrectly

Three-way match — reconciling the vendor invoice against the purchase order and the goods or services receipt — is the control that prevents the business from paying for things it didn't order or hasn't received. In ERP systems, this matching is automated, but its behaviour is determined by tolerance configurations that are rarely tested with realistic procurement data:

• —Standard stock purchases: invoice quantity and price matched against PO within configured tolerances — test with invoices at, above, and below tolerance thresholds
• —Partial receipts: goods received in multiple deliveries against a single PO line — invoice should match against cumulative receipts, not individual delivery lines
• —Services and milestone billing: no physical receipt exists — match logic should use service entry sheets or milestone completion records, not GR quantity
• —Foreign currency invoices: exchange rate applied to the PO commitment versus the rate used at invoice posting — tolerance checks should operate on functional currency amounts, not original currency
• —Invoices with early payment discounts: discount terms on the invoice should not cause a price tolerance breach against the PO
• —Credit notes and reversals: a vendor credit note should correctly reverse the matched quantity and value against the original PO and GR
• —Blocked invoice processing: invoices that fail matching should route to the correct exception queue, not sit unprocessed — and the queue should be visible to the right users

Procurement-to-AP integration: closing the loop

The procure-to-pay cycle ends in the accounts payable subledger and the vendor payment run. Finance UAT must trace the full chain — from purchase requisition to payment — to confirm that each hand-off between procurement and finance produces correct entries:

• —Goods receipt posting creates the correct GR/IR accrual entry — credit to the GR/IR clearing account, debit to the inventory or expense account — at the correct value and in the correct period
• —Invoice posting clears the GR/IR accrual and posts the net difference (if any) to a price variance account — not back to the expense account
• —Open PO liability reporting correctly reflects outstanding commitments: POs raised but not received, receipts not yet invoiced, invoices matched but not yet paid
• —Payment run selects the correct invoices for payment based on due date, payment terms, and bank configuration — and produces the correct payment output format for each bank
• —Payment posting updates the vendor open item ledger correctly and reconciles to the bank statement format used for bank reconciliation
• —Vendor statement reconciliation: test the end-to-end cycle with a realistic vendor statement — invoices, partial payments, credits, and outstanding items — to confirm the system view agrees

Platform-specific procurement UAT considerations

SAP S/4HANA: Funds Management and Materials Management alignment

In SAP, budget control is typically implemented through Funds Management (FM) or through CO-OM budget profiles. The critical UAT risk is the alignment between the MM purchasing configuration and the FM budget structure: a purchase order coded to a cost centre that exists in MM but maps incorrectly to the FM budget hierarchy will post without error but report to the wrong budget position. Availability Control in FM must be tested with the actual FM account assignment structure, not the CO account assignment used in standard MM testing.

Three-way match in SAP operates through the LIV (Logistics Invoice Verification) process. Invoice tolerance keys — configured per company code — determine whether a price or quantity variance triggers a hard block or a warning. These tolerance keys must be tested with realistic procurement data across all purchasing document categories in scope: standard POs, framework orders, scheduling agreements, and service entry sheets each have different matching behaviours.

Dynamics 365: Budget Control and Procurement integration

In Dynamics 365 Finance & Operations, budget control is configured in the Budget Control module and integrates with the purchasing workflow via budget checks on purchase requisitions and purchase orders. The most common UAT failure is the budget control configuration that correctly blocks a requisition at the PR stage but fails to enforce correctly when the PO is created from the approved PR — because the budget check at PO stage uses a different financial dimension combination than the PR stage.

Dynamics 365 three-way match operates through the Invoice matching policy configured per legal entity and vendor. UAT should confirm that the matching policy applied to vendor invoices is consistent with the purchasing policy — an invoice matching policy set to two-way match (PO only, no GR required) for a category that should require three-way match is a control gap that passes all automated checks and fails the first audit.

How to structure procurement UAT for finance sign-off

Procurement UAT run in isolation — by the operations team, using procurement data, reporting to the programme — doesn't give Finance the assurance it needs to sign off. Finance-led procurement UAT requires a different structure:

1. 1.Scenario design anchored to financial controls: each test scenario should trace to a specific financial control — budget commitment, matching rule, accrual logic — not just to a process step. The question is not 'did the PO get approved?' but 'did approving the PO deduct the right amount from the right budget position?'
2. 2.Test data that reflects real procurement patterns: procurement UAT with three POs and two invoices doesn't surface the failures that appear at month-end with three hundred POs and partial receipts. Volume and variety both matter
3. 3.Cross-functional test execution: scenarios that cross the procurement-to-finance boundary — goods receipt creating an accrual, invoice posting clearing it — should be run end-to-end, not tested separately in each module
4. 4.Finance team validation of financial outputs: the accounts payable aging, the open PO commitment report, the budget utilisation report — these outputs should be checked by finance team members against expected values, not just confirmed as 'produced'
5. 5.Defect classification by financial control impact: a workflow routing failure that delays approval is operationally important; a budget check that doesn't fire is a financial controls failure. Defect severity should reflect this distinction

The procurement scenarios most often deferred — and why they matter

In every ERP programme, time pressure compresses UAT. The scenarios that get deferred are almost always the ones that are hardest to set up — and almost always the ones that matter most to finance:

• —Multi-entity procurement — intercompany purchasing scenarios require both entities to be configured, with intercompany posting profiles aligned. This is set up last and tested last, which means defects surface at the first intercompany purchase in production
• —Foreign currency procurement — realistic exchange rate scenarios, including rate fluctuations between PO creation and invoice posting, are skipped because they require currency data that wasn't loaded into the test environment
• —Year-end and period-end encumbrance handling — the behaviour of open POs at period close is tested once, with round-number data, in a UAT environment that doesn't reflect the volume or complexity of a real period-end
• —Vendor credit note processing — reverse scenarios are deferred because they require existing posted transactions to reverse against. In production, the first vendor credit note processed incorrectly creates an AP reconciliation difference that takes a week to untangle
• —Payment run exception handling — the scenarios where the payment run produces no output, produces a malformed file, or fails to clear the bank reconciliation are the ones most likely to cause a crisis on the first payment run date

Finance leads signing off on an ERP go-live should ask specifically whether these scenarios were tested — and with what data. A 'yes, it was in scope' from the programme team is not the same as documented evidence that the scenario was executed and the output verified.

Independent procurement UAT: what it adds

An implementation team testing its own procurement configuration has a structural disadvantage: the testers know where the configuration boundaries are and tend to test within them. The three-way match tolerance is set to a value that their test invoices all fall within. The budget check is tested with a budget that has plenty of headroom. The approval workflow is tested with requisitions that are straightforwardly in scope for a single approver.

Independent procurement UAT is structured to find the edges: invoices at exact tolerance thresholds, requisitions that should route to two approvers but only reach one, budget positions that should block a PO but don't because the financial dimension mapping has a gap. These are the defects that appear at go-live, not in vendor test scripts — and the reason finance leads who want a defensible sign-off seek independent validation of procurement and budget control before they commit.