Enterprise Resource Planning Blogs by SAP
Get insights and updates about cloud ERP and RISE with SAP, SAP S/4HANA and SAP S/4HANA Cloud, and more enterprise management capabilities with SAP blog posts.
cancel
Showing results for 
Search instead for 
Did you mean: 
stefan_walz
Product and Topic Expert
Product and Topic Expert

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.

1.    Functional scope

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:

  • The down payment request is now reflected in General Ledger – see figure 1 and 8.
  • The received customer down payment clears the DPR journal entry items and creates additional journal entry items with own liability G/L accounts – see figure 13.
  • To allow simple tracing in reporting, these JE items are posted with own SLA type: 8011 for DP request, 8010 for down payment received.

This new down payment posting logic works in public cloud only for customer project scenario. There are prerequisites in the sales order master:

  1. a wbs billing element must be assigned to the sales order item.
  2. the DP request must be maintained in the sales order billing plan.

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

 

2    system walkthrough – Down Payment in professional service projects

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.

DPN03-DPR-in-billingplan.png

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. 

DPN04-manage-project-billing.png

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.

DPN04-2-manage-project-billing-popup.png

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:

DPN05-billig-request.png

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.

DPN06-DPR-billing-doc.png

Figure 6: app Manage Billing documents with the DP request


With the button “Post billing document” we create the financial documents.

DPN07-DPR-BSEG.png

 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:

DPN08-DPR-JE.png

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.

  • with the account assignment to customer project the profitability segment is derived – like for the other actual postings on the project – see linked blogs above
  • This DPR journal entry item - posted with SLA type 8011 - is not relevant for revenue recognition!

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.

DPN09N-DPR-project-actuals.png

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)

DPN11-payment.png

 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.

DPN13-payment-JE.png

Figure 13: journal entry for the down payment received

The created Journal entry consists of 3 parts

  • The first 4 journal entry items (red part) reflect the received payment
  • The yellow part reflects the reversal of the down payment request (with clearing the balance sheet account with SLA type 8011)
  • The last 3 journal entries (blue part) is the reflection of the down payment received on a new „Liability from down payment“ G/L account (posted with SLA type 8010)

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.

DPN14-product-and-service-after-payment.png

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.

DPN15-WIP-details.png

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”.

DPN16-EBRR-simulate.png

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:

DPN17-EBRR-netting-JE.png

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

DPN18-WIP-details-after-netting.png

Figure 18: app Project WIP Details after netting

The WIP details app shows now:

  • A reduced WIP of 200€. Remark: the billable revenue in next column is untouched of course and still 1200€
  • The down payment request is balanced to zero.
  • The column DP WIP netting shows the amount reduced by WIP.

 

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.


DPN19-prepare-billing.pngFigure 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:

DPN19-billing-JE.png

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.

DPN20-EBRR-final-JE.png

Figure 20: Journal entry of EBRR run – final netting of accrued and deferred revenues and liability


The journal entry consists of two parts:

  • Line 1 and 3 nets the balances of the accrued and deferred revenue
  • Line 2 and 4 reverses the previous down payment received netting.


Let’s look on the final view in the WIP details app:

DPN21-WIP-details-final.png

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.

DPN22-product-and-service-final.png

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



3.    Down payment example for EPPM projects and customer projects in on premise


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.

 

4 control for G/L document creation and EBRR


The configuration consists of two parts:

  • the netting of accrued revenue and received down payment in EBRR
  • the journal entries creation, which is a prerequisite for the EBRR netting, without the activation you get only the BSEG entry for DP request and no liability JE item for the down payment received, so not the journal entry items with SLA type 8011 and 8010.

 

Activation of journal entries creation


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



Activation of DP netting in event-based revenue recognition


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.

    • With CDU:Blank – like you see it in figure 32 – the netting is for all methods active. There is no the netting.

 

    • With CDU=X the netting is in general inactive. Y



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.

Closing remarks

 

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

 

 

 

 

 

1 Comment