SLA in EBS R12 vs Fusion Financials & FAH

Subledger Accounting (SLA) in Fusion Financials release (including Fusion Accounting Hub) has some changes/improvements compared to SLA in e-business suite R12.
Here is a side-by-side overview of the main components of SLA:

EBS R12	Fusion Financials	Description
Subledger Accounting Method (SLAM)	Subledger Accounting Method	SLAM groups AADs (R12) or Journal entry rule sets (Fusion) which have common set of accounting requirements  together to define a consistent accounting treatment -  It can be assigned to 1 or more ledgers FAH: FAH uses SLA to process financial data from Oracle-owned and non-Oracle external applications, which is then transferred to Fusion GL.
Application Accounting Definition (AAD)	--	R12: AAD groups together journal line definitions and header assignments for event classes & event types. Fusion: This component does not exist in Fusion*.
Journal Line Definition	Journal Entry Rule Set	Journal line definition (R12) corresponding to Journal Entry Rule Set (Fusion): groups and assigns all the below listed subcomponents, within an event class or event type.
Journal Line Types	Journal Line Rules	These are defined for a particular event class. -  Decide DR or CR, Accounting Class, where to fetch the amount from, conditions etc.
Journal Entry Descriptions	Description Rules	This component lets users define the elements of a description that appears on the subledger journal header and/or line.
Account Derivation Rules (ADR)	Account Rules	This is possibly the most important component of SLA, which provides maximum flexibility in deriving the accounts in the Accounting Flexfield. Account Rule (ADR in R12) lets users define rules by entire Account combination, segment or value set and the Conditions when to apply it. Values can be Constant, fetched from Source, Mapping Set or another Rule.
Mapping Set	Mapping Set	Mapping Set associates a specific output value for an Account segment (or all segments) based on an input value.
Supporting References	Supporting References	Supporting References can be used for: -  providing additional information at header or line level -  maintaining additional balance at subledger (line level)

*In Fusion Financials, the Subledger Accounting Method setup page appears to be simplified and hence the 'Application Accounting Definition' component from R12 is no longer needed.

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.