Introduction
I will start by giving you a bit of background on New Asset Accounting and S/4HANA, and then I will run through some of the key changes that were introduced which distinguish it from Classic Asset Accounting. Next, I will go into some more detail on some of the larger areas, for example how the depreciation areas work with the ledgers to record the different accounting principles. You may already have heard of the Universal Journal, which is one of the biggest innovations in Finance in S/HANA. I will explain what that is and how New Asset Accounting integrates with it and how the new asset transactions work. I will also run through the depreciation and finally I will briefly touch on the migration of assets.
Background
The first version of New Asset Accounting was actually introduced in 2013 on SAP ECC6 Enhancement Pack 7. So, if you’re not on S/4HANA but you’ve already implemented the New General ledger, you can still get New Asset Accounting, although you need to activate some business functions first and you won’t have the full functionality until you are on S/4HANA.
Initially the SAP Business Suite simply ran faster on the new in-memory HANA database, with its super fast processing speeds. With S/4HANA, SAP has rewritten and partly redesigned some areas to take advantage of the increased power and to run with greater efficiency.
New Asset Accounting is one of the areas that was further optimized to run on S/4HANA with additional functionality and a new data structure along with full integration to Finance via the Universal Journal and the ACDOCA table.
Only the New Asset Accounting and the New General Ledger versions are available on S/4HANA. The New General Ledger is now officially called the SAP S/4HANA General Ledger, by the way. You don’t have to implement all the functionality of either, but you won’t be able to use the old classic versions any more on S/4 HANA.
The actual components of the asset module haven’t changed much, so you still assign your company code to a local chart of depreciation where you have most of the local rules for calculating the depreciation, such as straight line or reducing balance methods, and whether to start depreciating at the beginning, middle or end of a period and so on. The account assignment, screen layout and default useful lives are still linked to asset classes, which group together assets of a similar nature, and you still have the concept of depreciation areas to record different values for different accounting principles.
However, there have been many improvements in different areas and a much tighter integration to finance, which you can see straight away if you are migrating fixed assets from a legacy system. You no longer post the asset master data and values together and then later post a summary journal to finance. Now, similar to the accounts payable and accounts receivable sub-ledgers, you create the master data first and separately post the value to the asset and simultaneously to the general ledger.
Key Changes Introduced with New Asset Accounting
The reason that the asset value can be posted to the asset and to the general ledger simultaneously is because most of the asset value tables have been replaced, and both the asset and financial actuals are now held in a single table in Finance, the aforementioned ACDOCA table.
A common phrase you may hear a lot in relation to S/4HANA is the Single Source of Truth. In S/4HANA, Finance and Controlling have been merged; and Asset Accounting and even Profitability Analysis all create entries directly to the ACDOCA table in Finance. In other words, you now have everything in one place.
Additional accounting principles no longer have to be posted periodically; instead all accounting principles post real-time and at the same time. Because the accounts are reconciliation accounts in all ledgers, you can’t post only to the general ledger and not to the asset. Altogether, this means that you how have everything in sync with everything else, which has got to be one of the biggest advantages, especially for us accountants.
In addition, asset postings are transferred to finance at asset level and more asset information is now available in finance, so you can run financial reports by asset number for example in the general ledger line item display transaction. You also don’t have to wait until the period end to see values in the parallel ledgers, and even the planned depreciation is always up to date.
The table in Figure 1 shows some examples of transactions that have changed with S/4HANA. Although many of you will be using Fiori to access the S/4HANA transactions, particularly if you are using the public Cloud version of S/4HANA, quite a lot of the S/4HANA transactions are very similar whether you are using the SAP GUI or the Fiori equivalent. I thought it would be easier to show the transaction codes so you could compare the ECC transactions and see what has changed. Also, I’m sure some of you will still want to explore the SAP GUI transaction codes on the on-premise version, even if you have Fiori, or intend to implement Fiori later.
Figure 1 Asset related transactions that have changed with S/4HANA
As the asset and general ledger values are now in the same table (ACDOCA), the consistency and reconciliation transactions are now obsolete and do not even exist in S/4HANA. All ledgers post real-time, so the periodic posting transaction is also now obsolete. One of the migration prerequisites by the way, is to complete all periodic postings before the migration, as you won’t be able to post them afterwards without that transaction.
Prior to S/4HANA, in a legacy migration, after you had uploaded the asset master data and the related values to asset accounting, you could then use Transaction OASV in order to post those values to the general ledger. Now, as both the asset and the general ledger are posted to simultaneously, this transaction is no longer required.
The legacy Transaction AS91 can no longer be used to post the values to an asset, but you can still create the master data with it and post the values to both the asset and finance with Transaction ABLDT.
The post depreciation transaction AFAB, like the calculate planned depreciation Transaction AFAR has the same transaction code but there is a different program underneath and a slightly different selection screen. I will explain these differences in the depreciation section shortly.
Finally, a number of transactions now contain an L at the end to signify that you can post to different ledger groups, for example ABAA is now ABAAL. In fact, if you try to select the old code on S/4HANA by mistake, you will see that you have been redirected to the new code anyway. Previously, you had to set up specific transaction types if you wanted to post to one ledger and not another.
Depreciation Areas and Ledgers
In Asset Accounting, different accounting principles are managed by setting up different depreciation areas. In the next sections, I’ll explain what has changed with S/4HANA, and show how the depreciation areas and ledgers work along with an example at the end.
Originally the only way to record different accounting principles in Finance, for example local GAAP and IFRS or Group Accounts, was to use different number ranges in the chart of accounts. When the New General Ledger was introduced in SAP, your main ledger then became your leading ledger and you could set up parallel ledgers with identical GL accounts instead of using different number ranges. Most postings would update all the ledgers together, but if the accounting treatment for something was different in one of the parallel ledgers, for example an accrual, you could post an adjustment just to that ledger, by selecting its ledger group in the transaction.
Depreciation area one posted to the leading ledger real-time and you could map the other depreciation areas to the parallel ledgers and post them at the end of the period; but for technical reasons you also had to create delta depreciation areas.
With S/4HANA, in order to map a depreciation area to a ledger, you assign an accounting principle to the depreciation area in the asset accounting configuration. You also assign an accounting principle to the ledger group in the financial configuration, you will see this in Figure 2.
You still have the option to use the accounts approach or the ledger approach for your different accounting principles. The accounts approach may be a better choice if you have only a few differences between the two accounting principles. However, in S/4HANA, you still have to assign a ledger group to each accounting principle in the configuration, even though each ledger group will contain only the leading ledger as you won’t have any other ledgers with the accounts approach.
You also no longer need delta depreciation areas, but, if you want to have additional currencies in one ledger you have to set up additional depreciation areas for those currencies in the asset module.
Figure 2 shows one of the configuration steps of an example US company code with a European Head Office. The depreciation areas are shown in the first column on the left. Depreciation Area 1 contains the US asset values and depreciation in USD, and posts real-time to the leading ledger 0L. Depreciation area 30, which posts real-time to the parallel ledger 2L, is also in USD but because of different capitalization rules and useful lives, some of the assets will have slightly different values in accordance with the European Head Office policies.
Both ledgers have USD as their company code currency and EUR as the group currency, so additional depreciation areas 31 and 32 are required for the EUR. As you can see, other asset valuations are recorded for tax and other purposes, but not posted to the general ledger.
When you assign the accounting principle to each depreciation area, it then pulls in the target ledger group that is assigned in the financial configuration, to that accounting principle. Usually there is one ledger in the group with the same name as the ledger group.
Figure 2 Depreciation Area Configuration for an example US Company code
All depreciation areas are now equal, which means that you can choose any depreciation area to be the main accounting principle and linked to the leading ledger. More than one area can be set to post real-time to both the asset and to the general ledger, and you can choose which depreciation area updates quantities.
Integrated Asset postings and the Universal Journal
The next section is about how New Asset Accounting integrates with Finance. I’m going to start by explaining the new table structure and the Universal Journal and then I’ll introduce something called the “Technical Clearing Account” which basically makes the real-time postings of different amounts to different ledgers possible.
Because of the power of S/4HANA, you no longer need to split data into a number of tables with additional totals tables and special programs for managing and storing the indexing, summarizing and aggregations etc. The actual data from the various asset value tables can now be stored in the single finance table ACDOCA, with the header data in BKPF, and the statistical, planned and year dependent data stored in the other tables in Figure 3, for example FAAT_PLAN_VALUES.
Don’t worry though, if you have a lot of bespoke programs which use the old tables. Although the old tables no longer exist, the programs will still work, as long as you are just reading the tables and not writing directly to them. This is because of something called compatibility views. These are views, which are recreated from the new tables such as ACDOCA, but linked to the old table names such as ANEP, ANEK and so on, so you can still read the data, but you would not be able to update anything in that view.
Figure 3 New table Structure in New Asset Accounting
The Universal Journal
The Universal journal is the underlying comprehensive document for all postings to finance. It is not a separate transaction as such and you wouldn’t immediately notice a difference if you were posting a journal or a customer or supplier invoice, but the different table that is updated in the background is ACDOCA which now contains all sorts of additional information from the different modules, not just asset accounting. As mentioned, it doesn’t just make all the index and totals tables obsolete, but contains for example characteristics and segment numbers from account based profitability analysis, material information from the material ledger, and additional costing, purchasing and sales information as well.
The Technical Clearing Account is a new account that has been introduced for accounts that cannot be posted to in a single ledger only. If you’ve set up parallel ledgers in the New General Ledger, you will know that there are certain accounts that the system will not let you post to in one ledger and not another. If you receive an invoice from a supplier for 100 dollars, you cannot record it against that supplier as anything other than 100 dollars in all ledgers and the amount you pay against it will be the same in all ledgers along with any related taxes. By the same logic, the GR/IR accounts (where you post the goods receipts and invoices received) and the customer accounts have to be posted to all ledgers at the same time as well.
In S/4HANA, when you have an integrated posting in asset accounting, such as an asset acquisition with a posting between the asset and the supplier for example, or between the asset and the GR/IR, you have to post the supplier or GR/IR side the same to all ledgers but you may want to post the asset side, differently, for example to a different account.
You can see in the Figure 4, that the Technical Clearing Account allows you to do this by posting the first document to all ledgers, crediting the supplier and debiting the technical clearing account. This is called the operating part of the posting. Then you can post the other side in two separate documents one to each ledger. This is called the valuating part of the transaction. The valuating part credits the technical clearing account and debits the assets separately for each ledger, or posts to costs instead. An additional posting is required if for one ledger, you need to post for example to freight, or legal fees or whatever the policies of the other accounting principle requires.
Figure 4 The Technical Clearing Account
The Technical Clearing account is a reconciliation account and works in the same way for both account and ledger approaches, and you can also have more than one technical clearing account. It is defined in the configuration by Chart of Accounts and account determination, so you could have a different account by asset class assuming your account determination is mapped closely with your asset class.
This is different to the normal clearing account for asset acquisition which still exists and behaves in the same way for transactions such as the acquisition ABZON where there is no automatic offsetting account.
An example of a non-integrated asset posting, where the technical clearing account is not used, is the settlement of line items from an asset under construction to the final asset.
Figure 5 shows that you can still create different settlement rules, for example settling to an asset in the leading ledger 0L, but settling to a cost center for the parallel ledger in this case ledger 2L.
Figure 5 Settlement of line items by ledger group
You can no longer set a transaction type to be ledger specific. Instead you can select the ledger by choosing the depreciation area or the accounting principle in the new transaction codes, for example Asset Retirement by Scrapping, Transaction ABAVL.
Figure 6 Transaction Types are no longer ledger specific
Because Finance and Controlling are merged in S/4HANA, there are no more cost elements. instead, the chart of accounts master data contains a new field for the P&L cost element categories. However, this does not include cost element category 90 which was used for statistical postings to the Balance Sheet so that you could link internal orders and WBS elements to balance Sheet accounts. Instead we have a new check box in the chart of accounts to allow you to apply account assignments statistically in the fixed asset accounts and the material accounts see Figure 7.
Figure 7 Statistical Postings Check Box in GL Account Master Data
How Depreciation runs in New Asset accounting
Now we come to the depreciation programs. There are a few changes in this area, for example speed, different selection screen options, and under the hood (or bonnet in the UK) there is a new Depreciation Calculation Engine, which you may have heard of and be wondering what it does.
The planned depreciation is updated every time an asset transaction is posted, or a change made. Therefore, the asset explorer and asset reports will always show you up to date values. At the end of the month, when you run the depreciation transaction, it should be quicker as it is simply posting the already calculated planned values. The system still posts collective documents for depreciation, not one document for each asset, but it does post a separate line item in the general ledger for each asset, giving you more detail than before for reporting in Finance.
The first thing you will notice when you enter the depreciation transaction AFAB, is that the selection screen is simplified, as you can see in Figure 8. Previously, if I had to rerun the depreciation in a particular period, I always had to think for a minute which button to choose, now the system figures it out automatically.
The second point is that you can still run the depreciation for all accounting principles at the same time, or you can choose to run it for the different accounting principles separately.
I find the new icon at the top of the screen, called “info for posting parameters”, particularly useful in test environments, so that I can quickly find when depreciation was last posted.
Figure 8 Depreciation Transaction AFAB -Selection Screen
The main difference in S/4HANA for transaction AFAR, the calculation of the planned depreciation, and Transaction AFBP, the depreciation posting log, is again the option to run by accounting principle. In the depreciation log, when you run the transaction, you will see a button marked “Notes on Use” at the top, which explains in detail the additional functionality.
The New Depreciation Calculation Engine
The New Depreciation Engine was designed in order to cope with some country specific requirements, in particular I believe for Japan. It introduces new options, for example to changeover the depreciation method mid-year automatically, and for calculating depreciation after impairment.
Previously depreciation was calculated on every transaction line item sequentially, with the annual depreciation being the total of the line items, so for example you have the depreciation for the whole year calculated on the first acquisition value. Then if you have a disposal mid-year you would deduct half a years’ depreciation on the disposal amount. Finally, if you then had an addition to the asset near the end of the year you would add on the depreciation for that acquisition just for those remaining months.
Now, as you can see in Figure 9, the transactions are grouped by period and the depreciation is calculated based on periods. So, in this example, instead of calculating depreciation on the original amount of 1,000 for the whole year and deducting and adding retirements and additional acquisitions, you take the balance of each period and calculate it separately.
Figure 9 The New Depreciation Calculation Engine
Of course, normally, you wouldn’t even notice a difference in the depreciation calculated, apart from perhaps some rounding. However, if you are moving to New Asset Accounting and want to compare in detail the calculations before and after, it might be useful to understand the above.
Migrating to New Asset Accounting
Generally, you’re either going to be migrating to a Greenfield implementation of S/4HANA, or converting your existing system data to S/4HANA. Many customers already on SAP for a number of years are using this opportunity to re-implement and get rid of all the bad practices and bespoke programs that have accumulated over the years, and it is the only option available if you are moving to S/4HANA on a public cloud.
The second option, system conversion is less disruption and you keep your transaction history, but it is only available for on-premise S/4HANA versions.
The New General Ledger is the only ledger available in S/4HANA, but if you don’t have it already, and want to use the full functionality, for example the parallel ledgers and document splitting, a separate project to migrate to New General Ledger prior to S/4HANA may be advisable.
Document splitting at the moment cannot be implemented once you convert your data to S/4HANA, although the functionality should be available in the next on-premise version 1709. Adding parallel ledgers on S/4HANA which wasn’t initially available, is now available from the 1610 version. Of course, timing is important, because whereas you can migrate to S/4HANA at any period end, you need a fiscal year end to do a full New General Ledger migration.
Migrating from SAP to S/4HANA
If you plan to keep most of your existing business processes and convert your existing system to S/4HANA, there are a number of tools available for pre-checks, particularly to ensure that your custom code will work on the new compatibility views.
During the migration, there are a number of checks and adjustments to be done, for example for the cost elements during the merge of finance and controlling, and ensuring everything has the correct fiscal year variant. It is particularly important to get the asset module correctly aligned with finance, especially if you have additional accounting principles in both.
The exact changes that you will need to carry out will depend on your existing and planned configuration. If you already have parallel ledgers you will need to match the depreciation areas to the parallel ledgers and currencies using the accounting principles. If you plan to use the accounts approach for different accounting principles you need to set up ledger groups and tick the new flag in the ledger configuration for parallel accounting using GL accounts.
You also need to create your technical clearing account, and change the asset accounts to reconciliation accounts for the non-leading ledgers (the leading ledger should already have reconciliation accounts). If you have any transaction types that are applicable to only one ledger, you will need to mark them as obsolete as you will no longer be able to use them. There are also some additional flags to verify for net book value retirements and revenue distribution.
Only one fiscal year can be open during migration and the last year cannot be reopened after migration, but you can still run reports for prior years.
Obviously, the usual rules of reconciling everything before you start and running reports before and after to compare and check the figures apply. In particular you should reconcile asset accounting with the general ledger using transactions such as ABST and ABST2. There are many standard asset reports such as asset balances, asset history, planned depreciation and so on that you can run both before and after the migration.
Data Migration from legacy system
This section applies more to a data migration from a legacy system to a Greenfield implementation of an on-premise version of S/4HANA as there are different tools available for the public cloud versions.
If you are used to using the LSMW (which stands for the Legacy System Migration Workbench), the bad news is that it has not been fully converted to the new table structures and methods of posting, so SAP do not recommend to use it in the same way as before. (see their Simplification List of new functionalities released for the 1610 on-premise version). The new transaction ABLDT to post the legacy values, uses an input enabled ALV grid control, so it can’t be used with batch input and therefore can’t be used by the LSMW. Instead SAP suggest three options to transfer your data depending on the quantity of data that you have.
If you have a small amount of data, you can still use transaction AS91 to create the asset master data, but the take-over values button is grayed out so you can no longer enter values and need to use the new transaction ABLDT for the values. The reason for this is that the posting of the value now creates a Universal Journal document which posts between the asset and finance, and therefore the asset has to exist before the posting can be made. Hence you have to save the asset first and then go into a different transaction to post the value. ABLDT however, posts directly to the migration account so you don’t need to make any additional postings.
For medium amounts of data SAP recommend to use transaction AS100 and for larger amounts to use the BAPI_FIXEDASSET_OVRTAKE_CREATE (see OSS note 2208321). Note that the BAPI only supports new assets, not the transfer of amounts to an existing asset or the correction of values previously transported.