The governance that made it deliverable

A European manufacturer approached us with a specific ask: deploy Microsoft Copilot for Finance, and prove it had delivered value.

They had tried this before. They enabled the AI features in D365 Finance and Operations, watched the toggle flip to active, and waited. Nothing meaningful happened. The reconciliation suggestions were generic. The collections recommendations did not reflect how their business actually operated. After a few months, the features sat unused. No ROI. No adoption. Time written off.

What they had learned, the hard way, is that enabling Copilot in the Feature Management workspace takes approximately five minutes. Running a programme that makes those features deliver real financial return is an entirely different undertaking.

Flipping the switch turns on the AI engine. It does not configure the risk thresholds that tell the model when to act and when to flag. It does not define who owns a recommendation, who can override it, or what happens when the output is wrong. It does not clean the customer master data the model will act on. Without those foundations, Copilot analyses what is available and generates output against whatever it finds. Your finance team is then left with recommendations that are either useless, or plausible enough to action without being trustworthy enough to rely on.

The scope we agreed covered three use cases: automated Bank Reconciliation, Collections Intelligence for their outstanding receivables portfolio, and Period-End Close Acceleration. All three were operating on live data, inside a production environment, with 3,000+ customers on the AR ledger. The margin for a generic AI recommendation acting on uncleaned data was not small.

This is not a story about the technology. The technology worked, when it had what it needed to work on. This is a story about building that foundation.

This is not a story about the technology. The technology worked. This is a story about what it takes to run a programme like this without it unravelling when the inevitable happens.

Phase 3 was dedicated entirely to governance. Not a governance appendix. Not a slide in a steering pack.

A working governance framework that would be in place before a single Copilot use case went near a user.

This produced three documents that became the backbone of the programme. An AI Output Review Policy (POL-AI-001), which defined how outputs from each of the three Copilot capabilities were to be reviewed, escalated, and overridden. An Ownership RACI (RACI-AI-001), which assigned explicit accountability for every AI decision pathway: who owned the data, who owned the model output, who had authority to override, and who was responsible for exception management. And a Confidence Thresholds Document (THR-AI-001), which set the quantitative boundaries below which the AI would flag rather than act.

The confidence threshold work was the part the client found most uncomfortable, in a productive way. Setting a threshold is an act of honesty about what you trust the AI to do unsupervised. For bank reconciliation, we set the auto-approve threshold at 95%: matches below that confidence level go to individual review rather than batch approval, and anything under 60% cannot be processed at all. For collections, customer risk is scored from zero to ten, with anything above 7.5 reviewed the same day and anything above 9.0 escalated to the CFO within two hours. Every collections communication the AI drafts is reviewed by a person before it is sent, at any score. For period-end, the AI drafts and nothing it drafts reaches the management pack without Finance sign-off.

These were not arbitrary numbers. They came from stakeholder workshops, analysis of the client's existing exception rates, the Phase 1 data quality baseline, and a frank conversation about what happens when an AI gets it wrong inside a live finance system.

The governance pack was signed off at CFO level before Phase 4 began. That sign-off mattered more than the documents themselves. It meant that when things went wrong, and things did go wrong, we had an agreed framework to operate within.

What I want to note about that Steering Committee meeting is not the outcome. It is the quality of the conversation.

Because the exception process had been followed correctly, with a formal report, documented options, quantified impacts, and a clear recommendation, the committee was able to make a real decision rather than a reactive one. The question on the table was not "what do we do about this crisis." It was "which of these three options best serves the programme's objectives." That is a different conversation to be in.

The revised timeline came at a cost, and I want to be straight about which one. UAT had been planned as a three-week window from 15 June. To avoid pushing go-live any further, we compressed it into eight days, from 1 to 8 September. What we did not compress was the coverage: thirty-five test cases across all three use cases, executed by the client's own finance team, with defect triage and resolution running in parallel through the same week.

Ten defects were raised during UAT, catalogued as D-001 through D-010 in the defect log: three high severity, four medium, and three low. None were critical path blockers. The three high-severity items were the ones worth having found: foreign currency transactions were not enforcing the mandatory individual review the governance framework required, collections risk scores were not refreshing after a payment was posted, and the period-end commentary was reversing the sign on variances, showing favourable as adverse. All ten were resolved and re-tested before the sign-off meeting on 8 September 2026.

"Ten defects in UAT is not a warning sign. Ten defects in UAT that are all resolved before go-live is exactly what a working QA process looks like."

I get asked regularly what the single most important thing is to get right before deploying Copilot for Finance.

Or any enterprise AI capability on a D365 estate. The answer is always the same: governance architecture.

Not because it is the most technically interesting work, because it is not. Not because the AI tools require it, because they do not, they will operate without it. But because everything that can go wrong with an enterprise AI programme goes less wrong when the governance is clear before anyone starts. The change controls are cleaner. The exception process has a framework to operate within. The Steering Committee has a basis for decision-making that is not just instinct and cost. The users know what the AI is allowed to do, and what a human is expected to do instead.

In this programme, the governance framework we built in Phase 3 did not prevent the programme from slipping. It prevented the slip from becoming a crisis. When the bank feed complexity surfaced, we had a formal exception process to run it through. When the Steering Committee had to choose between three recovery options, they had documented criteria to evaluate them against. When UAT found ten defects, we had a defect log with agreed severity classifications and a resolution process that was already in place.

None of that is glamorous. All of it is the difference between a programme that delivers and one that does not.

Related reading