Key Concepts: Account Reconciliation Cloud – Application Design – Pre-Built Formats
As the product adapts to ever-changing needs and grows with ever-more-complex requirements, this series documents the tools available, the questions to ask, and the leading practices that lay the foundation for a successful solution.
Let’s start at the beginning: Application design in Oracle’s Account Reconciliation Cloud.
Recently, I heard of some…“interesting” ideas creeping into the application design discourse of Oracle’s Account Reconciliation Cloud Service solution, and I wanted to weigh in on the conversation. Some of these “interesting” ideas proposed and implemented appear to stem from the application architect’s experience with other Enterprise Performance Management (EPM) products, namely Hyperion Financial Management (HFM) and it’s Cloud counterpart Financial Consolidation and Close Cloud Service (formerly called FCCS), while others demonstrate a misunderstanding of the product’s purpose. Starting the design and requirements-gathering dialogue using familiar terms for your target audience, such as discussing dimensionality or consolidations/aggregations/business rules, can be helpful, but ultimately these concepts do not exist in the same way within Account Reconciliation Cloud. This is not inherently an issue, but these close-but-not-exactly design concepts can fester into incorrect assumptions if left unattended.
A successful solution starts with a sound foundation, and the Account Reconciliation Cloud application is no different. In order to unlock this tool’s potential to streamline your reconciliation process, we must look at the building blocks that distinguish Account Reconciliation Cloud from the other EPM Cloud offerings. Some of these building blocks include:
- System Settings
- Custom Attributes
- Others I haven't thought of yet....
A firm grasp of these unique application components – what they are, how they work, and when you should use the different features – is critical to effective application design. The posts related to the Application Design subseries discuss the different Formats available: Pre-Built Formats, Core Components, and Process Priority in Deployment. This post explores the first of the three Formats: Pre-Built Formats. First, let’s define Formats as they relate to Account Reconciliation Cloud…
What are Formats? The Oracle Help Center defines Formats as the artifacts that “…determine what reconciliations will look like, and the type of information that Preparers and Reviewers can enter.” Formats are a defining aspect of building reconciliation templates and a key component to any Account Reconciliation Cloud application. They contain critical information regarding how a reconciliation is performed and is a required selection when creating a reconciliation. Formats are often utilized across multiple reconciliations, and sometimes across many types of accounts. Therefore, it is common for administrators to use Formats as a mechanism to standardize the end-user experience of working in the application for the subset of reconciliations selected.
To get the ball rolling, Oracle provides many pre-built Formats in the sample application that are immediately available for use. These are quite helpful in demonstrating the various options across a large range of reconciliation circumstances and account types. Below, you’ll learn how to optimally utilize these pre-built options – when they work best, and when you may consider exploring a more tailor-built solution for your business. However, I recommend fortifying your basic knowledge of Formats first with my discussion of core components.
Opening a format for the first time, whether a pre-built one or a completely clean slate, can be a bit overwhelming. There are many options available – tabs within tabs within tabs - and it can be difficult to know where to start. These customizations; however, can be broken down into four core components – 4 cores for 4mats (bad joke…sorry…I couldn’t resist…#notsorry):
- Reconciliation Method
- Display Options
- Standardized Artifacts
- Unique Features
Everything set up in a Format fits into one of these core components. Having a grounded understanding of how each option fits into this framework will greatly improve the efficiency of your application design, creating a purpose-built solution. Each of these are discussed in subsequent posts in the series, and under what circumstances the “I need a new Format for this!” warning bell should go off.
Much of how Formats are ultimately set up in Account Reconciliation Cloud can be traced back to certain process priorities from the business. Most notably, the balance of simplicity versus flexibility plays a critical role in identifying what the ideal deployment should look like. Understanding what the company values should drive all design decisions in order to create the best solution for both today and tomorrow.
Pull up any newly created sample application in your Cloud environment, and you will see a fully stocked arsenal of pre-built Formats covering the spectrum of financial account types. Oracle has done a solid job with keeping their sample applications relevant as new functionality is introduced, such as creating four new sample Formats – TM Bank BAI, TM Clearing, TM Intercompany, and TM Multi Source – when the massively influential 2018 season finale changes rolled out.
[Screenshot 1a: The sample application is created with a list of pre-built Formats.]
When you click through the pre-built Format samples that tickle your fancy (who doesn’t love a good ole’ fashioned bank reconciliation?), you may notice a few differences. The obvious ones will be on the Properties tab which may display different label descriptions, rows indicated to be hidden, or even the subtabs available. The setup of the other main tabs, such as Attributes, Questions, and Rules, may also vary from Format to Format. These nuances across the pre-built Formats spark the imagination of how an application could be setup.
[Screenshot 1b: The pre-built ‘Bank Reconciliation’ Format demonstrates how different Properties can be setup.]
So that’s it, right? Just use the pre-built Formats and you are good to go? You have probably guessed the answer if you have read other posts I’ve authored or watched webinars I’ve hosed – it’s “yes and no!” I know, I know – a “consultant answer.” Hear me out, okay?
The “yes” is because using these pre-built Formats as the basis for creating reconciliation Profiles will not limit your application design. The Oracle documentation says it best: “Formats are designed to evolve. You can start with one set of Formats, and then modify Formats over time as your business changes, or as you become aware of new or different risks.” As I mentioned in the “Modularity in Account Reconciliation Cloud” series, tacking on additional scope, which includes creating new Formats, in a live application is a relatively straightforward change in this tool.
Additionally, the pre-built Formats can be used in application “Quick Starts.” If speed is the focus of the project at hand, then it may make sense to use what has already been provided by Oracle rather than creating a custom solution. The Oracle Support team will have more familiarity with the pre-built artifacts when troubleshooting, and these Formats are fairly straight forward even for newer implementation partners.
However, just because you can use these pre-built Formats and can make changes after-the-fact does not mean that you should have to. My qualm with recommending the pre-built Formats in a live application is that they place a lot of emphasis on account type rather than on reconciliation type. They do an excellent job painting a picture of how Account Reconciliation Cloud can fit in all these different accounting circumstances – bank reconciliations, accruals, inventory, equity – the list goes on and on. The question is: is this functionally how system administrators manage their application? In many cases, these examples are great for product demonstrations but are a less efficient design in day-to-day use.
Understanding what the different Formats actually do and which requirements indicate that new Formats should be built will help create a streamlined application while minimizing administrative maintenance. To this end, let’s discuss what makes the Format a unique artifact in Account Reconciliation Cloud and how we can leverage its strengths to lay an efficient and effective framework for creating reconciliations.
The next post in the series highlights Core Components and focuses on the first of four: Reconciliation Method.
Continue the conversation in the comments down below or join our lively Cloud Customer Connect community forums and Idea Lab.
Product Manager - Financial Close & Consolidations