FSAH known as Financial Services Accounting Hub was changed to FAH(Financial Accounting Hub) recently as the former title was misleading. This hub has nothing specific to Financial Services, rather can be used anywhere to address the universal challenges of compliance, single source, drill down to subledger, consolidation and duplication of accounting engine.
Major industries having versatile business tend to build lots of high complexity application to cater to multiple business needs. Businesses can vary from loan to core banking to retail banking to investment banking and so on. The applications meant to do business are either developed in house or procured from market or can have mix of both. This may look good having individual systems to cater to individual operations. However it throws up lots of challenges from maintenance and accounting perspective. Primary challenges are:-
1. Accounting transactions stored in different places. No single source of truth.
2. Excessive effort in building and maintaining accounting treatments at multiple system level
3. Difficulty in enforcing corporate wide standards
4. Ineffective reporting from compliance perspective (GAAP, IFRS etc)
Everyone desires to have a single source of truth where it can look in for any transaction information that has already happened. This apart, re-usability is something everyone wants to have to ease out maintenance and cut cost.
The above challenges led to the evolution of concept called “Accounting Hub”.
Oracles Financial Services Accounting Hub (FSAH/FAH) solves these problems with a centralized accounting rules engine and repository. Accounting journals are created with a transparent rules transformation engine, validated, and stored in an auditable format in a single location. Your organization can enhance its reporting, efficiently account for products and services, simultaneously meet diverse and mutually exclusive accounting requirements, and increase internal controls.
Why FAH
· Implements centralized Business Rules, Accounting Services for different products and Accounting Systems and acts as a Financial Data Store with different representations for different reporting purposes.
· Allows user to maintain coherent accounting policies with tight internal controls. This rules repository contains the instructions for completing accounting transformations.
· Provides a common accounting engine that transforms data from source systems into journals and stores them in the accounting repository.
· Is tightly integrated with Oracle Applications like Oracle Receivables, Payables, Fixed Assets Oracle General Ledger etc. The OGL set-ups provide FSAH with the chart of accounts to be used for accounting generation. FSAH generates accounting for OGL
· Provide visibility, efficient and control in the streamlined accounting process.
Flow
· Identify Data
· Load data in staging area
· Create Events in FAH
· Create Accounting in FAH
· Transfer Journal to GL
· Post Journal in GL
Complexity Factors
Following Factors bring in more challenges in a FAH implementation. They should be given diligent consideration before stepping and committing to FAH projects.
• Number of Feeder Systems
• Input Data formats
• Multi Currency
• Business Rules
• Accounting Rules
• General Ledger Mapping
• Drilldown to Feeder systems
• Reporting Needs
Monday, November 16, 2009
FSAH/FAH - Financial Accounting Hub
Saturday, December 6, 2008
Payables -
Payables
Release 12 introduces Oracle Subledger Accounting, Oracle E-Business Tax, Ledgers, Banks, and other common data model components that are used by Oracle Payables.
The following Payables features are new in Release 12:
• Suppliers are defined as Parties within the Oracle Trading Community Architecture (TCA).
• Invoice Lines are introduced as an entity between the Invoice Header and Invoice Distributions to better match the structure of invoice documents and to improve the flow of information such as manufacturer, model and serial number from Purchasing through to Assets.
• Banks, bank branches, and internal bank accounts are defined centrally and are managed in Oracle Cash Management.
• Document sequencing of payments has moved to the Cash Management bank account setup.
• Payments and all funds disbursement activities are handled by a new module, Oracle Payments.
• Payment features controlled by Global Descriptive Flexfields (GDF) in prior releases have been consolidated and migrated into the data models of Oracle Payables, Oracle Payments, and Oracle Cash Management. The architecture of this solution moves attributes from the GDFs, which are now obsolete, to regular fields on the appropriate entity, including the invoice, payment format and document, supplier site, and bank account. Having a single code base as opposed to GDFs implemented per country simplifies global implementations and streamlines transaction processing.
• Oracle Subledger Accounting, a new module in Release 12, handles accounting definitions and all accounting setup associated with a Ledger. (In Release 12, Oracle General Ledger has replaced Sets of Books with Ledgers.) As part of this change, centralized accounting reports are available to all applications. Additionally, Oracle Payables introduces a new Trial Balance report.
• Oracle E-Business Tax, a new module in Release 12, manages transaction tax setup associated with trading partners and tax authorities, as well as transaction tax processing and reporting across the Oracle E-Business Suite. Part of the architecture of this solution moves tax attributes from Global
Descriptive Flexfields (GDFs), which are obsolete in Release 12, to regular fields on the appropriate entities.
• A Responsibility can be associated with multiple Operating Units using Multiple Organization Access Control (MOAC). Due to this change, all processing and some reporting in Oracle Payables are available across Operating Units from a single applications responsibility. Hence you can isolate your transaction data by operating unit for security and local level compliance while still enabling shared service center processing.
Pre-Upgrade Tips
Just prior to the upgrade:
• Import all invoices from the Payables open interface.
• Confirm or cancel all Unconfirmed Payment batches.
• Run the Payables Accounting Health Check script (see OracleMetaLink Note 416699.1) to ensure that there are no inconsistencies in your 11i data.
Setup Tips
• Once you have set options for Automatic Offsets, do not change them. Doing so would represent a major setup change that does not update past transactions and would lead to accounting issues. A change in Automatic Offsets should be considered as a project that includes full testing before being implemented in your production system. Past transactions must be cleared before such a change.
• When specifying the Open Balances Definition, include all code combinations that need to be reconciled (accounts that can be attached at the Invoice header level.) If automatic offsets are on, include the overlay accounts that can be generated.
• When defining new bank accounts, ensure that cash clearing and cash accounts have been provided at the bank accounts control level.
Run the Invoice Validation program on a regular basis (at least daily) to determine if there are invoices that are not getting validated. The best practice is to schedule a concurrent request so that it runs daily at a time when load is not high.
Operational Tips
Regular Activities
• Run the Invoice Validation program on a regular basis (at least daily) to determine if there are invoices that are not getting validated. The best practice is to schedule a concurrent request so that it runs daily at a time when load is not high.
• Run the Create Accounting program on a regular basis (at least daily) to identify invoices that are not getting accounted.
• When you make manual entries to the General Ledger, ensure that proper descriptions are provided so that they can be tracked back as required
• For U.S. implementations: Once you begin creating 1099 payment information for 1099 suppliers, periodically review the information to verify its accuracy and completeness. Payables provides three standard reports to help you identify 1099 reporting exceptions:
• 1099 Supplier Exceptions Report - Review this report to identify 1099 supplier exceptions, for example: null, non-standard or duplicate TIN. Correct any exceptions in the Suppliers form.
• 1099 Invoice Exceptions Report - Review this report to identify and correct invoices without income tax types for 1099 suppliers, 1099 invoices for a non-1099 supplier, and 1099 invoices with null or invalid income tax regions.
• Tax Information Verification Letter - Submit the Tax Information Verification Letter report for each supplier, requesting name, address, TIN, and type of organization.
Period Closing-related Activities
• Consider doing a mock closing at least 5 days before your actual close. Check the exceptions report for any unusual activity, for example: Invoices or Payments that should have been accounted but are still appearing in the report, or Invoices that should have been validated but are still appearing in the report.
Reconciliation-related Activities
• Ensure that accounts used as liability accounts, and that need reconciliation, are not used for any other purpose. For example, such accounts should not be used in any other subledger and no manual entries should be made against them. To ensure this, make these accounts control accounts using a new feature of Release 12.
• Ensure that accounts used as liability accounts, and that need reconciliation, are not used as accounts at the distribution level. Otherwise, reconciliation will become difficult.
• After closing the periods in Payables and General Ledger, please run the needed reports to balance within Payables. This would typically include the Trial Balance, Posted Invoice Register, and Posted Payment Register reports. You’ll also need to run the Account Analysis in General Ledger and reconcile that to Payables. Ensure that a monthly reconciliation is performed. Track any unexpected data.
