Financial Accounting Hub (FAH)

What is Financial Accounting hub (FAH)

The Financial Accounting Hub is an integration tool which enables customers to integrate data from Non-Oracle source systems or sub-ledgers such as Billing/Banking, any 3rd Party Accounting or Insurance systems.  Specific rules can be applied to the data as it passes through the hub into the Oracle General Ledger. Oracle Financials Accounting Hub enables the transformation of information from disparate systems into a centrally and consistently maintained accounting repository. The core strengths of Oracle Financials Accounting Hub include its ability to create a single source of accounting truth for multiple external and legacy systems using business user-defined accounting rules. 

Oracle Financials Accounting Hub allows the integration of External Application by centralizing the definition and maintenance of accounting rules in a business user orientated repository. Accounting journals are created with a rules transformation engine, validated, and stored in an auditable format in a single location.  FAH acts as the accounting engine for any sub-ledger (Oracle or non-Oracle), create adjusting journal entries, and provide drill back from General Ledger (GL) to FAH,

How Does FAH Works:

FAH is an uptake of SLA. It is basically standalone Subledger Accounting (SLA), it allows to use Oracle SLA and GL to perform the accounting for third party / External applications.

Using Accounting Method Builder (AMB) Tool, FAH Efficiently Create Accounting for Multiple Heterogeneous Source Systems Oracle Financials Accounting Hub provides a flexible rules builder for business users to create accounting rules once and deploy them many times across different external and legacy systems. Legacy systems that do pre-accounting can pass journals through the hub to validate and store the accounting in the accounting repository for a single, reliable, enterprise wide view.

Financial Accounting Hub (FAH) V/S Sub-Ledger Accounting (SLA)

• The Financial Accounting Hub (FAH) is very similar to the Subledger Accounting product (SLA). In fact, looking merely at the functionality, there's no difference between FAH and SLA.
• The only distinction between both products is that with SLA you get seeded event models for all Oracle Subledger modules that require accounting and if desired one can use the components from these seeded event models to create your own customized Subledger Accounting Method.
• While with a FAH organizations get the possibilities to register external applications as Subledger, from which they can build their own event model, and use the SLA functionality to create accounting for the events originating from their external applications.

FAH Event Model:

FAH/SLA uses an Event Model consisting of Event Entities with underlying Event Classes, and at the lowest level we have the Event Types which in their turn belong to the Event Classes.

The accounting is entirely event-driven meaning that for each Event Type you can define how you would like the accounting to be created. This is done using Journal Line Types, Journal Entry Descriptions and Account Derivation Rules which tie together in a Journal Lines Definition. Conditions can be applied at various levels, and optionally you can use Mapping Sets and/or Supporting References.

For each Event Type such a Journal Lines Definition can be build. These Journal Lines Definitions roll up into an Application Accounting Definition.  The Application Accounting Definitions are grouped together under a Subledger Accounting Method, which is the component that gets tied to the ledger (In R12 a ledger consists of calendar, currency, chart of accounts and Subledger Accounting Method).

FAH transaction Flow:

FAH allows to use Oracle SLA and GL to perform the accounting for third party applications. Using Accounting Method Builder (AMB) Tool, The Application Accounting Events, Accounting events of source External application are mapped and stored in the SLA tables. External/Source Application’s accounting event’s for, accounting attributes and transactions supporting references are kept in FAH transactions objects.  When user submits accounting program,

• Accounting program fetches the applicable accounting events from SLA Tables depending the External application and Event model.
• The Configured Accounting definition rules are then applied and Loaded FAH transactions objects
• journal entries for the External Application are then created and stored in the SLA Tables.
• SLA journal entries for External application are transferred to GL using standard Oracle Transfer to GL Program.

Project Accounting Basics

Project Accounting Basics

Project: A project is a primary unit of work that can be broken down into one or more tasks.

Task: It is the small unit of work created under the project against which transaction can be created.

Note: we cannot create transaction/expenditure items directly on the project, hence it is mandatory for each project to have at least one task.

 Project Classes:

Oracle PA has provided three pre defined project classes.

• Indirect projects – Track overhead activities and costs of the organization. Note: Does not generate revenue and invoicing process.
• Capital projects – Track asset development activities and costs, and costs are capitalized as one or more assets.
• Contract projects – Contract projects created with external customer to track cost, revenue, and billing.

 Project Type:

The project type controls how Oracle Project Foundation creates and processes projects, and is a primary classification for the projects your business manages. You must set up at least one project type to create projects. You must set up project types for each operating unit.

•  Examples of Indirect project: Admin Project, Transport Facility etc.
• Example of Contract project: External Project, Intercompany project etc.

Expenditure category: It is the category created to classify the different types of cost an organization may incur.

Revenue category: It is the category created to classify the different types of revenue an organization may earn.

Expenditure type:It is the identification of cost that is associated to an expenditure item.It is assigned to the expenditure category and revenue category during the setups.

Expenditure class: It is the classification for an expenditure type as how the expenditure type can be used to create transaction. When an expenditure type is classified for a certain type then only those expenditure class transactions are allowed to enter.

 In Oracle Project Costing we have predefined expenditure classes.

 Labor:

Straight Time: For standard time entry. We use the cost rate multiple with number of hours.

Overtime: Labor cost calculated using a premium cost rate multiplied by hours.

 Non-labor project costs:

Expense Reports – Expense reports from Oracle Payables or Oracle Internet Expenses. You cannot enter expense reports directly into Oracle Project Costing. Expense reports that you import into Oracle Project Costing must be fully accounted prior to import.

Usages – You must specify the non-labor resource for every usage item you charge to a project. For each expenditure type classified by a Usage expenditure type class, you also define non-labor resources and organizations that own each non-labor resource.

Supplier Invoices – Supplier invoices, discounts, and payments from Oracle Payables or an external system, and receipt accruals from Oracle Purchasing.

Miscellaneous Transaction – Miscellaneous Transactions are used to track miscellaneous project costs. Examples of uses for miscellaneous transactions are:

• Fixed assets depreciation
• Allocations
• Interest charges

Burden Transaction – Burden transactions track burden costs that are calculated in an external system or calculated by Oracle Project Costing as separate, summarized transactions. These costs are created as a separate expenditure item that has a burdened cost amount, but has a quantity and raw cost value of zero. You can adjust burden transactions that are not system-generated.

Work In Process – You use this expenditure type class for Oracle Project Manufacturing WIP transactions that you interface from Manufacturing to Oracle Project Costing. You can also use this expenditure type class when you import other manufacturing costs via Transaction Import or when you enter transactions via pre-approved batch entry.

 Inventory – This expenditure type class is used for the following transactions:

• Oracle Project Manufacturing transactions that you import from Manufacturing or Oracle Inventory.
• Oracle Inventory Issues and Receipts that you import from Oracle Inventory in a manufacturing or non-manufacturing installation.

 Example:

Sr No	Expenditure Category	Revenue category	Expenditure type	Expenditure Class
1	Labor Time	Labor Revenue	Standard_Time	Straight Time
2	Vendor Cost	Service Revenue	Supplier_cost	Supplier Invoices
3	Travel Cost	Travel Revenue	Travel Cost	Expense Report & Supplier Invoices
4	Misc Cost	Misc Revenue	Misc_Transactions	Miscellaneous and usages

In the above examples for line number 1, time can be entered for expenditure type “Standard_Time”.

Similarly for line number 2 & 4 the respective expenditure class transactions can be entered.

For line number 3 supplier invoices & expense reports can be entered as it has been classified for two different classes.

Types of Currencies

Transaction amounts are stored in the following currencies:

• Transaction Currency:The currency in which a project transaction occurs.
•  Expenditure Functional Currency: The functional currency of the expenditure operating unit.
• Project Functional Currency: The functional currency of the operating unit that owns the project.
• Project Currency: The user–defined project currency.

When you enter transactions in a currency that is different from functional currency or project currency, Oracle Project Costing must convert the transaction amount to the functional and project currencies. To convert transaction currencies, Oracle Project Costing must first determine the exchange rate type and exchange rate date.

 Task Type:

• Billable Item: It is a functionality associated at the task level identifying the expenditure items created against the task to be billed to the client.
• Non Billable Item: It is functionality associated at the task level identifying the expenditure items created on the task is only to record the cost incurred against it.

Note: We can adjust the task at the expenditure item window to make the non billable as billable and vice versa. This is called as expenditure item adjustments.

Employee/Job bill rate Override: In case a different rate needs to be updated for a particular job or employee the same can be updated at the project or task level.

The employee name needs to be entered along with the bill rate, currency and period applicable. The rate at the task level overwrites the rates at the project level and the rates at the project level overwrites the rate of the bill rate schedule attached at the project level.

Cost rate: It is the rate defined at the job or employee level to derive at the basic cost for a particular expenditure item. The cost rate scheduled are defined in the OU functional currency.

The cost rate can be defined at two levels:

• In the setups -> Expenditure -> Rate schedule.
• Overrides: Labor Costing Overrides

( Navigation: PA Responsibility->Setup->Costing->Labor->Labor Costing Overrides.)

Bill rate: It is the rate defined at the job or employee level to derive at an amount which will be billed to the client.

The bill rate can be defined at two levels:

1. In the setups -> Expenditure -> Rate schedule.
2. Overrides: At the project level as employee or job override.

•  For employee override: Navigation: Project -> Options -> – Bill Rates and Discount Overrides -> Employee Bill Rate and Discount Overrides
•  For job override: Navigation: Project -> Options ->   Bill Rates and Discount Overrides -> Job Bill Rate and Discount Overrides

Transfer Price Rules and Schedule: Transfer price rules control the calculation of transfer prices for labor and non-labor cross charged transactions. To drive transfer price calculation for cross charge transactions between the provider and receiver, use the Transfer Price Schedule window to assign labor or non-labor (or both) transfer price rules to the provider and receiver pair on a schedule line

ICB: It is a process, where we have different legal entities involved, and the OUs under these LE owns the employees and projects.

• The OU to which the employee is assigned is called PROVIDER OU.
• The OU to which owns the project is called RECEIVER OU.

 Note: In ICB process, an internal invoice is generated in provider OU.

The Trial Balance and its Significance in the Accounting Process

The Trial Balance and its Significance in the Accounting Process

Trial Balance is a list of closing balances of ledger accounts on a certain date and is the first step towards the preparation of financial statements. It is usually prepared at the end of an accounting period to assist in the drafting of financial statements. The report is primarily used to ensure that the total of all debits equals the total of all credits, which means that there are no unbalanced journal entries in the accounting system. Ledger balances are segregated into debit balances and credit balances. If all accounting entries are recorded correctly and all the ledger balances are accurately extracted, the total of all debit balances appearing in the trial balance must equal to the sum of all credit balances.

Trial balance ensures that for every debit entry recorded, a corresponding credit entry has been recorded in the books in accordance with the double entry concept of accounting. If the totals of the trial balance do not agree, the differences may be investigated and resolved before financial statements are prepared.

Ledger accounts are closed at the end of each accounting period by calculating the totals of debit and credit sides of a ledger. The difference between the sum of debits and credits is known as the closing balance. This is the amount which is posted in the trial balance


If there are subsidiaries in an organization that report their results to a parent company, the parent may request an ending trial balance from each subsidiary, which it uses to prepare consolidated results for the entire company.


Types of Trial Balance

Un-Adjusted trial balance
When the trial balance is first printed, it is called the un-adjusted trial balance.

Adjusted trial balance
Then, when the accounting team corrects any errors found and makes adjustments to bring the financial statements into compliance with an accounting framework (such as GAAP or IFRS), the report is called the adjusted trial balance.

Post-closing trial balance
The adjusted trial balance is typically printed and stored in the year-end book, which is then archived. Finally, after the period has been closed, the report is called the post-closing trial balance.


Trial Balance Format
The initial trial balance report contains the following columns:
1. Account number
2. Account name
3. Ending debit balance (if any)
4. Ending credit balance (if any)
Each line item only contains the ending balance in an account. All accounts having an ending balance are listed in the trial balance;


Limitations of a trial balance
Trial Balance only confirms that the total of all debit balances match the total of all credit balances. Trial balance totals may agree in spite of errors. An example would be an incorrect debit entry being offset by an equal credit entry. Likewise, a trial balance gives no proof that certain transactions have not been recorded at all because in such case, both debit and credit sides of a transaction would be omitted causing the trial balance totals to still agree. Types of accounting errors and their effect on trial balance are more fully discussed in the section on Suspense Accounts.

How to prepare a Trial Balance
Following Steps are involved in the preparation of a Trial Balance:
1. All Ledger Accounts are closed at the end of an accounting period.
2. Ledger balances are posted into the trial balance.
3. Trial Balance is prepared and errors are identified.
4. Erred Entries may be posted to Suspense Account Unless Approrpiate Rectification is identified.
5. Errors identified earlier are rectified by posting corrective entries.
6. After the Posting the Adjustments are incorporated in Traila balance. They can be specifically noted in order to highlight the Adjustments.

Sub-ledger Accounting Configuration - Part 1

Sub Ledger Accounting method (SLAM):

SLA is a rule based accounting Engine that introduced the ability to define how transactions originating in Sub Ledgers can be Accounted. Hence in order achieve this high level of flexibility SLA is accommodated with lot of configurable and predefined components.

This article will talk about different Predefined and configurable components of SubLedger Accounting which are used to setup accounting rules in order to achieve various accounting requirement.

Below mentioned are Predefined Components of SLA. We will talk about their specific Examples as we move on.

Predefined Components of SLA:

Entities:

Entities in SLA represent a Specific Document category in the Application. For example an Invoice or Payment in Account Payables. 

Event Class:

Event Class in SLA represents a specific type of the entity for which the Corresponding accounting entry will be generated. For Example a Standard Invoice is a Type Of invoice there by Standard Invoice will be an Event class for the Entity AP Invoice.

Event Type:

Event type is an Action or an event which should be defined as trigger for the creation of accounting entries.

For example: in reference to a Standard accounting requirement an Standard Invoice should get accounted once it is validated. Hence the Event which will initiate the accounting for the invoice is Validation. So Standard invoice validation is the Event Type for Event Class Standard Invoice

In Order to explain the complete concept let’s take one more example.

There should be accounting entries generated for Cancellation of a credit memo. And hence Credit Memo is a Type of Account Payables invoice.

Entities à AP invoice

Event Class à Credit Memo

Event à Cancellation.

Sub-Ledger Accounting

Sub-Ledger Accounting

Sub ledger accounting traditionally had accounting rules spread across multiple Products and Sub ledger applications hence it was Difficult to keep the rules up to date and manage.

And if there used to be any requirement which requires a different Accounting treatment as per different geographies, Regulations  or entity it was extremely difficult to implement and many times the ultimate solution was to implement a customization or pass manual Adjustment entries.

The New Sub Ledger accounting feature of oracle E-business Suite R12 popularly known as SLA addresses such issues through a central accounting rule engine allowing among other things, Superior controller ship of definition of accounting rules.

SLA is a rule based accounting Engine that introduced the ability to define how transactions originating in Sub Ledgers can be Accounted. One of the significant benefits of SLA is the ability to generate multiple accounting representations (IFRS and local GAAP) for a single sub ledger transaction.

Hence in Simple words, Different from 11i where accounting Entries used to get created in respective Sub ledgers and then get transferred to GL, In R12 the Entries get created using SLA for all the Sub ledger applications and then gets transferred to GL. Hence it would be appropriate to say SLA is placed between different Sub ledgers such as AP, AR, CE, PA and General Ledger as mentioned in below. 

Sub Ledger Accounting Gives capability to Massage/ Change the accounting entries which gets generated as part of the Standard Sub Ledger application specific account so as to have the accounting entries posted to the desired accounts to address various geographies or entity specific accounting requirement

Above Example shows how the accounting String (A.B.C.D) generated by SubLedger Applications (Eg: AP, AR, CE) can be altered to A1.B1.C1.D1 to achieve specific Accounting requirement and then can be transferred to general Ledger.

Accounts Payables Accounting Flow

Accounts Payables Accounting Flow

Below are few of the key concepts about Accounts Payables Accounting. Accounts Payables have multiple Flows which will be elaborated below. Even though the accounting engine has been moved to Sub Ledger accounting in r12, the Core Concepts of Payables accounting remain same.

Standard Accounts Payable Invoice/ Payment Accounting

One of the most commonly seen scenarios in Accounts payables is Standard Invoice and Payment. Below are the accounting entries for them

Standard invoice creation:

               Dr. Expense / Item Expense / Misc. Expense

                              Cr. Supplier / Liability

The “Expense / Item Expense / Misc. Expense” are derived from the Payables Invoice Distribution where as “Supplier / Liability” Account id derived from Supplier’s Site, from the liability account code combination on that particular site. Although the liability account is defaulted from Payables’ Financial Setup, but you can change the account code according to your need. We can even change the liability account code combination on the Invoice Workbench by enabling the Column from Folders option.

Payment of the Standard invoice:

               Dr. Supplier / Liability

                              Cr. Bank / Cash / Cash Clearing

Now comes the payment, the liability account is fetched from the supplier whose invoice is being paid, the cash clearing or cash account is fetched from the bank you select during the payment. This account is defined during the Bank Account Setup.

PREPAYMENTS / ADVANCES:

Prepayment Invoice creation:

Dr.  Prepaid Expense / Advance Paid

               Cr. Supplier / Liability

Prepayment invoice Payment:

               Dr. Supplier / Liability

                              Cr.  Bank / Cash / Cash Clearing

Standard Invoice creation:

               Dr. Expense / Item Expense / Misc. Expense

                              Cr. Supplier / Liability

Prepayment Application to Standard invoice

               Dr. Supplier / Liability

               Cr. Prepaid Expense / Advance Paid

INVOICES with “TRACK AS ASSETS”:

Track as Asset” is a functionality for moving the items from Oracle Payables to Oracle Assets. It is a check box on the Invoice Line TAB and can be enabled on Distribution Line using the Folder View option. When you check this box and run the “Mass Addition Create Report” from Payables, the items on invoice line or distribution line moves to Oracle Assets. 

Invoice creation:

Dr. Asset Clearing
                              Dr. Supplier / Liability

Invoice transferred to oracle Assets:

               Dr. Asset

                              Cr. Asset Clearing

INVOICE with WITHHOLDING TAX

In the Payables invoices with Withholding tax Scenarios, accounting entry for the WHT payables or Liability account is selected from the supplier defined as a Tax Authority. The WHT expense is picked from the WHT setup.

Taking an example of withholding at time of Payment

Invoice Creation:

Dr. Expense / Item Expense / Misc. Expense

                              Cr. Supplier / Liability

Payment with Withholding Tax 

               Dr. Supplier / Liability

                              Cr. Bank / Cash / Cash Clearing

                              Cr. Withholding Tax

WITHHOLDING TAX INVOICE

               Dr. WHT Expense

                              Cr. Withholding Liability

Procure to Pay process Flow (High Level)

When I started working on the Oracle Applications I always had a desire if I could get a Process Flow of the Business process that I am working on, That could help me Understand how the data and transactions Flow. and I can also get a Good understanding of the Big Picture of what is it that we are trying to achieve.

So as part  of this Blog here is a Process Flow for all new explorers. Below mentioned is a Summary Process flow of Procure to Pay Process and How are Purchasing, Payables and General Ledger Modules are Used in this Business Process.

My next post will have a Detailed process Flow Procure to Pay Model