What month two of accounting automation looks like

Implementations are sold on the steady state and experienced through the transition. The gap between the two is where most projects are abandoned — not because they failed, but because month one is genuinely worse and nobody said so in advance.

Here is the realistic version.

Month one: more work, and it should be

The exception queue is long. Much of it is not current — it is historical unmatched items, suppliers the system has not learned, coding decisions nobody ever standardised. The system is surfacing a backlog that existed before it arrived.

Proposals need correcting often. The system has your history but no corrections from you yet. Recurring suppliers are handled well; everything else needs a decision.

People are doing two jobs if you are running in parallel, which you should be.

Someone says it is making more work. They are right. It is temporary and it is not obvious from inside week two that it is temporary.

What to do: correct inside the workflow rather than downstream with journals, because corrections in the workflow teach and journals do not. Clear the historical backlog deliberately rather than letting it sit in the queue confusing the picture.

What not to do: lower thresholds to make the queue shorter. That hides the problem instead of solving it and removes the evidence you need.

Month two: the diagnostic month

This is where you find out, and there are three possible shapes.

The good shape

Exception volume noticeably down. Recurring suppliers handled without attention. The queue is now mostly genuinely new or genuinely ambiguous cases. Time spent is at or below the old level.

What it means: working. Start looking at which confidence bands reviewers approve without amendment, and lower thresholds on that evidence.

The stalled shape

Exception volume about the same as month one. The same kinds of exceptions keep recurring. The team is still correcting the same suppliers.

What it means: something specific is wrong, and it is almost always one of three things:

• Corrections are being made downstream. Journals fix the month and teach nothing, so the same proposals return forever. The most common cause and the easiest to fix.
• Historical coding is inconsistent. The system cannot resolve an ambiguity that genuinely exists in your data, so it keeps asking. Fix the history for the affected suppliers.
• A threshold is set wrongly. Too tight, so ordinary transactions are being flagged.

All three are fixable in days. What is not fixable is ignoring it — a stalled month two becomes a permanently long queue and eventually a queue nobody works.

The bad shape

Errors nobody can explain. Exception volume rising. The team has lost confidence.

What it means: stop and investigate before going further. Rising exception volume after a full cycle means something upstream changed or the configuration does not match the process. Unexplainable errors are a vendor conversation — see what happens when the AI is wrong.

Month three: the assessment

By now the picture is real. Days to close should be improving. The queue should be short enough to work daily. The first sampling of confidently-processed transactions should have happened.

This is the point to decide whether to lower thresholds, whether to add a second process, and whether anything needs reconfiguring. Deciding earlier is deciding on transition noise.

What to tell the team beforehand

The single most useful thing an implementation can do, and it costs nothing:

"The first month will be more work, not less. The queue will be long and a lot of it will be old problems the system is surfacing rather than creating. Month two should be visibly better. If it is not, that tells us something specific and we will fix it. Judge it at month three."

A team told this in advance interprets a long queue as expected. The same team told nothing interprets it as failure, and by week three the narrative is set and difficult to change regardless of what the numbers do afterwards.

The pattern to watch

Across all three months, the number that matters most is not the exception queue's size but its direction. Falling means learning is happening. Flat means something is blocking it. Rising means something is wrong.

Everything else can be read from that.

Common questions

Does accounting automation create more work at first?

Yes, for roughly the first month. The exception queue contains historical backlog as well as genuine items, proposals need frequent correction while the system has no corrections from you yet, and a parallel run means doing two jobs. The increase is real and temporary, and telling the team in advance is what prevents week three being interpreted as failure.

What should month two look like?

Noticeably fewer exceptions, recurring suppliers handled without attention, and a queue consisting mainly of genuinely new or ambiguous cases. If month two resembles month one, the cause is almost always corrections being made downstream through journals rather than inside the workflow, inconsistent historical coding the system cannot resolve, or a threshold set too tight.

When should I judge whether it worked?

Month three. By then the historical backlog is cleared, recurring patterns are learned, days to close should be improving and the first sampling of confidently-processed transactions has happened. Judging at month one measures transition noise rather than the system.

What is the clearest warning sign during implementation?

Exception volume that is flat or rising after a full cycle. Falling volume means the system is learning; flat means something is blocking that learning, usually downstream corrections or inconsistent history; rising means something upstream has changed or the configuration does not match the actual process.

Related: measuring whether AI accounting worked · running an AI accounting pilot · change management in a finance team