Introducing Central Finance
Many global organizations record their financial transactions on not one but several ERP systems and then combine these financial transactions for the purposes of corporate reporting. Some of the financial transactions are typically captured in SAP ERP systems, whereas others aren’t. How- ever, even using SAP ERP systems doesn’t guarantee that corporate reporting is simply a matter of aggregating financial data from multiple systems. Some SAP ERP systems will inevitably have been implemented at different times using different approaches or will have been acquired along with acquired companies.
The consulting approach to deal with this disparity has often been to define a global template at headquarters and gradually roll it out to the various subsidiaries so that all parts of the organization are capturing their financial transactions within a similar framework. This typically means virtually reimplementing financials and can be a costly and time-consuming undertaking.
Another approach that is gaining favor is to set up a Central Finance system that includes the best practices that have evolved over the last several years and the technical innovations that have been made possible recently with the advent of SAP HANA and the strategic redesign of financial applications. This Central Finance system collects the financial data from each of the local systems and combines them into a harmonized form in real time.
The idea that a global organization might want to combine financial data from multiple systems in one central system is hardly new. Consolidation solutions have been gathering financial data from multiple systems, harmonizing this data, and eliminating the intercompany markups to provide a consolidated financial statement for the group as a whole for many years. Many large corporations have implemented one or more data warehouses to bring their data into a structure suitable for financial reporting.
Before we delve into employing the Central Finance model, let’s first review the approaches your organization is already taking and where Central Finance extends or changes this approach.
Consolidation Systems
The purpose of a consolidation system is to provide a consolidated financial statement for all affiliated companies in a group that eliminates intercompany markups. This is a highly regulated process driven by
requirements such as IFRS 10 (Consolidated Financial Statements) and similar regulations.
This method isn’t without its disadvantages. The challenge of the typical consolidation approach is managing timeliness of the data. The parent company must wait for all subsidiaries to prepare their individual financial statements and submit their data before it can then aggregate and eliminate intercompany business to prepare the consolidated financial statements. It is the nature of this process to be looking backwards to the period just closed, and this wait time means that it can be too late to remedy any local issues by the time the information reaches headquarters.
How can this be improved? Instead of taking monthly snapshots from the local systems, the Central Finance approach involves a real-time update with each and every journal entry. Headquarters has the relevant journal entry mere seconds after the transaction happened.
Another challenge of typical consolidation is that the primary purpose of financial data being collected in a consolidation system is to state the financial position of the organization as a whole and not necessarily to understand whether individual plants or market units are working efficiently. To make this sort of decision, financial data needs to be more granular—in other words, to include not just the legal entities in the
group but also the reporting entities that represent the structure of the organization, such as profit centers and cost centers, and those that represent the business output of the organization, such as the products and services it sells, the customers it serves, and the regions where it is active. Therefore, instead of collecting highly aggregated data at month end, the Central Finance approach collects each and every journal entry. The journal entry itself contains all the reporting dimensions available in the local system, including vendors, customers, materials, plants, profit centers, cost centers, projects, and so on. The potential to slice and dice through all the relevant dimensions for running a business is huge and is greatly facilitated by the technological advances provided by SAP HANA.
Of course, aggregating this kind of data brings its own challenges. The typical systems that many corporations use today collect their financial data using multiple charts of accounts, and their master data is far from harmonized. This means a huge transformation exercise must occur as part of the period close to bring the financial data into a structure that can be reported on easily.
In Central Finance implementations, these reporting structures are prepared in that central system. As part of the implementation exercise, you set up your companies, profit centers, cost centers, customer masters,
material masters, and so on. This is your chance to rethink your approach for every reporting entity, whether corporate, legal, or local, and potentially fix structures to take into account lessons learned since your original implementation. It can be your chance to “start afresh” at reasonable cost. You then define business rules that determine the accounts to be updated, the profit center to be derived, and so on as each journal entry is posted. This transformation sounds daunting, but with the correct business rules in place, you will be able to harmonize on the fly to achieve a “golden” chart of accounts, cost center structure, profit center structure, and so on, and reporting will simply be a matter of selecting the correct information and displaying it in the form required.
Although most organizations welcome the idea of the perfect chart of accounts and reporting dimensions, the practical implications of keeping the business rules up-to-date to accommodate whatever entries might
exist in the local systems are complex. As each journal entry arrives, it is subjected to the same checks as if it were the initial journal entry. This means that you can significantly improve the data quality available for
reporting purposes. Any journal entry that fails one of these validation checks is parked in an error list, where corrections can be made manually while the master data and business rules are being worked on in the central system.
Essentially, the Central Finance approach is simple: establish a trigger to recognize the creation of a new journal entry in the local system, transfer to the central system using the system landscape transformation tools, map to the correct reporting dimensions, validate, and post. However, before we dive into the detail of how to establish such a system, let’s look at some of the approaches from the past so that you understand what your organization might already be doing today.
Central Reporting
Data warehouses were widely implemented to provide corporate reporting options from the late 1990s onwards. These were designed specifically to provide reports that aggregated vast amounts of data.
These systems were designed differently from the operational systems, moving the data into multidimensional star schemas to enable drilldown reporting.
This distinction is typically referred to as the difference between an online analytical processing (OLAP) system and an online transactional processing (OLTP) system. This shift in the way data could be handled
revolutionized corporate reporting. In general, data is extracted from the operational system using nightly batch jobs, transformed, and then loaded into the reporting system in a process referred to as the extract,
transform, and load (ETL) process. If you use SAP’s own data warehouse, SAP BW, then the extract process uses business content delivered by SAP to retrieve the relevant financial data from the SAP ERP system and moves it to the staging areas in SAP BW for transformation into the reporting cubes. One of the challenges here is that the data in a data warehouse is just…data. The journal entry that is the heart of the accountant’s thinking is aggregated to give totals, and organizations spend a lot of time checking that the totals that arrive in their data warehouses match the sum of the journal entries in their operational systems and hunting errors when the two don’t match.
Just as we discussed in the context of consolidation, it’s rarely sufficient to simply transfer data to another system and aggregate. A transformation is required. Over time, more and more business logic was implemented to transform and check data during the data loads to the warehouse, with the result that the load times and, along with them, the latency or time lag of the information available in the central reporting system increased.
Of course, today’s SAP BW is a far cry from the SAP BW of the late 1990s. You don’t have to replicate data; instead, you can work with virtual loads, for which in extreme cases the SAP BW is simply a metadata layer that describes the type of data you are analyzing but does not actually hold that data. Nonetheless, with each transformation come concerns about auditability and reconciliation. Organizations want to trust their data and in the case of financial data want to look back to a single document and understand what business transaction (sales invoice, material movement, allocation, and so on) triggered that journal entry. A consulting solution emerged to fill this need: the central journal.
Central Journal
The central journal differs from a data warehouse in that it is document based. Instead of simply looking at data, you’re looking at journal entries. Every journal entry in the local system results in an equivalent journal
entry in the central system. If the sending system is an SAP ERP system, then the two journal entries can be almost identical or business rules can be applied to transform, for example, the accounts or the profit centers in these documents. Nonetheless, there is an inherent connection between the source journal entry and the target journal entry; this means that a business analyst or auditor can be provided with a drilldown that allows him to see the document that initiated the posting in the central system.
The building blocks of this approach are as follows:
» SAP Landscape Transformation (SLT), which provides the technical link
and field mapping between the two systems
» The BAPI BAPI_ACC_DOCUMENT_POST, used to create the new jour-
nal entry in the central journal
» Error Correction and Suspense accounting (ECS), which provides error
handling for documents arriving in the central system
» SAP General Ledger (New G/L) and account-based Profitability Analysis
(CO-PA), which provide the basic accounting structure in the central
journal
The SLT process uses a table trigger approach. It relies on the data trigger in table BKPF (the header for the accounting document) to initiate a transfer of this accounting document to the central system. You can then define business rules within the SLT process to transform the data in the source document, thus allowing you to map from a local chart of accounts to a central chart of accounts.
The posting mechanism in the central journal is the BAPI BAPI_ACC_DOCUMENT_POST, and the transferred document is validated against exactly the same rules as would apply if the document had been posted in
the central system. This means that the account must exist, the account assignment must be correct, and so on, before the document can be posted.
However, substantially different settings can exist in the central journal. For example, it’s common to assign documents to a single controlling area so that management reporting is possible across all documents. Although the accounts and account assignments are typically mapped from the local system, for management reporting it’s worth considering what is derived within the document. Many organizations derive new profit centers that match their ideal profit center reporting structure. It’s also common to set
up a single operating concern with account-based Profitability Analysis and to derive new CO-PA characteristics on the basis of the transferred products and customers.
The central journal approach brings together software components that already existed to achieve the desired result without making any changes to those components. With SAP Simple Finance, SAP offers a deployment option that offers dedicated features designed to support its use as a central reporting system.
Central Finance
Without jumping too far ahead, Central Finance acts as a document-based reporting system.
To understand what this means, consider Figure 1, which shows a document that looks at first sight like any normal journal entry, for document
number 100000817 in company code CF01 and fiscal year 2015. This document records the price differences during the settlement of a production order, as shown in the header of this document via the reference transaction (Ref. Transactn) AUAK and the transaction code (TCode) KO88.
More important for us is the link back to the journal entry in the local system via the new fields Sender Logical System, Sender Document Number, Sender Company Code, and Sender Fiscal Year. These fields did not exist before SAP Simple Finance. You’ll notice that the document number 4400000727 in the sender system is different from the document number in the central system, 100000817, because the document has been reposted rather than replicated or copied. This document link is critical because it ensures auditability; each document in Central Finance is explained by the triggering document in the local system. To find out more about the origin of this journal entry, you can use Environment Document Environment Relationship Browser to display the chain of documents responsible for this journal entry. Again, this automatic drill-
back did not exist before SAP Simple Finance.
In Figure 2, first you see the accounting document from Figure 1 and then the accounting document that was transferred from the local system that you saw referenced in the header. You can see that this accounting document was triggered by a settlement document (12807) when the production order settled its costs and that this settlement document triggered a separate controlling document (7000006417) and special ledger document (1000356660) alongside the accounting document.
What you see in Figure 2 is not just a technical link between two SAP systems but also an illustration of how SAP Simple Finance is simplifying the financial landscape and merging the contents of several documents (in
this case, the accounting document, the controlling document, and the special ledger document) in classic SAP ERP implementations into one journal entry (the accounting document in the central system).
We’ll turn our attention next to how SAP has been simplifying the financial landscape.