SAP S/4HANA Extension ledger – Use cases
In this blog post, I will give you an overview of extension ledger use cases in the latest release of SAP S/4HANA 1909. These use cases will give you a clear idea about extension ledger usage. However, before we start, we will need to understand what is an extension ledger. You are probably well aware of standard ledgers functionality in SAP ERP. Due to different regulations and requirements, the majority of companies today publish financial statements according to multiple accounting standards in parallel. Starting from SAP ERP with newGL you can use standard ledger functionality where a separate ledger is kept in the system for each accounting standard. There are 2 types of ledgers – leading ledger which is integrated with all subsidiary ledgers and controlling. Then you have parallel ledgers which are called non-leading ledgers. These parallel ledgers are always managed as complete ledgers. This means that all postings relevant to the specific valuations are always posted fully. At the moment, parallel ledgers are supported fully in General Ledger and Fixed Asset Accounting, but the vision is that all finance application based on the universal journal will be able to work with parallel ledgers.
What is an extension ledger?
In SAP S/4HANA, we have a new type of ledger – an extension ledger. The extension ledger, in contrast to the standard parallel ledger, is a delta ledger. It means that only differences between valuations are posted into the extension ledger. As a delta posting is meaningful only in combination with the original posting, the extension ledger always must have a standard ledger assigned as an underlying ledger. The postings to the underlying ledger also apply to the extension ledger. Anytime you report on the extension ledger, data from the underlying ledger are always accessed and displayed together with delta posting.
Based on what kind of journal entries you want to post to the extension ledger, you can define 3 extension ledger types:
- Standard Journal Entries– stores journal entries with real document numbers. These journal entries cannot be deleted and have to be reversed when required. Use cases – management adjustments, tax adjustments, realignments
- P – Line items with technical numbers /no deletion possible (former Prediction) – stores journal entry with technical numbers only, without document numbers. They cannot be deleted and have to be reversed when required. Use cases – predictions, commitments, statistical sales conditions.
- S – Line items with technical numbers/deletion possible (former Simulation) – stores journal entry with technical numbers only, without document numbers. They can be deleted. Use cases – simulation, posting
You may also come across the so-called valuation extension ledger V -Journal Entries for valuation differences, which is not ready yet but was made visible in the configuration by mistake.
Advantages of an extension ledger
- Flexibility – This is probably the biggest advantage of extension ledger when comparing to standard ledgers. Setting up new extension ledgers is easy, it is not necessary to perform any kind of data migration, only the configuration is needed., This is enabled by the extension ledger concept, as it just inherits the historical data of the underlying ledger. You can activate or deactivate the extension ledger in a productive system anytime during the year without having to migrate data as it is the case with the standard ledger.
- Reuse of existing reports – All reports supporting standard ledgers work also with extension ledger. This is true for new FIORI analytical apps and classical SAP GUI reports as well.
- Reduced data footprint – as only delta values are kept in the extension ledger
Replacement of standard ledger with extension ledger
It is important to realize that the extension ledger is not a replacement for the standard parallel ledger. It still has many limitations in terms of functionalities. You can post to extension ledger via
- manual postings (i.e. transactions FB50L, FB01L, KB1, KB41 or corresponding FIORI apps such as Post General Journal Entries)
- General ledger Allocations (FAGLGA15, FAGLGA11, FAGLGA31, FAGLGA35) work on top of the extension ledger.
However, in contrast to the standard ledger, the extension ledger is not integrated with subsidiary ledgers and many crucial finance processes such as asset processes and open items are not supported.
Extension ledger restrictions
- No postings to vendor or customer reconciliation accounts
- No postings to GL accounts with open item items management
- No integration with Asset Accounting
- Only very few automatic processes work with extension ledger (GL allocations)
What are some existing extension ledger use cases
Besides preparing GAAP financial statements, many companies have fairly rich management reporting requirements. Most of the information needed comes from standard ledgers but usually, data must be regrouped, enhanced, or refined. In the past, in SAP ERP you could use a special Ledger, a second parallel Ledger, or just add cost objects to address this kind of requirement. However, none of these solutions was optimal and each came with its problems and limitations. Now, in S4HANA we have a better solution – the extension ledger.
You can set up an extension ledgers, for example, to record:
- Internal Management reporting adjustments
- Adjusting entries after books are closed.
- Topside adjustments
- Adjustments for tax purpose to reach a tax-adjusted profit or loss
Predictive accounting is a functionality enabling bottom-up prediction of future financial results. If you look into an ERP system, you can see there is already a lot of information out of which can create predictions. There are documents such as sales orders or purchase orders which are not accounting relevant yet, but we can assume that at some point in time they will result in postings. In addition, these documents already contain the amount and expected date when they will be transformed into accounting relevant documents. For example, if you look at order to cash process, we have a sales quotation, sales order, goods issue, invoice, and payment. However, only goods issue, Invoice, and Payment are relevant for Accounting. The other documents are in the system as well, but they do not impact accounting. The first scenario of Predictive Accounting available in SAP S/4HANA is for Incoming Sales Orders. The idea here is pretty straightforward: when a sales order is created, the system will simulate the follow–on documents, goods issue, billing documents, and create predictive journal entries in a P-type extension ledger. The best part is that the corresponding documents are displayed in the system as if they were real data. All subsequent financial processes such as document splitting, derivations, and splitting of costs of goods sold are also triggered.
For further details, please refer to SAP help
Statistical Sales Conditions
Statistical Sales conditions, for example, warranties can be posted to an extension ledger during sales order billing. This can enable enhanced SG&A reporting in a P&L Statement by allowing the inclusion of projected sales warranty costs.
For further details, please refer to SAP help
Commitments Management functionality in SAP S/4HANA updates purchasing commitments in the extension ledger. A Purchasing commitment represents an obligation to pay a vendor for the future delivery of goods or services. Commitments are triggered when a purchase requisition or purchase order is created in the system. At this point, there are no actual payments recorded against GL accounts, but a reservation (commitment) should be made against the budget. The activation of commitments updates in Universal Journal makes sense especially in relation to the new Budget availability control available since the 1909 release. Until release 1809 commitments were stored in the dedicated line items table COOI, totals were stored in the table COSP. Since S4HANA 1809, the commitments now update Universal Journal (table ACDOCA). In order to distinguish them from actuals, they are stored in a separate extension ledger which must be defined as a prediction ledger. For compatibility reasons, commitments are continued to be updated in the old commitments tables as well.
For further details, please refer to SAP Note 2778793 – Constraints with New Commitments Management Solution .
An example of a simulation is a closing activity with Foreign Currency Valuations. Imagine that you would like to see an impact of foreign currency revaluation on your financial statement before actually running it. Since SAP S/4HANA 1610, you can run the Foreign Currency valuation in simulation mode. The simulation run generates valuation posting documents that are posted into an S type extension ledger. Reporting on the simulation ledger combines simulation data with actual data of the underlying ledger. You can see the simulated data on all reports for which you can specify a ledger. The simulated data are deleted automatically once you run the foreign currency valuation in productive mode. This way you can run financial statements and see the impact of currency changes any time before actually posting them.
Another example is the simulation of organizational changes. The current scope of organization changes supports profit center reorganization for S/4HANA Cloud customers (available since release 2008). Here you can use an extension ledger for posting the simulated transfer journal entries.
These are some of the use cases of extension ledgers that have already been developed and successfully implemented by customers. And there is more coming in future releases. Some of the upcoming enhancements are on the roadmap already, for example, enabling predictive accounting for purchase orders. Some of the future concepts include the possibilities of using extension ledger for simulation of closing activities or simulation of reorganizations. I would like to hear your thoughts in the comments below. What do you think about the extension ledger use cases? Should we add more?
Brought to you by the SAP S/4HANA RIG
You have not mentioned about V - Valuation ledger (Extension ledger)?
If possible could you provide some light on Extension ledger V?
At the moment, there are no further details. I will update the blog once information about Valuation ledger use case is made available.
Hi Martin. Can you post in Extension ledger only to an auto posting controlled GL account? like revenue (Auto post only set) or you would need an open adjustment revenue account?
Thanks for nice info. There is no simulation ledger available in 1909 release. Is it discontinued? Any idea.
Simulation ledger is still there. It is extension ledger type S – Line items with technical numbers/deletion possible
Thanks for nice info.
Thanks for nice info.
I would just like to check if the Extension ledger restrictions are still existing.
Yes, they still exist.
I was searching for the extension ledger uses.
Thanks for sharing this. Looks promising in new developments.
Can we use the statistical condition types with same account key and same GL account in the setup to have separate line items in ACDOCA for the condition types?
For example: I have 4 condition types ZSC1, ZSC2, ZSC3 and ZSC4. I have assigned same account key ZS1 with same account number 10000000 in VKOA.
Is it possible that extension ledger also give different line items as happens leading ledger?
thanks Martin, it is indeed a very good post and it is more and more interesting our clients.
below few feedback after implementing extension ledger for FX simulations:
Question: what is planned in terms of features for the simulations? it will only kept for FX revaluation?
thanks or your help,
Thank you for your feedback.
What is planned is, for example, simulation of organizational changes. Please see the road map here.
thank you Martin. Can you some how share this feedback with the product owner?
Thank you, Martin, for this excellent information.
One question regarding the use cases for extension ledgers: should predictive accounting, statistical conditions and purchase commitments use the same ledger or a separate one? What is the recommendation?
To my knowledge, no predictive journal entries are created for statistical conditions in predictive accounting. Hence there is no need to have predictive accounting and statistical conditions in one ledger for analysis purposes.
Does predictive accounting cover scheduling agreements (VA33) as well?
a separate ledger for predictions+commitments and a separate ledger for statistical SD conditions.
Please refer to SAP Note 2947863 - Predictive Accounting: Restriction Note (SAP S/4HANA 2020) for sales processes supported in predictive accounting.
Firstly thank you for the content you have shared.
I am think of an adjustment scenario, however it would be great to automate the adjustment to enable real-time reports.
For example, a charge is posted to the standard ledger against a Business Area that has defaulted from a Functional Location to a PM Order. The business area represents a type of service for example regulated vs unregulated services provided by the organization. In this instance a small amount of physical assets are 'mixed' in that they can be used for both services.
We would like to automatically create an adjustment entry in the extension ledger that allocates costs to regulated / unregulated based upon an agreed % for the asset concerned.
How might we best go about this?
Good and concise info.. thanks for sharing..!!
This commitments ledger is a WIP product. Considering the list of "constrains" (declared as features) it is too far from substituting the COOI table.
Thanks for sharing detailed information on extension Ledger.
Thanks for sharing Martin !
For a customer we succeeded to create an extension ledger with an existing extension ledger as the nase ledger. The Pfkey4 dropdown shows only standard ledgeers as possible base ledgerm but we ignred this and put in the extension ledger as base ledger for the 2nd extension ledger.
This enables the opportunity to stack extension ledgers.
the customer can report
Can we just do this? It seems to work, but are there any restrictions?
Yes, it is possible. Please see the sap help Extension ledger types for restrictions.
Thanks for excellent blog.
Thanks Martin for the helpful blog.
One question about "S - Line items with technical numbers/deletion possible" of extension ledger type, after doc posted with FB50L I can still see the doc number in the table, and how it will be deleted? with which Tcode?
At the moment, there is no standard transaction or app for the deletion of the journal entry. It is handled by programs that use this type of ledger for simulation postings. I would recommend disabling manual postings to this type of ledger in the ledger settings.
Is it possible to use extension ledger when an organization is using accounts approach in SAP HANA rather than ledger approach?
Yes, it is possible.
Can you tell me , or provide me bibliography, why extension Ledger do not update BSEG and cannot display journal entries per extension ledger in fbl3n or fbl3h?
Only fagll03 or fagll03h depict the account entries per extension ledger
Thanks in advance
We would like to understand whether extension ledger supports foreign currency valuation without defining it as simulation ledger. As simulation ledger data are transient and will be deleted as soon as production run is done, we want to understand whether fcv can be posted to extension ledger which is of type standard journal entries.
In that case whether system will update the fcv ONLY in extension ledger,.
Excellent work, thanks.
Here I've got a question about extension ledger and special ledger.
Does a posting to extension ledger transfer data to special ledeger, for example, usimg FB50L?