WIXLIB

3. Listen to the business – not everyanswer can be found in the COAOur point of viewA multi-dimensional COA that provides greaterperformance and analytical insights needs to bebalanced with not overburdening the generalledger (GL). A ‘thick’ GL can extend the closeprocess, with a greater number of segments to posttransactions to, or more reconciliation of variancesduring period end. On the other hand, pullinginformation from outside the ledger can make itinaccurate, inefficient and hard to manage; causesystem performance challenges; and result in highmaintenance costs. Sub-ledgers should be used totrack detailed transactional information, which canfacilitate in-depth analysis and reconciliation.Typically, these key questions need to be asked whenredesigning the COA:1. What is the purpose of the GL? Should it be usedonly for statutory financial reporting?2. How much data will be in the GL?3. Do we develop a single global COA?4. What are the legal requirements for theorganisation based on its countries of operation?5. What are the organisation structure complexitiesthat have to be taken into account in the design?Answering these questions and considering thefollowing points will help you understand how ‘thick’or ‘thin’ the GL needs to be.6Thick ledger: The GL is the central repositoryfor financial, management and, in some cases,operational reporting. Data is detailed in the GL,with several dimensions of information incorporatedinto the COA to facilitate most reporting needs.Thin ledger: The GL holds summary-level financialdata required for statutory reporting only. A reportingand business analytics solution (data mart) providesfocused management and operational reporting.Data marts rely on sub-ledgers to gather detaileddata and additional dimensions of information.Management ledger: This is a ledger that reconcilesback to the financial books and records butcontains data at a more granular level than the GL.It predominantly supports management reportingand some external reporting.It is important to remember that the code blockstructure varies in each organisation, based on driverssuch as the scope of information to be addressedthe application architecture and the underlyingsoftware solution.Once the design questions have been answered,ensure that you involve the financial reporting andthe financial planning and analysis teams to identifythe information that needs to be considered in thefuture state design.

Client storyThe existing COA of a large bank supported itsstatutory reporting requirements but did not meet allmanagement reporting requirements. The bank askedtwo questions of its group and business unit CFOs:‘What are we using the GL for; and what reportingwill the GL enable?’ The CFOs determined that the GLwould be the ‘book of record’ and the bank decidedthat the ledger would enable statutory, regulatory(where it made sense to do so) and high-levelmanagement reporting. With this vision established,the bank took the opportunity to ensure its GLincorporated a recent realignment in its segmentationaccountability from product to customer relationship.This was a major consideration in the design of thecode block and, in particular, the creation ofmulti-dimensional values in its COA segmentstructure, such as lines of business and products.Key takeaways Establish key design guiding principles by asking:– Do we design a thick or a thin general ledger?– Should the GL be used only for statutoryfinancial reporting? In your interviews, don’t just speak to the financialaccounting team. Make sure the financial analysisand planning team is included to achieve thebest outcomes Incorporate a parallel reporting and businessanalytics strategy and solution into the COA designto provide focused management and operationalreporting, and extensively leverage sub-ledgers Remember there is no ‘right’ and use of the codeblock will vary from institution to institutiondepending on various drivers While it is important to include tax resources inthe COA design, every tax decision cannot besolved by the COA (e.g. transaction tax calculationssuch as VAT, GST, Sales and Use). GL accounts arenot required to drive tax decisions. Other dataelements from sales or purchase order documentsare used to drive tax decisions.Unlock the power of your Chart of Accounts June 20127

4. Leverage technologybut put the business firstOur point of viewA COA redesign is often triggered by an enterpriseresource planning (ERP) system upgrade or a newimplementation. Best-of-breed vendors offersophisticated solutions that automate traditionallypainful processes, such as balancing intercompanytransactions. While there may be an attraction todesign the COA in a way that caters for the application,our view is that a system-agnostic approach needs tobe adopted. This is illustrated below.Client storyIn both our global banking case studies, while thevendor and application was known to the projectteam during the design phase, the banks took abusiness-driven process to develop the final design.To best capture the data required to supportdecision making across the organisation, Deloitte hastypically used information and accounting models.Information models identify the organisation’sdimension (slice and dice) needs and accountingmodels identify which dimensions are needed byeach component of the financial statements andkey performance indicators.Application independentIdentify informationrequirementsDevelop dimensiondefinitionsDevelop accountingmodelDefine the systemenabled COAImplement Chartof Accounts‘Who needswhat informationand how?’‘How shouldrelevant informationbe organised?’‘How shouldinformationbe presented?’‘How should datafields be organised?’‘Implement dimensionstructure based oncommon communicatedbusiness needs’ Summariseinformationrequirements ormodels to define aproposed businessdimension codingblock that providesa natural classificationof assets, liabilities,equity, revenue andexpenses. Align accounts toapplication functions Take feedertransactional systemsinto consideration Design andimplement businessprocess controls andapplication securityto facilitateoperational efficiencywhile maintainingcompliance. Addressorganisational,communicationand knowledgerequirements. Review existing Develop a setCOA structuresof information Develop COA visionrequirementsand future state goalsby information Interview key businesscomponentgroups to identify(i.e. revenue,reporting requirements. costs and expenses)and dimension(i.e. legal entity,business segment).8Application dependent

After the information and accounting models arefinalised, a rationalisation filter will be applied based onestablished selection criteria. In our client case studies,once this view was formed, application options weredeveloped to support the desired future state COA.Often, the application is already known beforeredesigning the COA; however, identifying thereporting requirements, and establishing standarddefinitions for them, should happen beforedetermining how the COA will be set up in thesystem. Best-of-breed applications are configurable toinformation requirements and a clear understandingof business needs should precede evaluation ofoptions to define and implement the COA inthe system. This approach will ensure that the initialphases of design are driven by business reportingrequirements, establishment of standard definitionsfor those requirements and modelling how theinformation will be presented. The following exampledemonstrates this type of business approach:Key takeaways Focus on gathering information requirements first Use information and accounting models tounderstand the information requirements Establish criteria to rationalise informationrequirements for a future state COA Consider the application only after the informationrequirements have been finalised.Information modelInformationmodel sinessdimensionsThe models are used to communicate high-level,business-defined requirements and guide themanagement of that information.InformationcomponentsWho:Survey keystakeholders Finance Treasury Capital markets.What:Informationcomponents Revenue Costs & expenses Assets Liabilities & equity Statistical/KPI.How:Business dimensions Legal entity Accounting basis Reports.Accounting model example (COA by dimensions) (B/S, P/L, KPI’s)AccountsBusiness unit Operating unitLegal entityResponsibility centreProcessingBranchSharedservicesProductChart field 1Chart field 2ProductLocationcustomerCustomer segmentDepartmentCostcentreRevenuecentreProfit and loss statementInterest IncomeLoansxxxxxxxSecuritiesxxxxxxxSecurities purchasedunder resale agreementxxxxxxxDeposits with nated debenturesxxxxxxInterest expenseCapital instrument liabilitiesxxxxOtherxxxxProvision for credit lossesxxNet interest incomexxxxxxxxxxxxxUnlock the power of your Chart of Accounts June 20129

5. Keep regulators happy and yourfinance talent engagedOur point of viewWhile this lesson will not resonate for all organisations,for our banking clients, regulatory reporting is amajor task. Finance staff members spend significantamounts of time extracting data from legacy systemsand reconciling it with externally published reports.With increased regulatory pressure and an ongoingneed to respond to regulatory changes and requestsfor information, the GL can ease the reconciliationworkload and the need to manipulate data. To reducethe potential risk of reputation loss or financial costsassociated with inadequate regulatory reporting,finance teams require consistent data sets that servemultiple purposes.Although it is not possible for the COA to enable allthe reporting roll-ups and dimensions required byregulatory bodies, the COA contains opportunities tostore commonly requested regulatory dimensions.Typically, regulatory reports need to be reconciledback to externally published figures. Often,regulatory reporting is subject to significant followup questioning from the regulators and organisationsneed to show how the specific roll-up of informationties back to what has been reported to the market.While some regulatory reporting cannot becompletely sourced from the GL, much of it isdriven by reporting from an income and balancesheet perspective.Exploring opportunities such as leveraging existingCOA segments to house regulatory values can helpstrengthen financial integrity and eliminate the needto gather and manually manipulate data. The clientstory below shows how global banks are focusing onupdating their COAs based on regulatory changes.Client storyAt Client 1 (a global bank) the COA incorporatedcounterparties in its customer segment code block.Counterparties are other national banks, monetaryauthorities or governments that act as the ultimateguarantee for loans and indemnities. Managingcounterparty risk has been a key focus since theglobal financial crisis. The ability to report againstthis dimension sheds insight into the bank’s risk andsupports more accurate filings to regulatory bodies.At Client 3 (a global bank) the use of a location codeblock segment provided insights into residency andnon-residency splits in the organisation’s balancesheet. This was a key requirement demanded by thenational regulatory bodies to which it reports.Key takeaways Don’t ignore regulatory requirements whenconsidering information requirements Focus on regulatory dimensions that are prevalentacross the group’s local environment, as well aslocal regulatory reporting requirements.10

6. Incorporate the needs of your global businessesOur point of viewWith a vision of a common global COA, addressinglocal Generally Accepted Accounting Principles (GAAP)and reporting requirements in various countriesis daunting, especially in environments whereregulations are immature and changing. One of thehallmarks of a localised COA is the proliferation ofnatural accounts and cost centres to track dimensionssuch as residency status and counterparties.Another is the amount of detail in accounts to meetdemands for more information by local statutory andregulatory bodies.In designing a global COA, the organisation mustinterview and gather local requirements beforedetermining what can or cannot be enabled inthe GL. In best-of-breed applications such as SAP,Oracle and PeopleSoft, there are functions to meetglobal and local requirements.Creating second ledgers for individual countries tomeet local GAAP reporting requirements and usingsub-accounts within group legal entities are goodoptions to consider. Sub-accounts or local accountsreserved for local GAAP entries are options for allowingthe organisation to meet country-specific needswithout ‘thickening’ the group COA.Client storyAt Client 2, a six-month study of newly createdvalues suggested that the expanding global footprintand the inability of group accounts to meet localreporting needs were becoming issues. In theredesign process, the bank used local accounts whereGAAP differences were minimal and a secondaryledger where GAAP differences were significant.Furthermore, the inclusion of other optional codeblocks such as residency and the use of a customersegment to track counterparties supported themore stringent statutory reporting requirementsof emerging countries.Key takeaways Gather local reporting requirements Understand the ‘art of the possible’ afterrequirements have been gathered Validate the group set of values with local officesto gauge the gaps that may arise after the initialCOA design has been set.Unlock the power of your Chart of Accounts June 201211

7. Consider the governance modelOur point of viewIt’s important to keep in mind that the COA is a‘living chart’ and will continue to evolve with businessgrowth and external changes. In our experience,a new COA often suffers from poor governance anda lack of clear policies and procedures to maintainits status as a ‘living chart’. This causes commonissues such as multiple uses for single code blocks,proliferation of duplicate values and inconsistent useof those values. To ensure the new COA maintainsits design principles and integrity, it’s critical thatthe project team also designs a governance model,as well as a robust communication and changemanagement plan.To maintain the benefits, integrity and relevance of anew COA, we recommend a periodic review of theCOA and embedding COA maintenance frameworksinto standard business processes. A COA should besupported by a comprehensive governance structure,drawing upon the principles in the COA GovernanceModel outlined below, that includes documentedpolicies, processes, and accountabilities related tothe use and maintenance of the COA.The typical governance areas includes: establishingkey data element standards to ensure integrity ofdefinitions is maintained through the life of the COA;well defined COA maintenance protocols to preventproliferation of GL accounts and other segments;defining and implementing a standard process to helpintegrate changes to the COA structure or processesand keep all COA users and systems up-to-date.During a COA redesign, corporate accounting policiesshould be updated. This is further exemplified in theclient case study below.Client storyClient 3 commenced initiatives to documentdata elements; however, it had limited successimplementing these data standards due to a lackof resources and unclear executive sponsorship.A lack of central ownership over COA segmentsmade it challenging to define new segment valuesand usage in a consistent manner. Consequently,the chart became ‘polluted’ with values that werealready blocked for future use or which could beeasily eliminated or captured in other dimensions orsub-systems (e.g. currencies, intercompanies, loans,inventory, staffing costs, VAT and legal accounts,statutory requirements).COA Governance ModelKey data element standardsPolicy and process standardsCommunication and training Establish a centralised locationthat is easily accessible byall COA users and whichconsolidates all new COApolicies, segment definitionsand documented processes. Develop a robustcommunication plan that keepusers informed of the status ofCOA-related initiatives, changesand updated definitions Select and prioritise processstandardisation andimprovement opportunities Define follow-up actionsfor non-compliance withCOA policies Assign ownership forenforcing consequencesof non-compliance. Promote COA educationacross the organisation Review and approvetraining curriculums Provide oversight toguide training andcommunication initiatives.12

As new requirements were implemented, the chartbecame increasingly inflexible, non-transparentand difficult to use. During the redesign phase,the company took the opportunity to develop acentralised Chart of Account Policy, owned by aGovernance Committee. The Committee evaluatedeach change request and assessed the requestwith Chart of Account best practices and the Chartof Account Policy. This was strictly enforced andchanges centrally overseen by the Committee,ensuring the integrity of the redesigned COAwas maintained.Key takeaways Ensure the COA is not a one-time event,but is reviewed in depth every three to five years,complemented with regular reviews and maintenance Governance is as important as the redesignitself and needs to encompass key dataelement standards, policy and procedures,and communication and training The importance and extensiveness of thegovernance model is influenced by the level ofdetail in the new COA. The more detail the COAincludes, the higher the maintenance cost and risk Implement robust training and communicationprograms to manage the impact of future changes Conduct a review of Corporate Accounting Policymanuals to ensure they are consistent with thenew COA design.Unlock the power of your Chart of Accounts June 201213

8. Involve the business indesigning the COAOur point of viewThe main objective of the COA is to track, in anaccurate and timely manner, every single businessevent that has an accounting impact. However,the COA’s design is not just the finance team’sconcern. To make the COA effective and relevant,a key success factor is ensuring that a broad rangeof stakeholders are involved, both at the corporateand operational levels.Based on our experience, COA redesign projectsoften fail due to a lack of understanding of theimpact on stakeholder needs. By extending theproject team beyond the finance function, differentperspectives can be included, both in definingrequirements and determining any impacts thechange will have on the business.A natural place to initiate design is in the Controllersgroup, as the COA must meet statutory andregulatory requirements. However, limiting the inputto this group may affect the COA’s ability to addressthe organisation’s existing and future informationneeds, or worse, create future issues due to a limitedscope and narrow perspectives. It can be challengingto balance both statutory and management reportingrequirements and operational considerations.To mitigate this, we recommend the project teamis complemented with a cross-organisational teamthat best represents information and operationalrequirements.It is also important to include tax stakeholders aspart of the cross-organisational and functionaldesign team. In a complex global ta

up and rationalise the existing chart. They are also sometimes misconstrued as a mapping exercise that attempts to create a 'single' COA by linking many source systems to a group ledger. While rationalising and deleting duplicate and unused values supports the development of a future state COA, it does not expose all the pain points in the .