Mastering the Basic Concepts of Settlement and Revenue Recognition

Settlement is a critical part of the contract management process, serving as an invoicing and billing pre-processor that consolidates multiple transactions against one or more contracts. It uses the schedules and terms specified in the contract to calculate an adjusted price, which is then used for payment issuance or customer billing.

In the basic process flow, settlement takes place after the Load Data Capture (LDC) has been completed and application documents have been created and applied against the contract. The application status must either be provisionally applied or finally applied in order to initiate the settlement process.

During settlement, an invoice is generated, and an Agency Business Document (ABD) is created to accumulate the results of the settlement calculations. The ABD acts as an intermediate step before the final invoicing process, where detailed calculations from the settlement document are summarized based on accounting logic.

The settlement process typically involves multiple steps, including creation, release, and approval of the settlement. Automation can be employed using business rules and batch jobs to streamline the process. The settlement document contains all the intricate details of the calculations, while the ABD presents the summarized results before final invoicing.

The structure of settlement documents consists of a settlement group at the top level, with settlement units beneath it. Each settlement unit would be equivalent to an application document and contains all the necessary details, analysis results, and weights related to that specific application.

Multiple settlement units can exist within a single settlement group. For example, if we want to run settlement for all the loads of a specific counterparty on a given day, we would have one settlement group with multiple line items representing each application document for that counterparty.

At the group level, we find information such as the document category, document types based on the business scenario (for example purchase, sale, intra or intercompany), counterparty information, organizational data, and various possible statuses for tracking purposes. Additionally, we can view details related to incoterms, fees, freight, and payment splits to different counterparties. If there are any liens, the relevant information will also be displayed at the header level.

Moving down to the settlement unit level, we find the actual settlement document with its specific DPQS, optionality, expenses passed to the counterparty, fees, and the assigned contract. Here, we also see the pricing details associated with the application documents.

Here, we have a more detailed view of an ABD document that includes essential information like the counterparty details and the settlement group. The payment terms, material quantities, and other relevant information are displayed at the item level.

The settlement work center is a central hub for various settlement-related activities. It offers a selection screen that allows you to choose specific documents for settlement based on your criteria. In this work center, you can create new settlements, make changes to existing ones, and release them for further processing. Additionally, you have the option to perform settlement adjustments and reversals when needed. The work center also facilitates handling customer returns, managing liens, and processing storage settlements. Moreover, it provides valuable insights from the Commodity Pricing Engine (CPE), enhancing the settlement process' efficiency and accuracy.

This view presents a detailed layout at the header and the item details level. The settlement unit, representing the application level, is broken down into multiple tabs offering various functionalities and details.

Under the settlement amounts tab, we can observe the summarized premiums or discounts applied. At the item level, you can find the results of DPQS calculations and any tolerance evaluations performed. The pricing details are shown under the pricing tab, including optionality premiums or discounts, if applicable. Additionally, you can view expenses for service providers that are passed on to the counterparty, as well as detailed CPE pricing, and information related to fees.

SAP Agricultural Contract Management categorizes settlement documents into different categories such as provisional settlement, final settlement, or adjustment settlement. Reversals and returns can also be tracked based on their type, whether full or partial.

When it comes to provisional settlements, the system automatically determines it's category based on various factors. It checks if you have provisional pricing, if you are working with estimated weights and grades, and if there are any invoicing adjustments pending based on actual weights and prices received. Multiple provisional settlements can be created per shipment.

For final settlements, the system looks for established prices and complete price fixations for all components for the application document. Additionally, it verifies if the actual governing weights and analyses are present in the contract. In case of previous provisional settlements, their total is calculated, and the delta is derived by subtracting them from the final settlement.

Settlement adjustments come into play when you need to account for additional financial adjustments not captured in the final settlement. These could include overlooked expenses for services or additional fees, among other things.

Regarding reversals, they can be full, where the entire settlement group and all attached units are credited, or partial, where only selected settlement units are reversed.

Return settlements are relevant for final settlement documents whose revenue has been recognized and involve matching Return Application Documents (RAD) with sales or purchase application documents.

The settlement statuses are defined as follows:

Provisional

A provisional price based on estimated weights and grades. It is possible to have several provisional settlements per shipment.

Final

An established price based on actual governing weights and grades.

Adjustment

Created after the final settlement document has been invoiced. Captures any additional financial adjustments made to the preceding invoice or billing document due to additional expenses, additional fees, or DPQS characteristic charges.

Full Reversal

Process where credit for the entire amount of the settlement group is created.

Partial Reversal

When only a part of the settlement group is reversed, which means only a few settlement units out of a group.

Return Settlement

This is only valid for a final settlement group whose revenue has been recognized and is invalid for a provisional settlement scenario. Return settlement allows for RADs to be selected for settlement creation.

In the settlement process, various types of settlement amounts can be observed, including the gross amount, which represents the total amount before any adjustments or deductions. Additionally, provisional pricing and full pricing from the contract are used to describe the settlement. The DPQS adjustment displays any changes made to the pricing based on quality variations. Furthermore, the settlement process also includes the display of fees and expenses if they are being passed on to the counterparty. Lastly, Foreign Exchange (FX) negotiation is possible, making it convenient when dealing with different currencies.

Contract settlement involves the evaluation and allocation of pricing lots associated with a contract line item. There are two methods for price allocation in the settlement document:

1. Provisional Pricing: During provisional settlement, available pricing is distributed based on pricing distribution rules. Provisional pricing is used for quantities where pricing is not established. This process doesn't modify existing pricing lot distributions.
2. Final Pricing: In the final settlement, pricing lots are allocated to the specific load being settled, following pricing distribution rules. For final shipment settlement, pricing lots that were previously distributed to other loads can be undistributed and then redistributed to the application document being settled.

There's also a feature that allows price overriding specifically in the provisional settlement:

• This functionality permits overriding prices at the item level during provisional settlement.
• When the override price is copied into the settlement document, the settlement values are recalculated to reflect the changes.

It's important to note that this price overriding feature is only applicable to provisional settlement and is not available in the final settlement process. The override can be performed through the change settlement mode in the work center, where a popup allows you to enter the new price and initiate the recalculation of the settlement values accordingly.

In the settlement process, when there are lien holders defined for a vendor, the payment to the vendor is always made by check, and the check bears the names of both the vendor and the lien holder. Here's how the lien process works:

1. Generation of Settlement Unit/Group: When a settlement unit or settlement group is generated, the liens associated with the vendor, commodity, state, country, and dates (including the current settlement date) are automatically retrieved.
2. Lien Retrieval for Partnerships: If the vendor of the settlement is in a partnership, all the liens associated with the partnership and the other vendors in the partnership will also be retrieved.
3. Deactivating Liens: At the settlement unit level, there's an option to deactivate a lien for a particular settlement unit by deselecting the Active checkbox.

The use of liens may vary depending on regional regulations and practices. In the US, it is common for checks to be used for payments and for lien holders to be included on the checks. This is often a regulatory requirement to ensure that lien holders are also involved in the payment process. However, this specific practice may not be applicable or common in other regions, like Europe, where different payment methods and regulations might be prevalent.

Revenue recognition in SAP Agricultural Contract Management is only relevant for final settlements and is not required for provisional settlements.

Revenue recognition is the process of recognizing the revenue and related expenses on the financial accounts of the firm when the contract quantities have been executed and settled. This process involves recognizing revenue when certain indicators, such as title transfer and other revenue recognition criteria, are met. Along with revenue recognition, the cost of goods sold and any accrued expenses and service revenues are also recognized.

In some cases, invoices are issued before the final price determination or title transfer occurs. For example, when contract quantities are delivered with lengthy transit times, and the governing weights and analysis are not determined until after arrival at the destination, revenue must be deferred, and associated expenses are accrued until the final title transfer and price determination take place.

Revenue recognition in SAP Agricultural Contract Management is event-based and occurs during the final settlement process, once all the necessary criteria have been met. The revenue recognition processor is run to create a posting document that recognizes revenue and cost of goods sold. This processor also updates certain quantity types in the contract and removes the risk from risk and position reports after the final settlement. The posting document used for revenue recognition is specific to the ABD document type.

• The Purchase Realization/Revenue Recognition monitor is an SAP GUI ALV-based report that displays data and other related documents from the event registry.
• The monitor only displays data and does not allow users to change records (manual changes to settlement event indicators are not allowed).
• A selection screen allows you to enter the selection criteria to retrieve the records from the event registry.