In this blog post, I will give you an overview of extension ledger use cases in the latest release of SAP S/4HANA On-Premise and S/4HANA Cloud, private edition. 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 ledger 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 applications based on the universal journal will be able to work with parallel ledgers.
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:
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.
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 the extension ledger via
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.
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 ledger, for example, to record:
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 that 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 the order-to-cash process, we have a sales quotation, sales order, goods issue, invoice, and payment. However, only goods issues, Invoices, and Payments 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 issues, and 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, 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, and 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 an extension ledger for the simulation of closing activities or the 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
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 entries 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 entries 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 an extension ledger when compared 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 also work 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 the extension ledger via
- manual postings (i.e. transactions FB50L, FB01L, KB1, KB41, or corresponding FIORI apps such as Post General Journal Entries)
- interfaces
- 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
Adjustments Ledger
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 ledger, for example, to record:
- Internal Management reporting adjustments
- Adjusting entries after books are closed.
- Topside adjustments
- Adjustments for tax purposes to reach a tax-adjusted profit or loss
Predictive Accounting
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 that 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 the order-to-cash process, we have a sales quotation, sales order, goods issue, invoice, and payment. However, only goods issues, Invoices, and Payments 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 issues, and 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
Purchase Commitments
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, and 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 .
Simulations
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.
Conclusion
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 an extension ledger for the simulation of closing activities or the 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
- SAP Managed Tags:
33 Comments
