Intercompany netting at Inmarsat
At Inmarsat, intercompany netting is gross amount based and settled via their SAP In-House bank solution, however, the current setup made intercompany reconciliation difficult and intercompany funding needs less transparent. We offered a solution.
Inmarsat had one FTE spending 3-4 hours every month, including during the month-end close, manually allocating an excessive number of payments against open invoices on the customer ledger. This was time that should have been spent on value-add activities that could have resulted in closing the books earlier. How did this come about?
In the current setup, credit/debit balances are building up on multiple intercompany payables/receivables accounts with the same entity, reflecting various business transactions (intercompany invoicing, cash concentration, POBO payments, intercompany settlement). This situation makes intercompany reconciliation more difficult and intercompany funding needs, less transparent.
Searching the solution
As part of the Zanders Treasury Technology Support contract, Inmarsat asked Zanders to define and implement a solution, which would reduce the build-up of multiple intercompany receivables/payables from cash concentration, and instead, reflect these movements in the in-house bank accounts of the respective entity.
During the initial set-up of in-house cash (IHC), it was our understanding that all intercompany netting inflows should auto-match with open invoices, if both the Vendor and customer invoices carried the same reference. “Netting” in Inmarsat terms means a settlement of intercompany customer/vendor invoices through IHC.
Unfortunately, a very small percentage of IHC intercompany inflows auto-matched with open customer invoices (14% achieved in May 2020). Sample cases reviewed show that the automatic matching was happening where references on both vendor and customer invoices are same. However, for most cases, even where references were the same, no auto-matching happened.
The IHC Inter-Co Netting issue
In phase 1, the intercompany netting issues were addressed. Intercompany netting is an arrangement among subsidiaries in a corporate group where each subsidiary makes payments to, or receives payment from, a clearing house (Netting Centre) for net obligations due from other subsidiaries in the group. This procedure is used to reduce credit/settlement risk. Also known as multilateral netting, netting and multilateral settlement.
Figure 1: Netting circle
SAP standard system logic/process:
FINSTA Bank statements are internal bank statements for internal Inhouse Cash Accounts and these statements post to the GL and subledger of the participating company codes, so that the inhouse cash transactions are reflected in the Balance Sheet.
Any Intercompany transactions posted through the FINSTA bank statements, should be able to correctly identify the open items on the Accounts Receivable (AR) side to post and clear the correct line items.
Root Cause Analysis:
We found that a payment advice segment present in FINSTA was overriding the clearing information found as per interpretation algorithm ‘021’. As such this was forcing the system to rely on the information in the payment advice notes to find a clearing criterion.
The documents should be cleared based on the information passed to the payment notes table FEBRE.
As a solution, we set the variable DELETE_ADVICE with an ‘X’ value in user exit EXIT_SAPLIEDP_203, so that SAP relied on the interpretation algorithm via a search on the FEBRE table and not the payment advice, for identifying the documents uniquely, and then clearing them. Information from the FEBRE table that includes the document reference, feeds into the interpretation algorithm to uniquely identify the AR open item to clear. This information is passed on to table FEBCL that has the criteria to be used for clearing.
With the above change maintained, SAP will always use the interpretation algorithm maintained in the posting rule for deriving the open items.
Prior to the fix, the highest percentage auto-match for 2020 was 16%. Post fix, we increased the automatch to 85%.
Table 1: interpretation algorithm
Christopher Killick, ERP Functional Consultant at Inmarsat, expressed his gratitude for the solution offered by our Treasury Technology Support services in a testimonial:
“In the autumn of 2019, Inmarsat was preparing for takeover by private equity. At the same time, our specialized treasury resources were stretched. Fortunately, Zanders stepped in to ensure that the myriad of complex changes required were in place on time.
- Make a number of general configuration improvements to our treasury management and in-house cash setup.
- Educate us on deal management and business partner maintenance.
- Update and vastly improve our Treasury Management User Guide.
- Run a series of educational and analytical workshops.
- Map out several future improvements that would be of great benefit to Inmarsat – some of which have now been implemented.
Without this support it is likely that Inmarsat would no longer be using SAP TRM.
Inmarsat’s relationship with Zanders has continued through a Treasury Technology Support Contract, that is administered with the utmost professionalism and care. In the past six months or so, a large number of changes have been implemented. Most of these have been highly complex, requiring real expertise and this is where the true benefit of having an expert treasury service provider makes all the difference.”
Since the start of the TTS support contract, Zanders has been intimately engaged with Inmarsat to help support and provide expert guidance with usage and continuous improvement of the SAP solution. This is just a small step in optimising the inter-company netting, but a big steps towards automation of the core IHB processes.
If you want to know more about optimising in-house bank structures or inter-company netting then please get in contact with Warren Epstein.