Letting Your Business Process Drive Financial Reporting

March 9th, 2007 |   Send this article to a friend!

Establishing an integrated business process is one thing - tailoring this process so that the financial results make sense to the organization is another. 

There’s no doubt that one of the most difficult aspects of implementing a system is crafting an efficient, integrated process that works with the business, all while making sure this process can produce the financial reporting that is key to the accounting organization and top-management.  Many times we find ourselves in a situation where we find a process that works, but because the system cannot post the detailed financial transactions needed, we’re forced to revisit our design.  Unfortunately this situation can lead us into a routine of:

1.) Making customizations or adjustments to the business process so that…
2.) Detailed financial transactions can be posted to the general ledger so that…
3.) Financial reporting can be driven directly from a central set of books so that…
4.) Finance is happy.

On a past project I was involved with a client who, in order to differentiate the accounting between their internal and external sales, wanted their users to manually classify sales orders based on the criteria of the sale.  For example, if a sale was made internally within the organization for product that was to be used for experimentation, display, or routing, a classification would be entered by the user to label it as an internal order.  If the sale was to a direct client, then the transaction would be classified as an external sale. By classifying their sales, finance would be able to drive their accounting to produce the internal and external reporting needed to support the business.

This requirement isn’t out of the ordinary - and neither is the approach.  Many clients, like this one in particular, go about implementing an approach that relies on the users performing an additional decision step in order to capture or generate the necessary financial information.  There’s no doubt that this process can work, but you’ve just put your financial reporting directly into the hands of your

users.  In this case, placing a decision point at the time of order entry can be very susceptible to errors because of the high volumes of transactions.  As the risk of user error increases, so does the risk of corrupting your financial data.

On another engagement I worked with a client who wanted to be able to reflect revenue recognition directly from the general ledger based on the shipment terms established with their customers.  So for example, if terms were established with the customer that agreed to transfer the ownership of the delivered goods when the shipment arrived at the end location, an additional step in the process would performed by the user to trigger the revenue recognition transactions when the shipment reached its destination.  Likewise, if terms were established to transfer ownership when the goods were made available to the client, meaning that the goods are packaged and ready for pick up by the carrier, then the interface step could possibly be performed well before any shipment activity occurred.

By incorporating this additional step into the process, the client would be able to successfully post the revenue recognition transactions, but like the first case, they are also relying heavily on the users to perform this step.  Timing of when this step is performed is also an issue because of the various possibilities of when product ownership can be transferred, thus, you’re also dependent on this activity being accurate in accordance with the shipping terms. 

As you can see from these examples, generating financial transactions to drive reporting tends to be the common approach.  For the finance organization, success tends to be defined by creating a set of books, or if you will, a central data source, that can provide the quarterly, annual, and on-demand reporting needed to measure the organization’s financial success.  Most organizations are willing to make sacrifices in other business processes or put in hefty customizations to meet this goal.  And while they’re conscious of the amount of overhead added to these processes, they view it as a sacrifice in the ultimate goal of obtaining a detailed set of books.

In consulting there’s a fundamental rule I like to follow:

When possible, do not modify a working business process to meet reporting requirements.

Why mess up a good thing?  Rather than looking first to modify or customize the process to generate detailed financial transactions, look at the transactional data you have at hand. 

Let’s take a step back and look at the first case I mentioned.  The client was looking to add a step in the order entry process to classify the types of sales transactions.  If we went about this process without the classification step and entered two sales orders, the first being an external order, the second being an internal, how could we distinguish these two orders?  If we look at the customer data - the first order would be placed with a client considered to be outside of the organization, the second would be placed with another branch or location of the company.  So essentially, by looking at the customer, we can distinguish between an internal and external sale without classifying the sale. 

This was a simple example, but hopefully you get the idea.  By looking at the transactional data elements, we were able to derive from that the information needed to report on internal/external sales without having to modify the process.  Granted, we are still dependent upon the user to classify the customer as an internal or external entity, but then this leads to the next rule I like to follow:

If additional information needs to be captured, capture it at a point where the least amount of transactional activity occurs.

In this case, the volume of setting up a new customer in the system is far less than the client’s sales order volume, so it’s less prone to human error.  Additionally, since the volumes are low, more controls can be put in place to ensure a label is placed on a customer indicating internal or external without slowing down the business.

Now let’s revisit the revenue recognition case.  In this example, the client was looking to post financial transactions to reflect revenue recognition based on the terms of shipment by adding a user-initiated interface step.  Again, this is a very high-risk approach because your dependent upon the user getting it right every time to reflect accurate revenue recognition.

If we stay in the mind-set of “matching our books to our reporting”, another solution could be to customize this process so that it interfaces to the general ledger automatically based on the captured shipping terms and the status of the corresponding shipment.  This definitely could be a more reliable solution since you’ve removed the human element out of it, but this also violates another rule I like to follow:

If you are generating transactions based on the criteria of other transactions – chances are that you do not need these transactions.

What does this mean?  If you are generating transactional data for reporting that is based on the criteria of already existing information, why create more transactions that in the end will replicate the same information?  I’ve just upset many accountants by saying this, because what I’m saying from a reporting prospective is that there isn’t a need to post detailed financial transactions to your general ledger based on transactional information, but instead the transactional data can be referred to in your financial reports.  By keeping a general, more broader set of books and referring to the transactional data for details, you’ve accomplished your end-goal of generating a detailed financial reporting, all while leaving your process intact. 

From a technology prospective, by tying your transactional data together to formulate your reports, you’ve downsized your reconciliation efforts and minimized the risk of a data mismatch occurring between your financial data and your actual transactions.  Even more good news – you’ve just cut the amount of reoccurring transactions in half, and depending upon your transactional volume, this could mean less hardware to support your infrastructure.

Many technologists would argue that we’ve simply shifted the burden from the process consultants to the technical resources that develop these financial reports.  Rather than having a single set of books to obtain the detailed financial data, the developer will instead have to scan across several information sources in the database.  This is true to an extent, but while you’ve increased your report writing efforts, you’ve eliminated the need to modify or customize the business process to generate additional financial transactions.  Instead of it being a two step approach of customizing your process and writing developing your reports, it now becomes a single step approach that goes directly to report development.

This strategy exemplifies the true benefit of having a relational database: being able to refer to different sources of information, making the relationships, and putting it all together so that it makes sense on paper.  I believe many organizations continue the approach of maintaining separate, yet equivalent sets of information because it’s what we’ve been doing for decades.  Never before had we been given the ability to have one integrated system where the information can be made available to us.  For years many technologists have been dealing with the “quilt” of information systems and making sure that transactions in one system are accurate and accessible to the other.  This mind set continues today despite the capabilities available to us in an integrated, relational database system.  This “old school” approach has got to go!

When all is said and done, designing a process focused on streamlining the business and relying on the reports to derive the financial information from the resulting transactions is the most optimal approach.  By following this methodology you’re guaranteed minimal disruption to the business and the most accurate financial reporting.

As a process consultant, I’ve had exposure to finance, but would not consider myself an expert in accounting.  If you are an expert, I’d greatly appreciate any comments/feedback you may have!

---

Mr. Thompson is a Senior Oracle Applications Consultant with Lexerd Group Consulting. Visit www.LexerdGroup.com to find out more about our firm.

Interested in hosting your own blog? Lexerd Group’s Internet Services division provides specialized blog hosting services that utilizes the Wordpress blogging platform. Visit http://www.lexerdgroup.com/blog-yourself/ for more details.

Entry Filed under: General