“A Complex, Lengthy Process, Often Not Well Understood”
Starting from business transactions such as the purchase of materials, payment of employees, execution of ﬁnancial transactions and ending with reporting and decision making; including the submission of detailed annual reports, the record to report process (RtR) is a long, complex process that involves people from across the enterprise.
Despite the critical nature of the process it’s rare to ﬁnd RtR clearly documented from end to end, few employees can describe the process in detail from start to ﬁnish. This could be in part due to the process extending from the core customer facing business through to technicalities of statutory and regulatory reporting. Some excellent papers and books exist, but many focus only on individual aspects of RtR.
“How Do We Deﬁne Record To Report”
There are different definitions out there, from a narrow view such as it’s primary financial statements (balance sheet, proﬁt & loss, cash flow) only, through to a wider view which includes aspects of planning, management reporting and regulatory reporting.
It’s useful to start from a wider view, after all the primary statements are a huge dependency for these other processes.
The majority of organisations have followed the trend to address processes from a horizontal or value chain perspective, however it’s observed that while processes are named on a horizontal basis the actual organisation and method of managing process, data and business applications is often still done according to traditional functional leadership models.
For the purposes of this paper we will consider from all business transactions and reporting with financial impact as part of the extended record to report process.
“Looking at the Big Picture”
Every step of RtR is beset by problems due to errors in previous steps, this is another reason why it’s important to take a step back and look at the end to end ‘big picture’. Secondly it’s important to retain a business based view of what the process aims to achieve. It’s possible to find entire accounting teams working exclusively on the preparation of one IFRS disclosure, whilst highly capable they cannot always describe where their input data came from or the originating business transactions. Stepping outside the need to comply with specific requirements on a technical basis a core aim of financial and management reporting is to ensure that information accurately reflects the reality of the business.
Anyone working in record to report should understand the context of:
- What is the current corporate strategy (targets, markets, risks etc.)?
- What is the current product set (products, customer base etc.)?
- How does this ﬁt with their part of RtR? – how does this related to the numbers, analysis, commentary etc. that they are working on?
“Start From The Customer”
A useful mindset that from six sigma is ‘voice of the customer’ and customer satisfaction, with RtR it’s highly beneficial to start from the requirements of external and internal end customers and then work those requirements back through the process. End customers of RtR include:
- Statutory authorities – ﬁling of full accounts & other disclosures (IFRS / local GAAP)
- Tax authorities – ﬁling of tax returns
- Regulatory bodies – disclosure of required industry speciﬁc reporting, for example:
- Insurance & banking – assets, valuation, product sales, transactions, liquidity etc.
- Pharmaceuticals – US FDA or local equivalent requirements
- Shareholders, market analysts etc.
- Half year and annual reports
- Ad hoc announcements and reports based on key business events
- Other parties
- Special topics such as sustainability, diversity, health and safety etc. which may include some limited ﬁnancial information
- Internal management
- Financial information as a basis for planning, budgeting, and generation of performance indicators utilised in making decisions to steer the business.
When considering management reporting it’s useful to think of RtR within such context of management models such as “plan – do – check – act”. At a simpliﬁed level the business transactions we record provide a continual way to measure the “do” while the resulting information output in reports and analysis provide a basis for “check” and “plan”. Thus the planning process is closely connected, if not part of RtR.
“What Does The Customer Need or Want?”
Unfortunately a lot of efforts to improve RtR fail by going straight into mid-process improvement without ensuring they are focused on the right outputs. Requirements are often based on what the customer receives in the ‘as is’ process or guess work.
An issue lies with availability of senior management and top experts. CEOs and CFOs rarely have the time to sit and explain to a project team the exact structure and wording they would like to see in their annual report, likewise general managers rarely have the time to help design every line of a monthly business review reporting pack.
There are also risks and issues in engaging with statutory and regulatory bodies or with external analysts at this level of detail; speciﬁcally trying to uncover requirements without giving away sensitive information about the operation of the business.
Regardless of the challenges it’s critical to try and connect with the end customer in order to deﬁne the answer to questions such as:
- What is the minimum that has to be reported to maintain shareholder and market conﬁdence?
- On top of the minimum what extra information needs to be reported, what beneﬁt does it give and what is the cost?
- What questions and decision is each report attempting to answer?
- How does reporting capability compare to competitors – content, timing, quality?
- How will requirements change over time for each report / information area?
These answer are not only needed for the design and implementation of reporting and analytics, they are also at the stage of data model design for business applications (transactional). ERP projects fail due to poor data model design, entire multi-million pound ERP projects have occurred without any noteworthy discussion on reporting occurring. Companies have been known to re-implement the same ERP to ﬁx this.
“Remember The Core Business”
On the ﬂip side of understanding the customer is understanding what exactly is being manipulated and consolidated to provide a set of accounts and reports.
Often RtR improvement initiatives focus on ‘turning the handle’ of mechanical processes to produce a set of numbers. Converting an insurance policy to a general ledger entry, consolidating to a group level, eliminating inter-company, summarising into ﬁnancial statement format etc. ERP systems, data integration experts and consultancies traditionally focus on these mechanical steps. In recent years a lot more focus has been placed on data warehousing, analytics, dashboarding, formatted reporting etc. however there is still a gap in knowledge and capability around business analysis.
This involves understanding the context of a business transaction and how that affects the accounts, this context is often provided manually via supplementary ‘outside of the main systems’ excel style reporting. Whether talking about variance analysis, current vs. prior period analysis, balance sheet substantiation or other activities the RtR process requires the capability to clearly explain the position of each account or KPI during each reporting period. A huge opportunity exists to do this in as automated a way as possible and reduce lengthy streams of communication to explain and resolve unexpected results.
“A Sample Illustration of the Extended RtR Process”
It’s worthwhile to look at a simple illustration to show how RtR breaks down into a complicated process. RtR can be considered a top level enterprise process which consists of many individual processes that chain together. This can vary considerably by industry, organisation design and technology. This illustration is not nearly complete, but shows some sample individual processes which by themselves can also break down further into additional sub processes.
As the illustration shows a large part of RtR is a periodic process. A key part of periodic RtR is a repeatable standard timetable. It could be suggested that RtR is more akin to a project than a typical high volume transactional process. Within the timetable it’s worthwhile to apply critical path analysis. If the critical path is understood resources and management attention can be placed on this, while other activities can be moved around ﬂexibility to help smooth out the peaks of the resource requirements.
“Dealing with Common Pain Points”
RtR improvement can be delivered via new ERP or business intelligence software, however often large parts of the process can be improved without any systems work. Included below are some illustrative common pain points in RtR for the purposes of discussion.
[table id=1 /]
[table id=2 /]
[table id=3 /]
[table id=4 /]
Policy & control
[table id=5 /]
“How to Approach Long Term RtR Optimisation”
Whether dealing with small scale continuous improvement or large scale systems implementation there are a number of things that can be done to improve the chance of making long term sustainable improvements to RtR, most of these deal with organisation structure and culture.
1. Identify and assign a horizontal process lead
Assign an owner to the end to end process. It’s important that this person has authority over the end to end process and can command respect from all participants. Often this role fails as the process lead lacks power outside of their own function. Recommended responsibilities:
- Ensure the process is documented and well understood
- Ensure that appropriate policies are in place
- Maintain issue list, problem list, continuous improvement list
- Approve process, systems and organisation changes
- Escalation contact for policy, process, systems, data issues during process execution.
2. Create a record to report design authority
Organise a group with representation from all functions in scope of the process including IT. This is a senior group that can advocate for improvement work and can sponsor work through resource and budget allocation. Recommended responsibilities:
- Review, validate, sign off any proposed change work
- Prioritise change work based on issues / problems and provide budget / resources.
3. Create a common global issues and problems list.
Regardless of the state of process and systems documentation it’s recommended to start with a log of issues and problems encountered in the current process. This can be developed over time as and when issues are encountered. It’s recommended to use this list to capture a few speciﬁc points:
- Impact of each issue – time, quality etc.
- Root cause – what is the real cause of the problem
- Solution – long term / workaround – can be used to note ideas is solution unknown Once established this list will provide a good basis for discussions around the prioritisation of change work.
4. Embed lean thinking across all teams which participate in the process
Lean is very easy to implement and brings huge potential beneﬁt. Lean can be misunderstood; it’s been seen that some organisations jump straight to technical training on topics like 5S, Waste, Kaizen etc. however the heart of Lean is not about training a project team it’s about embedding the mindset to identifying issues, identify the root cause and feel empowered to propose ﬁxes.
Most of the time people who run a process know what the issues are, however they lack a method to act on their knowledge. Implement Lean from this perspective and encourage the update of issues lists with root cause and proposed solutions. Create a forum to review input from across the organisation and ensure the top opportunities are acted upon.
5. Focus on change management and governance
Often continuous improvement and change programs fail not due to the technical approach, but rather to the governance around requirements identiﬁcation / validation, communication of the change purpose etc. therefore it’s highly recommended not to overlook change management roles and governance roles.
“What About Business Applications”
Business applications and data ﬂow is critical to RtR effectiveness, a lot of RtR effort is spent dealing with problems caused by suboptimal data and systems. A simpliﬁed application architecture for RtR may look something like the below:
1. A global standard ERP system that can handle all business transactions – purchasing, manufacturing, sales, marketing, human resources etc. a. Unfortunately this ideal architecture won’t work for industries that require specialised business applications such as ﬁnancial services
2. Common data – the ERP has one chart of accounts, one common set of hierarchies and common master data
3.. A single data warehouse for all enterprise reporting optimised for the size of the business / volume of data and access / manipulation requirements
4. A limited number of specialised software that provide functionality that the ERP and data warehouse cannot, this would typically include a consolidation engine for multi-nationals and analytical tools that can handle ad hoc reporting, multidimensional analysis, budgeting and planning (scenarios, versions etc.)
5. Software required for formal presentation to internal stakeholders or external parties typically including dashboards, formatted reports, publishing and electronic ﬁle transfer.
- Platform or software as a service (i.e. cloud) isn’t mentioned in the diagram however depending on the size and requirements of the business it could be anything from 0-100%
- Theoretically with new technologies ERP and data warehousing could be done on the same technical platform, however this is not yet common.
Unfortunately this simplified architecture is not realistic for most large businesses. Even in companies that run a global single instance of ERP this tends to be restricted to certain business units. Behind the scenes a number of other systems are often required to meet special business requirements or deal with data or integration problems.
“A More Realistic Application Architecture – Financial Services”
The below diagram provides an illustration of a more realistic application architecture. In fact this is still highly simplified versus the real world, but should hopefully highlight some common challenges.
- Many different business systems used in the front office to deal with client transactions, covering equities, bonds, transaction banking, retail banking, asset management etc. Each of these systems may have different data models and structures
- Separate financial, management and regulatory processes, they work concurrently on similar data and need to be reconciled throughout the process
- Many points of data integration as shown by black arrows, potentially different data technologies handling mapping, conversion, cleanup, reconciliation etc.
- Numerous data warehouses / data stores and various different reporting tools
- Different software applications used for different purposes, this can exist because of:
- Acquisitions of businesses and continued use of their systems
- Development of new processes and systems particularly in the regulatory space each time starting from scratch and adding new technology
- Shadow IT within business functions building product or unit specific technology solutions where the business unit lead has P&L control to run their own IT spend
Fixing the kind of complex architectural problems present in multi-nationals is not easy, partly due to the organisation structure and stakeholders involved, with this in mind the most important step is introducing governance to take control on decision making on application usage:
- Employee an Enterprise Architect – ideally not sitting directly in one business or IT but with leverage over both (perhaps office of COO)
- Ensure that a application repository is maintained so that a current catalog of all approved technologies with licensing details is available – new projects can easily identify existing technologies to be re-used
- Catalog ‘end user applications’ i.e. the use of excel, access and user developed technologies w/out formal IT support so that risk mitigation and replacement plans can be considered – these are generally control risks
- Create a set of architecture principles that lay out the recommended software products and principles to select software products where required, these principles should promote things such as:
- Using one data migration technology where possible
- Optimising use of data warehouses
- Trying to reduce overall number of different instances of software
- Ensuring software is fit for business needs, for the above to work the organisation managing business applications must have business expertise and provide adequate solutions to business requirements.
”The Future of RtR”
There is a lot to talk about in the RtR space, this paper was originally intended to be 3-4 pages long, but completely overshot that while still only touching on some aspects of the process.
One thing worth highlighting is the need to think about the process, systems, data and organisation aspects of RtR – most major consulting firms run their transformation projects with these streams – this does increase the likelihood of delivering effective improvements.
One point not discussed is disruptive processes and technology, for example:
- Moving towards daily / real time RtR close
- Fintech including blockchain as a ledger and it’s impact e.g. as a PtP sub ledger or banking ledger for a particular product
- New database technologies and machine learning e.g. the ability to data mine a mass volume of local reporting (internal / external) to generate analysis to explain business performance
These are worthwhile topics to discuss one by one, however at this point none of them will solve the end to end problem of making RtR effective for most large multi-nationals.
Which RtR problems have you encountered that this paper did not address?
Which future process changes or technologies are you excited about?
Please let me know your feedback.