Through the early period of the project, my role was mostly one of secondary support. I sometimes joked about being the office of “post decision support”; after a decision was made I could either give a thumbs up or thumbs down, but really was expected to be quiet during the deliberations.
One day, as I viewed the results of the performance test for a component called the accounting rules, I couldn’t take it any longer. On February 1st, 2006 I came across a recent performance test of the accounting rules component. As I reviewed the results, I could tell the component was going to have significant performance problems when higher volume systems were used. I wrote an e-mail to Dave Willis about my observations, and stepped in the middle of a significant area of confrontation on the project. Dave told me later he wasn’t sure he wanted to get my e-mail, but decided he couldn’t ignore it once I sent it.
After a few months of serious debate about which course was the best, I was asked to give a presentation on accounting rules. The meeting was in a small room on a second floor of a rather old building in late June and I was assigned to present late in the afternoon. My slide deck was only 30 slides long, but later I was accused of having a 3,000 page deck. After 45 minutes, John Carr, the IT exec. at the head of the meeting, turned to someone sitting next to him and said “Pull him off the stage.” I had carried the debate for my approach but was subsequently teased that if I were a doctor I would solve people’s health problems by boring them to death.
Having made it this far in the book, I hope no one dies from reading the following summary of a paper I wrote in the midst of the debate.
Accounting Rules Engines and Accounting Rules are any automated facility that generates input data for the accounting systems. It performs many of the functions described in Outputs. They can be programs or the parameters programs use. A program in a product system, like a checking account system, that calculates accrued interest and creates a transaction could be considered an accounting rules engine. Many rules and engines are embedded in operational systems. Accounting environments usually contain processes between the source systems and the general ledger to modify and refine source system accounting transactions, and generate new transactions, e.g., to reflect offsets or reversals.
Transactions, Values and Journal Entries
Interest accrual records, for example, created in different bank operational systems have varying formats because source systems vary. Yet the general ledger classifies similar records from different sources in the same way. Therefore one function of the accounting rules is to change these records into a common or standard format before posting to the general ledger.
Doing so requires using values in the records produced by the operational system. For example, a value of “ABC” may mean “Deposit” in one current account or checking system, but “123” is used in another. Values from both records must be changed into journal entries, to reflect the credit to current account liability before posting to the ledger. Thus, the accounting rules for the first system must associate “ABC” with “credit current account liability” whereas rules must associate “123” with the same meaning for the other. Additionally, one source system may send the offsetting debit as an additional record, whereas the debit for the other might need to be generated.
Technical Transformations
In ages past, finance has been adequately served by writing specifications for IT functions and having IT write the programs. Changes required were specified by the business, and made by IT. However, with more frequent need for changes and greater familiarity with IT systems by finance, systems have become more and more parameterized. Finance can make changes to the systems by changing the parameters or reference data.
Finance could actually take responsibility for all aspects of the system, writing and implementing programming logic. However most finance departments do not desire complete control, including responsibility for very technical functions such as initializing data formats or error handling.
The architecture includes a Technical Transform Layer or TTL which can perform these functions. Effectively, any function that finance does not want to own specifically can be placed in this layer. If finance were comfortable with IT making all changes to all parameters and programs required to create accounting system inputs, the entire Accounting Rules Engine function could be placed in TTL.
Logic and Tables
Accounting Rules Engines (ARE) are programs. Accounting Rules are often expressed as parameters to those programs. They are mostly maintained in one of two ways: Tables or procedural logic.
- Tables are easily thought of as spreadsheets, with rows and columns. They have one or more columns designated as the key. For example, if the “123” were a value in the first column of the table, the second column might contain “credit current account liability”. The reference data described in Define Reference Data could be considered a list of parameters which act as rules. Values in one column – the key – are converted into values selected in the outputs – the answers.
- Procedural logic is very close to program code. This logic might be presented to the user in syntax comparable to that used in Excel for conditional statements such as IF (A31 = “123”, “credit current account liability”). This does not require that all valid values be listed, thus reduces the number of rules that must be maintained.
An accounting rules engine can be constructed completely of logic without the use of any tables, but the opposite is not possible. An ARE cannot be constructed purely of tables. Logic is necessary to string together and access tables. Said another way, someone could write all of the logic needed in an IF statement without using an Excel “Lookup” function, but simply creating a table within a spreadsheet does not highlight the row containing the answer.
Although an accounting rules engine can be constructed completely with logic, tables provide a distinct advantage: transparency. Values in tables can be easily searched, more quickly understood, and are simpler to update than values embedded in logic. As an analogy, the financial statements are also presented as tables, allowing simple search, rather than trying to find total interest expense in a management discussion document. Tables are easier to search and update than is logic. In most systems a combination of logic and tables is used.
Record Types
Source systems for financial services companies normally provide more than one type of record to the accounting environment.
- Transactions. Records that reflect particular business events are called transactions. They are most often turned directly into journal entries, as discussed above.
- Balances. Often systems also present end of day balance records, giving perhaps the end of day position for each customer’s account. These can be used as either “post and reverse” type journal entries for some systems, or to reconcile the platform balances to the source systems.
- Static data or Arrangement. They also can provide account details, describing customer account arrangement type, interest rate, and maturity date. These records are used primarily in reporting processes, to categorize the posted balances. The values on these records must also be standardized across the system, by product at least, to simplify the reporting processes.
All three records are used for financial and regulatory reporting processes.
The accounting rules bridge the source systems to the accounting functions. The functions they perform are tightly coupled with the source systems, but the outputs are standard across the enterprise. They can be expressed as either tables or procedural logic. And they can use information from multiple types of records to properly classify information.
Having expressed these concepts, I watched over the next few months as Dave “Murph” Murphy, Debbie Byrnes, and Jerry Canterbury proved that these thoughts were correct. I was very impressed with the simplicity of the architecture Murph defined to make this all real. What had been months of debate and contention simply washed away as the solution began to take form. It showed me how important it is to have the right idea and a team capable of making that idea reality.
Parent Topic: Part 6. The Platform