SAP R/3 4.7 has a functionality to help you calculate and post month-end accruals within R/3. The Accrual Engine can help create, calculate, and manage all of your accruals for processing, which saves precious time during month- end close. I will examine the Accrual Engine and what it offers compared to R/3's accrual/deferral feature.

R/3 provides functionality for entering, posting, and the subsequent reversal postings of those accrual entries using the accrual/deferral feature. However, this functionality doesn't differ much from creating a normal journal entry. The two main differences are that when you use the accrual/deferral feature, you enter a reversal date on the entry (created using transaction code FBS1), and R/3 generates reversal postings using program SAPF080R (transaction F.81).

The accrual/deferral feature does not, however, calculate the amount entered in the accrual postings. It allows for entering storage of the amount, accounts, and cost objects impacted and automatic reversal on a specified date, but cannot calculate the accrual amount if it changes each period.

For example, if fringe benefits are accrued at month-end and the amount of fringe benefits depends on the amount of salaries as well as headcount, the accrual/deferral entry must be manually changed at each period-end in order to reflect the correct amount. As a result, many companies calculate the accrual amounts outside of R/3.

The Accrual Engine

The Accrual Engine essentially functions as a separate ledger for accrual entries within the FI module. The accrual/deferral entries are entered, managed, and processed within the Accrual Engine. In addition to the G/L documents, the engine creates separate documents for entries that are processed internally. The results are then passed on to the FI module. The reversal process occurs similarly.

At month-end, processing takes place within the Accrual Engine itself. The accruals can be checked or simulated and their results validated prior to their posting within the G/L.

Many clients whom I've assisted over the years want a feature that can determine accrual amounts based on posted data. R/3 provides some of this functionality with other features, such as its Revenue Recognition tool, but this is lacking in the Accrual Engine, which may be a key sticking point with some SAP customers.

Processing Accruals

Processing accruals within the Accrual Engine occurs via periodic processing runs, which are managed by company code and can be managed by an accrual type. The accrual type is a key feature used within the Accrual Engine that groups accrual entries for the purpose of managing and processing the entries.

As an example, consider a monthly accrual for electricity. Accrued electricity expenses can be grouped with other utility expense-related accruals, such as telephone expenses, into a utility accrual type (Figure 1). You can process this type for posting as a whole.

Figure 1

Process utility accrual types

The engine creates each accrual entry (via transaction code ACACTREE01) as an accrual object and assigns it to an accrual type. The accrual type within the engine manages the processing of the accruals. You only need to enter the lump sum of the entire amount to be accrued, because the accrual method (defined within configuration) specifies how the amount is to be broken down and posted to the individual periods.

In addition, you can break down the entries by cost object (i.e., cost center, internal order, etc.). For each entry, you specify the amount, quantity, and accrual method, as well as the cost objects for the postings.

In Figure 1, an accrual type for utilities expenses contains two accruals: one for electricity expenses and the other for telephone expenses. When you select the accrual object, the Accrual Engine displays the details of the entry and the proposed postings.

Once the accruals are defined, they are processed in a posting run and posted to FI using transaction ACACACT. This process is similar to executing a depreciation run in that only one planned accrual run can be executed per fiscal period. After the accrual is posted to FI and CO, the details are shown on the Posted Totals tab (Figure 2). Then the reversal process occurs by calling transaction ACACREVERS to post the reversing entries in subsequent periods.

Figure 2

Details of the planned accrual run on the Posted Totals tab

Key Features and Configuration

Some customization must be performed in order to use the Accrual Engine, the key components of which are described here. First, you must assign the company codes to the Accrual Engine.

As described earlier, you organize accruals into accrual types within the Accrual Engine. This helps with processing and account determination. You then can configure all accruals within an accrual type to post to the same set of G/L accounts and document types, while other accrual types (such as ones defined for insurance, salaries, fringe benefits, etc.) are posted to different G/L accounts and document types. The benefit of this configuration is that you do not need to maintain individual accrual entries to set or maintain the G/L accounts to which they post. In effect, you are saving a methodology for managing and creating the entry, rather than saving an entry. Therefore, if the accounts change, you simply change the account determination, not every individual entry.

The accrual method defines how the amount of the accrual should be spread over the life of the accrual. R/3 provides standard methods to calculate amounts using methodologies such as straight-line or declining-balance. Additionally, you can define a custom function module to calculate the accrual breakouts by fiscal period. Ultimately, the accrual method feature provides the ability to create a custom calculation for the monthly amount for the accrual entry.

The Accrual Engine can determine the G/L accounts and document types used for posting accruals using the values of other fields. It can also define different G/L accounts for opening and closing postings (separate and apart from the normal month-end postings). Also, the Accrual Engine can use different G/L accounts (and document types) for different accrual types, as described earlier. It can use symbolic account determination for further flexibility within G/L account determination.

As with any other subledger used within the FI or CO modules, you must configure number ranges for Accrual Engine documents, logs used when processing the accruals, as well as the accrual posting runs themselves. See Table 1 for a summary of features that the Accrual Engine and accrual/deferral entries provide.

Features Accrual Engine Accrual/deferral feature Program to auto-reverse accruals Separate accrual ledger   Ability to manage/analyze accruals by type   Function module in which to calculate accruals   Flexible account determination
Table 1	Characteristics of the Accrual Engine and accrual/deferral feature

When deciding whether the Accrual Engine is right for your business, keep in mind the extent of functionality that you require for your accrual postings. You may want to consider that the Accrual Engine creates separate documents and must be managed like a separate ledger. It also provides for the management and analysis of accruals by type.

The Accrual Engine can provide assistance through the customizable function module when the calculation of accrual amounts is a cumbersome, offline process or when retrieving and calculating data requires a significant effort. Reviewing your requirements with regard to what the functionality offers will enable you to determine whether the Accrual Engine or accrual/deferral feature is the right solution for automating accruals in your accounting department.