UAT Is Not a Technical Test. It Is a Finance Sign-Off. And You Are the Signatory. In your finance career you have signed off a lot of things. The management accounts. The statutory accounts. The audit file. The year-end journals. The grant return. You sign because you understand what you are certifying. UAT — User Acceptance Testing — is the same principle applied to an ERP system. Before Oracle Fusion goes live, the finance team must confirm: Can we process an AP invoice from receipt to payment with the correct approval workflow, the correct GL coding, and the correct payment terms? Can we run the period close from AP cutoff through to a signed trial balance — in the system — with the correct journal sequence? Can we run payroll, post the journals to GL, and reconcile the payroll creditor control account? Can we produce the management accounts from Oracle — and do they agree to what we would expect to see? Can we run the CIPFA SERCOP return from Oracle without manual manipulation? If you can answer YES to all of those — in a test environment, with test data — the system is ready for go-live. If you cannot — it is not. And a Finance BA who understands what each test is proving is the person who can make that call. Not the Oracle consultant. Not the Programme Director. The accountants who understand what these reports and processes are supposed to produce. **Discussion question:** If you had to test your current finance system from scratch, what would be the three processes you would test first — and why? Fall4U FCA FCCA — Future Defined Academy

Budget Variance Reporting and Programme RAG Reporting Are the Same Thing. You Already Do This. Every month you produce a budget variance report. Revenue: £2.4m budget. £2.1m actual. £300k adverse variance. Reason: three contracts delayed. Action: accelerate Q3 pipeline. You rate it: RED. Needs management attention. Operating costs: £1.8m budget. £1.75m actual. £50k favourable. Reason: recruitment delay. Action: monitor — headcount plan at risk. You rate it: AMBER. Under control but watch it. Capital: £450k budget. £430k actual. £20k favourable. Reason: procurement savings. Action: none — tracking well. You rate it: GREEN. On an ERP implementation programme the Finance Workstream does exactly the same thing. Gate 2.1 — Test Complete: — SIT test pass rate: 95%. GREEN. — Data migration reconciliation: 3 variances under investigation. AMBER. — Payroll integration: CWM hours defect unresolved. RED. The framework is identical. The content is different. The accounting judgment that tells you what is material and what is not — that is the same skill. You have been producing RAG reports your entire career. You just formatted them differently. Discussion question: What is currently RED in your organisation's finance performance that is being reported as AMBER because nobody wants to have the difficult conversation? Fall4U FCA FCCA — Future Defined Academy

You Reconcile 847 Accounts by Hand. Oracle Reconciles Them in 4 Minutes. Here Is What That Means for Your Career. Every month someone on your team opens the bank reconciliation spreadsheet. They paste in the bank statement. They paste in the cash book. They match items manually. They investigate the differences. They produce a signed-off reconciliation for the auditors. For one account. One currency. One bank. Oracle ARCS reconciles 847 accounts. Automatically. At period end. With audit evidence attached to every reconciliation. But someone had to design it. Someone had to define: which transactions should auto-match against which? What tolerance is acceptable before a manual review is required? Which accounts need a risk rating applied? How does the AP sub-ledger map to the GL creditor control account? That is pure accounting knowledge. The Oracle consultant knows how to configure ARCS. The accountant knows what each reconciliation is checking — and what a failure means for the financial statements. On the DBIS Finance Transformation programme, 12 manual Excel reconciliation templates across 847 GL accounts were replaced by ARCS. The Finance BA who specified the matching rules, the tolerance thresholds, and the sub-ledger mapping was an accountant. Not because accounting was required. Because only an accountant understood what each reconciliation was actually proving. **Discussion question:** How many manual reconciliations does your team produce at period end — and what would happen to your financial controls if any one of them was missed? Fall4U FCA FCCA — Future Defined Academy

Before You Go Live on Oracle, You Have to Reconcile the Entire Organisation's Financial History. You know what a trial balance is. Every debit has a credit. Every balance agrees. Every account is accounted for. Data migration is a trial balance — applied to the entire organisation's financial history. Before an ERP goes live: Every open supplier invoice must transfer to Oracle AP. Balance must agree to legacy AP sub-ledger. Every open customer invoice must transfer to Oracle AR. Balance must agree to legacy AR sub-ledger. Every asset on the fixed asset register must transfer to Oracle Asset Management. NBV must agree to the legacy register. Every open purchase order must transfer to Oracle Procurement. Value must agree to the legacy commitment. Every employee record must transfer to Oracle Payroll. Pay scale, pension rate, tax code — all must transfer correctly. And all of it must reconcile to the closing trial balance of the legacy system. Zero tolerance. One variance means the trial balance is wrong. And a wrong trial balance at go-live is a financial statement risk from Day 1. The finance team are the only people who know whether the migrated numbers are right. Not the Oracle consultants. Not IT. Not the Programme Director. The accountants. Discussion question: If your organisation went live on a new ERP tomorrow, which balance on your current system would you be most worried about migrating correctly — and why? Fall4U FCA FCCA — Future Defined Academy

You Know What a Clean Ledger Looks Like. That Knowledge Designs the To-Be. After audit season you have looked at ledgers in every condition. The clean one: every transaction coded correctly, every balance reconciled, every accrual supported, every intercompany agreed. The messy one: miscoded expenditure, unsupported accruals, unreconciled balances sitting open since last quarter, intercompany disputes that have been open since the previous Finance Director left. You know — instinctively — what a clean ledger looks like. That instinct is your To-Be design capability. When an ERP Business Analyst runs a To-Be design workshop, they are asking: "What does the perfect version of this process look like?" You already know. Because you have seen the clean version and the messy version. You know that the clean version has automated bank feeds, not manual import. Three-way matching, not manual invoice approval. System-generated accruals based on goods receipt, not manual estimation. Auto-cleared intercompany, not monthly dispute calls. The To-Be is not an aspiration. It is the clean ledger. Designed into the system. Enforced by configuration. Not dependent on the right person being in post. Discussion question: What is the single biggest difference between your cleanest period close and your messiest? That difference is your To-Be design priority. Fall4U FCA FCCA — Future Defined Academy