Month End Mania: Taking the pain away
As an event, the month end process is entirely predictable. We know what we have to produce, and we generally know where the raw materials are. Predictability and practice give rise to experience, so we also tend to understand where any potholes lie. It sounds simple, yet month-end, to all but a relative few, remains an enigma. How does a single business process deliver such misery month on month?
It is arguable that the finance function suffers from change overload. With constantly shifting regulation, systems and business requirements, it is easy for every month to feel different to the last. As a result, we risk seeing our processes as isolated events, and of running them as if they had never been done before (re-inventing the wheel each time).
There is nothing to prevent us from seeing a month end as a manufacturing process, complete with a production line, defect tracking, quality control and formal customer feedback. Ultimately, we all want the same thing – to avoid a “costly” product recall.
So, like every production line, we have to start with the raw materials. The principal feed for our month end is our general ledger (GL), but we will no doubt require detail from other systems.
Quality assurance
In manufacturing, there is always a bad cop with a clipboard who is responsible for quality assurance. If we were to apply manufacturing techniques to our month end, we would always test our process inputs before we relied on them.
As it happens, our month end actually does have quality assurance, but this only tends to happen to the result. The cycle goes a bit like this: the CFO reviews the numbers, spots an issue, the team tries to find the answer, spots the issue, makes a change, and then resubmits. Imagine if a car was developed this way – would you want to drive it?
Some of our reporting problems can be tracked to data issues in our GL or other upstream systems. Obviously it can be time consuming to find and correct these issues during critical path month end time, so we often leave the problem for next month. But having had this experience, the question is: what do we do next?
Some of these issues will recur naturally, while others will disappear. For the latter, we breathe a sigh of relief, and move on. For the former, it can be months before we identify and fix the root cause.
In both cases, however, we’ve missed the point. Our new production line mind-set requires that, instead of waiting for defects to find us, we go and find the defects. Not only that, but we need to track and measure them to determine whether our remedial action is working. It is important to note that a data defect could come back a year later, so these tests must be on-going.
Intellectual Property
Let’s consider that our (considerable) knowledge about the business puts a great deal of intellectual property in our hands. Naturally, we put this to good use during our month end process, but gradually we see the burden of this begin to grow on our able staff, both during information production and review.
For instance, when I review process output, I need to consider whether we checked for all data issues that occurred within the past year (at least). What happens when we take on a new member of staff – what does this mean for the review process?
Consolidations
We should also bear in mind that many consolidation systems now contain “referential integrity tests” within our monthly and quarterly submissions, where, for example, relationships between Income Statement and Balance Sheet account movements are tested.
Our manufacturing process, being completely focused on customer experience, would also aim to detect any defects that may affect downstream dependencies. Fundamentally, the solution to these challenges lies in having an automated diagnosis process that tests your GL data for all previously experienced errors.
Introducing General Ledger diagnostics
A GL diagnostic process should be able to test for a number of standard defects: invalid general ledger codes, for example, product (these may originate from upstream systems), relationships between GL accounts (in other words, did a journal post to the correct accounts?), dimensional combinations (for example, business unit / profit centre combinations) and so on.
There are two groups of tests that are advisable: defect testing and review testing. Defect testing is absolute – it either fails or succeeds. Review testing involves identifying transactions that may not be wrong, yet almost definitely warrant a review. Good examples of this might be postings to other reserves, manual reserve adjustments over a certain threshold, and so on.
Ownership
Tests should be split up into logical units, and should be “owned” and executed by the staff that own the underlying problems, for example expenses, technical processing, intercompany, and so on. We have had considerable success with these processes where they were user-friendly enough for non-technical users to be able to add new tests quickly and easily.
Adding workflow into the mix means that our GL diagnostics can be made an integral part of the month end process. It also goes without saying that if we can automatically spot errors, we can certainly create automated processes to correct them.
An easier month end
With all of this in place, firms are able to run diagnostics at key intervals during the month. By month end, the GL is mostly clear of all known defects, focusing month end critical path time on more valuable activity and reducing the number of reporting iterations.