Timesheet Accounting and Billing on S/4HANA Cloud for Professional Services

This blog attempts to cover details around the time posting process, its accounting and billing for ‘Time and Expenses’ contract type in S/4HANA Professional Services for Cloud. The objective of this blog is to share key learnings from implementing time posting, revenue recognition and billing for Professional Services on S/4HANA Cloud.

The time posting process in S/4HANA Cloud begins with the ‘Manage My Timesheet’ app. Consultants staffed on a customer project would be able to see details of the Project and Work Package in the app and book time against it. Most firms however have third party time booking applications and time sheet entries need to be integrated with S/4HANA using the ‘Workforce Timesheet’ API. Using this API, the time sheet application can directly integrate with S/4HANA Cloud or via middleware.

To understand the process flow, we will post a timesheet entry on a customer project using the API. Customer project has been created with work packages and assigned to sales order line items with contract type as ‘Time and Expenses’. Please note that no resource planning has been performed for the work packages and hence planned values appear as 0.

Once the project is moved to the ‘In Execution’ stage, we can post a time entry on a work package using Postman. The body of the request can be seen below:

Some of the key fields on the receiver side are ActivityType, WBSElement, BillingControlCategory and RecordedHours

• ActivityType – While using ‘Manage My Timesheet’ app, resource type planned on the work package is passed as Activity Type whereas in the API, this needs to be derived from the employee details. Typically, Activity Types are designed based on employee roles which form the basis of bill rates. A possible solution is to use the Service Cost field on the employee master to derive the Activity Type and to use this during time posting.
  
• Billing Control Category – This field specifies whether the time sheet entry is billable or non-billable (Use NON_BILL to post the time sheet as non-billable).

Some of the key fields on the sender side are PersonWorkAgreementExternalID, CompanyCode, PersonWorkAgreement, TimeSheetRecord, Time Sheet Date and TimeSheetOperation

• PersonWorkAgreementExternalID – This is the external ID of the employee record and not the personnel number or the business partner number
  
• CompanyCode – If PersonWorkAgreementExternalID field is being used, then this field has to be mandatorily populated with the company code of the employee
  
• PersonWorkAgreement – This field corresponds to the personnel number of the employee and can be used on its own without specifying the above two fields
  
• TimeSheetOperation – This field determines the type of timesheet transaction and has values like ‘C’ for Create, ‘U’ for Update and ‘D’ for Delete
  
• TimeSheetRecord – This field refers to the existing time sheet record and has to be populated for update and delete scenarios

Further details about the parameters and fields of the API can be found in the documentation here

On successful posting, the response returns details of the timesheet along with the TimeSheetRecord number

Time Sheet Accounting

Using the ‘Display line items in General Ledger’ app, you can see details of the accounting entries for the posted time sheet. You can filter entries using the ‘Reference Document’ field where Reference Document = TimeSheetRecord number.

However, we have seen that this may not be the most accurate way of determining the right accounting entries. The right way of determining the CO document or other accounting documents of a time sheet posting is to use the TimeSheetAccountingDocument field from I_TimeSheetRecord CDS view and to pass this value as the Reference document.

Since we are talking about time sheet related CDS views here, another point to be noted here is that to get the TimeSheetNote of a time posting, it would be best to the use the PlainLongText field from I_TimeSheetRecordLongText CDS view to get the text in its entirety without truncation issues. This field is used when the TimeSheetNote has more than 40 characters and is indicated using the field TimeSheetHasLongText field in I_TimeSheetRecord CDS view.

Now, CO document of the posted timesheet has two entries. A debit posting on the project and credit posting on the employee cost center. You can see the quantity of 1 Hr. and cost of 100 USD by adding the fields Quantity and Amount in Transaction Currency columns. Journal Entry Date is the Timesheet date.

Amount in Transaction Currency is arrived at by multiplying the rate maintained in ‘Manage Cost Rates – Services’ app. For this time posting, you can see that the cost rate maintained is 100 USD for Activity type T001. Amount in Company Code currency is determined by translating the transaction currency amount to the company code amount using the exchange rate as on the posting date. Please note that time posting would fail if cost rates are not maintained for the sender.

‘Manage Cost Rates – Services’ app allows users to maintain cost rates at various levels like Company Code, Receiving Company (Intercompany), WBS Element, Work Item, Personnel No, Service Cost Level, Activity Type and Cost Center.

Project side of the posting also contains details of the sender like Personnel Number, Origin Cost Center, Origin Profit Center. Also, you may notice that Activity Type is empty on the project side of the posting. However, this is available in the Origin Cost Center Activity Type field. There are also a set of ‘Partner*’ fields which contain sender information like Partner Company Code etc. Billable Control field on the journal entry tells us whether the entry is billable or not. Non-billable entries will have ‘S1’ as the value.

There may be instances where even though time posting was successful, CO document is not posted to accounting and hence not seen in the G/L line items. This can happen if a timesheet entry is being edited for a period that is closed. This could also happen when cost rates are not maintained correctly in intercompany scenarios. In such cases, you can use the ‘Process Unposted Time Confirmations’ app and input the employee number or work date and determine the cause of the failure.

Once the issue is resolved, you can run the process again with a posting date in the open period. The same process can be scheduled as a job using the ‘Schedule Overhead Accounting Jobs’ app with ‘Process Unposted Time Confirmations’ as the job template. This is usually scheduled to post late timesheet entries after period closure.

Now, we can look at the journal entries related to revenue recognition. There is a debit posting on the Balance Sheet (BS) Work-in-Progress (WIP Accrued Rev) account and a credit posting to the Profit & Loss (P&L) Revenue Adjustment (Unbilled Revenue) account for an amount of 650 USD.

You will notice that the revenue postings are against the WBS Billing Element associated to the work package and personnel number information is available against the entries which helps us determine the employee level revenue and profitability.

General Ledger (G/L) accounts to which entries are posted are driven by the EBRR configuration (SSCUI ID 102530). How this works is that a time sheet event results in the creation of a CO document on a GL account for Secondary Costs as we know. This GL account is maintained as a part of the source YT0.

YT0 is assigned as a source in assignment rule COSPTM. YT0 has the usage ‘200’ and since there is a revenue generated for the accrued costs via DIP profile using SD pricing, system tries to determine the revenue account maintained in G/L account determination. This revenue G/L account is maintained in the source YR1 with usage ‘100’ which triggers postings to Accrued WIP and Revenue Adjustment accounts.

COSPTM is the assignment rule associated with the revenue recognition key SPTM. SPTM is the default recognition key for ‘Time and Expenses’ contract.

A detailed explanation of this configuration has been provided in the blog here

As mentioned earlier, the calculation of WIP is driven using SD pricing. The time posting is simulated as a sales document line item by mapping the activity type to a product with related attribute . This mapping is carried out using the flexible billing profile configuration (SSCUI ID 103637). The pricing procedure assigned to the customer project sales org in pricing procedure determination (SSCUI ID 101118) then helps calculate WIP.

In our example, activity type T001 maps to product T001 via the billing profile configuration. Standard rate of 650 USD has been maintained for condition type PSP0 with Sales Organization/Distribution Channel/Product (T001) for 650 USD.

Pricing date determines the effective rate record and system sets pricing date equal to the last day of the timesheet date period (month) . A valid record as on this date is used for pricing calculation. In our scenario, pricing date is Sep 30 since timesheet date is Sep 9. The record is determined and an amount of 650 USD (1 Hr *650 USD) is posted as WIP (Amount in Transaction Currency).

Please note that WIP is calculated in project currency. In scenarios where the rate record is maintained in a different currency, pricing date (last day of period) is used to determine the exchange rate for translating the rate into project currency. Another point to be noted here is that the ‘Amount in Company Code’ currency is arrived at by translating the Amount in Transaction currency with the rate as on the project creation date. Project creation date is the date on which the project sales order has been created.

We will know look at a business scenario where a deviation has to be applied to the standard rates. For this purpose, in Step 25 of the pricing procedure, a custom condition type ZDEV has been configured in place of DCM2. ZDEV has been configured to apply a % deviation to the standard rate and is a copy of DCM2 but with a custom access sequence.

Using the access sequence configuration (SSCUI ID 103121 ), PCP0 was copied over as ZDEV and steps 115 and 116 were introduced to allow a % deviation to be maintained at a project/work package level or project level.

To allow this deviation to be applied during revenue recognition, we have also added the discount account associated to ZDEV via account key ERS to the source YD1 in the EBRR configuration.

We will now add a condition record for ZDEV at a Project/Work Package level for 10% and post a similar time entry as we did earlier.

In the G/L entries, you will observe that there is an additional credit posting of 65 USD in the Accrued WIP Account for the deviation amount and an additional debit posting in the offset P&L Account maintained in the configuration. This means that the revenue recognized is for 585 USD after reducing 10% from the standard rate of 650 USD.

In summary, you can achieve the desired revenue postings by customizing the pricing procedure. Also, if there are instances in which revenue recognition is failing or not posting to the right G/L accounts for certain projects, incorrect pricing procedure configuration may be a cause of this issue. When this happens, you can validate whether

• Customer pricing procedure is populated correctly on the customer master

• Customer Account Assignment group is populated correctly on the sales order which it derives from the customer master

Time Sheet Billing

Time entries posted on a customer project can be billed using the ‘Manage Project Billing’ app. This is a part of the project billing solution (Scope Item 4E9). As mentioned earlier, the billing profile configuration (SSCUI ID 103637) maps activity type to product. Using SD pricing, revenue is calculated and this enables billing. This blog here provides a detailed look into the billing profile configuration and pricing.

On the landing page of ‘Manage Project Billing’ app, we can filter for the required project. You can see details of the billing element including the billed, unbilled and to be billed amounts. Since we have posted two time entries for 650 USD and 585 USD, the estimated actuals and unbilled amount is displayed as 1235 USD.

On clicking ‘Prepare Billing’, details of the accounting entries with timesheet data and amount to be billed can be seen here. Please note that the ‘Billing Due Date’ filters out all entries that fall after the date. Also, any timesheet entry with a future work date is not displayed on the details screen for billing.

You can postpone and write-off entries on this screen. More details of this app and supported functionality are available in the documentation here. To proceed, we can click the Submit button and this should create a Billing Document Request (BDR). However, in this case we get an error!

Now this is an error in project billing that arises when there are pricing inconsistencies, typically, when pricing updates are made and they impact already posted time entries. In our scenario, it is because we have applied a deviation % on the workpackage and only one of the time entries have recognized this deviation. To resolve this error, we must run repricing for the project using the ‘Schedule Repricing for Projects’ app.

Once the job finishes, we can go back to ‘Manage Project Billing’ app. We can now see that unbilled amount and estimated actuals have been updated to 1170 USD (2 entries @ 650 USD after 10% deviation )

Also, note that repricing has made adjustment postings to the WIP accounts as well. (Use the ‘Project’ filter to view all the postings on the project)

Click on the Project Billing Request to proceed with billing. Click on ‘Submit’ and now the BDR is created.

The pricing error has been resolved. We can click on ‘Create Preliminary Billing Documents’ to create the preliminary billing document and from the ‘Manage Preliminary Billing Documents’ app we can click on Create Billing Documents to create and post the final billing document.

Another point to discuss here is that in the billing document, time entries are summarized into fewer billing line items. Generally, it is observed that time entries with the same Personnel No, Activity Type, Work Package, Work Item, and Work Period are summarized into a single billing document line item. If any of these attributes differ, it will result in a separate billing document line item. In our scenario, two time entries have been summarized into a single billing document line item.

Now, the billing document creates an accounting entry which debits A/R and credits billed revenue accounts

A posting on the billed revenue account once again triggers revenue recognition resulting in a credit posting on the Deferred Revenue (WIP Clearing) account and debit posting on the Revenue Adjustment (Unbilled Revenue) accounts. (G/L entries have been filtered using billing document as the reference document here)

Using the ‘Project’ filter, you can see that all WIP and adjustment accounts balance out to zero and only billed revenue is available. System calculates the profit of 970 USD and this is displayed as well.

One common requirement is to tie the billing document to the underlying timesheet entries. Here are some pointers on how this could be achieved using custom CDS views.

Firstly, we need to determine BDR document number from the final billing document or preliminary billing document. BDR is a preceding document to the final billing document. I_BillingDocumentItemBasic provides billing document item details and contains preliminary billing document details as well. This can be joined with I_SDDocumentMultiLevelProcFlow using the fields SubsequentDocument and SubsequentDocumentItem equal to BillingDocument and BillingDocumentItem respectively. I_SDDocumentMultiLevelProcFlow provides details about SD document flow.

PrecedingDocument and PrecedingDocumentItem from I_SDDocumentMultiLevelProcFlow gives us the BDR number and Item number when PrecedingDocumentCategory = ‘EBDR’.

PrecedingDocument and PrecedingDocumentItem with the BDR details as determined above can be joined on BillingDocument and BillingDocumentItem fields from I_ProjectBillingElementEntrFlw which is also available as an associated view of I_ProjectBillingElementEntry CDS view.

I_ProjectBillingElementEntry is a key CDS view in project billing. Using fields from this CDS view and its associated views, we can determine details of the underlying CO document for time entries and related details. Some of its associated views are:

• I_PrjBlgElmEntrJrnlEntrLink
  
  • Ledger, CompanyCode, FiscalYear, AccountingDocument and LedgerGLLineItem are primary key fields that can be used to join with the journal entry item CDS views
    
  • ReferenceDocument can be used to link with I_TimeSheetRecord using TimeSheetAccountingDocument field
    
• I_ProjectBillingElementEntrFlw
  
  • BillingDocument and BillingDocumentItem fields provide the BDR Number and BDR Item Number respectively. This can used to join with the billing document CDS views as discussed earlier
    
  • BillingReqdRevenueAmtinDocCrcy and BillingRequestedQuantity fields provide the billing amount in document currency and billing hours for individual timesheets

Details of the project billing CDS views can be found in the documentation here.