Introduction to FPEM: Financial Period End Management

Over the last six months I’ve worked with a new vendor in the financial system space, Svayam Infoware, headed by Rakesh Kant. His platform has many of the characteristics I’ve talked about in my vlog, including:

• A Metric Engine
• Universal Ledger, and
• Integrated General and Sub-ledger environment.

The following video gives a sense of the system in action.

Context

Let’s put this system into context.

This is a simple view of the typical General or Enterprise Ledger context in most organizations. The key feature of this diagram is the summarization or aggregation of data from the transaction systems or subledgers before use in the General Ledger.

This was done because in decades past compute costs were so high, and system availability to meet the daily financial cycle meant aggregation had to be used to produce the enterprise view.

The problem this creates is it limits the types of analysis that are possible from the most trusted ledger in the organization with the only enterprise perspective, the General Ledger.

In extreme cases if the enterprise view cannot explain some critical piece of the business, it can be very costly. In a sense, because Lehman Brothers could not explain adequately their exposure to subprime mortgages to their trading partners, they went out of business. Cost of not knowing that answer? $638 billion.

Traditionally we have built all sort of systems which work around the Enterprise or General Ledger to provide some level of answer to these questions. But they typically don’t reconcile adequately, are costly because of the duplication of data, and create confusion among those seeking answers with confidence.

>>> Related Post: The Data Warehouse vs. the Finance System <<<

An alternative, given today’s available computing capacities, would be to eliminate the aggregation of data.

If a more detailed enterprise ledger were possible, it could support a wide variety of answers to our questions. This is a fundamental change in how we think of enterprise business ledgers.

Technology Characteristics

The following are the characteristics of the platform as described by Svayam:

• Cloud Deployable to private, hybrid, or public cloud environments
• Big Data Scale achieved through potential massive parallelization when required
• Digital Fully automated, no manual processes
• Metrics Engine Calculation of myriad of critical business metrics through flexible reporting
• Instrument Ledger Integrated General and Subledger Functionality
• Daily Close Period tracking made simple
• Rule Based Accounting Integration with existing ledgers possible to get started
• Real Time Streaming posting processes supported
• Straight Through Processing End-to-end platform from data ingestion to report delivery
• Event Driven Organization using business events enhances enterprise understanding of data

FPEM is built upon Apache Spark and Drools business rules engines. This means it is highly scalable. It uses the ledger processing techniques pioneered and proven in global use by the IBM Scalable Architecture for Financial Reporting (SAFR).

Architectural Fit

I use the following reference architecture for financial systems to evaluate various platforms.

>>> Related Post: Financial System Overview <<<

The following slides give a sense of the functionality as demonstrated by the system interfaces in FPEM to see how they fit in the reference architecture.

Platform Administration, Reference Data and Process Control

>>> Related Post: Support Functions Architecture <<<

In the Platform Administration, Reference Data and Process Control sections, FPEM provides:

• Platform dashboards
• Control over accounting and platform processing dates
• Chart of account and reference data maintenance facilities
• Hierarchy maintenance facilities
• Security, Roles and Privilege maintenance
• Activity and Process dashboards
• Balance Reconciliation
• Adjustment facilities
• File upload and manual process facilities

This is an extensive set of facilities, often neglected in new platforms. They communicate quite well the ambition and scope of Svayam’s platform.

Interfaces and Accounting Rules Engines

The following are platform aspects of the Interfaces and Accounting Rules Engines areas.

>>> Related Post: Interface Layer Architecture <<<

FPEM is data structure independent. One begins to populate FPEM with data by defining

• Source Fields
• Registered Sources
• Source Events
• Rule Lists, and
• Accounting Rules

Source fields are independent of each source, and can be reused. For example if many of your systems provide a field called org unit to the General Ledger, this field can be defined once.

Source events are the basis for creating transactions and associated reference data (like involved parties, contracts, etc.) on the platform. A source event may turn into a double sided journal entry if one wishes to use FPEM for fully balanced accounting processes. These entries may contain one, or multiple entry lines generated from the individual business events.

For example, in the demo system we constructed in FPEM, I defined the following accounting schematics to reflect the business data I had available to me for demonstration purposes.

We were able to construct all the rules needed to produce all these journal entries from the originating transactions using the FPEM facilities.

Financial Applications

The following are the applicable user interfaces in the Financial Application area of the reference architecture.

>>> Related Posts: Sub-ledger Architecture and The General Ledger <<<

FPEM is a full fledge ledger. Ledgers create balances in order to increase efficiencies in processing, and as such, FPEM allows definition of Ledger Layouts, so users can chose from the transactions/journal entries (if they choose to use double entry accounting) which balances to consistently maintain.

The Business Term area allows customization of FPEM data structures, for your own terms for accounts, products, channels, customer types or other elements of the financial system.

The Journal Process Definition recognizes that not all the required business events are fed from external systems. In true financial systems, some times ledgers generate new business events. These might be what I term Temporal Events, which are the result of the passage of time. Currency Revaluation is an example. Or they may be Analytical Events which are created for analytical purposes, but then often replaced when the analysis is performed the next time. Funds Transfer Pricing or Allocations are examples here.

The journal process definition can generate new business events off of either transactions or balances. For example, interest is calculated from a balance, where as typically inter-unit elimination processes are often triggered by transactions.

This interplay between transactions and balances goes on in all our financial systems, but often requires separate processes for each step: Transactions are applied to balances; then another step generates a new transaction from these balances; then these new transactions have to be posted to other balances; which then generate new transactions.

FPEM can perform these functions in rapid succession, without having to pause between each one, or even separate systems for each function as is sometimes the case.

Reporting and Analytics

>>> Related Post: Report Layer Architecture <<<

In the Reporting and Analytics space, FPEM proves

• Saved Reports
• Pivot Tables
• Report Formatting
• Filtering and Hierarchies
• Drill Down Capabilities
• Download Functionality

This is where the rubber meets the road; being able to use the very rich data environment FPEM makes possible is very powerful.

The ability to calculate any metric of interest is what makes FPEM a “Metric Engine,” as opposed to a “Search Engine.” There should be many more of these kinds of applications in the world. With renewed, vigorous innovation in financial systems, I think there will be.

>>> Related Post: Introduction to Metric Engine <<<

Integrated General and Sub-Ledger: The Universal Ledger

The General Ledger, should by definition, holds the impact of every financial transaction in the organization, at least upon the few elements in its defined chart of account. Typically, though, those transactions are highly aggregated (the problem of the daily financial cycle).

If we were to simply put those few attributes on the subledger business events (in addition to the required subledger attributes), we could begin to have consistency of our data across the enterprise.

This then becomes a Universal Ledger.

A powerful aspect of a Universal Ledger is that it allows cross business function analysis not possible with the siloed subledger architectures of our historical systems. One can analyze relationships between vendors and customers, shipments and manufacture of goods, can receipts and payments. Cross subledger analysis will become critical for greater efficiencies in the future.

As shown in the video demo, FPEM not only produces the enterprise General Ledger view, but also the customer or vendor analytics typically reserved for the subledgers.

>>> Related Post: Why Sub-ledgers Were Created <<<

Implementation Approach

I think the most likely approach to implementing FPEM could be described as “Adjunct Reporting Ledger, to Parallel Ledger, to Book of Record System.”

Using this approach means exploring those critical feeds to the existing General Ledger, in the Accounting Rules Engines. Duplicating these rules in FPEM, but retaining visibility to the customer contract level of detail is the key to enabling the FPEM ledger to produce reconciled, auditable results in aggregate and at the sub-ledger level.

But that detailed work can be done over time. Start with a simple feed from the GL to FPEM, to create a more flexible reporting environment using your existing trusted ledger. Then determine high value source systems and sub-ledgers where additional details would pay back the effort to find the accounting rules.

You can leave these feeds posting to both ledgers simultaneously if you wish. Or eliminate the legacy GL feed and start to move FPEM to a book of record system.

Here is a sample project timeline to get started with the initial set up of FPEM and a proof of value.

A segment of video below talks through many of the aspects of the system I have described here. Listen to the full video to get a sense of why this technology and architectural approach to financial systems is significant.

Conclusion

I was impressed with FPEM. Rakesh and his team have built a system of substantial functionality, great flexibility, and scalable performance.

If you’re interested in learning more, please contact me through the contact page.

This is another episode of Coding with Kip, the technical sub-series of Conversations with Kip, the best financial system vlog there is. Literally learn more–about ledgers and financial systems–at LedgerLearning.com.

Watch the series in order at the Coding with Kip Playlist