Differentiating Cost and Revenue Settlement Scenarios

Within the marketing department at Bike Company SE, Ella, an enthusiastic intern, is actively involved in supporting marketing projects from a management accounting perspective. Recently, her manager set forth a new challenge for her: to plan for an impending fair in Madrid . This task requires some preparation steps, from the creation of master data, in-depth analysis of anticipated costs and revenues, to the final project settlement. Some reuse of data from the previous fair in Paris will be useful here. Notably, the fair in Madrid isn't exclusive to the marketing department; Sales and HR departments are also contributing. It is consequently crucial to allocate the costs fairly among these departments.

Considering this complex challenge, Ella turns to Chris from the management accounting team for guidance. Their past interactions were beneficial, and Chris' should be able to provide important insights for this task. Let's see what they talk about:

Having listened to the exchange between Martina and Ella, it's now time to focus on the possible settlement scenario for projects. Then you'll concentrate on the interest of the available tools to rationalize settlement and how they can help. You will also delve into a more sophisticated settlement-related feature: a source structure that can distinguish different settlement rule principles according to the type of posting receiver.

Let's begin with an analysis of the different types of settlement needs.

Projects and their WBS element(s) are usually used, for reporting purposes, for example, as interim posting objects.

First, several elements trigger the actual costs and revenues of a project:

• Material withdrawals and goods receipts

• Vendor invoices

• Customer billing

• Internal activity allocations, transfers, cost distribution, process costs, and overhead

• Confirmation of network activities

Then, as these costs and revenues occur and are posted, they should be passed on to receiving objects in a process called as settlement. This process, often launched at each period-end or once the project is completed, allows for cost and revenue transfer either to a single or multiple objects.

Settlement is not mandatory. You can process settlements for individual elements or collectively.

Before you can settle a project or a WBS element, you must decide in the settlement rule where and how you want the costs to be posted. It can be done through a:

• Basic settlement to settle 100% of the costs to some cost center(s) or G/L account(s) using one cost element.
• Extended settlement in the project/WBS element master record to settle costs to one or more receivers (WBS element, profitability segment, and so on) with differentiated accounts and methods.

The settlement scenario may vary depending on the context and the specified settlement profile:

• To monitor internal actions settled to cost centers (overhead project)
• To monitor internal actions settled to fixed assets (investment project)
• To monitor internal actions in parallel with other objects for reporting needs (statistical project)
• To display cost accounting sections of sales orders and include revenues that are not part of the company's core business (projects with revenues)

In the case of extended settlement, the settlement process is controlled using the assignments done in the settlement parameters on the master record. These parameters include the settlement profile, allocation structure, and the profitability analysis transfer structure.