Finance Effectiveness – Optimising Record to Report

“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.

“How Do We Define Record To Report”

There are different definitions out there, from a narrow view such as it’s 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 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 fit 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 – filing of full 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 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 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.

“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 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.


[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 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.

4. Embed lean thinking across all teams which participate in the process

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.

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

  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”

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.

Chart of accounts optimisation

A 500 Year Old Idea

To fully appreciate the Chart of Accounts (CoA) it’s worthwhile to step back 500 years to the invention of double entry book keeping.

Double entry is a revolutionary way to record business transactions and track key financial information including:

  • Assets and liabilities
  • Profitability i.e. revenue minus expenses over a given period
  • Cash flow: cash received minus cash spent over a given period.

Double entry involves recording each transaction from two perspectives which are equal and opposite.

An example; in manufacturing a raw material is received from a supplier, this is a business transaction which increases inventory (asset) and increases a supplier balance (liability). Other examples utilise further account categories:

  • Assets, liabilities, equities
  • Revenue, expenses
  • Gains, losses

The sum of the accounts in these categories constitute the CoA. This is a key structure in business with the ability to succinctly describe the day to day operations of an enterprise.

That Created a Monster

What started from seven categories of accounts, has grown over the years in number and complexity to hundreds or in some cases thousands of accounts at medium and large sized enterprises.

  • As trade grew in volume the need to break up business transactions into more and more detailed categories for analysis and reporting grew
  • With the advent and increase in statutory and regulatory reporting a number of mandated categories of reporting appeared
  • With the development of enterprise systems the ability to capture more transactional detail and run higher volume transactional businesses evolved and these systems came to significantly influence how the CoA works.

The level of detail and structure of the CoA is a basis for corporate reporting and decision making, therefore it’s key to ensure the CoA matches the focus of the enterprise. In financial services the structure of the balance sheet is key, in manufacturing the ability to track detailed costs for the purposes of profitability is key. Furthermore accounts together with other objects; e.g. cost centres and profit centres, are used to manage the performance of departments and divisions and can affect the behaviour of management. This all highlights how seriously CoA design and governance should be taken.

A Few Technicalities

Chart of Accounts – Usually refers to a full set of accounts set up for one or more legal entities in an organisation. Accounts included will depend on business activities and the reporting location. Note – some countries have mandated account names and numbers for local reporting.

Group Chart of Accounts – For enterprises that consist of more than one legal entity consolidated reporting is required, this usually requires less detail than individual legal entity reporting and therefore a group chart of accounts is used which may have a many to 1 mapping from legal entity to group chart of accounts. Note – it’s common to see account naming conventions such as XXXXYYYY as the full account name where XXXX is the group level account.

Local Chart of Accounts – In some multi-national enterprises a standardised international chart of accounts is used according to IFRS or their home country GAAP, however local statutory bodies in individual countries may mandate certain accounts or valuation methods. In this case multi-nationals need to be able to produce two sets of financial statements based on standard and local accounts.

GL Code Block – The term general ledger (GL) is more or less synonymous with chart of accounts. When you post a transaction to a general ledger account e.g. say 100 USD to sales, more information than just 100 is recorded, initially the currency ‘USD’ and whether it’s a debit or credit. In addition to this many additional dimensions can be captured, the full list of dimensions captured with a general ledger posting is referred to as the GL code block. Note – while this is a technical name from the applications world, the conceptual design of the dimensions captured on GL postings is key in complex modern businesses.

Factors of Poor CoA Design and Governance

The CoA is has a far reaching impact on the enterprise, the list of design considerations, pain points are often unique to the industry and ‘current state’ of processes, systems and reporting, however it’s useful to look at some common examples:

1. More than one CoA (due to decentralised business model / acquisitions etc.)

  • Lack of standard financial language
  • Need for multiple mappings to group accounts
  • Extra effort required to interpret accounts

2. CoA does not mirror financial and management reporting structure

  • (Significant) manipulation required during preparation of financial and management reports (manual or automated)

3. Lack of detailed policy and guidelines on accounts

  • Transactions entered against inappropriate accounts; statutory reporting misleading or business performance misinterpreted
  • Incorrect valuation methods, approvals, materiality limits etc. applied to certain postings

4. Accounts not governed to meet changing requirements

  • New statutory or regulatory requirements met using workarounds with existing accounts
  • No longer required accounts still used – missed opportunity to streamline transaction capture, close and reporting

5. Different CoA accross different systems

  • No ability to ‘drill down’ from consolidated reports to originating transactions – increased time and reduced transparency to queries

6. CoA not used as ‘main basis’ for management and regulatory reporting as well as statutory

  • As the CoA is primarily finance owned (statutory), management and regulatory reporting needs are given secondary status:
    • Parallel similar structures maintained in management reporting tools
    • Effort to reconcile statutory, management and regulatory numbers
    • Potential confusion between stakeholders on ‘correct final numbers’ versus various estimate, flash etc.

7. Excessive number of accounts – excessive use of ‘nice to have’ – excessive detail

  • Increased difficulties in:
    • identifying right account for posting
    • maintaining controls and policy
    • interpreting account balances

8. Account design based on systems

  • Software houses are not experts in the structure of individual businesses, systems driven structures can be ineffective for reporting and decision making. Start with system agnostic conceptual designs.

9. Effective flow of numbers, but lack of contextual information

  • The process of recording transactions through to preparing financial statements is heavily based on numbers coded with data dimensions, careful consideration needs to be placed on how commentary for business analysis fits with this flow on key transactions.

9. Extent of usage of GL code block

  • There is a trade off between simplicity of the GL for maintenance and number of dimensions populated in the GL code block. For example for any dimension that full accounts are required e.g. legal entity, business segment they have to be in the GL, for other dimensions are they best in the GL or in other reporting.

CoA Good Practice

Discussion of ‘best practice’ are not necessarily useful based on the different requirements across enterprises by industry, size, focus etc.

And with the 80/20 rule in mind it’s often better to focus on eliminating major pain points and pursuing the more obvious elements of ‘good practice’. With that in mind, a few examples of good practice include:

  • The volume of accounts reflect a sensible view of level of detail that needs to be captured in order to meet statutory and regulatory requirements and support the management and regulatory processes
  • The usage and control requirements of each account is clearly defined
  • The majority of transactions are automatically posted to the general ledger based on originating entries in business systems e.g. financial trades, invoices etc.
  • Use of manual accounts are minimised
  • Use of reconciliation accounts are minimised to those truly required
  • The Chart of Accounts and associated GL code block has a systems agnostic basis meaning that any change to the IT landscape does not lead to extra complexity and acquisitions and divestitures can be easily handled
  • A clear strategy should be in place to handle multiple valuation methods e.g. different depreciation rules in different countries. Depending on systems there are various approaches from multiple accounts to multiple ledgers, as this adds complexity the right solution should be carefully identified.
  • A limited number of manual adjustments at period end close. Adjustments logged and reason for adjustment clearly documented. Accounting policy and CoA design constantly reviewed in order to reduce required adjustments.
  • Group and operational CoA closely aligned, similar financial language at all levels.
  • The CoA is designed in accordance with an overall conceptual data / information model which clearly defines how accounts vs. other objects work e.g. profit centres, countries, business areas etc.

Insight in finance – the light bulb moment!

Insight is often talked about in Finance, but not always clearly defined. What does it really mean to provide insight and how does this differ from the core role of preparing financial and management reports and accounts?

Let’s Start By Defining The Basics:

Financial reports & accounts: A balance sheet, profit and loss, cash flow and other KPIs which correctly record and value business activities to accepted accounting standards.

Management reports & reports: Additional breakdown of the financial accounts by other dimensions; e.g. product, sales person etc. and other calculated KPIs.

Do these accounts and reports provide insight about a business on their own?

One of the primary purposes of the financial statements is to give analysts and shareholders information to compare companies on a like for like basis.

An expert can read financial statements and gain an understanding of the business e.g. sales, costs, investments, debt, cash etc. However this is limited to a publicly available view of the current state of a business, it would be a stretch to consider it as insight.

What Do We Consider As Insight?

One definition from the Oxford dictionary is, “An accurate and deep understanding.” This is a little abstract. Let’s further say that:

  • Deep means understanding business patterns; having an intuitive view of how business activities translate into financial numbers.
  • It’s not only financial and management balances and KPIs with explanatory comments. It’s something more – advice which leads directly to increased revenue, margin, asset utilisation etc.

What Kind of Analysis do Finance Do

Insight is driven from analysis, so it makes sense to think about the typical types of analysis finance does; common examples include:

  • Review the account postings; apply business knowledge, identity, investigate and resolve errors
  • Review the account postings & balances vs. prior period and plan – to identify and explain unexpected activities
  • Calculate KPIs – review vs. prior period and plan.
  • Develop scenario plans, what if analysis etc.

This analysis brings finance to a clear mechanical description of current business performance, yet it doesn’t on its own cross the boundary into Insight.

A Light Bulb Moment!

Perhaps the best way to think of insight is that it doesn’t come from one report or KPI, but rather it comes from a skilled individual / team using layers of information:

  • An individual or team – with deep knowledge and experience of the business and a critical thinking mind-set
  • Layers of information – validated account balances exist, with overlays of finance generated info – prior period, plan, KPI, trend analysis etc. And further overlay of non-finance data – market analyst, economist etc.
  • A light bulb moment – a leap or a light bulb moment, the individual or team bring together the business context and the layers of information to say, “Ah! We should do this”.

Examples 1: Inconsistent revenue

A company organises market festivals. They have predictable costs, but their revenue varies widely.

  • Deep knowledge – Finance have deep understanding of the business – they know historical performance and what has affected it.
  • Information – Alternative plan versions, monitoring actual performance against it, overlay of economics, weather, news, sales performance etc.
  • Insight – A late spring may affect produce availability and hence cost.

Example 2: Receivables Recovery

A company delivers business services. The demand from clients is highly variable and in addition clients may pay less than agree based on performance:

  • Deep knowledge – Finance understand the services, and the business teams, they have a solid view of factors which affect receivables historically – difficult clients, poorly performing divisions etc.
  • Information – Close monitoring of services provided, outstanding receivables, overlays of performance vs. plan and risk assessments on clients.
  • Insight – The ability to identify high risk receivables and focus attention.

These are basic examples, perhaps not quite Aha – light bulb! Moments, have you come across any great examples of finance insight?

The role of the finance business partner

One of the more forward looking roles in the finance function is the business partner. It’s something that is often talked about in articles, but less commonly seen in real life.

A good place to start thinking about the business partner is with a clear definition, I think the following is a good summary:

  • Finance working alongside business departments;
  • Providing tools, analysis and insight,
  • To make more informed decisions.

Essentially; by being closer to the business, finance skills can be applied to make better decisions. This shouldn’t be considered as something wooly or indistinct. It’s using proven analysis techniques and expert knowledge to spot opportunities to increase sales, improve margin and reduce costs.

It’s not really a new role, but rather part of management accounting

The business partner appears to be positioned as a new role in some articles. However when you dig into the details e.g. using financial analysis, generating insight, making recomendations, it’s seen that most of the technical capabilities that a business partner needs are simply parts of management accounting.

Why then, is there so much focus on the business partner?

The question then is why do we need to talk about business partnering rather than simply management accounting. I think this is because management accounting has failed to deliver decision support in many organisations. Why might this be the case?

  1. Due to the nature of accounting the 1st priority of work is always compliance with legal, statutory and regulatory requirements. Decision support often falls to the bottom of the ‘to do’ list.
  2. Finance sometimes talk in a different language from business counterparts. The finance focus is initially on standards, accuracy, control, stability etc. This view doesn’t always connect well with the business focus on growth.
  3. The education and career path for a finance professional may be more weighted towards classic control topics vs. networking, influencing etc. which are often required to get a seat at the table when it comes to even giving recommendations.

So the difference between management accounting and business partnering may come down to soft skills

While management accounting should cover information and analysis required for management decision making, the gap is likely the aforementioned wider business skills; the business acumen, influencing, probing etc.

A simple model for finance

I would suggest business partnering as being a subset of the management accounting capability, somewhat similar to how financial controllership is a subset of financial accounting capability.

Business Partnering In Detail

I think there is a sliding scale here. Business partnering can be implemented several ways from light touch; as part of a financial controller’s role, to a full blown separate team. A starting point for discussion is to consider which capabilities are included:

  • Management Accounting – handling complex queries, ad hoc requests, special projects e.g. acquisitions support, insight development, fighting decision bias, measuring decision impact, ensuring management information is relevant and utilised, assembling multiple complex information.
  • Planning – forward looking, understands and applies strategic goals, close to execs, business leaders and revenue generators, ability to understanding scenario models and plans.

Critically, in the case of partnering, these are supplemented with:

  • Business – business acumen, commercial environment / curiosity, internal consulting, professional judgement, business strategy, business history, market / product focussed.
  • Interpersonal – relationships, conversations, asking the right questions, challenging people, observation, resilience,

Is the business partner just an ‘interface’ or do they do accounting and analysis. I think this can also be done in several ways.

The most important thing to remember is they are not separate from financial and management accounting. Whether they are an interface or more, they need to be tightly integrated to the complete delivery model.

How Many Business Partners?

As mentioned the business partner may in some cases be the financial controller, or may be a separate role:

  • The most valuable focus is probably on partnering with the revenue generators in the business – so the product or service lines – depending on the business 1 per line or less.
  • From a group perspective the CFO could be considered as the business partner, there may be a need to have dedicated support for them – much like the group financial controller.
  • For shared cost functions, it may make sense to business partner – especially if operating margin is a key focus.

What Are the Risks?

There is genuine value in the business partnering discussion, however there are some risks to consider before implementing:

  • Is it truly partnering? There is an argument that finance is not truly a partner. Finance is a service provider. It might be better received by some businesses to stick to ‘management accounting’ for provision of insight.
  • Despite the talk there seems to be little concrete evidence of finance as a business partner making a measurable impact to business results.
  • A balanced view is important, if there are any issues in basic financial and management reporting (accuracy, transparency, controls etc.) finance will probably deliver more value for money fixing these than focussing on business partnering.
  • If partnering and controllership is in the same role it may cause some conflicts of interest. My personal take is that most finance teams can benefit more by optimising basic reporting and putting an effective model for ‘decision support’ e.g. ad hoc queries, self-service reporting etc. I do however see value in a program of capability enhancement for all of finance to work with a ‘business partner’ mind-set.

Recommended reading

A couple of excellent papers exist on this topic, one from the ICAEW and one from CGMA: