Two seemingly similar processes with very different purposes and outcomes
The title of this article does not imply a sporting event, nor does it suggest legal action. In our world of finance, it simply denotes two specific processes conducted in the finance department of most organizations.
On the surface, one may conclude that both processes are one and the same. You use data supplied by your accounting system and perhaps also your budgeting and forecasting software to produce financial reports. These reports are then given to management to review or perhaps used to satisfy external reporting requirements, e.g., government, banking institution and shareholder compliance.
Financial reporting, such as at period end (month, quarter, year), is a process where consolidated or non-consolidated data is used to construct statements required for management or legal review and distribution to shareholders, government entities (e.g., SEC) or lenders and other persons who have a need to receive this information.
The data is extracted from the ERP or accounting GL and is either used with a built-in report writer or exported to an external tool, such as a spreadsheet (not a good or reliable choice but used by many companies). The final reports and statements are constructed, reviewed, edited, formatted and finally published and distributed. No company can escape producing financial statements and other compliance reports, but the distribution of these reports greatly varies from organization to organization.
Analytics, on the other hand, is a process that is not regulated nor is it mandatory and many smaller organizations simply ignore it, either by choice or ignorance. But common sense and experience dictate otherwise: Like many other business and work-related processes, just because you don’t have to do it doesn’t mean you shouldn’t do it.
According to the Business Dictionary:
“Analytics often involves studying past historical data to research potential trends, to analyze the effects of certain decisions or events, or to evaluate the performance of a given tool or scenario. The goal of Analytics is to improve the business by gaining knowledge which can be used to make improvements or changes.”
Another important use of analytics is to compare actual business results with budgets and forecasts and see how actual performance differs from its stated budget. This is useful in making decisions, realigning strategic and operational plans with new realities and making sure the business continues to function as envisioned and planned.
So why do many smaller organizations fail to recognize the importance of analytics?
There’s nothing mysterious or complex about the fundamental approach to regularly using analytics. You can certainly define what you want to see and at what intervals and to whom the results should be reported. Where it becomes complex and often impossible for many organizations is the process itself, especially after extracting all available and relevant data.
Nowadays, with computerized accounting functions, capturing transactional data is simple and automated. The process, however, usually generates vast amounts of information that’s stored in the application’s database and can be archived indefinitely.
Here’s a typical example of data that many ERPs (and even low-end accounting software) can capture:
A customer invoice is generated. The invoice lists on each of its lines a product or service. The product data is automatically retrieved from the product (or inventory) master file and may have several or more attributes: Product Code (Item ID), Product Type (e.g., Made-In, purchased), Product Group (e.g., Defense, Commercial), Product Category (e.g., metric fasteners, U.S. fasteners), or perhaps a lower-level classification of the item, such as Product Class (e.g., Phillips Flat Head, Slotted Oval Head, Phillips Round Head, etc.).
Customers, as captured in the Customer Master File, have their own attributes such as: Customer Number, Customer Type, Customer Class, Customer Category, Customer Region, Customer Territory, Sales Person and more.
In this example, a single invoice line will capture twelve attributes plus the date and time the invoice was recorded, the GL accounts the revenue and cost were recorded to, the inventory control account, the AR control account, the GL source category and perhaps other GL attributes for a total of at least eighteen (18) attributes (or data dimensions).
The system database will retain all this information for however long you want past the current fiscal year. It’ll amount to a lot of data, but given the low cost of electronic storage space, the data can and should be archived indefinitely.
Smaller organizations certainly realize the data is there, assuming all these common data dimensions were set up and standing records (Customer Master Records and Inventory Master Records) were properly created, but often are unable to extract the needed intelligence from these databases, either due to lack of qualified staff, management direction or technology-based tools.
In the next part of this article I’ll examine what can be done with the available data and how even smaller companies can leverage certain tools to perform in-depth analytics with little effort and cost.