Finance automation: month-end reports, bank reconciliations and documents that stop running on Excel

What repeats every month in the finance department, in the same form?

Take one month of work in the finance department and mark every task that was also done last month, in the same order and from the same sources. Most of the board gets marked. That is not a management failure. It is simply the shape of the work: a monthly cycle, a quarterly cycle, an annual cycle.

That is also exactly why this department is a better candidate for automation than most departments in the organisation. A process that repeats identically is a process that can be described precisely, and what can be described precisely can be moved.

The difficulty is not in spotting it. It is that this work lands precisely at month end, when it competes for the same hours with everything urgent, so it gets squeezed into nights and weekends instead of being examined.

Month-end reporting automation: the monthly management report

It is almost always the first process that comes up in conversation, and not by chance. It repeats in the same structure every month, it relies on fixed sources, and it has to go out on a date.

But it is worth splitting it in two, because only half of it is relevant here:

• Gathering and assembly. Pulling from every system, matching formats, cross-checking that the numbers add up, building tables and charts, formatting. That is the mechanical part, and it is usually most of the time.
• Interpretation. What the numbers say, what is an exception, what to recommend to management. That is the professional part, and it stays with whoever writes it.

An automated process handles the first and delivers the report built, with the data already in place, so that the time left goes to the second. In one process measured at a client, two days of manual assembly became a minute. This was not a finance report, so it is not a number you should expect. It is a number that shows the order of magnitude of the mechanical part once it is taken out.

Bank and supplier reconciliation automation: the work starts from the exceptions

A reconciliation is a cross-check between two lists: the bank transactions on one side, the entries in the accounting system on the other. The same goes for supplier accounts, for payment clearing and for the billing system.

The pain here is especially measurable, because the overwhelming majority of the rows are fine. You go through thousands of transactions to find the three that did not close. An automated process turns that around:

• The cross-check runs on all the transactions, not on a sample and not on what there was time for
• What matched with certainty is closed and never reaches the desk
• What did not close arrives as an ordered list with the reason: an amount difference, a transaction with no matching entry, an entry that never appeared at the bank, or a date that does not match

The work does not disappear. It starts from the exceptions.

Invoice and collections automation: documents that go out on their own

The other side of the department is not analysis but production: invoices to issue, collection letters to send, confirmations to produce, files to pass to the accountant.

This work grows linearly with activity, and that is the point: one document or a thousand takes the same effort once the process is built. At one of the clients the process built was producing quotes. The company reports a saving of dozens of hours a month, and the ability to price projects in depth instead of sending out a quick price for lack of time.

The same structure applies to collection reminders: who owes, for how long, what was sent to them before, and what the next step is under a policy you set.

AI for the finance department: where it helps, and where it is unnecessary

This is the question with the most stories sold around it, so it is worth being precise. AI does not replace a rule. It reads what a rule cannot read.

• AI helps when the information is free-form: a scanned invoice with fields to extract, a supplier's email where the request has to be worked out, an indexation clause buried in a forty-page contract, a transaction description written in free text.
• AI is unnecessary when the information is already structured: if the data sits in a field in a system or a column in a table, a simple rule is more accurate, cheaper, runs faster, and can be explained to an accountant. That is a real consideration in a department that has to defend what it did.

In a real process the two kinds appear together: AI reads the scanned invoice, and an ordinary rule checks that the amount matches the order. Whoever sells you AI for every step of the process is selling more than you need.

Hashavshevet, Priority, Microsoft 365 and the banks: what your existing systems allow

This question comes up early, and rightly so. The honest answer is that it is checked, not predicted, against your system, in the version and with the permissions you have:

• Some systems have a proper interface for reading and writing
• Some allow only file exports or scheduled reports, and that can be worked with too
• And there are operations the vendor simply has not opened to external access

This is true of Hashavshevet, Priority, the billing systems, Microsoft 365 and the banks. A process that relies on data that cannot be exported is not built, and that is said at the measurement stage, not after it.

Exception detection: continuous controls have a page of their own

The finance department is also where control sits, but that is a separate subject, and it gets full treatment elsewhere. A duplicate payment, a change in a supplier's bank details, an indexation that was not updated, a breach of investment policy, a deal delivered and never billed: all of it belongs there.

The difference between the two pages is simple. This page is about the work that repeats even when everything is fine. Controls are about what happens when something is not fine, and above all about what sits in the seam between departments.

Continuous controls in the organisation: catching what falls between departments

Repetitive work in a profit centre: what stays invisible when it runs correctly

From our point of view, every line of business, every unit in the organisation and even every team is a separate profit centre. That is how they are measured at the organisational level.

Whoever manages such a unit is measured on the result, but what determines it does not always reach them. They receive the output ready, so the cost of the output never enters the conversation about priorities. The table shows that gap.

There is deliberately no hours column here. Any number we wrote would be a guess about your organisation. The hours are measured at yours, before anything is built.

Notice what all the rows have in common: none of them contains an error. The work was done and the result went out. What is missing is its cost, so it never enters the conversation about priorities.

What automation gives back here is first of all visibility: once the mechanical part is taken out, the numbers stop being an estimate, and what stays on the desk is what actually needs a manager.

And what never moves, at any stage, is the interpretation, the recommendation and the professional responsibility. They are never identical to the previous round, and they stay with you.

The other side of that same gap is what is written about the unit from outside. That is what the audit unit sees when it examines the same work, and how much of that reaches the report presented to management and the board. That is a subject in its own right, and it gets full treatment on the page Unit controls and audit in the organisation.

When we say no: three situations where we recommend not building

This is not false modesty. These are three situations in which our recommendation is not to build:

• When the data itself is not reliable. Automation on wrong data does not fix it. It only produces the error faster and in greater quantity. The source is fixed first.
• When the process runs once or twice a year. The investment is not recovered, and it is probably better left manual.
• When it turns out the process exists for a reason that is no longer relevant. It happens that we measure a process and find it was born of a requirement that was cancelled or a system that was replaced. Then the recommendation is to cancel it, not to automate it.

Some measurements end with the conclusion that the saving does not justify the investment. That is a legitimate answer, and it is said before anything is built, not after.

Where to start: one finance process, measured first

Not from a plan, and not from an organisation-wide survey. From one process.

• We pick the one that repeats the most or hurts the most
• We measure how much time it really takes and which sources it relies on
• We check against the systems what can actually be exported
• And only then do we decide whether it justifies building

That measurement is also what sets the order for what follows, and what makes it possible to say no without guessing.

More on automation services for business: how it works, and when we say no

Frequently asked questions about finance automation