1809 Changes.docx

Finance in S/4HANA 1809, what you need to know by Ugur Hasdemir October 3, 2018 1 comment

We are getting used to SAP’s new yearly release schedules for S/4HANA On-Premise. Last week the latest release 1809 is released. Again, fully packed with new and enhanced functionalities. I especially like how SAP is increasing the integration of intelligence, machine learning and the Fiori UI to the existing business processes. In this post I will write about the key changes in the Finance area. Sit bag and enjoy the nice things you will see in the newest S/4HANA release. List of the topics handled in this post: 

Enhancements in Profitability Analysis (-> dedicated blog coming soon)



Predictive Accounting



Commitment Management



Universal Allocation



Global Accounting Hierarchies



Intelligent GR/IR with Machine Learning capabilities



Accrual Management (-> dedicated blog coming soon)

Enhancements in Profitability Analysis In my first blog about “why S/4HANA” I had already explained that Account Based COPA is the way forward in S/4HANA. In the 1610 and 1709 releases Account Based COPA was enhanced, but there are still some functional gaps compared to Costing Based COPA. With this newest 1809 release SAP closes the gap between account and costing based COPA further. The following enhancements have been made: 

Finally, we can track statistical sales conditions in account based COPA. SAP uses the extension ledger functionality in order to do this



Reporting on incoming sales orders together with predictive reporting functionality is made available in account based COPA. Also, with the use of extension ledger



COGS split calculation with actual costing available in any ledger for fixed and variable values.



Activate Derivation for Items without Profitabilit Segment for the following account assignments:



Cost Center



Internal Order



Project



Sales Order



Production Order



Maintenance Order I will cover the statistical sales condition and the sales order functionality in more detail in a a future post.

Predictive Accounting Predictive accounting in combination with margin reporting. 

Top-Down: Prediction uses a time series algorithm on historic data in order to predict future values considering trend, cycles and fluctuations.



Bottom-Op: Prediction is performed based on predicted documents being part of an individual business process and its document flow

Predictive accounting includes insights from expected revenue and expected expenditures. 

Predictive Accounting for incoming sales orders



Financial line item details for incoming orders reporting



Review incoming sales order report



Provides a comprehensive overview of all orders and their values for the time period regardless of billing status



Predictive Accounting for commitment scenarios



Include cost assignments to WBS, order, cost center and supplier



Can be shown for derived characteristics such as profit center, segment and functional area.

There are some limitations in predictive accounting today. Those are the following:



Only SD documents with category C, H, I, K and L are processed



Predicted costs are missing in the third-party direct shipment and intercompany sales scenarios. This is due to missing goods issue.



Service Sales scenarios are not covered



For statistical sales condition no predictive journal entries are generated

Commitment Management The New commitment logic and Commitment by Cost Center App provides full transparency over plans and spending, through embedded analytics solutions you get root cause analysis on the fly trough graphical and interactive user interface.

Universal Allocation Why Universal Allocation?

Universal Allocation is introduced to simplify and consolidate functionalities in the allocation, distributions and assessments areas. With Universal Allocation SAP wants to: 

Simplify the allocation process



Complex organization structures requiring multiple views



Legal and industry challenges



High number of cycle & segments



Local cycle runtime



Complex knowledge required



Dynamic organization boundaries



Answer allocation questions



How did the cost get allocated to my area?



How do amounts flow across the chain of cycles and segments?



Are the tracing factors reliable?



Why am I accountable for this?



Perform simulations



How would the result look like in case we merge two legal entities?



Customers want to understand and identify possible financial effect of changed allocation rules on their financial data



Tools are bound by operational requirements



Offer advanced reporting capabilities



Standard reports are limited



ERP transactions only based on one cycle at a time



Difficult to explore the allocation structure holistically



Simplify process with guided procedures, reducing effort of knowledge transfer

Vision and future direction of Universal Allocation is to combine various capabilities under one umbrella: 

Provides one architecture for FI and CO allocations



Combines actuals and plan



Provided simulation capabilities



Includes actual and predictive data ledgers



Presents data in a common structure



Provides all required reporting currencies



Shows currency breakdown



Can be enhanced / extended



Provides traceability of the value flow



Simplifies the proves with guided producers and validations Prototype for Cost Object Analysis: In the below screen shot you will see a lab preview of a prototype for cost object analysis in which you can easily answer the following questions:



Who is allocating which costs to me



Which tracing factor is used



To whom do I sent which costs

Prototype for Profitability Analysis: Whit this prototyped app the allocations to COPA can be analyzed on product level. 

Who is allocating which costs to the product?



Which tracing factor is used?



Which cost elements are used?



How does the cost flow look like?



Where are the costs originally coming from?

Global Accounting Hierarchies

Today each master data record type has an own logic and app to maintain and create hierarchies. In many cases you end up creating multiple cost elements hierarchies for different purposes like reporting or allocations. SAP want to unify gradually all the group and hierarchy maintenance activities in one App.

The Global Accounting Hierarchy has the following features: 

Modern, consistent UI and persistency in one hierarchy. SET group, FSV, custom hierarchies, etc.



Time dependency, status control



Support custom extensibility, custom hierarchy, custom field and custom logic



Compatibility with existing hierarchies

Intelligent GR/IR

The GR/IR account reconciliation process is an exception handling process for all purchase order items with difference between goods receipt and invoice receipt. This is a highly manual process that delays the period-end-closing. Most common reasons why GR/IR items cannot be cleared automatically are: 

Invoice goods receipt is missing



Amounts do not match



Purchase order item was created with an outdated price list



Delivery costs were posted on the wrong GR/IR account The new Goods and Invoice Receipt reconciliation overview App improves the process by displaying all necessary data on one screen so that the processing steps and statuses can easily be documented in the app. The proposal service with machine learning automatically proposes next steps for items that could not be matched.

Integrating Machine Learning capabilities into GR/IR clearing

The goal of the machine learning service is to learn from decisions taken in the past to apply the learned knowledge to the new business situation and to make recommendations for the next meaningful steps for each purchase order item. The machine learns from the decisions taken by humans and improves over time.

Training works by analyzing historical records of reconciled GR/IR accounts, and specifically manual assignments of purchase order items.

Accrual Management There are a lot of changes in the new accrual engine compared to the old one in previeous releases. Also the customizing is changed significantly. I will be briefly explain the reasons for the new accrual engine and the new logic/functionality. I will do a deep dive into the new Accrual Engine in a future post.

With the new Accruals Management Engine in S/4HANA SAP want to offer a coherent automated process with reliable outcome. To do this a unified UI, transparent reporting and auditability is delivered. When Migrating to S/4HANA 1809 all your data from manual accrual management must be migrated to the new accrual engine. Next to the new accrual engine, in release 1809 the new application Purchase Order Accruals is introduced. The S/4HANA Accrual Engine is optimized for S/4HANA: 

Fully integrated into the General Ledger



All currencies of GL supported



Postings are only stored in ACDOCA



Fiscal year variant of GL ledgers are supported



Standard FI reversal is supported



No redundant storage of the postings



No reconciliation effort with GL



No summary records in the engine



No limitation of the number of fields in reporting



No separate balance carry forward run required



Enables complex postings



Allows additional review/approval of periodic accruals at period end

Old vs New posting Logic:

New Features:

For manual accruals possibility to download and use excel template:

The purchase order accrual application At the end of each fiscal period the application calculates the accrual amount for the purchase order items by evaluating the pan data in the purchase order item. The delivery schedule with its planned delivery dates determines the cumulated planned costs that ere planned to have occurred from purchase order creation date up to the end of this period. At the end of each period the system assumes that these cumulated planned costs reflect reality. If at the

end of the period the cumulated actual costs are less than the cumulated planned costs, the system proposes the difference as accrual amount. There are different use cases in which the system reacts differently like purchase of consumables without GR or purchase of service with service entry sheet. I will explain the system behavior for each of these different use cases in a dedicated blog in future. Purchase order accrual architecture:

Hope you enjoyed this short preview of new and enhancement Finance functionality in S/4HANA 1809. Stay tuned for specific detailed blog posts about these topics in future.