In Project System in SAP S/4HANA, you bill a project using corresponding functions from sales based on sales order items that are assigned to WBS elements of the project.
Due to this assignment, the resulting payment flows and actual revenues of billing documents are updated on the billing elements of the project and can therefore be compared to the planned revenues. Two functions for controlling billing processes in sales using project data are explained in the following sections: the milestone billing and resource-related billing of projects.
Milestone Billing
When you create a billing plan for a sales order item, you can derive the billing date, billing percentage, and the billing rules from the milestones of a project. As long as the milestones of the project haven’t yet been reached, the corresponding items of the billing plan are used exclusively for revenue and payment planning. In other words, they are locked for billing. However, a lock can be automatically released if the milestone of the corresponding invoice date receives an actual date. You can either set this actual date manually in the milestone, or, if it’s an activity milestone, it can be set automatically due to an activity confirmation. A billing run in sales then automatically generates down payment requests or invoices based on the unlocked items in the billing plan. If the sales order item is assigned to a WBS element, then the resulting actual revenues or down payment requests are updated in the project. This process is called milestone billing and is illustrated next using the example of a robotics project.
Let’s suppose that the customer agreed to a down payment of 10% of the target value of 200,000 USD at the start of the project, a partial invoice of 30% when an agreed-upon project goal is reached, and a final invoice when the project is completed. Corresponding milestones called Down Payment, Partial Payment, and Final Invoice were defined in the project and copied to the billing plan of the sales order. In Project System, planned revenues of 60,000 USD for the planned date of the Partial Invoice milestone and additional planned revenues of 140,000 USD for the planned date of the Final Invoice milestone are shown in revenue reports. In payment reports of PS Cash Management, you can also analyze the planned down payment (billing rule 4) of 20,000 USD, taking into account the payment conditions for the planned date of the Down Payment milestone.
An activity confirmation creates an actual date in the Down Payment milestone and documents the fact that the milestone has been reached. The actual date is automatically forwarded to the billing plan of the sales order and unlocks the down payment item. The billing of the sales order in sales results in a down payment request (FAZ document type) of the agreed-upon amount being automatically created for the unlocked item.
The amount is shown as a down payment request in the payment reports in Project System. If the customer’s down payment is entered in financial accounting for the down payment request, then you can also analyze this using the payment reports of Project System. The amount of the down payment request is reduced accordingly.
If the Partial Invoice milestone is also reached during the course of the project, then the second item of the billing plan is automatically unlocked due to the actual date of the milestone. The billing of the sales order now creates a partial invoice (controlled by billing rule 1 of the item). The down payment made by the customer can be settled proportionately or completely (see figure below). Actual revenues in the amount of the partial invoice are now shown on the billing element of the project in the revenue reports of Project System. You can use payment reports in Project System to track the invoice-related payment made by the customer that has been entered in financial accounting.
If the last Final Invoice milestone is reached in the project and the corresponding item is unlocked in the billing plan, then the billing of the sales order creates an invoice in which all the customer’s down payments, which haven’t yet been settled, are deducted from the receivables. Based on this final invoice, the remaining actual revenues are posted on the project and can be analyzed in reporting. The actual receipt of payment is also shown later in the Project System payment reports.
Resource-Related Billing
If the required services and materials for implementing the project haven’t yet been established before the start of the project, then you can’t agree on any fixed prices for the project processes with the customer. In these cases, you can’t bill fixed amounts in the way you could in the preceding example. Instead, you can create a billing using the actual costs of the project. For the billing, you use billing requests in which you can verify for the customer the services performed, material consumed, and additional costs incurred. This form of billing is called resource-related billing.
Like sales pricing, resource-related billing is also controlled by a dynamic item processor (DIP) profile that is stored in the sales order item assigned to the project. The DIP profile controls how the actual data of the project or the relevant billing structure for individual items of a billing request are to be summarized. Using SAP S/4HANA, you can also use actual costs from the Universal Journal as a source in the DIP profile of resource-related billing. For more information about defining DIP profiles, see SAP Note 301117. When you start the resource-related billing for the sales order item (Transaction DP91), you can analyze and, if necessary, still change the two-tier summarization of the actual data in the Expenses view and Sales price view.
The Expenses view contains hierarchically structured actual data, such as actual costs or statistical key figures entered in the project execution, summarized as dynamic items in accordance with the DIP profile settings. In the Expenses view, you can now decide which of the dynamic items are to be billed, temporarily postponed, or not included in the billing request.
In a second summarization stage, the DIP profile converts the dynamic items for material numbers. These can be material numbers of the consumed material components of the project or material numbers of defined material master records specifically used for the purpose of confirming an activity. Pricing occurs automatically based on these material numbers and, if necessary, on sales order data, such as the customer number, sales organization, and so on.
The Sales price view displays the hierarchically structured material numbers that are combined for individual sales document items. In the Sales price view, you can also analyze the conditions of the different sales document items determined via the pricing and change or add additional conditions (see figure below). You can now create a billing request that includes the summarized items and any items you adapted. The billing of the request in sales finally posts the corresponding actual revenues on the project.
You can combine the milestone billing (based on a billing plan in the sales order) and the resource-related billing of the sales order. Consequently, by using milestones in the project, you can control when resource-related billings are possible and whether resource-related down payment requests (billing rule 4) or billing requests (billing rule 1) are created in the process. This includes all combinations of fixed down payments, fixed billing documents, resource-related down payments, and resource-related billing documents.
In international companies, employees from different company codes are commonly involved in the project execution. The costs between the company codes are normally settled on a resource-related basis. Let’s look at an example of a cross-company code process for the robotics project.
The robot is to be built and sold in Germany, but parts of the construction are to be carried out by employees in the United States. Therefore, the project structure contains branches for both the company codes of Germany and the United States. In the company code for Germany (the requesting company code), a purchase order is created for the construction and assigned to the corresponding part of the project. In the company code for the United States (the delivering company code), a sales order is created because of the purchase order and assigned to the branch of the project for the US company code.
In the course of the project execution, the employees in the United States post their activities on the branch of the project provided for this purpose. The actual costs that result from these postings can now be billed on a resource-related basis with reference to the sales order. The billing leads to actual revenues on the branch for the company code for the United States. In contrast, the corresponding invoice receipt in the company code for Germany results in actual costs on the object to which the purchase order was also assigned.
The source Intercompany-Line Items is available for defining DIP profiles. With this source, you can use an alternative option to the one explained previously to map the resource-related billing of project activities between company codes. In this case, rather than a sales order being created for each individual project, it’s only created once (or once for each fiscal year) in the delivering company code, with the requesting company code as the customer. Only structures for the requesting company code are required within the projects themselves in this scenario. Employees of the delivering company code can also use these structures to directly post the activities they have performed. These cross-company code activities are automatically collected in the new source. A resource-related billing in Transaction DP93 based on the cross-company code activities finally performs all the required adjustment postings in accounting and posts revenues for the delivering company code. For more detailed information on resource-related billing between company codes and the necessary settings in Customizing, see the appendix of SAP Note 1461090.
Editor’s note: This post has been adapted from a section of the book Project System in SAP S/4HANA: The Comprehensive Guide to Project Management by Mario Franz and Andrea Langlotz.
Comments