Intercompany position keeping is a simple activity. One entity lends money to another entity and charges interest on it. Simple, right? ….WRONG.
If your Treasury department is managing unstructured intercompany debt then you will be familiar with much of the following problems when managing the positions:
a) If Treasury lends money to an entity, let’s call it Company A, you need to record that loan transaction from the point of view of Treasury.
b) You need to record that transaction as a borrowing from Company A’s point of view also. These are known as mirror transactions.
c) On other occasions, Company A pays back some of the loan, so you need to record this as a repayment from Treasury’s and A’s points of view. Another set of mirror transactions.
d) Many of these transactions occur throughout every accounting period. So at the end of the accounting period you have to reconcile all these mirror transactions to ensure that all have been recorded accurately and correctly. As part of that, you have to handle disputes that arise.
e) After you have reconciled the positions, you then have to calculate interest and apply it …to both sides and record those interest movements…twice…., as mirror transactions and apply them.
f) Again, not too bad and manageable if you have ten intercompany positions. But what if you have 50, or 100 or even 500 positions? You are doubling up on every transaction and every position and increasing the reconciliation time and managing more disputes. The time involved in this activity is huge.
But that’s not the end of the nightmare. Sometimes after interest is calculated, it may be paid or capitalised. Or worse still, it may be part paid and part capitalised.
And it gets worse. while it may be paid, part paid, capitalised or part capitalised, this may or may not happen on the day or date to which interest is calculated. Meanwhile, while the position is being ascertained and the interest is being calculated, more loan activity is happening, loan funds are being received and paid, thereby compounding the difficulty.
Some Treasury departments counter this problem by putting a freeze on loan activity until the position and the interest is calculated, reconciled and applied. Sounds like a reasonable solution to that particular problem. Not necessarily. Company A, in our example, may need working capital funding during the freeze period and you could be starving them of necessary working capital.
Is that the end of the problem? Not a bit of it. You have to throw into the mix, the following:
a) Some loan movements may not be cash movements and don’t flow through your bank accounts. How do you deal with those non cash intercompany movements?
b) Company A may have close trading relations with Company B and Company C and Company D and others, compounded by the fact that many companies in the group trade with each other and transactions between them may be settled through their respective Intercompany Positions with Treasury as non cash transactions.
c) And just to make that scenario a little more complicated, these transactions between companies are quite often in different currencies and not necessarily in the currency of their Intercompany Position with Treasury
d) To counter this, Treasury may buy or sell foreign currency from Company A, settle one side in cash and the other side through its intercompany position.
e) Company A may have a different interest rate applied to deficit positions than it has applied to surplus positions. That’s right, Treasury may become the borrower if Company A pays back more than it borrowed. Positions reversed.
f) Company A may be charged different interest rates on positions to Company B and other Companies in the group.
Once you have taken care of those additional complications, you are on your way……no, unfortunately not. You may have to take care of ZBAs. If you haven’t automated the collection of these, your first problem is recording them, again in duplicate as described above. Let’s assume you have automated the collection of these transactions. One of the problems you will have is that usually one account per currency collects all of the transactions for all entities and these all have to be isolated and allocated to their correct intercompany accounts. Then repeat all of the above.
Are you there yet with completing your month end process for intercompanies? Almost, but not quite. You have to produce the general ledger postings for Treasury and possibly for all other entities also. Company A may not have the same General Ledger system as Company B or Company C or Treasury. So multiple variations of the GL postings have to be generated, and reconciled.
When all that is completed, then the nightmare is nearly over for the month once you issue all statements to the subsidiaries. If you are lucky, nobody will mention that they forgot a transaction during the period, or worse still they missed a transaction that occurred during a prior period. Then what? You may have to adjust prior periods balances and interest…in duplicate.
Then it starts all over again for the next month and the nightmare begins once more.
If you have a TMS to manage all of the above, at least you have a solution to the nightmare problem. If you are using EXCEL spreadsheets, then the nightmare never ends.
Does any of this sound familiar?
The dream is to have all of the above issues taken care of. The way to do that is:
a) Eliminate mirror transactions. This will reduce your transactions’ recording by half
b) If you eliminate the mirrors, then you eliminate the reconciliation process
c) Automate your ZBA collections
d) Allocate the ZBAs immediately to their respective intercompany accounts as soon as they are recorded, i.e. real time
e) Update your intercompany positions real time
f) Calculate your interest real time
g) Automate your journal postings real time or on demand
Utilising multi-impact data is a solution that enables you to move from the nightmare to the dream scenario, the right software can even reduce your intercompany month end process from days or even weeks …to minutes, saving huge resources for companies.