Archive for October, 2007
Subledger Accounting in R12
Posted by Helene Abrams in Basic Accounting, TECHANGES on October 20th, 2007
Oracle Applications Release 12 and Advantages of Subledger Accounting
In R12, each subledger can have its own calendar, chart of accounts, and currency. There are accounting functions and reports across subledgers that are much easier to deal with than what was available with sets of books. R12 has centralized accounting rules and bidirectional drill down to and from GL from the different modules. The whole structure has changed – you now can define event types, event classes, and account derivation rules that will create the transaction lines.
R12’s subledger accounting gives you:
- The flexibility to utilize user-defined accounting rules to administer multiple accounting policies for internal control and compliance.
- A common data model and repository that allows for a single source of truth for subsystem accounting.
- A centralized data model for accurate and streamlined accounting, reconciliation, and reporting.
- A common posting engine for a simpler closing process.
- Full-drilldown to clear, auditable entries.
R12’s accommodation of multiple ledgers in a single set of books enables smart decision-making by continuously and quickly providing key financial information crucial to important business decisions. The structure of the new sub-ledger accounting also allows for smoother processing and GL management as well as secure but widely accessible data. For example, a single subledger transaction can create multiple accounting representations in multiple currencies in the same set of books.
For a full list of documentation resources for Oracle Applications Release 12, see Oracle Applications Documentation Resources, Release 12, OracleMetaLink Document 394692.1.
Basic Accounting for IT – Part II
Posted by Chris Busbee in Basic Accounting, TECHANGES on October 20th, 2007
Basics of Accounting: Closing the Books
This is the second in a series of articles designed to help the more technical people understand the business. They are intended as general reference material. A copy of the first article, Basics of Accounting: General Ledger and Account Types, can be found here.
Closing the books is the process that a corporation uses to reconcile, consolidate, and report financial information on a periodic basis. The process usually involves the transfer of account balances from nominal (or temporary) accounts to real (or permanent) accounts and generally involves five steps:
- Closing each of the subledger modules (such as accounts payable or accounts receivable) and posting the detailed transaction information from each module to the general ledger (for more information on the general ledger, please see Basics of Accounting: General Ledger and Account Types).
- Running trial balance reports to confirm that transactions from all modules have been posted correctly.
- Reconciling to the general ledger and making adjusting entries.
- Posting all adjusting entries to the general ledger.
- Running standard financial reports.
As we noted in Basics of Accounting: General Ledger and Account Types, transactions create either a debit or a credit entry to an account depending on the type of transaction made. Furthermore, debits and credits are treated differently depending on the type of account the transaction is posted to. The following table outlines some common accounts found on financial statements and how they are treated.
ERP Systems: The Next Legacy Dinosaur?
Posted by Helene Abrams in Return on Investment Analysis, TECHANGES on October 20th, 2007
As businesses grow and become more complex, the information systems that support them require continuous updates to keep up with the changes. Moving to an ERP (Enterprise Resource Planning) system doesn’t reduce the need to change. The implementation of the ERP system reflects a static point in time, and supports the business processes and data requirements at the time of implementation. Supporting these “dated” business practices costs money, and more importantly doesn’t allow a company the agility to change as the business environment changes. The difficulty of changing the myriad of complex systems, and the interrelationship among the many enterprise systems, leads many companies to just leave things as they are, quickly giving the current ERP system the characteristics of a legacy system. When do ERP systems become legacy systems?
Legacy systems are often thought of as green-screened hardware comprised of applications that required hard-coding and continuous additions to that code to provide new features, lack of documentation for the changes, and unenforced data integrity. For example, database field formats may differ in many of the different applications or modules. Consider that a large part of the Y2K crisis was a result of format inconsistencies in the “date” field of legacy applications across the globe. Billions of dollars were spent making this single modification, and thousands of similar issues exist across the many systems of today’s enterprises. Forrester Research reports that “76 percent of IT budgets [are] earmarked to maintain existing applications.”1
Both the complexity and lack of quality of these systems force an abundance of ongoing maintenance and make it difficult for them to support agile business changes. Even within a single system, there may be over 2 million columns, each of which could be related to any other creating a cascading maintenance effort that results from making a single change to a specific part of the system. Making one change requires making changes everywhere in the system due to the multiple relationships, potentially resulting in millions of changes that must be made if a company, for example, changes its business from a product business to a service business. This complexity is exacerbated many times over when companies have not just one ERP system, but many integrated systems with inconsistent data. A change in one system impacts many different systems, often in unpredictable, undocumented ways.
“The Hackett Group estimates that the average $1 billion company maintains 48 financial programs, along with nearly three ERP systems,” according to CFO magazine. “So it’s little wonder,” says Randy Whitchurch, CFO at bar-code maker Zebra Technologies, that “if you’ve got a lot of far-flung locations on disparate accounting systems, [documenting controls is] a problem.”2
It can easily take hundreds of people to extract and refine data from multiple sources, or coax the information from multiple modules within the ERP system and reconcile them to the current business processes. Employees build elaborate spreadsheets, reports, and data warehouses that need to be maintained, compounding the initial reporting expense over time.
Expensive, time-consuming changes make an organization rigid and not agile enough to accommodate the ongoing nature of change.
The problem is, once an ERP system has been implemented, changes to the system are necessary if the data is to correctly represent the business and its processes. There is no way around it. So, when do ERP systems become legacy systems? I think the clear answer is the moment after implementation.
1 Murphy, Phil. “APM Tools Will Reach $500 Million to $700 Million By 2008.” Forrester Research. July 22, 2005.
2 Goff, John. “Sarboxing.” CFO Magazine. February 1, 2004.