Blog Series: Can an Asset also be a Liability? Let’s Talk About SAP Asset Retirement Obligation Management (AROM) (Part 1) Details on how AROs work in SAP Asset Retirement Obligation Management (AROM) (Part 2) Details on how AROM Integrates with the Lease Accounting Engine (LAE) (Part 3) How does AROM Integrate with the Accrual Engine (Part 4)
To continue with my ARO blog series, I wanted to now discuss the integration ARO has with the Accrual Engine (ACE). I’ll first go through a quick overview of what the accrual engine is intended to do and then discuss how it fits into the ARO solution.
Â
Quick Overview
The Accrual Engine was released back in 4.7 and functions as a separate ledger dedicated to accrual entries. It is a component of the GL but I don’t consider it to be a sub-module because it doesn’t have the functional depth that something like AP or AR has.
The accrual engine supports parallel valuations which comes in handy with the NewGL and ARO. It calculates the accruals based on the data that is entered and then manages the periodic postings to the GL. In addition to the GL postings, there are unique ACE documents that are created and managed directly within the accrual engine.
As it relates to this topic on ARO, one major design element of ACE was that it was intended to be a generic tool that could be accessed by other SAP solutions, both in ERP or external. It’s possible to manage the accrual objects manually but it can be done automatically by a CRM solution or an ERP one such as ARO. In this way, it acts as an inbound GL data layer so that the other solutions don’t have to directly manage the accruals and reversals with the GL themselves. Lastly, ACE is an engine so it’s not something that you interact with directly. In my case, I’m working with ARO obligations and need the periodic interest accretion postings to be executed… but I don’t have to work directly with ACE.
Â
Integration between ACE and AROM
The biggest benefit that ACE provides to AROM is the periodic accretion postings at month end. I suppose that without it I would have to run a report to figure out the interest expense for each ARO and then prepare a journal entry (or multiple) to get the proper expense recognition each month. That’s what a lot of customers have to do currently when they manage their AROs in Excel! If you have a few dozen AROs then it’s probably not a big deal. If you have a few thousand then it starts to become a bigger effort.
There is also a reporting benefit to the integration between these two areas. One of the ARO reports (future blog) reads from some of the ACE tables as well as the ARO ones so that you can get an actual/plan type of report for interest expense.
Another benefit is that ACE handles all of the posting logic for the periodic accretion run. If/when the ARO values are changed at a later date, the change in the monthly cash flow is passed over to ACE and it is ACE’s job to determine the delta amount based on what has already been posted to date.
As mentioned in the previous blog regarding LAE, it is LAE that is facilitating a lot of the data transfer from the obligation in ARO to the accrual engine so that it can make the FI posting.
Â
How does it work?
The accrual run works similarly to a lot of other FICO periodic programs in my opinion. There are some basic selection criteria, a report output that shows what was posted, and a log available to make sure that you execute the report in a consistent manner.
First, the selection screen. You can execute it based on the items shown below. The most important items to zero in are:
- Key Date – This is the posting date of the accrual run. The date entered needs to be consistent with the ACE posting control configuration. It’s customary to make this posting per fiscal period so the date must be period end. It’s also possible to make it quarterly, annually, monthly, or daily.
- Execution Type – There are three types and they are similar to how RAPOST2000 works… probably because both programs want you to post to the next available period and do so in a sequential or orderly manner.
- Normal – This is the most frequently used option and is the default value. With this selected you have to post to the next available month as determined by the posting control configuration mentioned above. Example: if the solution has been configured for fiscal period postings and you’ve made the posting for period 6 then you have to make the next posting to period 7. You can’t re-post period 6 or jump ahead to period 8…12. Only period 7 is an option.
- Repeat – This is used only if the previous accrual run was not fully posted for all accrual objects. If there were errors in the previous run or if the selection criteria did not include all available accrual objects then a repeat run for the same key date would be required.
- Unscheduled – This allows you to skip the natural sequencing of the key date logic. Example: if you forgot to run the job for period 2-3 and those periods are now closed, you could execute it for period 4 as an unscheduled run.
Here is the output. For AROM it will output each obligation and the amount of the accretion expense that will be recorded in FI. There are additional fields in the layout that show the total accrual amount, remaining amount, and some statistical posting information.
I wanted to mention one last thing about the program. You might have noticed in the first screenshot but there is an ability to reverse the accretion expense.
These documents can be viewed in the GL in the appropriate expense account but also within ARO on the specific obligation. If you navigate to the ARO Explorer you can see the interest expense for each period per ARO. If you go back to the report output up above, the first ARO is about to recognize $437.22 in accretion expense for this period. Pulling up the same ARO I can see the same $437.22 as well as the aggregate life to date amount of $84,340.09. There are more items to explore there but that will be another blog.
