A Go-Live Decision Taken in 2022 Is Still Setting the Audit Opinion in 2028

Where the programme stands this week

Birmingham City Council's Oracle Fusion reimplementation went live in August 2026, replacing the version that went live in April 2022 and never worked properly. Reporting on the council's own papers this week, The Register notes the new system has "no outstanding business-critical or priority level 1 or 2 tickets or issues" — a long way from the 311 open tickets the old system was carrying a year ago.

The same reporting puts the programme cost at £144.4m against an initial estimate of around £20m, rising towards £216m once forgone efficiency savings are counted, with over £5m spent on manual workarounds. It also reports that the council's auditors, Grant Thornton, expect disclaimer opinions for 2025/26, 2026/27 and 2027/28, with a clean opinion not anticipated until 2028/29.

A disclaimer opinion is not a finding that the numbers are wrong. It is an auditor saying they could not obtain enough evidence to form a view either way. That distinction is the story: the system is fixed; the evidence trail behind four years of transactions is not.

The areas that were never tested

Grant Thornton's review of the original implementation was reported in detail in early 2025. Its auditor Mark Stocks told councillors that testing "was completed in many areas" but that key areas had not been tested at all — the bank reconciliation system, the general ledger, accounts receivable and accounts payable. Officers reported struggling with bank reconciliation and found some aspects of the general ledger, in Stocks' account, untestable.

That is not a list of edge cases. It is the part of a finance system that produces the accounts. Everything since — the workarounds, the years the council could not control its finances, the disclaimer opinions running to 2027/28 — sits downstream of four modules going live without anyone able to demonstrate they worked.

The pattern repeated on the rebuild: in February 2026, Grant Thornton's Thomas Foster reported that the process for documenting data quality standards and confirming data was ready to migrate "was not well-established for finance in particular". Same function, same gap, four years apart.

"All the suppliers said go live"

The detail implementation partners should sit with is how the decision was made. Stocks' account is that all of the suppliers advised going live, that their advice carried caveats, and that council officers "did not have a thorough understanding of the risks". Grant Thornton also reported that end users were "unprepared and unequipped to use the system", and that the culture discouraged bad news.

Note what is absent from that description: anybody lying. Everyone appears to have said something defensible. The caveats existed; they did not survive contact with a date, because a caveat in a slide deck and an untested module in a test management system are not the same object. One gets nodded through. The other has to be closed, or accepted by name.

Grant Thornton noted that its assessment of the programme's suppliers was legally privileged and excluded from the public report — which tells you how these disagreements end when nobody can point to a record of what was tested, what was not, and who accepted the difference. The same dynamic ran through a troubled go-live that became a securities investigation, and through most of the best-documented ERP disasters.

What UAT actually has to prove on a finance system

Most UAT scripts on an ERP project are written as journeys: raise the requisition, approve it, receipt it, match the invoice. Necessary, but not sufficient, because they prove the screens behave. What an auditor needs three years later is different in kind — that the ledger balances, that the bank reconciles, that a subledger agrees to its control account, and that someone can show which version of the system produced which number.

A journey test passes when the user reaches the end of the journey. A reconciliation test passes when two independently produced figures agree. Only the second produces evidence an auditor accepts, and it is the kind dropped first under date pressure. Put to a client: a defect found in UAT costs a retest; a control never tested costs an audit opinion, years after the go-live everyone was worried about.

Four things to change in your own sign-off

Test coverage is a go-live gate, not a status slide. The question at the gate is not "is testing going well". It is: which scripts were never executed, which failed, and who is accepting each by name. If that cannot be answered from the tool in a minute, it is being assembled by whoever is most optimistic.

Put the financial controls in the script set explicitly. Bank reconciliation, the ledger close, control account agreement, AP and AR ageing, the year-end routine. Name them as their own suites, so their absence is visible rather than hidden inside a percentage.

Treat "untestable" as a defect, not a note. When a tester reports that something cannot be tested — no data, no environment, no interface yet — that is a finding with an owner and a date, not an asterisk. Birmingham's general ledger was reportedly in that category.

Make acceptance attributable. Someone named accepts each open risk, in writing, before the decision. Our guide to the UAT sign-off process covers how, and why a spreadsheet stops answering the coverage question at about the point a project needs it to.