Limitations of Advanced Global Intercompany System (AGIS)

There is no doubt that AGIS (Advanced Global Intercompany System) is a great product that was released as part of Financials modules in EBS R12. However, there are some limitations in the standard out-of-the box functionality that the implementation consultant, functional users and executive management need to be informed of: 
  
UPDATE: These limitations still exist in Fusion Financials 11g (Release 5) 

1) Only one Exchange Rate Type 

     AGIS supports only one foreign conversion rate type, which is defined in System Options. It does not support selection of any other conversion rate type or user rates on an individual intercompany transaction. Oracle recommends this standard practice in order to reduce intercompany reconciliation problems during consolidation and US GAAP impact. However, there are several countries (in Europe and elsewhere) where it is mandatory to use FX rates provided by the national bank or government on all foreign currency transactions, including intercompany transactions. 
     A possible custom solution to incorporate selection of exchange rate type on individual intercompany transactions can be to enable DFFs on Initiator as well as Recipient screens, and customize the workflow to populate the corresponding fields in AR and AP interface tables during invoice import.  

2) Recipient Approval without Review

     AGIS supports Recipient approval process, where (by default) any of the Intercompany accountants / users associated with the Recipient organization can 'Approve' or 'Update then Approve' an incoming intercompany transaction. Problems may arise in the following example scenario:
                               Initiator Organization ->  USA Corp.
                               Recipient Organization -> Romania Inc.

1.  USA Corp. user creates an intercompany batch for some charges. She populates the line descriptions and accounting on Initiator side correctly, which will appear on the AR invoice. However, not knowing Romanian language or local accounts, she selects wrong accounting on Recipient side. The transaction is submitted.
2.  Romania Inc. user gets an email notification or workflow notification for approval of Incoming transaction. Since she was expecting such an intercompany charge, she directly 'Approves' it.
3.  AP invoice in Romania Inc. is created automatically with wrong line descriptions and wrong accounts.

     To avoid this pitfall, there needs to be a robust internal control process where the Recipient users MUST update the incoming transaction with appropriate line descriptions and accounting information, and then approve it. In addition, customization can be done so that the 'Approve' button on email is hidden.

3) No Open Intercompany Invoices Report

     There are several seeded reports in AGIS for intercompany reconciliation and batch/transaction statuses. However, there is no seeded report which shows ALL the open intercompany invoices from both Receivables and Payables subledgers, for a particular operating unit.
     Such a report is an absolute necessity in any organization, and a simple custom SQL report may be written which addresses this requirement.
  

4) Confusing Web ADI layout

     Many business users and implementers find the seeded 'Intercompany - Single Batch Entry' document layout for Web ADI (uploading intercompany transactions from excel) very confusing. Having ALL the transaction fields on one single line, with debits and credits next to each other is difficult to comprehend and use.

        A simple solution is to define two easy-to-use custom layouts in Desktop integration - one for 'Intercompany Invoices / Receivable charges' and another for 'Intercompany credit memos / payable charges'. 

5) Euronetting / Multilateral Netting is not supported

     Many multinational corporations use 'Euronetting' or some other multilateral netting service in order to simplify intercompany payment processing at month end. Multilateral netting can be explained by the following figures,

     The standard 'AP/AR Netting' functionality (which is suited for bilateral netting) in Oracle is not adequate to meet such a complex requirement. Setting up multiple netting agreements does not reduce user manual effort.  
      A custom interface between Euronetting service and Oracle EBS can be designed, to automatically record payments and receipts in Oracle AP and AR resp. corresponding to the information obtained from Euronetting. This will significantly reduce manual effort of double entry in Oracle, and avoid user mistakes. Alternatively, by ensuring robust setups, a manual workaround can be implemented since the Euronetting payment process happens only once a month.