How ERP Distracts From and Undermines Intercompany Transfer

Executive Summary

• Because ERP offers mediocre functionality, it distracts from better functionality outside of ERP.
• Learn why this leads to so much waste on ERP projects.

Introduction

ERP sets up mediocre functionality at companies and interferes with buying better software that could provide a great deal of value to the business. I will use several examples in this chapter to explain this prevalent feature of ERP software. ERP implementations result in generic functionality being installed. Then, after the ERP system is installed, other applications that provide better functionality are frequently and selectively used to replace ERP. These superior applications must often coexist with portions of the ERP functionality that are still active.

See our references for this article and related articles at this link.

The Problem with ERP and Intercompany Transfer

An intercompany transfer is when a company buys a product from “itself.” While companies make a big deal about being global (and many certainly operate globally), when it comes to financing, a company must be incorporated in every country in which it works, and must report to the tax authorities based upon its activities within a country. Thus, when a product (or service—but as this is planning we concern ourselves with products) is sent/sold between two different companies. Say an automotive component from Toyota Japan to Toyota U.S.—an accounting transaction must be generated to record that the product has been transferred. This transaction, which is dated and has a transfer price, moves the product from Toyota Japan’s “books” to Toyota U.S.’s “books.” If you search for the term “intercompany transfer” in Google or on Amazon, you will find that most publications on the topic of intercompany transfer are on the subject of intercompany transfer pricing.

While accounting transactions are not particularly “relevant” for supply chain movements, they do have to be accounted for so that the supply network design can support the type of activities required on the accounting side. Supply chain planning systems and ERP systems generally have a standard workflow for dealing with intercompany movements, and this will work for simple intercompany transfers. However, as soon as the intercompany transfer becomes even slightly more complicated, ERP systems most often require expensive customization. Furthermore, because of the rigid design of ERP systems, this customization will consume many analytical and development hours.

Intercompany Transfer Alternatives

There are two basic ways of handling intercompany transfers: a billing stock transfer order and a standard stock transfer order. A standard stock transfer order (STO) is used between locations that are part of one company code. With a standard STO, no billing document is necessary because the STO is an internal movement. A billing STO combines the document used for internal company movements with the invoicing aspect of a purchase order. This is shown in the following graphic.

A standard stock transfer, transfers goods between two internal locations without any billing.

A billing STO performs the same movement and then performs the intercompany transfer in the ERP system. This is shown in the graphic below:

Intercompany transfer is covered by standard ERP system functionality. It combines an internal movement with billing, hence the “billing-STO.” Billing STOs work for straightforward intercompany transfers. The billing STO is the most straightforward way of transitioning ownership between two companies within one global company. However, it does not even come close to meeting all of the requirements of an intercompany transfer. For instance, some companies have multiple locations that interact with one another during an intercompany movement; while the billing relationship is between two locations, the goods are moving between different locations. Entities other than the receiving location can be involved in invoicing the sending location.

There can be four or five locations (or possibly more, although I have never seen more than five location interactions). The standard billing STO will not meet the requirement because the billing is not applied to the location that is sending the product. This is a complexity that is missed by those who propose the non-billing STO for every intercompany transfer situation. (I know as I used to be one of those who proposed the non-billing STO for a company that had a more complex need than I first understood.)

Matching Purchase Order/Sales Order for Asymmetrical Intercompany Transfers

To understand this nonstandard approach to intercompany transfer, we will begin by reviewing the standard purchasing goods transfer.

Standard purchasing transfers goods from an external location to an internal location with billing. However, intercompany transfer combines features of both the internal stock transfers and purchasing.

When the interaction between the locations is complex, and there are more than two locations, customization is required. Here the stock transfer goes between locations B and A, but the invoices go between locations A and C.

A custom program is required to take a stock transport requisition (STR), which in this case is created in the external supply chain planning system, and convert it into several documents, such as the Sales Order and Purchase Order pair between locations A and C, and the STO between locations C and B.

Thus, while an STR is created in APO, once it is sent to ERP, that same transaction becomes a purchase order and sales order (which cancel each other out as they are for the same item or items and same quantities. The sales order and purchase order are simply two transactions moving within a company, or should I say two different companies—a company buying and selling to itself but situated in different countries). Let’s review how the two different approaches work.

1. Standard Intercompany Transfer: When product flows from an intercompany location A to location B and the invoice flows from location B to location A, a billing STO is the standard and most direct way of managing the relationship between the locations. The external supply chain planning system is unaware that the STO is billing or not billing. Billing is handled completely in the ERP system as external supply chain planning systems do not deal with money. This approach is relatively easy to configure.
2. Asymmetrical Intercompany Transfer: When more than two locations are involved in the stock transfer relationship, the billing STO is not the way to set up this relationship, as it will place the invoice in the wrong location. In this case, an STR is still created within the external supply chain planning system between the sending and receiving locations. However, once this STR is sent to the ERP system, the STR must be converted to matching purchase orders and sales orders. These items will move between additional locations beyond the two that are involved in the stock transfer. A company engaged in broad-scale international stock movements will sometimes have different intercompany transfer models. Some of these models mean the creation of a paired purchase order and sales order from a stock transport requisition/order created in the external supply chain planning system. Other movements may require no sales order, and in this case, the STO is converted into a purchase order.

Controlling Transfer of Ownership in ICO Movement

In most cases, the transfer of ownership will occur when the product is receipted into the receiving location. Although this is the standard workflow for most ERP systems, it does not meet the requirements of all companies. Some companies want the ownership transfer to occur after the product has left the sending location, but before it arrives at the destination location. I have found this to be true particularly of transfers with very long lead times, such as ocean carriage.

The graphic on the following page shows the standard transfer of ownership versus the custom alternative.

The first alternative is preferable as it is in line with how many external supply chain planning systems and the ERP system operate. However, for different reasons, some companies prefer the second alternative. Because the transfer cannot be performed while the product is in-transit, an intermediate location—which is not an actual physical location but is a virtual location—is sometimes set up to perform the transfer.

The Core Problem of Limited Dimension Transactions

The issue that companies face when attempting to manage complex requirements of this type is that the ERP system is too limited and too inflexible to be adjusted. Instead of prescribing a limited set of functionality, ERP systems could have been designed quite differently.

We use the terminology of STO, non-billing STO, and billing STO. All of this terminology describes transactions that behave differently in a dimension where the transaction impacts the ERP system, as shown in the graphic below:

A transaction is nothing more than a container that initiates a series of related transactions— which change the state of the ERP database in prescribed ways. Rather than prescribing a limited number of ways that a transaction can behave in a particular dimension, one can open up the options, and this can be accomplished with far less complexity and without the confusing terminology. It is unclear why so many ERP systems took such a prescriptive approach when developing the software in the first place. Perhaps they lacked the development sophistication to make flexible systems and wanted to reduce the costs of development. Creating a system of more limited behaviour within the dimensions of a transaction saved development effort and money in the short term, but is ultimately a poor trade-off. The software must be customized per client location, resulting in a great deal of redundant customization (because the same customization, or at least very similar customizations, must be performed in a decentralized fashion at implementing companies). In case the point is elusive, this is exactly what has happened with ERP systems.

An alternate development approach is to decompose the transaction to its behaviour per dimension, provide an initial set of common dimension combinations, and allow the transaction to be easily extended. This can happen by simply copying over a pre-existing transaction variant and making a single change to a dimension behavior (or to multiple dimension behaviors), resulting in a new transaction variant. An example of this is shown below:

The total library of the transactions categories and variants within those categories constitutes the total of the functionality within any ERP system.

Conclusion

What I have described above would be the perfect scenario, but ERP systems were not designed this way. And because of their transactional inflexibility, the tight integration of their modules means that they restrict the ability of companies to fully leverage the functionalities in applications that are connected to ERP systems. Thus a company with an ERP system will receive less value from any other application that they implement (unless the application is extremely simple) than a company that does not have an ERP system. This is one of the major reasons why most ERP systems are either a dead end—or simply a starter kit setting a company for much more expensive and work down the road.