Articles Finance Transformation Process improvement

Improving the finance record to report process

“A complex, lengthy process, often not well understood”

Starting from business transactions such as the purchase of materials, payment of employees, execution of financial 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 find RtR clearly documented from end to end, few employees can describe the process in detail from start to finish. 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.

Defining RtR

There are different definitions out there, from a narrow view such as; primary financial statements (balance sheet, profit & 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 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 post we will consider all business transactions and reporting with financial impact as part of the extended record to report process.

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 process. Secondly it’s important to retain a business based view on 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 fit with their part of RtR? – how does this relate to the numbers, analysis, commentary etc. that they are working on?

Start from the customer

Useful tools from six sigma include ‘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 – filing of accounts & other disclosures (IFRS / local GAAP)
  • Tax authorities – filing of tax returns
  • Regulatory bodies – disclosure of required industry specific 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 financial 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 simplified 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; specifically 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 define the answer to questions such as:

  • What is the minimum that has to be reported to maintain shareholder and market confidence?
  • On top of the minimum what extra information needs to be reported, what benefit 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 needed at the stage of data model design for business applications. Enterprise resource planning system projects (such as SAP and Oracle), can fail due to poor data model design. I’ve seen multi-million pound ERP projects occurr without any noteworthy discussion on reporting needs. Companies have been known to have to re-implement the same ERP to fix this.

Remember The Core Business

On the flip 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 financial 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.

The end to end 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 flexibility 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.


  • Time wasted during periodic activities – asking questions / discussing the process – a big resource drain and can distract key resources at critical times
    • End to end process flows + detailed procedures + clear accounting policy + known problems / issues lists can help
  • Silo knowledge in sub components of the process – up stream inputs are not well understood and downstream requirements not met
    • Cross training / work rotation can help
  • Excessive waiting time throughout the process, waiting for data, waiting for management review etc.
    • When mapping process make a distinction between time factors of “effort vs. elapsed” – this will highlight waiting time. Review processes should be formalised – time, scope, quality etc.
  • Overproduction – producing reports where not all information is utilised
    • Periodically review all outputs with customers on a line by line basis
    • This is perhaps one of the biggest issues, where requirements are continuously added, but old requirements never reviewed. An effort / benefit consideration should be made when considering reporting requirements.
  • Over-processing – possibility of two many reviews – poorly defined review or control structures
    • Understand exact control and decisions making requirements and ensure implemented appropriately
  • Over-processing – excessive time on minor adjustments both to financial numbers and commentary / messaging that may have negligible impact on customer.


  • Multiple non standard chart of accounts
    • CoA simplification is straightforward and can be run by an individual or small team. After simplification tight and formalised control on new account requests
  • Profit and cost centre hierarchies that do not mirror business structure
    • All key data hierarchies need to be designed by business and application experts and carefully controlled, unfortunately this can be difficult to correct
  • Poor quality data
    • A complex area, start with creating a data governance organisation to look into process, maintenance, applications etc.
  • Over reliance on data integration technology with custom validations and mappings
    • Try to standardise around one set of technology, try to build application architecture longer term to avoid the need for mapping by ensuring data structures are common across systems (e.g. golden source)


  • Localised heterogeneous systems with different business language
    • Expensive to correct, short term try to standardise data standards across systems, long term move towards common shared systems
  • Proliferation of systems to meet different needs w/out consideration on effort to align data and manage the process e.g. business transaction systems to local ERP to group consolidation to group analytics to group publishing with various regulatory engines, tax engines etc.
    • Invest in a true enterprise architecture function which should sit between business and IT to be successful, create clear standards on use of technology and have appropriate governance control on selection and implementation of new technologies
  • Excessive use of spreadsheets to workaround poorly designed / implemented business applications
    • Start by creating an inventory of all ‘end user applications’ assess risk and feasibility to replace by systems with adequate controls and reliability


  • Ability to share work to deal with peak periods
    • People in RtR tend to like to specialise but due to nature of periodic work it leads to imbalances in work load, where possible look at sharing work in busy periods across teams
  • Junior staff dependent on inputs from senior staff
    • In some scenarios junior staff e.g. group accountant depend on info from senior staff e.g. local CFO, ensure that clear escalation and stakeholder management support exists
  • Review cycles – no. of reviews, quality of review inputs, contradictory review points over successive reviews
    • The entire business analysis, commentary, interpretation, review and approval process is poorly supported by most business applications, put focus on designing with process maps, procedures etc.
  • Misaligned priorities of work between groups – local finance, group, reg tax, downstream processes suffer
    • Using end to end process maps create more education on the impact of each functions work on other functions to create a stronger unified view of what success is.

Policy & control

  • Accounting policy not optimised to deliver the defined level of quality within time constraints; Rules around allowed adjustments at which times, Materiality thresholds for adjustments, Number of reviewers, role of reviewer, no. of times reviews carried out, Guidance on handling of repeat accounting issues”
    • The accounting policy should be clearly documented and kept up to date to answer any accounting related questions that repeatedly come up or to address accounting related pain points in the process. This is often under-utilised
  • Clear demarcation of responsibilities for accounts / issues / policy points between finance, tax, regulatory functional groups including also handover responsibilities in process
    • Often RtR experiences wait time while discussions are held on responsibility to resolve issues, there should be clear accountability matrix, this includes ownership per account, ratio, KPI, process step etc. Resolution owner does not necessarily have to be equal to the owner of all actions to resolve

How to approach long term improvement

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.

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.

Create a 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.

Create a global issues & 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 specific 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.

Embed Lean culture

Lean is very easy to implement and brings huge potential benefit. 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 fixes.

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.

Focus on change mgmt. & governance

Often continuous improvement and change programs fail not due to the technical approach, but rather to the governance around requirements identification / 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 flow is critical to RtR effectiveness, a lot of RtR effort is spent dealing with problems caused by suboptimal data and systems. A simplified 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 financial 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 file transfer.

Additional considerations:

  • 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 architecture based on the financial service industry

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.

  1. 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
  2. Separate financial, management and regulatory processes, they work concurrently on similar data and need to be reconciled throughout the process
  3. Many points of data integration as shown by black arrows, potentially different data technologies handling mapping, conversion, cleanup, reconciliation etc.
  4. Numerous data warehouses / data stores and various different reporting tools
  5. 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

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 as frequently 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?

Which future process changes or technologies are you excited about?

(cover graphic by rudityas |

2 replies on “Improving the finance record to report process”

This is such an informative article which provides a true end to end perspective and delves into the key components that need to be considered. Thank you SO much for this. I work primarily in Finance Transformation and find it incredibly detailed and useful.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s