Change management in a finance team specifically

General advice on bringing a team through change is in bringing your team along. Finance is a specific case, and three of the objections you will meet are not resistance to change — they are correct.

Treating them as obstacles to be managed is what makes finance implementations harder than they need to be.

The three rational objections

"If something goes wrong, it is my name on it"

Not fear of change. A correct description of professional accountability. The accountant signs, answers to the auditor, and carries the consequence — and is being asked to accept output from a process they do not yet trust.

What works: show them the controls rather than reassuring them. What posts automatically, what stops for review, what the audit trail records, what happens when it is wrong. An accountant who can see the control environment usually becomes the strongest advocate, because they understand better than anyone what the manual process was actually catching, which was often less than assumed.

What fails: "don't worry, it's very accurate."

"I will not be able to explain it"

The person who produces the numbers gets asked about them. If the numbers were produced by a system they cannot interrogate, they cannot answer — and being unable to answer in front of a director is a professional exposure.

What works: making sure they can drill from any figure to the transactions and the document, and demonstrating it early. This is the single most effective thing you can show a sceptical finance team.

What fails: telling them the system is reliable. That is not the concern.

"This is most of my job"

For someone whose role is largely processing, this is true. Denying it costs credibility for everything else you say.

What works: being specific about what their role becomes, and meaning it. Exception investigation, review, analysis — with actual training, not a queue and an approval button. See the career path after data entry.

What fails: "nobody's job is at risk", said without a plan. People can tell.

The objections that are not rational, and what they are really about

"The old way works fine." Usually means "the old way is mine and I am good at it". The underlying concern is status — being expert at something that is about to stop mattering. The answer is a visible path to being expert at the new thing.

"Clients/the auditor won't accept it." Frequently a proxy for the speaker's own discomfort. Worth testing gently: ask whether they have asked the auditor. Usually not.

"We tried something like this before." Often true, and worth taking seriously rather than dismissing. Ask what happened. The answer is usually specific and usually preventable, and addressing it directly does more for credibility than any assurance.

What finance teams need that others do not

To see the audit trail early. Not at the end. It is the thing that converts scepticism, because it addresses accountability directly.

To keep the parallel run. Other departments can switch over and adjust. Finance has a reconciliation to produce and a deadline, and running in parallel for one cycle is what makes the change safe rather than brave.

To be involved in setting thresholds. These are accounting judgements. A finance team consulted on them owns the outcome; one presented with them owns nothing and will not defend the result.

To know what happens at month end. The first close after a change is the anxiety point. Walking through it in advance — what will be different, what will be the same, what to do if something looks wrong — removes most of it.

The person who decides the outcome

In most finance teams there is one experienced person whose view everyone else takes. Not necessarily the manager.

If they are unconvinced, the implementation will be complied with rather than adopted — exceptions cleared without investigation, corrections made downstream, workarounds preserved.

Worth identifying them early and spending disproportionate time with them. Not persuading — involving. Ask them where they think it will go wrong. They will usually be right, the answers improve the configuration, and being asked is what changes their position.

What to say at the start

Short and honest:

"Processing is going to be automated. The first month will be more work while it learns and we clear the backlog. Your job becomes reviewing what it did and handling what it could not — which needs more judgement than entry did, not less. If something goes wrong it is still our responsibility, so we are keeping the parallel run for a full cycle and we will show you exactly what the audit trail records."

That addresses accountability, explains the transition, describes the role change honestly, and commits to something specific. It is considerably more effective than enthusiasm.

Common questions

Why do finance teams resist automation more than other departments?

Because three of their objections are correct rather than resistant: professional accountability means their name is on the result, being unable to explain a figure they are asked about is a real exposure, and for processing-heavy roles the change genuinely removes most of the work. The standard change-management playbook underperforms in finance because it treats rational concerns as obstacles to be overcome.

What convinces a sceptical accountant?

Showing the controls and the audit trail early, and demonstrating that any figure can be traced to the transactions and documents behind it. Accountants who can see the control environment frequently become the strongest advocates, because they understand better than anyone how much the manual process was actually catching. Reassurance about accuracy addresses a concern they do not have.

How should you handle someone whose job is mostly processing?

Honestly. Denying that the change affects their role costs credibility for everything else, and people can tell when there is no plan behind the reassurance. What works is being specific about what the role becomes — exception investigation, review, analysis — and providing actual training rather than handing over a queue with an approval button.

Who determines whether an implementation is adopted?

Usually one experienced person whose view the rest of the team follows, who is not necessarily the manager. If they are unconvinced, the change is complied with rather than adopted — exceptions get cleared without investigation and corrections get made downstream. Asking them early where they think it will go wrong tends to both improve the configuration and change their position.

Related: training your finance team on AI tools · what month two of automation looks like · bringing your team along