Ahcs best practice_white_paper_1.5 (1)

Accounting Hub Cloud Best
Implementation Practices
Key considerations, best implementation practices and use cases to
assist in determining the optimal deployment and configuration
options on Oracle Accounting Hub Cloud implementations.
August, 2021 | Version [1.5]
Copyright © 2021, Oracle and/or its affiliates
Public

PURPOSE STATEMENT
This document summarizes learnings from a number of implementations, and various guidelines and recommendations
provided by Oracle Development to help along the way.
There are many different ways that Oracle Accounting Hub Cloud can be configured to address requirements arising
from the complexities of real-world business environments. In this document, we have tried to outline the current best
practices in a number of key implementation areas. The summary covers only the most common use cases. There may
be valid exceptions.
Provided guidance should be used in conjunction with our documentation available on the Help Center. It is not meant
as a substitute for working with a qualified implementation partner to assist with the deployment.
DISCLAIMER
This document in any form, software or printed matter, contains proprietary information that is the exclusive property
of Oracle. Your access to and use of this confidential material is subject to the terms and conditions of your Oracle
software license and service agreement, which has been executed and with which you agree to comply. This document
and information contained herein may not be disclosed, copied, reproduced or distributed to anyone outside Oracle
without prior written consent of Oracle. This document is not part of your license agreement nor can it be incorporated
into any contractual agreement with Oracle or its subsidiaries or affiliates.
This document is for informational purposes only and is intended solely to assist you in planning for the implementation
and upgrade of the product features described. It is not a commitment to deliver any material, code, or functionality, and
should not be relied upon in making purchasing decisions. The development, release, and timing of any features or
functionality described in this document remains at the sole discretion of Oracle.
Due to the nature of the product architecture, it may not be possible to safely include all features described in this
document without risking significant destabilization of the code.

3 WHITE PAPER | Accounting Hub Cloud Best Implementation Practices | Version [1.4]
Copyright © 2021, Oracle and/or its affiliates | Public
TABLE OF CONTENTS
Purpose Statement 2
Disclaimer 2
IMPLEMENTATION APPROACH 4
Requirements 4
Architecture 4
Testing 5
Performance 5
Historical Conversion 5
Go-Live 5
Post Go-Live Operations 5
Functional Design 6
Enterprise Structures 6
Source Systems 6
Accounting Rules 6
Journal Line Rules 7
Mapping Sets 7
Supporting References 7
Journal Entry Rule Sets 8
Technical Design 8
Pre-Processing 9
Accounting Hub Processing 10
Transaction Processing 10
Other Processing 11
Error Handling and Reliability 11
Performance 12
Tuning 12
Subledger System Options 12
Control the Flow 13
Environment 13
Use Cases 13
Use Case 1: Low Volume 13
Use Case 2: High Volume 14
Use Case 3: Mixed 14
Reporting 15
Reporting Tools 15
Extraction Tools 16
Reconciliation 17

IMPLEMENTATION APPROACH
Consider the adoption of Accounting Hub as part of the overall finance transformation, not as implementing another
ERP module.
Get help from a professional system integrator (SI). Regardless of how well the project team is trained, working with a
professional SI - Oracle Consulting or a certified Oracle partner – will most certainly save you a lot of trouble.
Implementing in the Cloud is very different from on premise (and not just because of functional product differences).
Involve key stakeholders from the finance department, including financial planning and analysis, and internal audit
functions.
If you are piloting a part of the solution, keep the end state in mind. You would want to reality check your high-level
approach regularly to make sure you are on the right track.
Requirements
Determine your requirements prior to starting any designs or configurations of pre-processing, application setup,
accounting rules, or any other part of the Accounting Hub implementation. Avoid a ‘lift and shift’ approach. Focus on
current business needs.
Before you dive into the actual implementation, or even just the high-level approach, you would want a clear picture of
what requirements you are trying to address for reporting, accounting, reconciliation, and performance purposes:
 Reporting: including regulatory and management reporting.
 Accounting: accounting, internal control and audit requirements.
 Reconciliation: identify reconciliation items.
 Performance: establish processing needs and performance targets, consider peak volumes and time windows.
Too often, the implementation team doesn't actually know the reporting requirements so they opt to store all attributes
at the greatest level of detail "just in case". Having a clearer understanding of the destination and use of the information
offers opportunities to streamline the Accounting Hub implementation.
 Be pragmatic about what you plan to handle within your accounting system to avoid trouble down the road:
• Performance bottlenecks.
• Reconciliation challenges.
• Exception management difficulties.
• Unwarranted accounting adjustments.
 Focus on information useful for accounting, reconciliation and financial reporting. Requirements for reporting
on non-financial information are best addressed outside Accounting Hub.
Architecture
Have the big picture laid out – the various source systems, the end to end architecture for the accounting life cycle: from
capturing transaction information, to exception management, to delivery of information and reports to stakeholders.
You would typically choose to start with one (or few) source system(s), complete the implementation and testing, adjust
the design as needed before proceeding with the rest. For instance, you may choose source systems:
 With relatively low volume but representative of other systems (to reapply principles for additional systems).
 Where accounting requirements are well understood and documented and there are business users willing and
able to take an active part in the implementation and validate results.

 Where test data is readily available or easy to generate as needed (e.g. not limited to monthly cycles).
 Prioritize the order of integrating these systems into Accounting Hub. Prioritize systems where:
o The financial outputs are unacceptable, such as difficult to audit or prone to restatements.
o Require substantial manual work.
o It is difficult or impossible to update the system itself to accommodate accounting requirements.
For phased implementations, try to think ahead about global design items like chart of accounts, enterprise structures
and naming conventions. This would require a conscious stretch if the pilot does not cover the full set of requirements.
Testing
Plan to establish test cases and document results. Allow time to test all features and activities. You may need to
additionally factor in preparation of test data for both functional and performance testing of all flows and integrations.
Plan to test and verify the accounting treatments, reports and reconciliations. Besides common flows, consider testing:
 Month end/year end activities such as open period, balance carry forward.
 Less used features: transaction reversal, accrual reversal, intercompany, etc.
 Reporting: reporting currency, valuation methods, supporting reference balances, etc.
Test with one full quarter or at least one full period of historical data. For example, load all transactions for the second
quarter of 2019 and reconcile results to the legacy accounting system.
Perform end-to-end testing, or integration testing, that includes pre-processing, Accounting Hub processing, post-
processing and reporting. Testing individual components is good but be sure to test that the entire flow works and
nothing breaks.
Performance
Set aside time for performance testing, tuning and benchmarking on a production-like system. It will likely take several
cycles of testing with a variety of performance data to ensure performance targets are met. You will find some useful
guidance below.
Before you start, make sure you have an environment configured appropriately for the required number of users and
transaction volume. Review the white paper from Oracle Applications Cloud – Environment Usage Evaluation (2015718.1).
Historical Conversion
Do you plan to start with just initial balances or, do you plan to convert historical transactions too – e.g. for a full quarter?
One approach is to roll forward the beginning year balances and then convert year to date amounts as needed.
Depending on your requirements you can define one set of rules to be used for accounting during initial data migration
and a separate set of rules for ongoing transaction accounting.
In any case, plan proper data conversion testing before go-live. Historical data is very different in both shape and size
from that processed on any normal day. Consider whether to load historical transactions into a clean staging pod and
then copy via a Test-to-Production refresh into production or load data directly into production. You would want the
approach clearly defined in advance and activities planned accordingly with service lead times considered.
Go-Live
Customers often prefer a soft go-live with the Accounting Hub system running in parallel with the legacy accounting
system for an entire fiscal quarter (or more). This allows for side-by-side comparisons, provides a smooth transition for
the users and a buffer period to identify and resolve any unforeseen issues.
Post Go-Live Operations
As with any implementation, you would want to plan for life after go-live, and ensure appropriate resources are allocated
and trained for each process flow – both on regular days and at period end.
Define what the process would be like should issues arise and nominate points of contact. Plan accordingly to ensure
that the right resources are available and trained for the job.
Define the sign off criteria for Accounting Hub daily, monthly, quarterly run, e.g. accounting errors impact < $10,000, or
total receivables account variance to source system < $10,000.
Plan to keep learning about, testing and uptaking new features delivered in the quarterly updates. For additional
considerations, refer to the Oracle Cloud Applications Post Go Live Leading Practices white paper.

FUNCTIONAL DESIGN
Investing in a well-thought-out Accounting Hub functional design will help avoid rework, simplify down-stream
reconciliation and improve performance. In case of doubt, engage with Oracle for reviewing any key design decisions.
Enterprise Structures
It is extremely important to design the chart of accounts well and model the enterprise ledger architecture in line with
your company structure and management objectives. Decide how many ledgers would best suit your business.
Balance your performance requirements with the need for multiple ledgers and reporting currencies. Use multiple
representations judiciously. Consider options such as balance, journal, and valuation methods. Balance level secondary
ledgers and partial (adjustment only) representations produce significantly less volume than complete subledger level
secondary ledgers.
For additional considerations, see the ERP – Record to Report Enterprise Structures Best Implementation Practices
session on Cloud Customer Connect as well as the Oracle Cloud Applications Enterprise Structures Whitepaper (Doc ID
2415848.1).
Source Systems
Analyze the source systems and identify the transactions that have a financial impact. As a key step to creating
accounting entries, these transactions must be distinctly identified as different transaction types. Decide how much
transformation is required to produce subledger journal entries to meet your corporate and statutory requirements.
For each transaction type, work out an example of the accounting treatment in a spreadsheet and agree upon the result
with the finance department stakeholders. For every transaction event, describe an example, along with the required
accounting treatment (such as amounts, accounts, dates and rates), and sign it off with functional stakeholders. You will
return to this often throughout the implementation. A clear view of the complete set of transaction events and required
accounting treatment is key for the design of your accounting rules and can help spot any optimization potential.
Think about what information you will need to include to facilitate monitoring and tracking back transactions to the
source systems. Additional information, such as transaction identifiers, can be passed using supporting references or
journal descriptions.
The number of subledger applications that you define is an important decision you need to take. Using a single
application for all of your transactions has some functional benefits, as the data is centralized for inquiry and reporting
and accounting is generated using a single set of rules. However, using multiple applications can enable you to better
structure and secure your data. It can give you more flexibility in defining rules. It also provides substantial performance
and concurrency benefits.
 You can choose to create multiple subledger applications for a single source system. For instance, if you need
multiple event classes, e.g. to allow processing part of the transactions of a source system separately.
 Or, you can choose to group transactions from similar source systems into a common subledger application.
For large volumes of data, multiple subledger applications would generally parallelize better.
Accounting Rules
Accounting rules are components of the accounting method definitions used to construct journal entries and derive
account codes.
Image 1. Subledger Accounting Method

Design your accounting rules before the implementation:
 For each transaction type define the source (or the logic) for deriving the various attributes of the accounting
entry:
• The expected debit and credit lines, including which amounts from the transactions are used.
• The expected general ledger account combination for each line.
 Model the expected results given the rules design (use the same spreadsheet showing the required accounting
treatment)
 Agree upon the result with the finance department stakeholders.
 Reuse rules where you can (rather than creating multiple identical rules).
 Create enterprise-wide standards for rules.
 Include identifiers and descriptions to reconcile accounting entries with source system transactions.
 Use numeric identifiers rather than characters if you have a choice.
 When naming rules, use business terminology users are familiar with.
 Use effective dating when updating rules to comply with changes in management or regulatory requirements.
 Restrict accounting rule updates to the finance function.
Refer to Migrating subledger accounting rules for some examples, tips and considerations on the use of the various
setup export and import capabilities for migrating accounting rules.
Journal Line Rules
Journal line rules determine what journal entry lines should be created in debit or credit. Consider the following
guidelines:
 Minimize the number of journal line rules to reduce consumption of resources, improve performance and
simplify rule maintenance.
 Avoid using multiple journal line rules with identical attributes such as amounts, currency and journal side.
 Use mapping sets and/or conditions at the
account rule level to handle variations to accounts
instead of creating individual journal line rules.
 Use formulas in conditions for consistency and
ease of maintenance.
 Use priorities to define the most selective
condition first, the next most selective condition next,
etc. This will help avoid unnecessary processing for
each transaction line and will improve performance.
Image 2. Journal Line Rule Example
Mapping Sets
 Use file-based data import to load and import mappings, e.g. to integrate with an external mappings master
like Oracle Enterprise Data Management Cloud. Use the ERP Integration Service to automate the process.
 Consider using wildcards and multiple input sources rather than large number of individual mappings.
 Mapping sets should reflect real-world business mappings between domains. Caveats:
• Do not modify the preprocessing area to add
attributes that are only used for mapping sets.
• Do not create complex mappings that are
difficult to implement and understand.
• Do not artificially group business rules into a
single complex and unmanageable mapping set.
 Establish clear ownership of mapping set data
and processes to control and approve changes.
Image 3. Mapping Set Example
Supporting References
Supporting references allow storing additional information about a subledger journal entry line that could be used for
reporting or reconciliation back to source system. Optionally, supporting references can be used to maintain subledger
balances per ledger, period, GL account and a supporting reference combination.

For a supporting reference with two sources, Customer Type and Customer Name, assigned to your journal line rule, the
accounting program will create balances for the account combination, plus customer name and customer type.
Implementing supporting references at a later stage can be challenging so their usage should be planned early on. For
example: balances are tracked in ledger currency unless Entered Currency Balances for Supporting References Enabled
profile option is set. And it can only be set before balances are first created.
You may want to use supporting references to:
 Facilitate reconciliation to source systems by tagging journal entries with transaction and reference attributes.
 Maintain balances by dimensions not captured in the chart of accounts.
 Report using dimensions not captured in the chart of accounts.
 Enrich reporting on subledger journals.
Common pitfalls:
 Supporting references are not meant for replicating source system transaction detail. Subledger Accounting is
an accounting engine, not a reporting repository. You may define contract number as a supporting reference if
you need the contract referenced in accounting. Reporting on contract details through – like product and
customer specifics – is better addressed in the source contract system or a downstream reporting store.
 Don’t anticipate using GL features for supporting reference balances. Allocations, revaluations and other
general ledger features are not available for supporting reference balances.
 For performance, limit the number of supporting references with balances. Requirements for having more than
one supporting reference balance per journal line are rarely justified. For example, for loan receivables, a
supporting reference balance for anything but the loan identifier is unlikely to be appropriate.
 As part of performance tuning, plan to analyze supporting reference balance processing (including balance
carry forward at period-end and at year-end.
Journal Entry Rule Sets
The rules used to create journal entries are grouped into journal entry rule sets and assigned to accounting methods.
Some key considerations include:
 Event class level journal entry rule sets (Event Type: All) perform better than event type level rule sets.
 Performance is particularly impacted if a transaction data file contains many different transaction types or if
they are accounted at the same time.
 Journal entry rule sets with too many line rules should best be avoided altogether. If you end up with a really
large journal entry rule set (more than 50 rules), you may want to have a closer look and try to further
consolidate line rules with identical attributes.
TECHNICAL DESIGN
An equally important stream is the technical integration work required to extract, transform and prepare the data in the
predefined format and automate the end to end flow including steps performed outside Accounting Hub.
Image 4. The Accounting Hub Processing Flow

Pre-Processing
Accounting Hub implementations will invariably require some data transformation and pre-processing of data extracts
from the source transaction systems into the required Accounting Hub format. Allocate sufficient time to design,
develop and tune the pre-processing logic. Consider the following when planning this work:
 For extensibility and flexibility, plan to develop transformation logic using a metadata-driven ETL tool such as
Oracle Data Integrator, as opposed to hard coding such logic.
 Plan to use an orchestration/scheduling tool rather than hard coding the flow.
 Plan time to tune this logic and ensuring that it is reliable. Consider the following:
• Diagnostics. Provide sufficient logging to help debugging should things fail.
• Reliability. If it does fail, does it retry? Can it restart?
• Maintainability. Does it send notifications if it fails? Does it require significant manual effort to run?
Keep a clean separation of the extraction and the transformation logic, allowing each to be independently maintained,
tuned and tested. Focus on providing an efficient and incremental extraction solution. Consolidate all transformation
and processing logic, such as flattening, transaction splitting, validating headers/lines, etc.
Aim to reduce the volume of transactions being fed in to Accounting Hub to improve performance. For example:
 Filter out non-accounting events and net zero activities.
 Flatten transaction data by placing monetary components requiring distinct accounting treatment in columns,
rather than lines. E.g. send a single transaction record with principal, fee, service tax etc. provided in columns.
 Summarize based upon criteria such as:
• The granularity of accounting descriptions and supporting references.
• Transactions to accounting reconciliation requirements.
• The ability of business users to assess and understand the summarized amounts.
Image 5. Flattening and Summarization Example
Ensure the processing and transformation logic is flexible and maintainable. Use an ETL meta-data tool your IT
department is familiar with to facilitate future support and maintenance. Orchestration tools allows for flexibility in
scheduling and processing. Ensure that the process is easily configurable allowing you to specify parameters such as:
 The number of files.
 File chunk size.
 Scheduling frequency.
Avoid grouping data from different application/ledger combinations in the same file. Otherwise, the import will initiate
multiple Create Accounting parents (one per application/ledger) making processing hard to predict and control.
Importing extremely large files is not recommended. Importing 5 files of 1 million records each will typically perform
better than importing a 5 million file. This is mainly because Import Accounting Transactions will take longer to
complete and Create Accounting will start later.
Importing too many small files in parallel for the same ledger/application is not recommended either. Rather than lining
up hundreds of very small files, less than a thousand records each, consider grouping the records into fewer files.
In general, you should aim to keep both the number of files in a load and the number of records in the files relatively
stable from day to day. If you can, plan to feed data throughout the day rather than only once at the end of the day.

Very large transactions – e.g. a single transaction header with thousands of lines as in pass-through implementations –
do not perform well, especially in case of accounting errors. Break up the source data into multiple transactions with
fewer lines each to parallelize the load across multiple workers.
Accounting Hub Processing
The key transaction processing flow in Accounting Hub (see Image 4) consists of the following steps:
Prerequisite: Extract transaction data from source systems and transform it into the required format (zipped CSV files).
1. Upload compressed transaction files into UCM.
2. Import Accounting Transactions (import data from UCM and create accounting events).
3. Create Accounting (i.e. create subledger journal entries).
4. Post Subledger Journal Entries (transfer to GL).
5. Post Journals for Single Ledger (i.e. post in GL).
6. Update Subledger Accounting Balances.
7. Extract data to third party systems (optional).
You can run the end to end flow automatically for each file (steps 1-6), or, alternatively, you can first import transaction
data (steps 1-2), then submit a standalone Create Accounting (step 3) to create accounting for all imported transactions.
Depending on your choice of parameters this would also transfer the subledger journal entries to GL (step 4), post the
resulting journals (step 5), and update subledger balances (step 6), or you can submit those processes standalone too at
a later time.
When processes are run standalone, they will pick all unprocessed transactions at the time, which can improve
performance. E.g. you can import ten transaction files and run a single Create Accounting process at the end. This will
typically perform better than running ten separate Create Accounting jobs – one for each imported file.
The Flexible Configuration of Accounting Hub Cloud Service feature is now enabled by default for new customers.
Existing customers are encouraged to adopt that too especially in case of performance concerns. For more details, refer
to the Advanced Features for Importing Transaction Data to Accounting Hub in the Implementing Accounting Hub
guide.
See also Automating transaction import for how to automate transaction import (steps 1-2) using SOAP web services.
To decide which approach will best meet your requirements you will need to test, tune and benchmark your solution.
Some recommendations for the various accounting processes are provided below.
Transaction Processing
 Import Accounting Transactions (Step 2): Import throughput largely depends on file size. A single large file
of 20 Million rows may take a long time to import. Consider splitting up large files and importing the multiple
smaller files in parallel. In some cases, performance may be further improved by staggering the imports by a
few minutes which should be verified through testing.
 Create Accounting (Step 3): Each Create Accounting job consists of a parent job that will initiate child
processes / workers to process the transactions. The number of child processes initiated will depend upon
system settings and these are discussed further in the performance section.
 Only one Create Accounting parent can run for a given application/ledger combination at any time. You can
certainly submit Create Accounting parents for different application/ledger combinations at the same time, but
you’d better stagger Create Accounting parents for the same application/ledger so they are not sitting in the
queue waiting for each other, reserving ESS slots without doing any work.
 For large sets of data for the same application/ledger, import parallelizes best when the data is split into
smaller files and Create Accounting parallelizes best when the data is not split. In such scenarios, you may run
Create Accounting standalone and leave the parent to allocate the work across the multiple child processes.
 Post Subledger Journal Entries (Step 4): The process will initiate one GL Import for each batch defined by the
Processing Unit Size set in Transfer to General Ledger Processing Options under System Options. Too small a
processing unit size will result in more GL journal batches created, i.e. less aggregated GL journal data.
 Post Journals For Single Ledger (Step 5): It is important not to initiate too many GL posting jobs in parallel at
the same time, as 5% of the Essbase memory buffer is allocated to each GL posting job by default. This
effectively restricts the number of parallel posting jobs to 20 at a time. The buffer configuration can be changed
by cloud operations to allow more.
 Update Subledger Accounting Balances (Step 6): You can choose to skip third-party control account
balances update if you are not using any control accounts. Additionally, the Update Subledger Accounting
Balances process is now run automatically following the Create Accrual Reversal Accounting process. It should
only be run manually if the auto run fails for any reason. Suspend any scheduled jobs first.

• To skip control account balance update logic, define the profile option
XLA_UPDATE_CTRL_BALANCES and set the profile value to N.
• To automatically run Update Subledger Accounting Balances following Create Accrual Reversal
Accounting define the profile option XLA_UPDATE_SR_BALANCES and set the profile value to Y.
Other Processing
 Create Accrual Reversal Accounting: If you are implementing accrual reversals, make sure transaction
processing is completed and the resulting accounting entries transferred to GL before submitting any accrual
reversal processes.
• If you need to run multiple accrual reversal processes, start with the highest volume application and
ledger, and stagger the rest, rather than submitting them all at once.
• Optionally, skip accrual journal re-validation in the Create Accrual Reversal Accounting process and
rely on Journal Import validations further down the flow. To skip re-validation, define the profile
option XLA_SKIP_ACCR_RVSL_REVAL and set it to Y.
 Opening Periods: Carefully time the opening of accounting periods. High volume processing will complete
faster if there are less open periods to carry balances forward to.
 Accounting Hub Maintenance: The process is scheduled automatically to run daily at 2 AM UTC by default
purging old processed transaction data. You might want to run it at a different hour or with a different
frequency. See How to reschedule the Accounting Hub Maintenance process.
 Create Multiperiod Accounting: If you are implementing multiperiod accounting for a subledger application,
consider providing unique transaction line numbers in the line CSV file. The Line Number source is mapped to
the First Distribution Identifier accounting attribute and is used to uniquely identify transaction object records.
Processing takes significantly longer if every transaction has a line number 1.
 If importing transactions with multiperiod accounting start dates in the past, run Create Multiperiod Accounting
separately for each period you need amounts accounted in. Running the process for Nov-2020 would include
any unprocessed October amounts in the November entry regardless of whether Oct-2020 is still open or not.
Error Handling and Reliability
Break data extracted into logical units and design for re-startability in pre-processing, so that it is not necessary to have
to start from scratch. Build in functionality that will allow retry and restart operations into the orchestration flow
wherever possible.
Invariably, at some point, something may go wrong. For example, one of the processes may fail, accounting rules may
be incorrectly defined, etc. Therefore, it is important to understand how to correct and purge invalid transactions in
Accounting Hub. Refer to Accounting Hub Maintenance.
Understand how to restart in case of errors that may occur during the different stages of the Accounting Hub flow. For
example, which parts of the process can be re-run. Please refer to the Customer Connect topic Cancelling accounting
processes.
When transactions are accounted with error due to incorrect transaction data, you can purge the invalid transactions,
correct the data in a csv file and then re-import with the same transaction numbers.
When transactions are imported by mistake and have not been accounted yet, you can purge the unaccounted
transactions and then re-import with a correct data file.
If transactions have been imported and accounted successfully but you then realize the accounting is wrong due to
incorrect setup or incorrect transaction data, you can import a transaction reversal, which offsets the accounting from
the original event. The transactions can then be re-imported with a new transaction numbers after setup or transaction
data has been modified.
Retaining source transactions for a long time may result in slower performance for various reconciliation reports and
related activities. Therefore, the best practice is to not use Accounting Hub as a transaction repository. The pre-
processing area would be the best place to retain the full history of source transactions.
By default, the transaction retention period is 90 days. However, you can change the duration of the transaction
retention period based on your requirements. To change the accounting retention period, on the Manage Subledger
Accounting Lookups page, specify a value for the ORA_XLA_AHC_RETENTION_DAYS lookup type. The minimum value
of transaction retention period can be 30 days and the maximum value can be 458 days.
Although it is possible to extend the retention period of source transaction data within Accounting Hub, we recommend
not retaining any more than what is really needed for reconciliation and issue resolution purposes. Typically,
transactions beyond the last fiscal quarter would have had their accounting finalized and would have been through the
proper period and quarter close processes.

PERFORMANCE
Accounting Hub performance is influenced
by a wide variety of factors including data
shape and size, functional setup, features
used, environment sizing and
configuration, etc.
Performance tuning is an important part of
the implementation that should be factored
in the plan.
Ahead of any volume testing and tuning,
you need an environment prepared
following the process from My Oracle
Support Doc ID 2015718.1.
Establish clear performance targets. Start
by determining the processing window, the
flows that need to fit within that (and also
those that don’t). Image 6. Performance Requirements Example
Before you start, make sure the functional design is validated with much smaller transaction volume and basic results
verified (debits and credits). You shouldn't need to worry about accounting errors during performance tests. Just try
increasingly larger volumes working towards the desired performance objectives, tuning the settings as you go.
Tuning
There is plenty of flexibility in the setup and processes to achieve optimal throughput. It is important to benchmark the
end-to-end flow as you keep tuning the various components. You will likely need multiple iterations to arrive at stable
performance results.
 First tune and benchmark individual sections of the flow – pre-processing, accounting, reporting, and
extraction.
 Start with smaller transaction volumes and gradually increase until benchmarking an average daily run, a peak
daily run and a full month end / quarter end / year end run.
 Eventually chain everything together and benchmark end-to-end from source system extract to accounting to
extraction.
For very high volume scenarios, there is a Restructure Indexes feature which relies on hash partitioning certain
Accounting Hub indexes to improve performance. Contact Oracle Support if you are interested in using this feature.
Subledger System Options
Subledger System Options determine batch sizes and number of child processes initiated by the Create Accounting and
Post Subledger Journal Entries (transfer to GL) parents. These settings largely affect performance of accounting
processes. Default settings:
NUMBER OF WORKERS PROCESSING UNIT SIZE
Create Accounting 1 1000
Transfer to General Ledger * 1 1000
* Transfer to General Ledger processing options would default to the Create Accounting setting if left blank.
Processing Unit Size governs the size of the batches processed by the workers. It is recommended to start with the
default of 1000 for both Create Accounting and Transfer to GL.
Transfer to GL aggregates data before importing to GL. If Transfer to General Ledger Processing Unit Size is too small,
data will not be aggregated effectively which would negatively impact performance. If the value is too high, there may be
issues committing data.
Number of Workers determine how many child processes are initiated to process the batches. Initiating too many
workers may be counterproductive. If there is not enough data to process, they may end up sitting idle in the ESS job
queue preventing other processes from running until the parent job has completed.

The optimum settings will vary from use case to use case. Identifying which option best suits your case will be an
iterative process. Increase the settings gradually and then test to review performance with daily, quarter, year-end
volumes. Make sure you test feeding files of different application/ledger combinations in parallel and adjust the settings
accordingly to handle the full load.
Managing the Flow
Start by running the Accounting Hub flow end-to-end and then try running individual steps standalone. Try different
combinations and see which performs best for your own use cases. Some examples are provided in the Use Cases
section below.
If you have multiple files for the same ledger/application (e.g. very large files split in preprocessing) try different options
for the flow:
 Run Import Accounting Transactions in parallel for all the split files without initiating Create Accounting. Then
initiate a standalone Create Accounting with multiple workers to process all imported transactions in one go.
 Stagger submission of Import Accounting Transactions for the split files a few minutes apart and process end
to end.
Environment
Inaccurate table and index statistics can significantly impact performance. To ramp up a fresh environment and ensure
that accurate statistics are gathered, perform three initial runs importing 1000, 10000 and 100000 transactions
respectively. After each run, ensure that all Create Accounting processes have completed and then wait a couple of
hours before initiating the next run.
Make sure you have a concatenated index created on the GL_CODE_COMBINATIONS table. Refer to this note on My
Oracle Support: Tips To Improve Performance For Main Fusion General Ledger Programs (Doc ID 1404390.1).
Adding too many new accounts or cost centers dynamically may affect performance. Instead, for any massive changes
required to the chart of accounts, consider pre-generating code combinations in advance so that the performance of the
accounting process is not impacted. For further information, see How to Bulk Upload or Update Account Combinations
via FBDI (Doc ID 2329461.1).
If planning to load a large amount of data, contact Oracle Support in advance to ensure that disk space is appropriately
allocated. Also, be aware that disk space settings may be reset following refreshes. If performance is a concern for any
planned implementation activity, contact Oracle Support and check that the machine resources allocated are
appropriate for your volumes.
USE CASES
Review the examples in the use cases below and adapt to your scenario. Start with the suggested settings, adjust
gradually and see if performance improves. Look for improvements in time to complete accounting and in the total end-
to-end processing time.
Make sure you track processing time for each test run separately along with issues faced as well as any setup and
configuration changes. Refer to How to track accounting requests.
Use Case 1: Low Volume
You have to load 5 million transactions, spread equally across 10 ledgers, all files arriving at the same time.
Start with the default settings:
Transfer to General Ledger 1 1000
Run Import Accounting Transactions with the default parameters to process the transactions all the way, including
posting the journals to the general ledger.

Use Case 2: High Volume
You have 200 million transactions for a single ledger and application, e.g. having one month’s worth of historical data to
load and reconcile over a few days.
Start with the following settings for your application and ledger:
 Split the data into files of 1 million records each.
 Import 10 files at a time, in parallel.
 Once the first 10 files have been imported, initiate a standalone Create Accounting with Transfer to General
Ledger set to Yes, Post in General Ledger set to No. Using AutoPost instead will potentially preserve resources.
 Import another 10 files in parallel. Try staggering the imports a few minutes apart and see if results improve.
 Continue importing file this way while waiting for Create Accounting to complete.
 Once Create Accounting completes, submit another standalone Create Accounting to process any unprocessed
transactions imported after the previous Create Accounting run had started.
 Repeat until all files have been imported and processed.
 Schedule AutoPost Journals to run every hour during that time to post the resulting GL journals.
Use Case 3: Mixed
You have 20 million transactions across multiple applications and ledgers arriving over 3-4 hours. 15 million transactions
are for one application/ledger. The remaining 5 million are spread across 10 application/ledger combinations.
For the large application/ledger (the one with 15 million transactions), start with the following settings:
For the smaller application/ledger combinations, start with the default settings:
 For the large application/ledger split the data into files of 1 million transactions each and follow the high
volume process from Use Case 2.
 For the smaller application/ledger combinations, follow the low volume process from Use Case 1. Import
Accounting Transactions as the files arrive provided that no more than ten Create Accounting parents are
running at any time. Implement orchestration to facilitate this process.

REPORTING
Determine regulatory, operational, budgeting, and analytical reporting requirements. Use the financial reporting group,
i.e. those responsible for final reporting to management, and regulatory agencies to drive reporting requirements.
Analyze the reporting needs and try to map to existing reports. There is no need to create new reports if comparable
reports already exist. Consider customizing existing reports instead.
Reporting Tools
Reporting requirements differ according to the needs of report consumers in various job functions. For example, a
Finance executive needs professional-quality financial statements whereas a financial analyst needs general ledger
account level reports for variance analysis and account reconciliation. Oracle ERP Cloud provides several reporting tools
for the various reporting needs. Use the following best practices for Inquiry, Reporting and Analysis:
• Use the right tools – users have different reporting needs, e.g. GL account level versus transaction level,
financial reports versus detail analysis.
• Use hierarchies to focus on the right level of reporting, improve performance and usability. Drill down when
necessary.
• Avoid data dump and rebuild reports repeatedly.
• Use standard functionality for inquiry and analysis, e.g. Account Monitor, Infolets, Analysis and Exception
Reports.
• Focus on exceptions rather than review every single line of detail.
The following table outlines available tools in Oracle ERP Cloud for various reporting requirements:
REPORTING TOOL DESCRIPTION CONSUMERS
Business Intelligence Publisher
(BIP)
High volume transactional reporting. There are delivered
standard BIP reports that are accessible from the Scheduled
Processes page. You can also build custom BIP reports.
Most users. Reports are
accessible based on roles.
Oracle Transactional Business
Intelligence (OTBI)
Ad hoc transactional reports with real-time data. Not meant for
high volume reporting or extracting data to external systems.
Most users. Data is accessible
based on roles.
Financial Reporting Studio (FR
Studio)
Financial and management GL balance reports with professional-
quality formatting. Can be used online (drill down support) or
offline in spreadsheet/PDF format.
Senior Management and
External Stakeholders.
Smart View User friendly Excel Add-In for real-time analysis, slicing, dicing
and pivoting on GL balances, drill down capability.
Financial Analysts, Finance
Managers
BI Mobile Apps Designer Custom data analysis based on OTBI. Accessible on mobile
devices.
Senior Management
Account Group / Sunburst Visualize data from different perspectives, trend reporting. Financial Analysts, Finance
Managers, Senior Management
For reports that are based on General Ledger balances using tools such as FR Studio and Smart View, account
hierarchies are used to improve user experience. Maintain the account hierarchies regularly with at least two versions.
This approach ensures that the fully qualified member name is used to refer to the node in the hierarchy in financial
reports. Refer to Oracle Fusion General Ledger Hierarchies: Recommendations and Best Practices (Doc ID 1520970.1).
With hierarchies defined and the tree codes associated with the segments of the Chart of Accounts structure, use the
standard program Generate Financial Reports and Account Groups to create financial statement reports. You can then
leverage the generated financial statement reports as a basis to create additional reports with FR Studio reporting tool.
The Financial Reporting Center provides a single point to access all financial reports built with various reporting tools.
Users can run, schedule and view reports in the Financial Reporting Center. Use tags to group reports to accelerate
search.

Extraction Tools
If you have a requirement to extract the accounted data from Accounting Hub into a data warehouse or third-party
system, then ensure that you allow sufficient time for planning this phase.
Extraction can be a complex process, involving significant development and orchestration to process the data, identify
incremental changes and to move the data to the intended destination. The approach needs to be decided and the
appropriate resources assigned.
Extraction can often take longer than creating accounting from the transactions, thereby constricting the overall
processing window. Therefore, it is important to plan time for implementing the appropriate solution to meet your
requirements and to tune it properly.
There are standard data extract programs available to extract data from Oracle ERP Cloud. The extract process
generates a CSV file for the selected business object that can then be used in a spreadsheet for further analysis. For
high volume data extract to an external system outside Oracle ERP Cloud, use the BI Cloud Connector to facilitate
extracting data from Oracle ERP Cloud. For example, a data extract for a special purpose analysis along with other non-
ERP data source in an external system. The extracted data can be loaded into an Oracle Cloud Storage Service, an Oracle
Universal Content Management (UCM) server, Oracle Analytics Cloud or a custom in-house data warehouse.
Some customers that have extensive daily reporting requirement for a large user base may have concern over the
impact of system processes for reporting on the performance of the production environment. In that scenario, the
customer may opt to contract for Integration Access Cloud Service. Although this scenario is not common, it is an
option for consideration by large organizations.
EXTRACTION TOOL DESCRIPTION
Business Intelligence Publisher
(BIP)
 BIP is not an extraction tool but can be useful for lower volume extracts under 2 million
records. For example, pull summary GL balances to NetSuite GL.
 Allows data extract through View Objects or via direct SQL.
 2 million record limit for CSV output.
Business Intelligence Cloud
Connector (BICC)
 Extracts data using predefined view objects.
 Depending on the columns selected for the extract, BICC will prune the tables used by the view
object. Therefore, smaller sets of columns can improve performance.
 It uses Last Update Date as filter criteria for detecting changes with full table scans on large
Accounting Hub tables. Therefore, performance can degrade over time as data accumulates.
 Suitable for extracting a few million records from Accounting Hub tables that accumulate up to
hundreds of millions of records.
 Rest services available to orchestrate extraction and processing.
Integration Access Cloud
Service (IACS)
 IACS maintains a synchronized replica of the data by exporting the REDO logs and utilizing
Golden Gate technology to keep the data synchronized in real time.
 Intended for high-volume and low latency solutions. Requires additional licenses and Oracle
Executive level approval. Please contact your account manager if interested.

RECONCILIATION
The plan should allow sufficient time for developing reconciliation processes. Policies need to be devised for both daily
and monthly reconciliations, and the plan should allow both time and resources to develop and tune any reconciliation
reports or the required orchestration implemented to help automate the processes.
Ensure that key stakeholders from business are involved to guarantee that their requirements and expectations are met.
There are various points within the Accounting Hub flow where reconciliation should take place. For example:
 Between Source System and Pre-processing Area/PAAS.
 Between Pre-processing Area/PAAS and Accounting Hub.
 Between Accounting Hub and Data Warehouse/Third-Party system.
Reconcile a step at a time and at a high-level, so that issues can be easily spotted. Allow breakdown by a feature that is
significant to the business.
Consider separating daily validation into three parts as shown below:
1. Ensure processing completed successfully.
 Verify all pre-processing programs ran successfully.
 Verify all Accounting Hub processes ended successfully, including all process from UCM upload to
Import Accounting Transactions to GL posting. See How to track accounting requests.
2. Ensure events are successfully accounted.
 Review Create Accounting Execution Report in summary mode for any events that failed.
 Run Subledger Period Close Exception Report to verify that there are no unaccounted events, which
will include accrual reversals. The report also verifies that all Accounting Hub journals are transferred
to GL.
 Run Journal Entries Report with Transfer or Posting Status: Transferred Not Posted to identify
batches not posted.
 Use a management reporting summary segment in the chart of accounts to reconcile to source
systems.
 Resolve all failures, unaccounted events, untransferred or unposted journals. Resolve issues by
correcting Accounting Hub rules or mappings, reverse any incorrect transactions, etc.
 Try to automate the above steps, for example, run the reports in csv output mode, scan results and
send summary notification.
3. Verify control totals between transactions and accounting, ensuring that amounts and counts tally.
 Perform a high-level net verification between source system and Accounting Hub tables. For
example:
o Get net total activity from source system for a given day (i.e. total transaction amount value,
total count of transaction by event type, etc.)
o Create a BI Publisher report to get the same totals from Accounting Hub tables by account
class for a day.
o Make sure totals match within a set tolerance. This will ensure nothing is lost in pre-
processing.
 Create a BI Publisher report to provide amount breakdown further according to your requirements, for
example:
o Show total amount by accounting class, event type, etc.
o This will help to diagnose problems at the next level of detail.
4. Reconcile Accounting Hub with General Ledger
 Use Account Analysis Report to reconcile between Accounting Hub and General Ledger. It shows
opening and ending balances, and period activities.
Other features to consider in the context of your reconciliation needs:
Use the Clearing Account Reconciliation feature for reconciling clearing accounts, including such that are posted to
from different subledger applications, e.g. insurance claims and disbursements. Refer to How Clearing Accounts Are
Reconciled Automatically.
Create Accounting uses Control Reference accounting attributes to check control totals for a transaction by summing
up the line level source values and comparing to the header level source value. In case of a difference, the process
reports an error to indicate a potential data issue – e.g. a missing transaction line. Refer to Accounting Attribute
Assignments: Control Reference.
You may also wish to explore other tools for your reconciliation needs, such as the Account Reconciliation Cloud
Service, part of Oracle Enterprise Performance Management Cloud.

18 DATA SHEET | [Data Sheet Title] | Version [1.02]
Copyright © 2021, Oracle and/or its affiliates | Dropdown Options
CONNECT WITH US
Call +1.800.ORACLE1 or visit oracle.com.
Outside North America, find your local office at oracle.com/contact.
blogs.oracle.com facebook.com/oracle twitter.com/oracle
Copyright © 2021, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only, and the contents hereof are subject to change without
notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties
and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document, and no contractual obligations are formed
either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without
our prior written permission.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of
SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered
trademark of The Open Group. 0120
Accounting Hub Cloud Best Implementation Practices
August 2121

Ahcs best practice_white_paper_1.5 (1)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Ahcs best practice_white_paper_1.5 (1)

Similar to Ahcs best practice_white_paper_1.5 (1) (20)

Recently uploaded

Recently uploaded (20)

Ahcs best practice_white_paper_1.5 (1)