Time to Put Your G/L on a Diet?

If the finance IT systems at a good many businesses are broken -- and there's reason to think they are, given the problems organizations have in closing their books in a timely manner -- you can blame companies' failure to grasp how these tools function as a whole, what they're supposed to do, and where their strengths and weaknesses lie.

So argues J. Robbins, Jr., in a white paper from ISA Consulting. Robbins is vice president, advisory services, with the firm. Financial systems have grown by a kind of haphazard accretion dating back to the mainframe era, with successive layers of technology added under pressure of arbitrary timelines and rigid budgetary constraints. "People tend to fall back into taking what they've got and fitting it into a new tool, versus taking a step back and saying 'How do I mobilize this technology to support what I'm trying to do?' " says Robbins.

For example, companies historically have dumped anything they needed to report on into the general ledger and added it to the chart of accounts. As a result, the G/L functioned as both a data warehouse and the financial book of record, a situation that ISA Consulting describes as "the fat G/L." When ERP systems arrived in the 1990s, organizations essentially paved the cow paths by mapping their existing chart of accounts into the new system.

"I recall lots of projects where people tried to implement a budgeting solution that their ERP vendor offered -- though they really didn't have one," says Robbins. "So what they wound up doing was adding complexity into how they set up and configured the ERP system."

History repeated itself when business performance management (BPM) systems came along in the late '90s. Organizations benefited from new analytical capabilities and planning and reporting functionality, but they failed to address the complexity of their existing systems. Most companies simply implemented BPM software on top of their fat G/L. The result: another layer of processing to extract, transform, and load (ETL) the data into the BPM system, or the transfer of complexity into the BPM tool when ETL was not practicable. Some organizations added a data warehouse to process the data before feeding it into the BPM solution.

Companies ended up with sub-optimal financial systems architectures characterized by multiple systems serving the same purpose; a large amount of time spent reconciling data across systems; shadow reporting systems; and a large number of segments and members in the chart of accounts.

The way out of the maze is via a careful review of the organization's financial systems as a whole, according to Robbins. The goal is to configure the various components of the architecture in order to leverage their strengths and minimize their weaknesses.

For example, ERP systems are relatively inflexible, so management reporting -- which changes far more frequently than external reporting requirements -- should be kept out of the ERP as far as possible. "I would focus my ERP primarily on just getting my books closed," says Robbins. "I would want to take to my general ledger only the bare minimum necessary to do my filings -- legal entity and natural account. I'm oversimplifying, because most organizations report by segment, but in essence that's what you need.

"You're driving complexity out of the ERP system; your ledger is becoming thinner. For anything else you're doing, like allocations, you would say 'Do I need that allocation for my external reporting? If I don't, I'm not going to do it in that system.' So you're separating the close from management reporting."

In addition, ISA recommends the following:

• At the transaction layer, data is captured once and data redundancy is kept to a minimum.

• Data warehouses bring together sub-account detail, project/product costing details, and G/L data to support management reporting and analysis.

• Modeling, projecting, and analytical tools enrich that data via various business models.

• End users access reporting and analysis via online tools to support production and ad hoc reporting.

The ISA Consulting white paper is available here.