Many companies face a new requirement to manage and create financial statements for more than one fiscal calendar. This requirement can be driven by local accounting rules or tax laws and requires a full set of financial statements in both fiscal calendars.

One example is a multinational company doing business in Japan and using a 4-5-4 fiscal year for its consolidated financials. Japan Generally Accepted Accounting Principles (GAAP) reporting requires the company to produce financials on a January to December calendar as well. The SAP General Ledger can manage multiple fiscal years through the implementation of leading and non-leading ledgers. This scenario is set up with the leading ledger using the 4-5-4 fiscal calendar and the non-leading ledger using a January to December calendar.

The system automatically maps the postings to different fiscal periods and years by ledger. Reporting by ledger is standard and allows for easy creation of financials by ledger or fiscal calendar. If you aren’t using Asset Accounting in your SAP system, then your solution is complete. However, if Asset Accounting is part of your SAP solution, then there are additional considerations.

Asset Accounting in an SAP system cannot manage multiple fiscal years with differing beginning and ending dates in one company code. This has been a limitation since the beginning of SAP Asset Accounting and hasn’t changed with the SAP General Ledger functionality. If a company faces the dual calendar requirement, Asset Accounting is usually the most crucial piece when producing two sets of financial statements.

When an asset is retired, sold, or transferred from a company, the proportional depreciation is calculated using the convention of the applicable standard (e.g., US GAAP). The proportional depreciation can differ by fiscal calendar depending on the depreciation rules for the relevant GAAP. The proportional depreciation is calculated based on the fiscal year calendar of assigned company code, not the general ledger (G/L) to which it is posted. Therefore, a standard SAP system cannot satisfy the requirement because the differing valuation isn’t as simple as mapping the periods.

What Tool Is Available to Meet the Requirement?

To alleviate the issue in Asset Accounting, SAP introduced a Repeatable Custom Solution (RCS) called the Multiple Calendar Tool. This tool requires a second company code to be set up for each original company code. The secondary company code is assigned to the alternative fiscal year (e.g., January-December). Because the second company code is assigned to the alternative calendar, all asset activity is calculated and posted using that calendar. The calculation and postings in the secondary company codes use standard functionality in Asset Accounting. The Multiple Calendar Tool is used to automatically replicate asset master data and transactions into the secondary company codes.

The tool replicates the asset accounting master data creation and changes most postings from the original company code (OCC) to the secondary company code (often referred to as the mirror company code [MCC]). The Multiple Calendar Tool allows mapping of asset classes and master data from the OCC to the MCC. The system is configured so that the asset numbers are the same in both company codes. Most of the fields on the asset master record can be mirrored to the asset in the MCC. Most transactions are also mirrored to the asset in the MCC. The activity is done via an asset mirroring program that can be run on demand or scheduled as often as needed (Figure 1). Most users run the program on a weekly basis to keep the companies as closely synchronized as possible.

Figure 1

Mirroring of an asset data program

The Multiple Calendar Tool is configurable to choose which fields of the asset master record are transferred to the asset in the MCC. It also allows for mapping to differing asset classes if required. The transactional data is also configured to be mapped to the MCC based on the transaction type of the OCC asset. Not all fields and transactions are mapped to the OCC. Examples of master record fields that aren’t transferred are the Acquisition Year and Period. These fields are calculated based on the fiscal year assigned to the company code and the initial posting date. The fields aren’t transferred because the values for these fields differ between the OCC and MCC asset.

The mirrored asset data in the MCC uses standard functionality for all asset accounting calculations and postings. The asset values of each company code are updated to the non-leading ledger with the shifted calendar values using the same G/L accounts as the OCC. All asset and SAP General Ledger periodic processes must be completed in both company codes. Monthly and year-end activities must be executed independently in both the OCC and MCCs. This is logical, as these company codes have differing close schedules for the fiscal year and period (depending on the fiscal calendar).

How Are Financial Statements Created with Different Company Codes?

Once the OCC asset master data is copied to the MCC and transactions are posted, the full financial details are in the OCC’s non-leading ledger. However, these details include the proportional depreciation postings based on the original fiscal calendar. These values are incorrect in the non-leading ledger. SAP’s Multiple Calendar RCS tool enables you to complete a step, called the G/L Balance Transfer. This step of the solution posts the balances of the asset relevant accounts back to a second set of accounts in the non-leading ledger of the OCC.

This program must be run at month end prior to financial statement creation. Proper financial statements can only be created through the use of calendar-specific Financial Statement Versions. The original fiscal calendar must include only the original accounts and exclude the duplicate accounts updated by the G/L Balance Transfer (Figure 2). Transaction code /MTO/TRANSFER is added to your system with the Asset Accounting Multiple Calendar Tool to access this screen.

Figure 2

The G/L Balance Transfer program

Once the MCC is entered, many of the other fields default. The fields for period, year, and posting date must be populated for each run. The Number of Lines limitation is used to avoid overflow of the 999 line limit. The alternative fiscal year financial statements include the alternative asset G/L accounts and exclude the original accounts. Special consideration must be taken for retained earnings (RE) because the year-end process updates RE and includes relevant profit and loss (P&L) accounts (some of which are duplicated as part of the G/L Balance Transfer).

Transactions Not Included in the Mirroring

The Multiple Calendar Tool replicates most asset transactions, but it excludes some because of differences in the values that will be posted in the alternative fiscal year. A simple example is a write-up. Write-ups adjust depreciation values on an asset. The OCC and MCC might calculate depreciation differently because of a difference in the number of fiscal periods for that particular fiscal calendar. Therefore, mirroring such activity doesn’t make sense. In these cases the asset activity is manually replicated into the MCC, which allows the user to adjust the depreciation values as needed. The Multiple Calendar Tool provides a concise list of master and transactional data not mirrored. This simplifies the manual effort required in these unique scenarios.

Controlling Objects and the Dual Calendar

Cost and profit centers are assigned to a controlling area, which is assigned to a fiscal calendar. Therefore, the cost and profit centers assigned to the OCC’s controlling area cannot be assigned to MCC assets. The standard RCS program cannot mirror the cost and profit center fields of the asset master because the MCC is not assigned to the controlling area to which the cost and profit centers belong. Therefore, asset postings in the MCC cannot include the cost or profit center that impacts basic cost and profit center reporting on asset postings. There are two options to resolve this issue and report the MCC activity by cost object.

CO Option 1: Duplicate Controlling Areas

A second controlling area can be created and assigned to the alternative fiscal year calendar. The second CO area is assigned to the MCC and all cost and profit center data must be created in the duplicate CO area. All future creation of or changes to cost and profit centers in the original CO area must be replicated to the duplicate CO area. The profit and cost center data on the asset master records can then be mirrored, and the standard AA functionality posts all relevant transactions with the cost and profit centers from the duplicate CO area in the MCC. The advantage of this solution is that it uses standard functionality and requires no additional investment or custom functionality. The disadvantage is that synchronization of CO data is required. This option is viable for smaller companies that have limited CO data and seldom make changes to the CO data.

CO Option 2: SAP Custom Development Add-On

SAP sells an add-on tool to the Multiple Calendar Tool that allows creation of asset master records using the cost and profit center in the MCC assets without having a duplicate CO area. The functionality is often referred to as Pseudo-CO. It achieves asset postings in the MCC with the CO objects from the OCC without replicating or synchronizing CO data.

The solution uses custom fields on the MCC asset master record to store the mirrored cost and profit center from the OCC asset. It also has custom logic to use these custom fields when posting asset transactions to the G/L. The coding block of the G/L is expanded to include the fields. Standard reports also use the fields, so reporting of the alternative calendar values by CO object is easy. Lastly, the custom field values are transferred to the standard cost and profit center fields when the G/L Balance Transfer of the NLL values from the MCC back to the OCC is run. Finally, the correct values by CO object are available in the OCC in the non-leading ledger. Therefore, financial statements by CO object can be created using the alternative calendar values.

The primary advantage of this option is that the solution is proven, simple, and supported by SAP. There is no need to synchronize duplicate data across CO areas. The disadvantage of this option is the additional investment required to purchase the Pseudo-CO solution. Large companies with lots of cost or profit centers can benefit most from this solution.

Multiple Calendar Tool Implementation Impacts

The Multiple Calendar Tool requires special implementation considerations. The conversion of asset accounting master data and G/L balances must accommodate both the OCC and MCC. The asset master conversion balances must be shifted to match the alternative calendar. The proportion of current and prior year amounts for each asset differs by fiscal calendar and is not automatically adjusted during conversion. Conversion of G/L balances into the MCC only applies for Asset Accounting relevant accounts.

Testing of the RCS mirroring is critical to a successful implementation. The mirroring of transactions is dependent on the relationship of the calendars as well as the nature of the posting. For example, a post capitalization in one calendar might be a current year acquisition in an alternative calendar. Therefore, every permutation of calendar and activity must be carefully considered and tested through the multiple calendar processes to ensure the expected results are achieved.

The Multiple Calendar Tool from SAP solves the requirement to create financial statements or tax values in more than one fiscal calendar. The tool replicates asset master and transactional data into duplicate company codes. The duplicate company codes can calculate and post assets in the alternative calendar to meet the financial requirement. The standard tool is limited as it relates to CO, but there are options to mitigate this limitation. Lastly, the tool itself is easy to install, but implementation considerations are complex and require in-depth knowledge of asset accounting and the SAP General Ledger in an SAP environment.