In this topic, we shall be talking about Configuring Accounting Rules.
From the previous articles, we have understood how to get a data model by using the transaction object concept, and how to get the event model as part of the source system registration process. The next model that we need to think about is the accounting model. Here, we will talk about the concept of configuring the accounting rules.
An accounting method contains different components, and under one accounting method, you will have journal entry rule sets. Each journal entry rule set will be carrying journal line rules, account rules, description rules, and supporting references. And each one of these individual components may utilize conditions, custom formulas, and mapping sets.
Each Subledger application will have a unique Journal Entry Rule Set that groups all the rules together for creating journals. Journal entry rule set like a grouping component which groups all the other definitions that you might have defined under a subledger application.
The Journal Line Rules defines the debit and credit side of the journal entry. The journal line rules are also assigned to the journal entry rule set. There are multiple active rules that are governed by the journal line rules, such as identifying which line is a debit line, which line is a credit line for a particular transaction type.
And then we also have Account Rules which drives the GL account or segment for each debit and credit line of a journal. You may have multiple Journal Line Rules attached to the Journal Entry Rule Set and against each of those journal line rules, you will have to attach an accounting rule so that the system knows which account rule is applicable to enter the values for the respective segments.
Then accounting methods may also use some optional components such as Description Rules and Supporting References.
Description rules can be defined to dynamically extract the description for a particular subledger journal entry. This rule enables you to combine source system values and constant values to use as a description for the Journal entry.
For example, I want the loan officer name and Date of the Loan Origination in the description of the journal entry. I would need to define those as a source and concatenate them together with constant values and group them into a description rule. Using that description rule, whenever a journal entry is generated, the system will generate a dynamic description either at the header level or at the line level.
Another component that you can have is the Supporting Reference. These are basically used to store additional source information about transactions. They are also useful for reconciling the accounting with your source systems. They are also capable of storing the balances for a segment that might not be part of your chart of accounts.
For example, I want to identify the total loan that has been disbursed by a particular loan officer. So I can define loan officer as a supporting reference. Whenever a journal is posted, the system will keep on accumulating the amount by each of the loan officers. Then you can inquire on the balances using that supporting reference. When you click on the supporting reference name or when you search by the supporting reference, it will give you the consolidated amount, at the loan officer supporting reference level. Using supporting references, you can also drill down journal entries by each of the loan officers to see the amount that has been posted into their respective accounts.
Then we have another optional set-up called Mapping Sets. Mapping sets will have a direct relationship with account rules, and helps you map your source system journal entry rules to your Oracle chart of accounts.
Automatically, the system will create one header level object and one line level transaction object. Those transaction objects have been utilized to generate the sources. Then the sources are also automatically generated based on the transaction objects and are assigned to the corresponding accounting event classes. These sources will always be used as a value when you design your accounting rules.
What is stored at the header transaction object level? Header transaction objects are used to store one row with header source values for each transaction that comes from the source system. This header object will always get populated with the transaction information that is coming from the source system. So for every transaction that comes from the source system, we need one header level record.
Each transaction is identified by its unique transaction number. And each transaction is also automatically assigned with an event as well. The transaction details whose values do not vary by transaction line or distribution should normally be stored in the header transaction objects only. So if you do not have line level details for bifurcating that value that you're capturing at the other level, so only header level information is enough to create the accounting entry.
What is stored at the line transaction object level? If you have a requirement where one header may have multiple lines, then apart from populating the data into the header level object, we need to populate the data into the line level objects also. So line transaction objects will store the details of transactions that vary based on transaction attributes.
For example, a mortgage transaction for loan origination may have multiple amounts, each related to different components of the loan, such as a loan origination amount, closing cost amount, and escrow amount, and you want to charge them to separate accounts. So each of these amounts could be captured as separate lines, along with an indication of the amount type. One row per distribution is linked to the associated transaction by transaction number. So at the header level, you will have the transaction number. And same transaction number will be referenced at the line level also. Because against that header, we want to have three different lines.
Each row is also automatically assigned with a line number. Because for the line level transaction object, line number is a required field. Transaction details whose values will vary by transaction line or distribution are normally stored in the transaction object column, for example, the loan number for a loan payment.
If there is no breakdown for the amount, it's OK to capture that at the header level itself. Otherwise, then you must populate the values at the line level transaction object as well.
Sources
Each and every column that is part of your transaction object will be converted into a source. So you must assign an update value, certain look-up type assignments whenever appropriate sources can have lookup types or value sets assigned to them.
Assigning a value set or lookup type enables you to pre-define valid values for the sources that is used to create accounting rules. So basically, when the transaction object has been registered, you can look into the sources that system has generated against that transaction object. And against each of these columns that are part of the transaction object, you can associate them to a lookup code also so that whenever that will be used as a source while designing the accounting rules, you can pull the values from those lookup codes.
Accounting Attribute
Accounting attribute is a piece of journal entry. The mapping of the sources to accounting attribute specifies how the Create Accounting process will get its values for each of the piece within the journal entry. For example, the Entered Currency attribute is used to map the source values to the Entered Currency field for the subledger journal entry lines.
You have also got an option to add and update the source assignments to accounting attributes as per your requirement.
Go to the Functional Setup Manager (also known as the Setup and Maintenance work area)
Click on the Task Panel and choose Search
Search for a task called Create Subledger Application Setups in Spreadsheet
When you get to that task page, you will see a button on that page called "Download Setup Template" When you click on that button, a pop-up message will appear to open the spreadsheet template. Open it, and then you can start populating the data.
Once you're done populating the spreadsheet. Validate the information and correct any errors.
If there are no errors left, click on generate ZIP and it would generate a Zip file containing the spreadsheet information.
Go back to the task page and click on Upload setup data and choose the generated Zip file and click OK.
Once upload is complete, you may verify the created subledger application by going to the Manage Subledger Application task.
The first sheet on the template describes the instructions that you should follow to enter the data for registering your source system. The spreadsheet template will always have three worksheets:
Source system
Transaction Information
Line Information
Source system. This is where you will provide all the basic information, such as the name of the source system, event class name, event type information, and so on. This sheet has two sections: The Source System Transaction section and the Transaction Type Section:
In the source system transaction section and transaction type sections, you will provide the following:
Column Name
Max Length
Data Type
NAME
25
Character
SHORT_NAME
25
Character
The information that you provide in the source system transaction section is used for registering the source system name and the event class name, as well as to register the journal source name.
Meanwhile, the information that you provide in the transaction type section is used to represents an event in the lifecycle of a transaction that will always have accounting entries. The entries you've put in the transaction type section is grouped under the event class you've defined from the source system transaction section.
Transaction Information. After naming the source system, event class, and the event types, the next thing we need to figure out is what transaction attributes we are going to bring in from the source system.
The transaction information worksheet lists the sources that are used for setting up accounting rules. The system will create a transaction object using these details and each entry in that transaction object will be converted into a source, that will be used when you're designing the accounting model. You would have to define the below fields:
Column
Name
Max
Length
Remarks
NAME
80
SHORT_NAME
TYPE
Indicates
what Data Type the Source will have
JOURNAL
DISPLAY?
3
indicates
whether this source will be is shown on reports
and in inquiries along with the journal.
Values are Yes/No
The Transaction Information spreadsheet has three mandatory fields:
Transaction Date is, by default, used as the accounting date.
Transaction Number links the transaction information and the line information together. Use a unique transaction number so that the source system segregates each transaction differently.
Ledger Name is the reporting entity for which journal entries are booked in the GL application.
Apart from the three mandatory sources, you can add more sources as required. For Example, it may be relevant fields such as a loan schedule payment date, loan maturity date, loan type, loan amount, etc.
These additional fields are also known as User Transaction Identifiers. You can have up to 10 rows that can be used as user transaction identifiers. They constitute the user-oriented key of the underlying subledger transactions. These identifiers are primarily used in accounting events when you perform inquiries or you run accounting event-specific reports. The transaction data that identifies the transaction varies by subledger application. And accounting event reports and inquiries will display the transaction identifiers and their labels as appropriate for the corresponding event class.
Line Information. This sheet lists the type of transaction information that can have more than one value per transaction. There is a possibility that one transaction may have multiple lines. If that is the case, then you must provide those line level fields in this particular sheet.
The worksheet includes three predefined required sources:
Transaction number field links the transaction header with the line information. For example, if I have one transaction and it has got three lines, we need to ensure that the transaction number that we have given at the header level, the same transaction number should be given for all the lines so that system knows that all these three lines pertains to one header.
Default amount holds the transaction amount values that will be used when generating accounting entries
Default currency holds the entered currency value that you will be using in the accounting process.
Additional line sources can be added if multiple and different values are required for use in the same source attribute. The same details for the Transaction information spreadsheet applies to the Line Information spreadsheet. You must populate the Name, Short Name and Type fields.
The "Chart Of Account Value?" column indicates whether that source can be used to derive an account or not. There is a possibility that you might be using one of the fields to derive the chart of account values. For example, the salesperson name or maybe loan type. Acceptable values for this field is Yes or No and only text type sources can be used in segment rules.
An example of a source that would typically be used to derive general account could be Account, Cost Center, or Company. They could also be predefined values, so rather than using them as a derivation factor, you can directly pick up a field here called account value. So whenever the system will generate the accounting entry, if you have mapped it to this source, system will use that as a default value for the segment values under your chart of accounts.
Verifying and Uploading the Spreadsheet Data
Once the data has been populated into each of the three sheets, you will have to ensure that you have submitted the validation process. To verify whether the data that you have entered is accurate or not, you will need to click the Validation button in the Source System sheet.
If an error is generated, you will receive the error message and the system will also generate a validation report as a separate worksheet. You must open the validation report worksheet to review the errors. Then you must correct the error and validate the content again.
Once there are no more errors, then you can generate the zip file by clicking on the "Generate Zip" button in the Source System sheet and save the zip file. You will also receive a notification that the zip file was created and saved in the same local folder as the download spreadsheet template.
Once the file has been saved, the next step will be to upload the setup zip file. Go back to the application page and in the Create Subledger Application Setups in Spreadsheet task, there is another button available called "Upload Setup File". When you click on that, you will get an option to browse the file from your local machine. Choose the file that you generated and then choose "Select Import".
If errors exists during the upload process, you will be prompted with an error message. You must correct the error in the spreadsheet in the fields that have been notified in the error message box. If there are no errors, you will be able to successfully register the source system along with the underlying components like transaction objects, event models, and so on. The files uploaded will basically create the subledger setups in a single step. You don't have to do anything.
Editing the Uploaded Subledger Setups
Sometimes there is a possibility that you may be interested in overriding the uploaded source system information. In that case, you can re-upload the spreadsheet template for the same source system if you have not created any accounting rules under that source system.
You can download the template again, make changes, and load the data one more time. Once the data has been successfully uploaded, you can go to that particular source system from within the Setup and Maintenance work area and verify whether everything has been loaded successfully or not.
You can also update the uploaded setups from the user interface. For example, You can add new event types if you think that the event types that have been loaded are not enough for your requirement.
Also, if you want to make the changes to the source name the system has created to suit your business requirement, you can edit them so that they are easily understood when configuring accounting rules. It should be a user-friendly name, which every user who is involved in designing your accounting rules should be able to recognize them.
You can also add new sources from the user interface. The download of a new transaction data template will include this newly-added source as well. Then you can also complete the accounting attribute assignment, though when you upload the data, accounting attribute assignment happens automatically.
Post-Upload Process
Once the upload has successfully processed, Transaction objects (including Transaction Attributes) will get created automatically and can now be used to configure accounting rules through the Subledger Accounting user interface. Also, a Journal Source, Process Category and Event Class has also been automatically created using the name of the Source System.
Below is a quick step-by-step video demonstration of Creating Custom Subledger Application Setups in Spreadsheet:
The build phase is where you will actually register the source systems for Accounting Hub Cloud. You have the flexibility to register source systems with the help of predefined spreadsheet templates. The source system is the place where you will get all the information about the transactions that you want to bring into the Accounting Hub.
Before you start bringing the transactions, you must register the source systems and their underlying event models. And for that, you will use the Excel templates to populate the values for the source system name and columns that will be used for registering your transaction objects used to store the transactional data from the source systems.
Underneath the source system, you will establish an event model that will carry your process categories, event classes, and event types. This will also carry all the column details that are required for storing the values at the header-level values and line level values. This means when you use this template, you will specify the entire event model and the other attributes that are required for generating your accounting entries.
When the data is uploaded using that spreadsheet template, it will register a transaction object. A transaction object is a database table which is used to store the header-level data and the line-level data. You will have to analyze what attributes you want to bring from the source system. And you need to have a column for each one of those attributes in your transaction object.
For example, in the source system, you have many important fields like such as customer name, customer number, loan number, loan reference number, sales person, currency amount, etc. To bring this information into Accounting Hub, these fields need to be populated in the rapid implementation spreadsheets. When the data is loaded into the application through the upload mechanism, the system will register a transaction object and build the respective columns. Whatever fields you will specify on your spreadsheet templates, each one of those fields will be considered as the sources. And they will become part of your transaction object.
You can use these sources for the purpose of designing your description rules, account rules. Use those sources when you are defining your journal line rules to identify what is your debit line, what is your credit line as well.
And then you must verify the source system information. When the source system has been created, you will have to figure out the accounting attributes that are associated with those sources or with those objects. And you must figure out the source assignments as well. So that is going to be your first step.
Accounting Hub always works based on a three-model definition. The three models are called the data model, the event model, and the accounting model.
Data Model.The data model will be generated based on the source system registration process. In the spreadsheet template, provide the source system name, the transaction objects and specify the fields that will be used as columns. When you load the spreadsheet into the system, system will establish a data model.
Event Model.Simultaneous with the Data Model creation, the system will also establish an event model. When you provide the information on the spreadsheet template, you will also specify the event class and the respective event types that will be part of your event model. This process of registering source systems will help you in creating a data model and an event model.
Accounting Model.Creating the Accounting Model is the time when you will actually configure your accounting rules. Here, you will manage the information based on the transaction object data that has been created as part of the data model and the event model.
And finally, once your three models are in place, then you can start bringing the transactional data from the source system and upload that into the application either by using the spreadsheet templates or by automating the process using the predefined web services.
How can you Register a Source System?
The spreadsheet integration upload process accelerates the time from implementation and testing to production. It's a faster way of registering your source systems and helps us in registering our source systems by generating the transaction objects to the spreadsheet upload process.
After completing the source system transactional flow analysis, Go to the Setup and Maintenance work area, you will search for a task called Create Subledger Application Setups in Spreadsheet. When you go to that task page, you will get a button on that page called Download Setup Template. When you click on that button, a pop-up message will appear to open the spreadsheet template. Open it, and then you can start populating the data.
Populate the data into the spreadsheet template with the following guide questions to establish your data and event models:
What is the name of the source system?
What is the event class name?
What are the event types that you want to use?
What are the columns that will be used to store the data at the header level?
What are the columns that will be used to store the data at the line level?
Then you must validate the spreadsheet content once the data has been populated in each of those fields. You will generate the zip files. And then you will upload the zip files into the application. And finally, once the process gets over, you will verify whether your source system has been created or not.
Under each Source System, you need to establish your event model. An event model helps you map the transaction types from your source systems. Under each event model, we can then map accounting events which represent the transactions that may have financial significance. For example, issuing a loan and disposing of an asset is a transaction that we book in the source system.
For each one of these transactions, we need to manage and record their accounting entries by submitting the Create Accounting process for the Accounting Hub application. When you define accounting events, you must determine, from a business perspective, which activities or transactions that occur in your source system may create a financial impact. And accordingly, you will have to build an event model.
An Event Model contains three components:
Process category is just a grouping for event classes. For example, you can create a grouping for invoices and payments. Under each of these process categories are event classes and event types defined. The process category's name is taken from the source system name,
Event Class. An event class is used to group the related transaction information and attributes within a source system. An event class is created by using the registered source system name. From the above example, "Loans" is the source system name and will be the event class and process category name, and under that, multiple event types can be defined. Accounting Hub Cloud supports only one event class per source system application. But you can have as many unique event types for segregating your transaction types under that event class.
Event Types are basically represents the transaction types of your source system. In the current example, the event types could be loan chargeoff, loan interest accrual, loan interest accrual reversal, and so on. Events with significantly different fiscal or operational implications are classified into different accounting event types. Accounting definitions in the Accounting Hub Cloud are based on an event class and event type combination. And an event type must be unique within an application.
Whenever you are planning to establish your event model, visualize the hierarchy. You will have a source system. The source system, you will have process categories. Under process categories, you will have an event class. And under an event class, you can have multiple event types. And these event types are actually reflecting your transaction types from the source system.
This article provides an Overview of the Analyze Phase in the Accounting Transformation Implementation in Accounting Hub Cloud.
Analyze and Identify the Transaction Lifecycle of Source Systems
First, the number of custom subledgers to be created should be determined. In our example, we have separate third-party systems for commercial and individual loans, and a billing application. Depending on how your organization uses these third-party systems, we may want to register them as separate subledgers or just one subledger. Below is a quick comparison between the two:
Unified Subledger
Separate Subledgers
Share subledger accounting rules
Provides more security across
applications
Lets you report across all data
easily
less data in each processor,
performance will be much faster
accounting process can be run
simultaneously for different applications
much less likely to contend for
database resources
For example, If the commercial and individual loan systems will be registered as a single, unified subledger, data for processing will be huge and this might impact system performance. On the other hand, this actually saves time, because we can re-utilize the subledger accounting rules. So considering these points, you will have to figure out whether it is a wise decision to go with separate or unified subledgers.
Another point that we have to keep in mind is that, we need to determine what source data is required to create subledger journal entries. You should not bring each and every transaction from the source system into Accounting Hub, rather, only transactions which need to be accounted for. You need to analyze the source systems and determine what transaction types to capture and what transaction types should be considered for accounting purposes.
In the loan system example, we have the following activities in your source system:
loan origination
loan interest approval
loan interest accrual reversals
loan scheduled payments
loan late payments
loan charge-offs
Some of the mentioned transactions will attract accounting entries, and some of them will not. Only the transaction types that needs accounting entries must be established as part of your event model under the source system that you're registering within the Accounting Hub Cloud. These transactions must be distinctly identified and registered as transaction types.
A transaction type and it's associated transaction data typically relates to a single document or transaction in the source system. Transaction types will become accounting events in the Accounting Hub Cloud, and for each of those accounting events, we must generate the accounting entries.
Next point that we need to keep in mind is to figure out how frequent do you want the data to come from the source system. This will depend on the immediacy and volumes of accounting requirements in your company. It should not be scheduled during the day when your database resources are being consumed at a high level.
Also, you will have to evaluate if you will bring each and every individual customer transaction from the source system, or just the summarized activity for a customer that you have managed throughout the day.
Analyze the Accounting, Reporting, Auditing, and Reconciliation Requirements for Transaction Types
This analysis should, at a minimum, answer a couple of questions, such as: Under what condition does each of the subledger journal entry lines get created? Is it upon the loan approval or when the loan has been entered in the source system? You need to identify the event when the transaction should be picked from the source system. What is the line type of each subledger journal entry line, debit or credit? You need to figure out if a transaction will use a debit line or the credit line. For example, the transaction "Loan Origination" will have a debit line for loan receivable account and a credit line for cash or bank account.
What description should be used for the subledger journal entry? This determines the description the subledger journal entry will have for each transaction type. This will be useful for reconciling the subledger journal entry to the source system.
How are the accounts derived for the entry? This determines how are the account segment values for each of the segment in your chart of account will be retrieved. What logic is needed to be applied to identify the account segment values of each transaction type.
What additional information may be useful for reconciling the subledger journal entry to the source system? You would need to identify what additional information needs to be captured that will be useful for reconciling the subledger journal entry to the source system.
Aside from identifying the accounting transactions in your source system, you should also determine which attributes you need to include in journal entry creation. There are 10 attributes, called transaction identifiers, that you can use to capture transactional information from your source systems.
These transaction identifiers can help you easily reconcile journal entries. Specify which fields you want to map against those 10 transaction identifiers to, and when the accounting entries are generated, the system will populate the values of those transaction identifiers at the journal entry level. These transaction identifiers can be utilized for designing either the description rules or the account rules. Example transaction attributes may include:
Amounts (including entered and accounted amounts)
Dates (such as accounting date and transaction date)
Descriptions
Journal Ledger accounts
Customer Information
Transaction Type Information
Product Information
Salesperson
Loan Type
Carefully analyze, plan and model the custom subledger by visualizing the accounted journal entries. and identify the transaction attributes from the source system that can be used for accounting and reporting purposes, and model the source system to meet your business requirement in the Accounting Hub Cloud.
Transaction Identifier Example
From the above loan source system example, the transaction "Loan origination" is the debit line, and Cash is the credit line.
Observe that the Account column shows different values. Analyze whether the entire combination or each of the individual segments will follow a specific rule to retrieve the values. Those values could be based on the transaction attributes that were brought from the source system. This can be achieved with a mechanism called mapping sets.
For example, the value for the Line of Business segment (segment 2) can be based on the salesperson who is tied to that transaction line. Below, If the transaction was tied to Mr John Doe, the Line of Business Segment is 10. Additionally, the cost center segment can be dependent on the loan type. If the loan type is an adjustable rate, the value for the cost center would be "0000" and if the loan type is fixed rate, the cost center value is "2120".
When you have listed all the transaction attributes that are required to obtain the appropriate accounting entries from the Accounting Hub Cloud and visualized all these details, you will be able to retrieve the values for your chart of account segment and map them into the application. And based on that, the journal entry will be created.
Accounting Attributes
Next, we need to figure out, what are the accounting attributes that we need to assign for our source system. So the Create Accounting process basically utilizes the values of the sources assigned to accounting attributes and accounting rules to create subledger journal entries.
Each accounting attribute is associated with a level when you create the subledger journal entries. It could be the header level definition, or it may be the line level definition. Below are the mandatory accounting attributes and source assignments, these must be used whenever you are registering your source systems.
Accounting Attribute
Predefined Source Assignment
Accounting Date
Transaction Date
Distribution Type
Accounting Event Type Code
Entered Amount
Default Amount
Entered Currency Code
Default Currency
First Distribution Identifier
Line Number
Accounting Hub Cloud basically pre-defines transaction dates as accounting date. So whatever is your transaction date, that is identified by Accounting Hub as accounting date. The Create Accounting process will use this to derive the accounting date of the journal entries. There is another option that we have to keep in mind as far as accounting date is concerned, that is called accrual reversal accounting date source. This attribute is relevant to applications that must perform automatic reversal on accrual journal entries at a specified date or period. You can assign application and standard date sources to the accrual reversal accounting date on the Accounting Attribute Assignment page.
The First Distribution Identifier information is equivalent to the line number in the predefined source assignment. This basically links the subledger transaction distributions to their corresponding journal entry lines.
So these are the accounting attributes that we should always keep in mind, and they will always be associated to a predefined source assignment.
The rapid implementation approach is a new approach that has been introduced for the purpose of registering source systems quicker with the use of spreadsheet templates, where you will populate the details based on which the registration of the third-party systems will take place.
This is especially useful if you have numerous third-party application systems and you would like to register them into the Accounting Hub Cloud solution. It offers a simplified, streamlined source system registration and automation-ready transaction upload to Financials Cloud.
Steps in the Rapid Implementation Approach
Source System Registration. First, you need to figure out which are the third-party systems that you want to use for the purpose of registration into the Oracle Accounting Hub Cloud. And within the application, you have an option to download a spreadsheet template. You can populate the information into the respective sections of the spreadsheet template. And based on the data that you will enter, when you upload that into the application, the system will register a source system automatically.
Upload Transactional Data. You can upload transactional data for the registered Accounting Hub Cloud subledgers in a CSV format. Optionally, you can automate the process from uploading to create accounting journal entries with the help of web services as well. This actually increases control of financial and management reporting requirements because you have a streamlined, smooth approach to bring the transactional data from the various systems into the Accounting Hub Cloud solution.
Accounting Transformations.To generate the accounting entries against the transactional data that we are bringing from the various systems, we need accounting rules. And those accounting rules are basically designed with the help of a solution called accounting transformations. Accounting transformations will basically help you to set up your accounting methods which are containers for all the accounting rules and other related attributes based on the journal entry that's supposed to be created.
When you register a source system, you will need to establish an event model under that. Once a source system has been registered and an event model has been established, you will design an accounting method. All of them will be utilized. And then you will load the transactional data by using those components. Finally, these transactional data will be converted into journal entries and they are then posted into GL to update the balances in the Essbase cube. This allows your organization to run Financial Statements and reports using the Financial Reporting Center, the intended primary user interface for accessing all the journal ledger-related reports.
To use Accounting Hub Cloud, accounting rules need to be established with the use of accounting transformation. Accounting transformation is a mechanism that helps you to manage the creation of accurate, detailed, auditable accounting journal entries and reference information for transactions that were recorded from a third party system. And finally, those journal entries are pushed and posted to the General Ledger application.
Planning and Modeling Subledgers
The first thing that needs to be done is to plan and model the custom subledger applications that will be registered in Accounting Hub. You would need exists to have separate control over accounting and other business operation decisions for a specific source system.
If you look at the example below, we are presuming that we have a third-party application system that processes loans and billing:
For loan processing, we might be using a separate application for dealing with commercial loans and a separate application for dealing with individual loans. In that case, we need to register them as two separate subledger applications. Within that, we are going to have to determine what type of transactions are recorded in those individual subledger applications. In the example, both of them have a Transaction Type of Fixed Rate Mortgage and Adjustable Rate Mortgage.
In the same example, we have another third-party point of sale system that handles customer billing. This needs to be registered as a separate subledger application. Within that, there are two different entities that are operating in the US and UK. This can be registered together as one subledger because they can possibly share accounting methods and accounting rules.
Implementation Process for Accounting Transformation
There are six steps that are involved in the entire implementation process, but can be summarized into 3 Phases: Analyze, Build, Implement and Test. So whenever you are implementing the solution, you will have to keep these six steps always in mind, and they will give you a summarized idea of the implementation steps that you need to follow within the accounting transformation process.
The Analyze Phase is where you will analyze and identify transaction life cycle within the third-party application for transactions or activities that must be accounted and then you will analyze accounting, reporting, audit, and reconciliation requirements for each of the transaction types that you manage within those source systems.
The Build Phaseis where you will actually register the source systems into the application. And then you will configure the accounting rules, and assign accounting methods to the respective ledgers. Whatever source system you have registered, you will have to build your event model underneath it. An event model basically represents the transaction types that you are managing in your source system applications which have financial impact in the Accounting Hub Cloud to make them eligible for accounting. Event Model will then have Event Classes and for each event class, you must establish the logic to generate the accounting entries by setting up the accounting rules and by establishing an accounting method.
Implement and Test Phase is the stage where you will implement and test the accounting methods by assigning them to ledgers to create a complete definition of accounting convention for the transactions and activities of each source system. Here, you will upload your transaction data from the source system as a sample data for testing purposes to ensure that all the accounting is correctly generated. Once confirmed correct, you can start moving setups into the production environment, and then start uploading your transactional data on a day-to-day basis, and start generating accounting entries for them.
Soon to follow!
Manage the accounting transformation accounting methods
What is Oracle Accounting Hub Cloud?
Oracle Accounting Hub Cloud provides the option to bring transactional data from external systems into the cloud with use of the Subledger Accounting engine. Accounting Hub is a very useful solution if you want to utilize a single, rule-based accounting engine for various external applications that records your organization's day-to-day transactions.
These external applications (called Source Systems) are typically industry-specific applications that are either purchased from third parties, or they have been homegrown within the organization. Typically, these source systems are not be capable of generating rule-based accounting entries. Examples of such source systems could be core banking application, insurance policy administration system, billing applications, loan processing applications, and a point of sale (POS) system.
Rather than having a separate accounting rule logic for each source system, you can also register these systems in Oracle Cloud and use Accounting Hub for account derivation and have a unified accounting engine repository where you can maintain and apply your accounting rules, bring the data from all the external transactional applications, then push the accounting entries into the GL application.
Advantage of using Oracle Accounting Hub
With the help of Oracle Accounting Hub Cloud, you can:
Get the flexibility and control that you need in the implementation, expansion, and maintenance of user-defined subledgers to adopt in a flexible business environment.
Configure accounting rules to meet your corporate and statutory requirements.
Automate and control the processes that transform source system data to recording detailed auditable journal entries.
You can also use the modern reporting tools that are available in Oracle Cloud to reconcile the accounting journal entries. This will actually reduce the workload during the period-end processes. And you can also gain insightful information for your day-to-day business, for corporate performance, and for making business decisions.
Oracle Accounting Hub also helps you integrate and align information from virtually any source system into Oracle Financial Cloud services. It gives customers the freedom and flexibility to choose the tools they want we use to run their business as they start their transition to cloud-based computing. This capability provides a smooth transition to cloud computing for our Oracle Financials Cloud customers because they can continue their financial operations on existing systems while centralizing the critical information for management decisions, audit, and compliance to a central cloud service for easy access across the globe.
How does Oracle Accounting Hub Work?
For Example, you have an external Point-Of-Sale (POS) application where you actually manage your day-to-day transactions. We will register this POS system as a User-defined Subledger application within the Oracle ERP Cloud and import its transactions. With the use of the Accounting engine, we are going to generate the accounting entries of these transactions based on the rules that we have configured. And finally, these accounting entries are posted to the General Ledger application. From there, we can utilize the balances for complying with the management reporting requirements, audits and reconciliations, and to comply with statutory reporting requirements as well.
Accounting Hub Cloud Components
General Ledger. Oracle Accounting Hub Cloud comes along with Oracle General Ledger, where you will post all your actual balances. Oracle General Ledger provides journal entry import and creation, real-time balance storage, and accounting controls, intercompany balancing, and the period close functionality. It also comes along with a calculation manager, which helps you to define allocation rules using complex formulas. It helps you to automatically generate the allocation journals based on those allocation rules and helps you in also utilizing the in-house journal approval solution. And finally, you can also utilize the GL for your year-end process management as well. When journals are posted, the Essbase Cube, a multi-dimensional table that holds journal balances, is updated and you can generate reports of your organization's financials data.
Financial Reporting. Oracle Accounting Hub Cloud uses various Financial Reporting tools built in Oracle Cloud. Financial reporting is dependent on the data that is stored in the Essbase Cube, which will help you in faster and easier access to your balances by using various reporting tools.
Every time a transaction or journal is posted in the journal ledger, the balances cubes are updated at the same time with pre-aggregated balances at every level of summarization in your account hierarchy. This is leveraged by reports for quick processing. And you can extract the data in a much faster way because it is stored in a pre-aggregated format.
It helps you to slice and dice the data across dimensions. So you can easily move the definitions from rows and to columns, columns to rows. You can place them in terms of the page level. So it exactly works like a work table. And apart from that, you also get the flexibility to drill up and down and across on any parent level within the scope of your journal accounts.
Tools like Oracle Transactional Business Intelligence (OTBI) and the BI Publisher allows you to use seeded Financial reports across your enterprise in multiple formats. It gives you the flexibility to extract your balances in various formats including PDF, Excel, PPT, Word, etc. So that gives you a lot of flexibility because different stakeholders would like the data to be in their respective format so that they can utilize in a proper way.
Accounting Transformations. To transform the transactional data into Subledger accounting Entries, you need to use the accounting transformations. Accounting transformation is a mechanism that helps you to manage the journal entries for the transactions that would have been recorded in a third party system.
You will actually transform the transactional data that is imported from those third party applications into actual journal entries. And finally, those journal entries are pushed and posted to the journal ledger application.
Outbound Integration. You can also manage outbound integrations with Oracle E-Business Suite and PeopleSoft General Ledgers if you're already managing your transactional activities in any one of these two applications. You can even get the final posted balances from the GL of these applications into the Oracle Accounting Hub platform.
Configurations needed for Oracle Accounting Hub Cloud
