Key Concepts: Account Reconciliation Cloud – Application Design – Unique Features

Published February 4 2020 by Nick Boronski
Back to insights

Core Components: Unique Features

Now that we covered in the previous post how setting up Standardized Artifacts in Formats can simplify the administrative maintenance for the application while providing the end user with a seamless experience, it’s time to round out the fourth core component:  Unique Features.  These “bells and whistles” – settings, properties, and functionality - are unique to Formats and come in a variety of flavors, two of which are identified even before selecting a Method: the “Require 0 unexplained difference” checkbox and the Questions tab. These are fairly self-explanatory: the former prevents the reconciliation from being submitted if there are any unaccounted for differences, and the latter provides a unique tab on the reconciliation to ask either optional or required questions based on security role (i.e. Preparer questions, Reviewer 1 questions, etc.).

While these features provide an “easy button” for setting up an application, they are “nice-to-have” vs. “need-to-have.”  Since there are no filterable criteria on when these two features are used, it necessitates a new Format be created if it applies to one type of reconciliation and not another. Using the “Require 0 unexplained difference” property provides a straightforward example. If this level of strictness is required for one type of account but not another and an Administrator wants to use this unique Format feature, each account will require different Formats. Therefore, many application designs ultimately elect to replicate these use cases through Custom Attributes and Rules instead.

[Screenshot 1a: The ‘Require 0 unexplained difference’ checkbox and the Questions tab are unique features to Formats]

The other unique features are a bit more hidden but play an important role in streamlining the end-user experience and ensuring that completed reconciliations follow compliance policies. As mentioned previously, different subtabs will populate depending on which Method is selected. Selecting any of the subtabs will reveal the best kept secrets: Action Plan and additional Rule options.

[Screenshot 1b: All subtabs, regardless of which Method is selected, contain three additional sections: Transaction Detail, Action Plan, and Rules]

Let’s start by discussing the latter: Rules. For clarity, these will be referred to as Transaction-level Rules, since they strictly affect the reconciliation detail, called Transactions in the application. The drop-down list shows the options available for ensuring quality control on the adjustments and explanations made by Preparers. The Prevent and Require transaction-level Rules function similarly to the Format-level Rules, except in reference to individual transactions rather than to the reconciliation as a whole.

These are very useful but the “gold” here is the first rule listed: Copy Transactions from Prior Reconciliation. Out-of-the-box, Preparers have the ability to click on a button to pull some or all of the transaction detail from a prior Period. But who wants to click a button when it can be done automatically, and only when the criteria YOU set is met? Having these transaction-level Rules set per transaction type is useful as well. Most commonly, I see this type of Rule only set on “Subsystem Adjustments” (for Balance Comparison) and “Balance Explanations” (for Account Analysis). “System Adjustments” are typically (or should I say “hopefully”) reflected in the general ledger loaded balance in the subsequent period, and “Variance Explanations” (in Variance Analysis) can fluctuate and change over time. Therefore, automatically copying the transactions forward in these latter cases can create more work for the Preparer rather than streamline the process.

[Screenshot 2: Transaction-level Rules can ensure quality control on transactions prepared]

The second hidden gem under the subtabs is Action Plan. Like with transaction-level Rules, these are enabled per transaction type.

[Screenshot 3a: Action Plans are enabled per subtab / transaction type]

Enabling this feature creates a new available Action Plan tab on each transaction created. This provides Preparers with a defined place to answer every Administrator’s burning question: “So, how exactly is this reconciling item going to be resolved?” Furthermore, Rules can be customized to require that an Action Plan be submitted along with the reconciling item (*insert evil laughter* - but seriously, this is awesome). Action Plans can be a powerful tool to ensure that the application becomes an agent for business process change and improvement, rather than just for tracking.

[Screenshot 3b: Action Plans can be input on a per transaction basis to ensure that Preparers are actively working on resolving reconciling items]

Now that you have a more grounded understanding in the four core components that drive Format design, it is time to make some decisions on how to craft the Application Reconciliation Cloud application to best suit your business needs. The final post in this blog series details the two main “camps” your Format design will fall into – a focus on flexibility versus simplicity – and what these types of solutions could look like for you.

For comments, questions, or suggestions for future topics, please reach out to us at  Visit our blog regularly for new posts about Cloud updates and other Oracle Cloud Services such as Planning and Budgeting, Financial Consolidation, Account Reconciliation, and Enterprise Data Management.  Follow Alithya on social media for the latest information about EPM, ERP, and Analytics solutions to meet your business needs.

Product Manager - Financial Close & Consolidations

Contact us