Our last blog in this series focused on embarking on the financial transformation process. The content this week will outline the effective financial system process and the steps to take when beginning.
The General Ledger system is, of course, the heart of a firm’s financial system. A properly functioning General Ledger is, however, but one component of an effective financial process. Stepping back and looking at the financial systems environment holistically, one needs to consider the end results – namely the outputs of the process – and work backward towards the inputs.
The desired results of a financial process, simply stated, are sets of management and regulatory reports. From a management standpoint, the balance sheets, income statements, actual-vs-budget reports, etc. should be available at varying levels of granularity, sufficient for department management through Board reporting.
Regulatory reports should be produced “straight-through” without machinations (using Excel, Axiom, QlikView) to decompose, reclassify, and re-aggregate balances. In the perfect scenario, all attributes required to properly classify (map) accounts to a regulatory reporting line (e.g., FOCUS line, MDRM, XBRL line item, call report) will be contained within the accounting key (coding block). This can either be achieved by a chartof- accounts with appropriate granularity, or by the addition of additional data elements associated with each account. Where these attributes are available outside of the ledger (e.g., term of loan, foreign/domestic counterparty), they need not be part of the account coding block.
In order to further the paradigm of straight through processing, the reports should be sourced from a comprehensive financial data warehouse. In this context, balances, report items, and external account attributes not sourced from the ledger (e.g., risk-weighted assets, loan terms, etc.) can be integrated into the warehouse for seamless inclusion for regulatory and management reporting.
The warehouse can also drive an MIS front-end (SAP BusinessObjects, Cognos, PowerBI), affording effective, simple-touse, drill-down and drill-through analysis. The warehouse should include all reporting structures, hierarchies, and reference tables necessary to support the reporting function at all levels of consolidation, cost center, and account aggregation. All data tables in the warehouse should be automatically reconciled back to the ledger, or another source system, whenever a ledger or consolidation posting cycle is run and the warehouse updated.
With a proper chart of accounts and coding block established, it is crucial to ensure all source systems are effectively integrated. Front-office transactional systems often operate with different account nomenclature than utilized by the firm’s financial systems. Trading systems may indicate transactions by desk and blotter, brokerage systems by the typical Wall Street standard of ledger and account, and more. Whichever front-end accounting structure is used, these transactions must be mapped to the appropriate general ledger company, account, and center, along with any other associated attributes required by the accounting key.
The mapping of front-office accounting to ledger code block can be performed by the front-end application itself, an intervening sub-ledger, or a rules engine. Whichever methodology is used, the resulting posting transactions must contain all required attributes (e.g., counterparty, trade ID, loan number) to ensure data integrity is maintained, as necessary to support straight-through processing. It is best to avoid hard-coding mapping rules in program logic, as changes will require programming resources to modify, and testing and a scheduled system update cycle to implement.
It is also best practice to include identification of the source system and the originating accounting information, either in a ledger journal trailer or linked data table, to allow for end-to-end reconciliations, automated re-class entries, audit, and analysis. Source system transaction IDs can be used (thick ledger), or if transactions are summarized before general ledger posting (thin ledger concept), consideration should be given to summarizing entries only down to the level of the source system accounting key.
To learn more about the “hows” and “whys” of initiating a finance transformation program, download our insightful guide. You can fill out the form below, or you can find the guide here.
