Thanks for your post. I’m glad you can relate!

I’m in agreement with you in that most ERP systems today, such as Oracle and SAP, lack some of the fundamental financial requirements. Some of these basic functionality gaps also exist in other aspects of the operation such as sales, shipping, manufacturing, etc. The problem is that the ERP system architects built a system in accordance with a generic model that doesn’t represent a majority of the businesses today. This is why 99% of all ERP implementations often require some level of customizing to meet the client or industry specific requirements.

On the flip side, I think it would be extremely difficult to build such a system flexible enough to meet the requirements of all types of business models. If there comes a day when such a system shows its face we probably won’t be around to see it! The concept of an integrated ERP system is still a relatively new concept that has plenty of room for improvement. This leads us to the various gaps that often require a creative solution to close. I guess this is what keeps guys like me employed!

When I wrote this article I probably had just come out of a frustrating meeting with the finance group. I do not mean to say that accounting requirements are ‘dispensable’ as they are just as important (sometimes more) than the rest of the operation. What I wanted to bring emphasis to in this article were the difficulties in finding a “happy medium” between building an efficient business process that meets operational requirements and generating all the accounting data necessary to meet finance requirements.

As I mentioned, most clients tend to go down the path of customizing the system to interface detailed transactions to the general ledger. Then from a reporting prospective, these ledger transactions can be referenced to produce the necessary reports. This approach that can work, but I wanted to take a step back and look at this problem in such a way that we can eliminate potentially hefty customizations and rely strictly on a reporting solution.

When building any customization, there is usually a trigger point which we want this custom action to occur. For example, let’s say we were building a revenue recognition customization where one of the situations we want to generate detailed general ledger transactions was during the shipment process. If terms are established with the customer where the transfer of ownership occurs once the delivery leaves the facility, we want to recognize the revenue for this shipment at the point where the shipment transaction has been confirmed in the system.

If we were to build a customization to generate revenue transactions in the general ledger, we would first have to identify the logic that can identify the situation where ownership is transferred at shipment so that we know when to trigger the GL transactions. Once we identify this logic, we can build the mechanism to generate the postings, then continue with our reporting solution.

In this process we’ve identified the logic behind the event we want to trigger detailed postings, however, couldn’t this same logic be used in the reporting solution itself? We could even build what’s called a “view” at the database level that incorporates this logic and reports on all shipment transactions that contains these terms.

I argue this for many reasons…

1.) Regardless of whether the customization or report approach is taken, the logic to identify the transactional situation that should “trigger” the financial post needs to be identified.
2.) Triggering these detailed postings creates two sets of data; the first being the transactional data, the second being the financial data. This opens you up to the data potentially being inconsistent and having to be reconciled. Why not eliminate this?
3.) As I mentioned earlier, depending on volume, the number of transactions that are generated could potentially get messy and have negative implications on system performance.

I’ll admit that this approach may not be viable in all situations. Perhaps there is a legal or SARBOX requirement that requires detailed transactions to the GL be posted. But for situations such as the example I used above, I believe it has some good potential. What you’ve accomplished is a report that meets the criteria established by accounting by referring directly to the transactional data utilizing the logic that would have been used to generate the detailed postings. Essentially, you’ve obtained your report without the customization.

To me, one of the primary sources of return on investment in ERP systems is the elimination of manual processes. As you point out, manual processes with high volumes of transactions inevitably lead to increased error rates.

You state that ‘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.” So we are told we must redesign our process to fit the software, leading to the addition of manual processes that lead to high error rates. This is the key to why many ERP implementations have failed. The fundamental software design of the major ERP systems have not taken into account the basic realities of how businesses operate. The ERP vendors won’t refactor their product, and tell us that customization is difficult. That is a flaw in the software product, not in the customer’s processes. So the customer has to add manual processes to make sure that they can extract the information they need from the system.

As far as upsetting accountants, what you’ve missed is that the basic structure of accounting requires what you propose obliterating entirely: detail postings to ledgers. The problem with ERP implementations is not an excess of transactions in the database due to dispensable accounting requirements; rather it is due to the failure of the ERP system architects to take into account the basic requirements of business organizations. In SAP’s case, I attribute that to differences between German organizational structures and business laws and American ones.

With respect to your example of the order entry system, there should be separate tables in the underlying database to hold data related to the purchasing function and the accounting function. Even though the dollar amounts may be the same, the way that users in the two functional areas use the information incorporated in an order entry is radically different. The complete sets of information captured in the two different tables are not equivalent; therefore your proposition that the accounting set can be eliminated is faulty.