Welcome to the fourth edition of ITW – ‘Interesting Things this Week’ ??
In this newsletter, I share content from across the web that I found interesting. It’s loosely focussed on business transformation, and I try to avoid duplication with mainstream media.
This weeks post is around 1,000 words and a 4 minute read.
1) Nissan refocuses on its core business
The Economist wrote an interesting piece on Nissan CEO Uchido Makato’s plans for the brand. The situation Nissan finds itself in is a common trap for large corporations. A long period of growth leads to a drop in standards, a dilution of focus, and poor performance. In the case of Nissan, it seems that poor sales tactics in key markets and mismanagement of the product line were contributing factors. In this situation Uchida-san feels like the right leader, his approach to scale down and re-focus Nissan on a revitalised line of core products is sensible. To me, this was reminiscent of working under AG Lafley’s organisation at P&G back in 2000 when the company faced a similar situation. This is an important scenario to take into account when making strategic plans. Always check that the correct focus is placed on core products. Make sure that in-market sales strategies don’t risk long-term performance, to make short-term sales.
2) McKinsey wrote about centralising business operations
Last week I wrote about cost reduction. One of the biggest opportunities for cost reduction is centralisation. By this, I mean co-locating functions such as finance, human resources, purchasing and legal. Essentially all functions that don’t need to be in the field (e.g. sales) or at a specific facility (e.g. production). Centralisation brings a long list of potential benefits:
Moving to a low-cost location can provide significant labour cost savings;
Moving to a different location can provide a better talent pool;
Co-location reduces the overall number of managers required;
Scale drives more efficient ways of working;
Scale increases skills and knowledge;
It’s easier to implement and manage controls;
It’s easier to manage consistency of service levels;
It’s easier to manage information technology.
Centralisation is closely connected to process and systems improvements. This brings up a key question, whether to improve things before or after centralizing. McKinsey wrote a good article on the merits of shift then fix versus fix then shift. I think they reach the right conclusion; the best approach depends on the situation.
However, the article does miss a few factors; perhaps for brevity. The cited two options can be further expanded to four:
Centralise work w/out any improvement;
Centralise work and then improve it after it’s centralised;
Improve the work first and then centralise;
Both centralise and improve the work at the same time (by a project team).
The first is often overlooked. It is possible to centralise with no or a minimal amount of change and still gain labour cost and management consolidation savings.
Shift, then fix is often not an option due to a lack of capacity and capability to do the fixing. Companies in this situation can take advantage of centralising with an outsourcer on a shift, then fix basis. If a deal is well structured, an outsourcer can do the fixing for the company. The contract can be structured in such a way to incentivise this and deliver savings back to the company. I like this approach as it hands over topics such as robotic process automation or lean process improvement to the outsourcer and lets the company focus on its core business. A good outsourcer should, in theory at least, be an expert in process and systems improvement.
3. Bain wrote about assessing Change Power
Over the last decade, I’ve been both impressed and depressed by change management. Impressed by how a few simple adjustments to strategy or a program can make a massive difference in success rate. Depressed by the number of job postings and professionals that claim to want or be change managers, but have little substance other than being good at communications.
This leads to an important question. What exactly is change management and how do we measure it. Bain has developed a model composed of 9 elements that can be used to measure change.
I would propose these 9 elements are a good starting point, but this can be further customised the individual situation of a company. Considering the 9:
The ability of leadership to set direction is clearly important, I would also add the ability to ‘communicate or deploy’ that direction;
The capacity and choreography under ‘teaming for change’ is often overlooked, during strategic planning companies often create a long wish-list of change, but rarely appropriately consider the resources required to execute;
Development is a noteworthy focus on the skills needed to be able to identify and execute the right change. A solid example is digital, many companies lack the knowledge and risk being misled into the wrong programs by software companies.
Having a model for change management at the strategic and individual program level is something I would recommend as a top priority. I’d suggest using this as a basis for capability development and running regular self-assessments.
4. Analytics teams within Finance
CFO.com wrote about analytics within Finance. As expected their survey shows that most analytics work is done centrally. They also cite a low rate of outsourcing.
The potential benefits of outsourcing are often overlooked for analytics. Outsourcing is still seen as most suitable for low-skill, commodity work. However, outsourcing can also be a way to access large teams of highly skilled people.
Building an internal analytics team will face a number of challenges; building a high degree of expertise in what may be a small team, attracting top talent for some industries. With scale, an outsourcer can overcome many of these challenges and have both variety and depth of expertise in analytics e.g. employing statisticians, mathematicians, functional experts (e.g. finance) as well as experts covering a range of software products and programming languages.
I would consider an 80% outsourced and 20% internal model for analytics, assuming an outsourcer with the right capability can be identified. The 20% internal act as business partners and focus on understanding the business context and questions that analytics should be investigating.
What I’ve been up to this week?
This week I took a break from writing. Last week I finished a fairly long article on the chart of accounts. This article does mention SAP in the title, but the majority of the article is systems agnostic; this should work as a guide to the CoA in any environment.
And finally, something fun…
Have you played Pokemon Go? Have you heard of the mega-popular board game ‘Settlers of Catan’? Well, Niantic; the Pokemon Go developer is currently developing an augmented reality game based on Catan. A/R has been slow to evolve, but the gigantic success of Pokemon Go makes me wonder if Catan will be successful and what else the future will bring.
The chart of account (CoA) is one of the most important structures in business. It reflects all the activities a business is involved in and it provides a foundation for the majority of financial and management reporting. Correct use of the chart of accounts can both simplify operations and improve decision making capability.
Often on accounting projects, there is a gap between accounting expertise and systems expertise, this can result in a poor CoA design. This can easily be overcome by understanding the historical context and modern-day principles that surround the CoA. We can then better understand the implementation options in systems such as SAP ERP or S/4 HANA. This article will look at three topics:
Part I: Accounting: history & modern principles;
Part II: CoA settings in SAP ERP (from R/3 to S/4 HANA);
Part III: Common pain points and improvement initiatives.
Part I: Accounting: history & modern principles
Ancient civilizations had accountants!
To fully appreciate the general ledger concept and the CoA we need to step back over 500 years to the origins of accounting and the first documentation of double-entry bookkeeping.
The exact origin of accounting is not known, but basic practices are evident as far back as 2800 B.C. with the Sumerians. These ancient inhabitants of Mesopotamia (modern-day Iraq) were one of the first major civilizations in the world. One of their biggest cities was Uruk; with a population of between 40,000 and 80,000 people. It’s easy to imagine this as a bustling centre for trade at the time.
The Sumerians developed a wedge-shaped script called “Cuneiform” consisting of several hundred characters that scribes would mark on wet clay and then bake. This is thought to have been used to keep records of business transactions (source). The diagram below shows an early bill of sale written in cuneiform. This record-keeping could be considered an early form of accounting.
A friend of Leonardo da Vinci
Accounting in the above form has been found throughout history, it’s mentioned in the Christian Bible, and the Quran.
The shift from simple record keeping to modern accounting depends on the concept of double-entry bookkeeping. It’s unclear exactly when this was first used in practice. The earliest recorded documentation is found in the following two books:
Della Mercatvra et del Mercante Perfetto (On Trade and the Perfect Merchant) by croatian merchant named Benedetto Cotrugli, written in 1458 (link)
“Summa de Arithmetica, Geometria, Propotioni et Proportionanlit (Summary of arithmetic, geometry, proportions and proportionality) by Fru Luca Pacioli; a close friend of Leonardo da Vinci, first published in Venice in 1494 (link)
The work by Pacioli is quite complete in that it describes a system of accounting that resembles closely the modern-day approach. It’s thought that a lot of what he describes was already in use by merchants and traders at the time.
Double entry what?
The key principle of double-entry bookkeeping is; any business transaction creates two financial changes within a business. To illustrate:
Purchasing a raw material – an increase in the value of raw material, a decrease in the value of cash;
Selling a finished product – an increase in the value of cash, a decrease in the value of the finished product.
The two financial changes have to be equal and opposite for a transaction to balance and be complete. These financial changes are categorised into what we know as accounts. The main categories of accounts that exist in a business are:
Assets – what is owned (e.g. cash, property, finished products);
Liabilities – what is owed to others (e.g. supplier invoices, loans);
Income – sources of cash (e.g. sale of products);
Expenses – costs incurred (e.g. rent);
Capital: amount invested (by owners);
Reserves: profit owners receive (i.e. income – expenses).
In practice, the double entries are posted using debits and credits to the accounts. To understand debits and credits requires an understanding of the accounting equation.
The accounting equation
Consider a business startup. The amount invested by the owner will be equal to the cash assets held i.e. equity = assets. If the business then takes a loan from a bank this will represent an increase in assets (cash from the bank) and liabilities (cash owed to the bank). It can be said that equity = assets – liabilities. This is a key relationship between the account categories discussed earlier.
The accounting equation:
Equity = Assets – Liabilities.
Now if the business starts operations it will start to incur expenses and generate revenue, on a periodic basis we can calculate revenue – expense which will result in a profit or loss. This will change the value of equity i.e. equity = capital + revenue – expense. With this in mind, we can rearrange the accounting equation to:
Expanded accounting equation:
Assets + Expenses = Capital + Income + Liabilities.
Debits and credits
This accounting equation is the key to understanding debits and credits; one of the mysterious topic of accounting. Debits and credits are used to make the double entries discussed earlier.
A debit denotes an increase in the left-hand side of the accounting equation; assets or expenses, or a decrease in the right-hand side of the accounting equation; capital, income or liabilities;
A credit denotes a decrease in the left-hand side of the accounting equation; assets or expenses, or an increase in the right-hand side of the accounting equation; capital, income or liabilities.
To illustrate let’s look a manufacturing example; the purchase of raw materials:
Goods & invoice received: credit the vendor (increase in liability) and debit the raw material inventory (increase in an asset)
Pay the invoice: debit the vendor (decrease in a liability) and credit cash (decrease in an asset).
(those who are experienced with systems will know that in reality there are actually more steps, one of which involves a control account (GR/IR). We will ignore that for now for the sake of simplicity).
It takes time to get used to working with accounts and debits and credits. When working on accounting projects I always recommend drawing out all the accounting entries with t-accounts. With a little practice, it becomes second nature.
A simple illustration of the value of double entry book keeping
Consider a merchant in ancient Mesopotamia selling apples. A basic record-keeping approach to accounting could be a simple recording of each sale. On the other hand, a double-entry bookkeeping approach will allow them to track stock and sales in parallel.
Even in this simple example a number of benefits become apparant:
Stock and cash are updated at the same time. That the net of both entries should be zero provides a mathematical check that the record was correctly made;
A running total on stock and cash can be kept and it’s easier to make decisions on whether to change prices based on e.g. stock levels or cash targets;
Additional accounts could be added to advance credit to buyers and track receivables vs. cash.
From the historical context accounts were a management reporting structure
When working on accounting projects I often see confusion with the terms financial reporting vs. management reporting and internal reporting vs. external reporting. In reality, there isn’t a black and white separation between these things. Accounts are often described as an external or financial reporting structure. Sometimes they are excluded from discussions on management reporting. This is not the case. Accounts were historically developed for management purposes and form the basis of internal management reporting.
The accounting process
In his 500-year-old book Pacioli introduced the concept of the financial statements; balance sheet, income statement and cash flow. To prepare these statements we need to record all business transactions against accounts. Pacioli describes three stages of accounting:
Record transactions in a journal or book of primary entry:
Sometimes called a subsidiary book or sub-ledger;
Records all transactions in chronological order;
Highlights two accounts affected (debit / credit);
Includes notes / narration;
Different journals/books are used for different purposes e.g. cash receipts, cash payments, purchases, sales.
Transfer to a ledger or principal book:
Transactions are posted to separate accounts;
The set of accounts is known as the ledger.
Summary (final accounts):
At certain periods the ledgers are balanced and trial balance is prepared, which is further used for calc. financial position or profit and loss.
It’s quite shocking to think that modern ERP systems such as SAP S/4 HANA still work largely in line with the steps laid out in this 500-year-old book. ERP systems such as SAP tend to have different modules or functional areas which represent the books of primary entry e.g.
A purchasing book;
A sales book;
A fixed asset register.
When these books of primary entry are updated the financials are transferred to the principal book or general ledger. The main advantage of ERP is the integrated design which makes this transfer occur in real-time.
Modern day accounting
Accounting has grown in complexity over the years and many organisations have hundreds or in some cases thousands of accounts, there are plenty of valid reasons for growing no. of accounts, a few examples:
As trade grew in volume the need to break up business transactions into 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 first step in optimising the chart of accounts is being clear about the role of accounts. Accounts are often described as a structure for external reporting, with different structures used for internal reporting. This is a misleading simplification.
I propose that it’s better to think of the CoA as the foundation for all financial information whether that reporting is for external users or internal users, compliance or decision making.
The balance and line items on the accounts can then be further analysed by other dimensions which cover factor such as:
Team or department
Site (e.g. factory, warehouse or headquarters)
Responsible person (e.g. director with profit and loss responsibility)
The key to a good CoA design is being very clear about the purpose of, and usage of accounts vs. other structures and how it fits together to provide a full set of financial and management reporting.
A common mistake on accounting projects is to set up each structure; legal entities, CoA, cost centers, profit centers etc. in a silo-based on basic instructions from software vendors. These structures need to be designed in an integrated way with a view to how they will interact to provide reporting and analysis.
Modern-day accounting is governed by various bodies, the key ones to be aware of are:
US: The financial accounting standards board (FASB) issues financial accounting standards (FAS) which comprise US GAAP;
UK: The financial reporting council (FRC); with its subsidiary the accounting standards board (ASB), sets financial reporting standards (FRS) which comprise UK GAAP (more or less aligned to IFRS now);
International: Originating from a joint effort of Australia, Canada, France, Germany, Mexico, the Netherlands, the UK and the US, an international accounting standards committee (IASC) was formed and issued international accounting standards (IAS). In 2001 the international accounting standards board (IASB) issues international financial reporting standards (IFRS).
Outside of the U.S. it’s generally best to be familiar with IAS / IFRS and supplement that with local GAAP if and when working in a country that is not closely aligned to the international standards.
We need to be aware of the different standards as they will impact a few factors relating to the CoA:
The accounts we have;
The number and name of the accounts (some countries mandate specifics);
The way we post to the accounts; principles of valuation.
For organisations that operate across multiple countries they may need to maintain more than one CoA and produce reports according to more than one standard.
It’s important to note that the accounting standards to not represent an exact set of rules that can be programmed into a system. Accounting works on principles and requires interpretation. This is why we come across terms such as “fair representation”, “comparability”, and “materiality” in accounting.
This means that the exact details of transactions as they are captured are often not appropriate for external reporting. Accountants need to strike a balance of presenting information in a true and fair way, but a way that also benefits the company and it’s shareholders. This means there is always interpretation and consideration and potentially adjustment before reporting.
A useful resource for accounting information in the UK is the Institute of Chartered Accountants for England and Wales (ICAEW). The ICAEW have a reference list of model accounts.
Another useful reference is iasplus.com maintainted by Deloitte.
IAS 1 lists the financial account as taking the form of:
A statement of financial position
A statement of profit and loss or comprehensive income
A statement of changes in equity
A statement of cash flow
Two pictures from IAS 1 follow as illustrations of how they describe the content of the statement of financial positions and comprehensive income:
Multiple chart of accounts
Organisations that operate across multiple legal entities and/or countries will often require more than one chart of accounts, to illustrate these scenarios:
Organisations with more than one legal entity will need to consolidate their financial information at a ‘group’ level. With this in mind, they may have a different chart of accounts at the group level than at the legal entity level.
Organisations that operate across different countries will have multiple legal entities and in addition to the need for legal entity level chart of accounts and a group chart of accounts they may also have to deal with the legal entity CoA being different based on different accounting standards.
Even if an organisation has only one legal entity the accounts required to execute all business transactions at the operational level are more numerous than the accounts required to be shown on the ultimate external statements:
There may be reconciliation accounts or other accounts required by the way systems work
Accounts may be used to breakdown info. for management reporting but not be required for statutory reporting.
The general ledger code block
In accounting systems we ‘post’ transactions to the general ledger. When this happens more than just the amount is captured. The information recorded is sometimes referred to as the GL code block. Basic examples include:
The legal entity;
Whether it’s a debit or credit;
The user who posted it.
In addition to this other information relating to the original transaction may be captured. This can be information that is useful for management reporting. Examples include; department, brand, fixed asset, product etc.
Part II: CoA settings in SAP ERP (from R/3 to S/4 HANA)
I recommend starting by reading my post on the difference between R/3 and S/4 HANA which provides additional context for some of the topics covered in this section.
The chart of accounts is part of the finance general ledger component of SAP. The structure and naming of the modules has changed over recent versions, highlights include:
R/3 started with the FI – finance module which included GL. This is connected to a separate CO – controlling module for additional management reporting. As of ECC 6.0, it was possible to activate NewGL; a simplification and evolution of FI and CO. As the HANA platform was introduced simple finance became available. Finance has then gone through slightly different namings as S/4 HANA has delivered further simplification and enhancements.
Despite different versions and names, elements of FI and CO are still present in the latest release. The latest release should be considered as a simplification and evolution rather than a totally different system.
R/3 and ERP modules
SAP systems are broken down into modules and components. These are separate sets of tables and programs that deal with particular sets of activities. A rough illustration of R/3 and ERP could look like this:
Within FI we have GL as a central component;
All the components in grey can be considered sub-ledgers from a financial perspective. Some; such as materials management are separate modules outside of finance. Others; such as asset accounting, are part of FI. These all post to the general ledger;
The GL is connected to controlling via cost element accounting for additional management reporting capability. Controlling components are shown in green;
A noteworthy component is FI – special ledger; shown in yellow. The special ledger is a separately configurable ledger that can collect data from various application components.
Configuring FI – setting up the CoA and accounts
We configure SAP using the implementation guide (IMG). In this section I will highlight key steps and structures relevant to the CoA. I won’t step through the implementation guide. There are plenty of good books and help guides that walk through the details of the configuration step by step.
A note on the instance and client
We install SAP as an instance, within the instance we can define multiple clients:
All programs and a few configurations are common across an instance;
The majority of configurations can be defined independently in a client.
Everthing from here on will be within one client.
Define key financial structures
1. Chart of accounts: The first step is to create the chart of accounts. This can be created, copied from an SAP template or imported. If copying this will can copy the CoA, all the G/L accounts and other settings.
From a technical perspective starting by copying the SAP template is a good idea as it can simplify configuration. However it’s critical to define an optimal CoA for your own business therefore I recommend extensive review and adjustment of any template.
2. Fiscal year variant: This defines the no. of posting periods in a year, typically 12 regular (1 per month) and 4 special.
3. Posting period variant: This defines which periods are open for posting.
4. Create company codes: A company code usually represents a separate legal entity. A full set of accounting records can be produced at the company code level – balance sheet, income statement, including tax.
It’s important to note that there are challenges and difficulties getting a full set of accounts at a level below company code. This should be a key factor in considering the right structure for your business. This changes slightly in NewGL we will see later.
5. Create account groups: in line with the way financial statements are structured, accounts are categorised by type using account groups. These account groups let us control what type of posting the account can receive and what information is collected. Typically we create account groups for accounts such as assets, liabilities, revenue and expenses etc.
6. GL accounts – accounts can initially be created centrally with basic information. At this level they can’t be posted to.
7. GL accounts are then activated per company code and additional settings are added to control postings within that company code.
When setting up the company code, CoA, account groups and creating accounts there are various configuration points that control the information captured in GL postings and the fields that appear on the transaction screens. This can be seen working through the implementation guide step by step.
Other key factors closely connected to the CoA in FI
Currencies – traditionally in R/3 and ECC it’s possible to track several currencies:
Company code currency;
2 additional currencies e.g. hard currency or group currency.
Within financials there are also two additional reporting dimensions that form part of the company code – CoA – account group – accounts set up, these are:
Business area – originally designed to provide a cross-company code view on the financial statements. Note that it is hard to reconcile business area to company code, this can make use of them difficult. BA can be generated based on things like a plant, sales area, cost centre or fixed assets etc.
Functional areas – the idea is to split the view of accounts by functions, an example is having one GL account for labour and using different functional areas for sales, R&Dm marketing, production etc. This is closely connected to management reporting through controlling.
The link between financials and controlling
As this article is focussed on the CoA I won’t go into the details of management reporting in controlling. However the CoA is used as the link between FI and CO. A very brief explanation:
To re-cap FI uses accounts to capture summarised information on business transactions e.g. amount, business area etc;
CO is a separate module which captures and manages additional data on management structures e.g. cost centers, internal orders, profit centers;
If a transaction has a financial and cost management impact then documents are posted in both FI and CO;
These documents are connected by cost elements. A cost element is created based on identifying a GL account being relevant for profit / loss.
Issues with GL in R/3 and ECC
As can be seen above the basic structure related to the CoA in R/3 is not complicated. Having worked through a number of R/3 and ECC implementations the challenges I have seen with design and set up include:
Account concept not correctly implemented. For example, rather than having one account for labour costs and using cost centres to split labour cost by department, we have one labour account per department;
Inability to handle multiple valuation requirements for regional or global projects;
Limitations with data that could be tracked in the GL especially within. For example in financial services it’s often important to track sub-ledger information such as policy or agreement number;
Limitations with the no. of currencies;
Inability to get a full set of accounts below company code level e.g. in the case of monitoring financials for a manufacturing site.
Enhancements with NewGL and S/4 HANA improve the ability to cater to several of these. However, it’s still key to design and implement the correct concept for accounts.
The ability to meet record and report multiple according to multiple accounting standards is an important topic. In R/3 there were three ways to do this:
Use additional accounts (creating extra accounts)
Use an additional ledger (using special ledger)
Use an additional company code
None of these were ideal, each creating some additional complexity and effort. The second option uses Special Purpose Ledger. FI-SL is a separate application where ledgers can be defined for reporting purposes.
ECC 6.0 – NewGL
As part of ECC 6.0, SAP introduced NewGL. This is a step in the right direction for FI resolving a number of key issues.
Within NewGL company codes, a CoA, account groups and accounts are defined as before, but there are also additional simplifications and enhancements. These include:
Parallel accounting: NewGL allows for the specification of a leading ledger and non-leading ledgers. This makes it possible to handle parallel valuation without having to rely on the accounts approach or special ledger. A leading ledger can be defined according to the group accounting standard (e.g. IFRS) and a non-leading leger can be defined for local standards (e.g. local GAAP) and these ledgers can be used to track the transactions that have to be valued in different ways.
IAS 14 Segmentation: International accounting standard 14 brought with it the requirement to split accounts by business segment or geography. This means that a company code may now need to provide a full set of financial statements at a lower level. NewGL added the new field, “segment” to the GL code block. Segment can be updated based on profit centre.
Document splitting: Also connected to IAS 14 it’s possible to get a full set of accounts at a level below company code by using document splitting. Prior to NewGL a company may have wanted to see a full set of accounts by a dimension such as profit centre. It was possible to have profit centre included in the majority of account postings, but not all e.g. tax account postings don’t include any account assignments. Document splitting essentially forces at the time of posting the account assignment to be included on every account line in a document.
Customer fields: Addition of a number of customer-defined fields to the GL code block.
Note that NewGL also involved simplifications to the underlying FICO tables and the way FI and CO reconcile, which I won’t cover here.
One of the biggest changes S/4 HANA brings is the Fiori front end and a new approach to user experience on desktop/tablet and mobile. It’s now possible to customise a launchpad to the role of the G/L accountants working with the CoA. A range of apps are available. One of the new Fiori apps I noticed in S/4 HANA 1909 that I like is the t-account view on account postings:
T-accounts make it much easier to understand debits and credits at a glance. To browse Fiori apps use the app library.
The universal journal is one of the biggest changes to FICO. Enabled by the HANA platform, SAP have been able to rationalise the table design in SAP.
A new table; ACDOCA, and set of journal transactions allow GL entries to be made as a single source of info, including e.g. cost centers, internal orders, WBS elements, CO-PA characteristics and other info. from other modules.
In NewGL SAP introduced leading and non-leading ledgers to cover requirements for parallel valuation. Extension ledgers are a continuation of advancements in this space. The benefits of extension ledgers being that they only capture entries that are different for the multiple valuations in question. I came across a good blog post from Martin Schmidt on extension ledgers.
8 definable currencies
SAP has increased the no. of currencies that can captured in G/L postings.
Table simplification & compatability views
With the inclusion of the new universal journal; and table ACDOCA, a lot tables have been eliminated. To avoid the need to re-design a lot of historical functionality old programs can access ACDOCA through ‘compatibility views’.
The latest version of S/4 HANA at the time of writing is 1909. A summary of the new features can be found on the product page on SAP help. Both the features and scope and the simplification list can be found there.
There are many other changes that come with S/4 HANA, the above represents only the key highlights from a CoA perspective.
Part III: Common pain points and improvement intiatives
After summarising the concept and SAP design implications for the CoA, I’d like to summarise some of the common pain points, and guidelines on improvement initiatives.
1. Dealing with multiple chart of accounts
There is a valid reason to have alternative accounts to cater to multiple accounting standards (parallel valuation), however organisations often have multiple accounts due to other reasons:
No central governance of finance; individual business units or countries freely configure their own systems;
Central finance governance in place, but implementation in systems is not controlled; leading to variation;
Making acquisitions w/out carrying out full integration.
This can lead to the following pain points:
No standard financial language across the business, no common way to refer to the financial impact of business transactions.
Mapping needs to be maintained for group consolidation;
Interpretation is difficult at the group level as original postings are made to a different account structure.
2. CoA not well aligned to the financial structure
The operational CoA may not be well aligned to the financial statements that need to be prepared at a group level. This can happen in a few ways:
Too many accounts are created to reflect not only financial transaction type but also departments, teams or products;
Accounts are not well named or described and no guidance is available on correct usage.
This can make it difficult to maintain a mapping to the financial statements.
3. Poor quality accounting policy
Transactions entered against inappropriate accounts; leading to statutory reporting being misleading or business performance being 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 but not well aligned to the financial CoA;
The effort to reconcile statutory, management and regulatory numbers is increased;
Potential confusion between stakeholders on ‘correct final numbers’ versus various estimate, flash etc.
7. Too many accounts
Excessive number of accounts; excessive use of ‘nice to have’, excessive detail, creates difficulties in:
Identifying right account for posting;
Maintaining controls and policy;
Interpreting account balances.
8. Account design based on systems
Software companies may provide a sample CoA, however, they are not experts in an individual business. Blindly following the logic of a system from an accounting perspective can provide an inefficient structure for financial and management reporting.
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.
This is the biggest gap I’ve seen with accounting systems. None of them provide a good solution to capturing contextual information at the point of transaction entry and carrying that through to periodic analysis. This is not necessarily a bit issue in industries such as manufacturing where the structures in product cost control make context less important. However in financial services this can be critical.
10. Extent of usage of GL code block
The number of dimensions captured in a G/L posting is an important design decision. Capturing just a few ‘management reporting’ dimensions will reduce the volume of data stored in the system and the complexity of individual postings. Normally a full set of accounts can only be prepared by legal entity/company code. If a full set of accounts is required at a lower level e.g.; plant, segment, profit centre etc., then these details need to be captured in every line item of every G/L posting. If a full set of accounts is not required, sometimes this reporting is better delivered from alternate reporting structures. This is less of a concern today than it was in the past due to the improved performance of business systems such as S/4HANA.
Considerations for good practice
Discussion of ‘best practice’ is 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.
Structure of the CoA & conceptual data models
When it comes to the structure of the Chart of Accounts there are some reasonably well established good practices, which include:
Follow the structure of the financial statements;
Within that follow a natural order of importance to to the business (consider Account Balance);
Set number ranges to follow the structure, avoid alphanumeric, leave gaps for future accounts;
Create a a conceptual data model to layout how other dimensions are used, this is helpful in avoiding the creation of accounts which duplicate the function of other dimensions e.g. accounts for departments vs. transaction types;
Clearly identify and limit the use of special accounts for manual control or reconciliation purposes;
Avoid accounts for system reasons as far as possible, look at other control methods.
A conceptual information model is also extremely useful. This isn’t a formal technical data model, but rather a simple matrix which shows by account/value/KPI which dimension needs to be tracked.
This is a useful way to decide what information needs to be captured within the general ledger vs. what will be captured and recorded via other reports.
A classic example is where a full set of accounts are needed e.g. by IFRS Segment, this has to be captured in the GL, however, a variety of sales-related reporting could be provided directly from the sales systems e.g. sales by salesperson or sales organisation.
This is an excellent tool to align stakeholders and to cross-reference with report requirements from individual reports.
One of the major factors that separate the more effective organisations from the rest is governance; this is particularly true when it comes to managing hierarchies, master data, processes, systems etc. Chart of Accounts may be a complex area, but if well governed, it can be effectively managed. Key governance considerations include:
Move towards one master reference CoA;
Maintain the master CoA in one system;
Assign a centre of excellence owner for the CoA with approval on create / update etc.;
Create a policy for the CoA including principles for account creation and usage;
Formalise workflow for CoA maintenance with appropriate approvals;
Provide training to non-finance users who have ‘posting’ contact with the general ledger e.g. purchasing, sales, payroll to ensure they understand how their data relates to the GL.
In some circles, a highly flexible CoA is recommended, in others a highly controlled CoA. The truth is that each enterprise; in particular with respect to different industries will have different requirements. A balance has to be made in ensuring the CoA is as simple as possible, and transparent, but in addition to this, it provides the required information for statutory, regulatory and management reporting and decision making. Within management reporting, the planning and budgeting process should also be considered.
Project approach to improve the CoA
Continuous improvement and big bang approaches are both valid to improve the CoA. As with many finance transformation projects care should be taken around year-to-date and current vs. previous period reporting:
Changes to the CoA during fiscal year reporting may confuse year to date reporting and may require manual mapping at period-end;
Changing at fiscal year-end will not affect year to date, but will affect the current vs. past period analysis particularly at year-end.
There are different steps to work through, one suggestion is to 1) start with requirements and b) analysis of existing issues. A simple illustration:
There are a number of other systems worth considering which relate to the CoA and accounts, these include:
Integration layers that connect sub-ledgers with G/L (especially in financial services);
However regardless of the systems used the same design conceptual design and governance points needs to be considered.
As I was writing this I was wondering about the experience of other people with the CoA:
What challenges have you faced with the CoA in your organisation?
What features of ERP around CoA do you find most useful?
For the future, technologies such as cloud and AI provide potential to better analyse how we use the CoA and post transactions. However, one area that’s harder to analyse is the gap between “system produced accounts” and “published accounts” where there is a significant amount of interpretation and adjustment. Automatic generation of summary commentary using NLP based on original documents might be an interesting concept for the future.
Whenever discussing cost reduction it’s important to consider corporate social responsibility as a starting point. Ideally, companies can find the right balance between reducing costs and thinking about employee and business partner (e.g. supplier) impacts. Employee layoffs can have a devastating effect on individuals. Business partner changes can put companies out of business. When planning and executing cost reduction these impacts should be considered. In real life, this might mean trying to offer employees other options (reduced hours / different contract terms / new profit-generating roles) or business partners a revised agreement.
2) A model for cost reduction
A good starting point for cost reduction is to consider the type of costs incurred within the business. Accounting provides a consistent way to look at this. Costs are either tied directly to production or not. For example; in a manufacturing environment there are factories with machines, operated by people to produce products. Cost accounting is used to calculate ‘cost of goods sold (COGS)’. This is the cost that can be directly tied to converting the input materials to the finished product. In this case by adding the raw material, labour and utility costs.
In addition to COGS there are operating expenses. They include the entire cost of departments such as accounting, human resources and IT. They also includes the costs of headquaters or sales offices. The majority of operating expenses are sales, general and administrative costs (SG&A). This is sometimes further broken down to sales costs (S&A) e.g. advertising campaigns and general and administrative costs (G&A) e.g. rent and utilities.
In service industries there are no COGS so SG&A is even more important.
This structure will be useful in planning cost reduction initiatives. Each cost area can be considered in turn. Typically SG&A is seen as one of the top priorities of cost reduction as it’s somewhat independent of production and sales volume.
Approach to cost reduction
A basic approach to cost reduction that many organisations follow is to set blanket cost-cutting targets across the entire enterprise. Why? – perhaps because identifying the best place to cut costs requires a lot of analysis, thought and difficult decisions. Setting blanket targets across seems to be an easy way out and hands the responsibility to individual budget owners.
Costs are normally managed as part of annual budgets. This annual budget setting process is complicated. It can take as long as 6 to 9 months to set budgets. Typically the executive set high-level targets on sales, margin and costs. These are then filtered down through management layers to individual budget owners. There is then a back and forth that can continue for several months to agree on the budgets. The targets are often moving during this process.
Budgeting is often based on previous year actuals. If the executive takes last years budgets and asks each team to cut costs by 5%, each budget owner will try to negotiate a lower % cut. This leads to an allocation of investment based on the individual budget owners ability to justify and negotiate. The company might make it’s 5% target, but at the cost of reducing investment in the wrong areas.
A better approach to cost reduction would be to start from strategy and think carefully about the right areas to reduce costs.
During this strategy review the executive can carefully consider the products / services and markets and the different cost categories present across the business. An approach would be to build a matrix by cost category and product / service and answer some questions:
How closely tied is the cost to sales and production;
Has cost been challenged or reviewed in that area previously;
Is that department a key dependency for high volume or highly profitable products / services or customers segments;
How easy is it to make changes to the area in question;
This kind of analysis would be useful for deliberating the right focus areas for cost reduction. These will differ based on industry / market etc. Another useful tool is to apply zero-based budgeting. This will move away from assuming previous year budgets are the right starting point.
A word on benchmarking
Benchmarking is a common tool which helps to reduce costs. Ratios of different cost to revenue factors are often used to get a broad idea of whether a particular part of a company is efficient and shows value for money. The cost of the finance function as a percentage of revenue is an example of this.
But benchmarking can also be used in more granular ways. Two examples:
Checking salary rates against competitors – easier than ever with the advent of online comparison tools;
Internal benchmarking of departments / functions against one another, this can be done with sales offices, manufacturing sites etc. Where the benchmarked areas have slight differences complexity measures can be identified to adjust the benchmarks.
Ten ways to cut costs
Over the years I’ve seen or been involved in several cost-related programs. Here are ten areas where I’ve seen good results.
1. Focus on core products / services
My first employer; Procter & Gamble, is a good story of the importance of focussing on core products and services. Around 2000 P&G were struggling. They had become ‘fat’. Too many new products and services and a large unorganised support function (high SG&A costs). A.G. Lafley joined the company in 2000 and two key strategies helped with the recovery:
Focus on core brands/products;
Build an efficient back office (simplify, standardise, centralise).
This needs to be carefully planned and will result in a high degree of mid and long term benefits.
2. Cancel projects
The success and cost rates of projects is rarely a focal point of strategy. Every company should have a central PMO that monitors the benefits to cost ratio for all programmes. This is a low effort / light touch PMO. Projects can be expensive, the key is to carefully control project budgets and stop or re-direct them quickly.
3. Create a central procurement organisation
For large organisation scale can be leveraged by procuring centrally. This goes for everything from raw materials to pencils. Rather than individual facilities/locations/teams making their own purchases, all purchases can be handled by a central team. This is an opportunity to buy at scale and also build a procurement and negotiation centre of excellence.
4. Centralise operations – finance, IT, HR, legal, marketing etc.
If staff are decentralised across locations there will be an opportunity to improve rent and utilities costs as well as reduce overall management effort by centralising teams. This can be done for all staff not directly tied to production or field sales. Centralisation has a lot of additional benefits for culture, quality and controls. Centralising functions will also have a knock-on effect by simplifying requirements from IT, HR and property services.
Offshoring whether based on a captive or outsourced model can massively reduce labour cost. I’ve seen savings off over 50% on labour, this can be a huge proportion of SG&A, particularly in service industries. This does require detailed planning and very careful execution. However, it’s easy to calculate potential savings. First, calculate a blended fully loaded cost for the functions you are considering e.g. finance staff, and then calculate the equivalent for any target country of interest. The information to calculate this is easily available freely online.
Outsourcing has somewhat of a bad reputation. Based on my experience this is normally due to poor execution. Most of the time the companies squeeze the outsourcing supplier too far on price and hence receive poor service levels. Cost reduction should always be balanced with quality.
6. Review IT licensing
One of the patterns in IT over the last decades has been an ever-increasing number of technology products, services and suppliers. It’s worthwhile to consider rationalisation in this space. Is each application needed? Do we have the right number of licenses? Can terms be renegotiated?
7. Deep dive into sales costs
For companies with field sales there may be opportunities to reduce costs. The key factor is to figure out what costs drive success in sales. Travel, events, conferences etc. should be carefully analysed to understand how much they impact sales. Moving events online, or reducing budget for entertainment can result in significant savings.
8. Deep dive into employee costs
Layoffs are one option to save on employees, but there are also opportunities to reduce labour costs. Is the salary banding simple and efficient? Are the package related costs (benefits) good value? Is there an opportunity to change contract structures? Would employees consider a 4-day week?
Discounting can easily be overlooked on cost reduction initiatives as it happens at the point of sale. Discounts can total up to have a large impact on margin. This is true especially in industries like Pharmaceuticals where complex pricing structures are used.
10. Process improvement
Methods such a Lean culture and tools such as automation (RPA) can be key drivers of effort reduction, however, these do not reduce costs on their own. There must be layoffs or re-assignment of people to revenue-generating roles.
What the experts say
I’ve taken a look at some of the leaders in strategy and management to see what they have recently published on cost reduction.
McKinsey recently wrote this article about cost reduction, noting that it’s a top priority for most corporations and observing that cost targets seem to be fairly unfocused. The following diagram is a useful illustration of how organisations normally set blanket targets:
Bain currently have a webinar that looks at zero-based budgeting and five key themes of cost reduction. They also have an insight article that covers the less widely focussed on fixed product costs together with sustainability. It’s interesting to consider how a move to more sustainable packaging can cut costs. This is a good example of considering cost and CSR together:
Bain also have an article focussing on where to cut costs. They recommend focussing strategically on the right areas of the business. The ‘where to play’ and ‘how to win’ diagrams are useful and are normally an effective way to structure the discussion about the products / services and market segments to focus on and invest in vs. the ones to consider downsizing or as they note below divesting.
One of the first insights posted on Strategy& includes a downloadable PDF where they share a fairly comprehensive plan and approach to tackling cost. At a glance, this includes a starting point of thinking clearly about strategy and the market and then moving onto execution. I like the categorisation of short term, midterm and long term actions.
“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.
There are different definitions out there, from a narrow view such as; 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 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:
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
Special topics such as sustainability, diversity, health and safety etc. which may include some limited financial information
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 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 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 ﬁ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.
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 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.
Embed Lean culture
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.
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 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 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 ﬁ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 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.
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
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?