Co-Authored by Gabi Hoffmann and Stefan Walz
Welcome to this blog, in which we will show you the new integration of customer down payments in S/4HANA General Ledger and Event Based Revenue Recognition. Base for this functionality is the Universal Journal. The screenshots are taken out of a CE 2402 and OP 2023 system, the scenario is valid for public cloud and on premise.
We will start in this blog with a functional overview. Then we will show an end-to end process in the system based on the professional service tailored customer project scenario. We give some insights for customer projects in OP, which work like EPPM projects - alias projects - in public cloud. We will cover the two options in EBRR to react on the received down payment or not. We will close with deeper insights in the process control.
The customer down payment request (DPR) is mapped in financials as an Account Receivables entry in the BSEG table, which stores Accounting Document Segment data, see figure 7. Until this solution there was no general ledger journal entry created and DPR and down payment received was not visible in project reporting/Controlling.
In a customer project scenario, we have the requirement to show the DPR and the down payment received in the project reports - as balance sheet values. There exists also an IFRS requirement for certain cases to offset down payments received with existing accrued revenues - to shorten the balance sheet values. To reflect these requirements, we have added additional journal entries:
This new down payment posting logic works in public cloud only for customer project scenario. There are prerequisites in the sales order master:
The posting logic for down payment request and down payment received does not work for financial DP requests (App Manage Customer Down Payment Requests or transaction F-37).
To enable project reporting and additional EBRR functionality the liability journal entry items created by the DP request and the received down payment are account assigned to the wbs billing element and – same as for other actual postings – market segment fields are derived – see figure 1.
Figure1: reflection of the DP request in Universal Journal
We use here the new capabilities in the Universal Journal to account assign even balance sheet accounts to co objects and attribute market segments, derived by the sales order item.
In S/4HANA the accounting applications General ledger, Controlling, event-based revenue recognition and margin analysis are now integrated in the Universal Journal, in which all actual data is stored. There is no separate data store for controlling, margin analysis or revenue recognition. All KPIs like realized revenues, cost of goods sold, margin per quantity unit or multilevel contribution margin are calculated based on journal entry items, stored in the Universal Journal single source of truth.
More about the account assignment of balance sheet and market segment attribution you can get in this blog: https://blogs.sap.com/2023/08/06/co-account-assignment-and-attribution-with-s-4hana/
In the current solution, release CE2402, there are no taxes applied for the down payment request, which covers the legal requirement for multiple countries like Germany. An overview about the functionality and a comparison with the pre-payment method on account, which is only available for professional service projects and T&E Billing, you get in figure 2.
Figure 2: Overview down payment functionality and Comparison with on account
Further information about the customer project processes you get here:
Financial Accounting for professional service tailored customer projects
Financial Accounting for EPPM customer projects in S/4HANA
We will now show an end-to end process for a professional service project with a time and expense billing method: from the DPR to the customer invoice and the final revenue recognition posting.
First let’s look in the customer project billing plan with the app create or plan customer projects.
Figure 3: Down payment request maintained in the billing plan
In the first billing plan item a down payment request of 1000 EUR is planned.
To create the DPR invoice, we start the app Manage Project Billing and select for our Project SW007.
Figure 4: app Manage Project Billing
By tapping on the red triangle in the column "To Bill" we get the information about the planned prepayment of 1000€.
We select our wbs billing element and enter button “prepayment” to get the pop-up in figure 4a.
Figure 4a: pop-up for DP request
With submit we create a billing document request. We start app Create billing document and filter for the BDR:
Figure 5: app create billing document – based on the billing document request
We select the row with the BDR and enter the button “create Billing documents”, The created billing document can be analyzed with the app Manage billing documents.
Figure 6: app Manage Billing documents with the DP request
With the button “Post billing document” we create the financial documents.
Figure 7: app Journal Entry Analyzer - Entry/ BSEG view for down payment request
The DP Request updates the open AR item in table BSEG. This always happens, when customer DP is requested. And it is the only update in FIN, if no special posting logic is activated in configuration.
In our example an additional General Ledger journal entry is created:
Figure 8: General Ledger document of the down payment request
The G/L Ledger document contains two journal entry items with balance sheet accounts. The contract liability line item is account assigned to the billing wbs element (Account assignment type = PR) to allow controlling reporting – with new SLA type 8011.
Now we post a time confirmation to the project of 10h, which lead to consulting costs of 750€. This leads to real time EBRR posting of realited revenue of 1200€ and offset WIP of 1200€.
To check project reporting for these postings, we start the app Project actuals.
Figure 9: app Project -Actuals: down payment request is reflected in project reporting.
The DP request, first line item in the report, is visible in project reporting, like the also posted journal entry of time confirmation with the matching EBRR journal entry.
The Contract Liability DP request G/L account is, like the WIP/Accrued revenue account, a general balance sheet account – not open item managed.
Let’s have a look on the G/L account master for this liability account:
Figure 10: G/L account master of the down payment request Liability
The Contract Liability DP request G/L account, like the WIP/Accrued revenue account, is a general balance sheet account – not open item managed. (Remark for on premise: no cost element type 90 is used)
Now we post the incoming payment with the app Post Incoming Payment (transaction F-28)
Figure 11: creating incoming payment for down payment request
With the button “select more” you can specify the filter criteria on the customer and Down payment, which os specified with "F".
Figure 12: filter options for the open item
We assign the created down payment request and post.
Figure 13: journal entry for the down payment received
The created Journal entry consists of 3 parts
We account assign the wbs billing element in two journal entry items with SLA type 8010 and 8011. We analyze the project reporting with the app product and service margins.
Figure 14: Product and service margin after down payment received.
The received down payment, G/L account 21191100, is shown within project reporting in the column Customer Down Payt.
The down payment request, G/L account 21191200, is netted to zero.
Now let’s check the WIP details app, which provides additional analysis option for customer projects, which use Time and expense billing.
Figure 15: app Project WIP Details after down payment received.
In WIP details app there are own columns for the Down payment requested and Down payment received
– selection is done by SLA type.
The down payment requested is netted to zero. Down payment received are now 1000€ and the WIP, based on the time confirmation to the project, is shown with 1200€.
Now we start EBRR with the app “Event based revenue recognition – Projects”.
Figure 16: EBRR simulating result – netting of accrued revenue and down payment received.
The Simulation result shows that the down payment liability of 1000€ is taken in account by rev rec. The accrued revenue decreases from 1200€ to 200€.
With posting we get the following journal entries:
Figure 17: EBRR Journal entry for netting
EBRR offsets the two balance sheet accounts accrued revenue and liabilities from down payments received.
The described netting is one option for EBRR to react on the down payment received. Another option is that there is no netting between accrued revenue and contract liability for received down payments. Chapter 4 describes how this is controlled.
We check the result in the app WIP details
Figure 18: app Project WIP Details after netting
The WIP details app shows now:
As a next step we bill the open billable amount of 1200€. we start the app Manage project billing as in figure 4 and select our project SW007.
Figure 19: Prepare Billing
We select the complete billable amount of 1200€ for billing.
In the subsequent billing document these 1200€ are netted with the received down payment amount of 1000€ (these are net amounts without taxes).
The billing leads to the following journal entries:
Figure 19a: journal entry of the final billing
The JE for billing shows the billed amount of 1200€. The complete down payment amount is used and thus the contract liability from DP received G/L account is balanced to zero (Journal entry with SLA type 8010)
The second Journal entry is the matching EBRR document, which defers the billed revenue.
As next step we run EBRR for clearing the balances of the balance sheet accounts.
The EBRR posting leads to following journal entry.
Figure 20: Journal entry of EBRR run – final netting of accrued and deferred revenues and liability
The journal entry consists of two parts:
Let’s look on the final view in the WIP details app:
Figure 21: WIP details final view.
All values are now balanced to zero.
The same you get of course in the product and service margins app.
Figure 22: product and service margin - final view
An Overview of the posted journal entries by T-account you can get in figure 23.
Figure 23: Posted journal entries in T-account view
We start with the sales order maintenance in on premise (transaction VA02).
Figure 24: sales order item assigned to customer project.
We account assign a billing wbs element, here SW-Mario1, to the sales order item.
Figure 25: billing plan with DPR item
The first item in figure 25 reflects the down payment request – with an own billing type FAZ.
We invoice the due down payment request with transaction VF01 with relation to the sales order.
Figure 26: DPR invoice
The journal entry document of the down payment invoice you get here:
Figure 27: journal entry ofDPR invoice
The created journal entry looks similar as our example for the public cloud example – figure 8.
How you activate these postings in on premise we show in the next chapter.
The configuration consists of two parts:
In public cloud the journal entry creation is always active, if you use a ledger with IFRS accounting principle. In this case the new posting logic is active for all parallel ledger – including those with different accounting principles. There is no config available.
In on premise you need to activate the new posting logic in configuration. There are multiple steps required, which we list in the following.
There is an IMG view FINSV_AP_CNTRL_C available with which you can activate the DP posting logic per ledger.
Figure 27: IMG node for activation of G/L postings
The details you get in the next screen.
Figure 28: activation of G/L journal entries per ledger
Here for German GAAP, DEAP, and IFRS the new posting logic is active.
Additionally, you need to assign G/L accounts in the account determination SSCUI. In on premise with transaction FBKP you get the following screen:
Figure 29: G/L account determination - groups
Within the down payment posting group you need to activate G/L account determination for the transactions DPL and DPR.
Figure 30: G/L account determination – account determination activation for down payment process
Behind the two account determination transactions you can assign the balance sheet G/L accounts:
Figure 31: G/L account determination for liability of received payment
Figure 31: G/L account determination for down payment request
In public cloud the netting of accrued revenue and the liabilities created by down payment request for customer projects is always active. There is no SSCUI available.
In on premise, you need to activate it per expert config. Transaction SM30 table FINS_TRR_CNTRL.
Figure 32: required expert config in on premise.
With the parameter ROD you activate that EBRR includes additional postings on account assigned balance sheet accounts.
With the parameter CDU you can deactivate netting in general. But you can activate per assignment rule with usage 106.
How the posting logic looks like, if you deactivate the netting in EBRR you can get in figure 33.
Figure 33: DP process for customer projects T-accounts for no netting in EBRR
If you compare wih figure 23, you will miss some journal entries posted by EBRR. Unlike the example in figure 23 we do not use the complete received downpayment for the milestone billing.
We hope you enjoyed these insights into down payment handling in customer projects in S/4HANA. It is another scenario, in which we are now benefiting from the innovations in financial accounting.
Feedback welcome
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
7 | |
7 | |
7 | |
4 | |
3 | |
3 | |
3 | |
3 | |
3 | |
2 |