ACM contract information and features
This chapter is a continuation of part 2 and will look at additional contract terms and features provided by SAP Agricultural Contract Management.
Part 1: https://community.sap.com/t5/enterprise-resource-planning-blogs-by-sap/acm-capabilities-in-a-nutshel...
Part 2: https://community.sap.com/t5/enterprise-resource-planning-blogs-by-sap/acm-capabilities-in-a-nutshel...
Deferred payments and credit sales
Please note: following chapter includes local requirements and processes that may not be supported in all regions. Implementation teams should check for the local regulations prior to activating these features.
Deferred payment is a process supported by SAP ACM contracts and settlement that allows farmers to sell their crops in one period, but defer the payment of that sale into a different period. This process may offer tax incentives to the farmer, which is why he might elect to do so.
Credit sale: this is a US specific term and regulation. If a payment following a grain delivery is deferred for more than X days, the contract must be reported as a credit sales. The number of days can vary between the different US states. A contract flagged as a credit sales may be subject to periodic audits and must therefore comply with certain audit requirements. SAP Agricultural Contract Management provides tools to support these audit requirements.
Additionally, SAP ACM provides additional reporting offerings like the “Credit Sales Report” to track or identify deferred payments and as part of the Daily Grain Report has specific reporting key figures to report how much unpaid quantity is locally stored in an elevator. The DGR (Daily Grain Report) will be described more in detail in a future blog.
Contract snapshots and amendments
Like many other documents in the agricultural industry, contracts are subject to frequent changes like establishing new prices, maintaining fees or updating other terms and conditions. Some of those changes are more relevant for the company’s internal tracking, while other changes affect the contractually agreed terms and need to be captured and reported as an official amendment which may also need to be signed by the involved contract parties.
Snapshots: ACM provides the ability to define the contractual fields that a company deemed as snapshot relevant. This means that all changes to those fields will be captured as a new snapshot and any change to those fields will be logged and recorded. Authorized end users may go back any time into the past to see every change that was made in the contract. The person who made the change has also the ability to document the specific change he/she made in a free text field; example: “In mutual agreement after a phone call with farmer X on Feb. 8th 2024 the following contract terms have been updated”. Besides audits, this can be helpful information for the person who needs to approve the changes made to a contract.
Amendments: Amendments leverage the above explained snapshot functionality of tracking and documenting contract changes. However, the distinction is that changes to fields which are configured as amendment relevant will also be sent to the counterparty as an official contract amendment form that needs to be accepted.
Example: Changes to internal text fields may be tracked as a snapshot for internal reporting and approval purposes, however they are not passed to the counterparty. Other changes like updating the incoterm or altering price information have to captured as an official amendment as they need to be sent to the counterparty for acceptance.
Contract closure
ACM offers the ability to close contracts at the end of their lifecycle either manually or automatically. Closed contracts are not relevant for risk reporting (like position reporting or MtM) and companies may therefore choose to close eligible contracts frequently to limit their impact on the risk reports.
When can a contract be closed? ACM delivers several validations that need to be fulfilled before a contract can be closed and additionally customers can add their own validations. ACM standard validations include i.e. checks that each delivery against the contract needs to be fully settled and realized before the contract can be closed or that the contract needs to be expired by more than X days, with x being configurable for .
How can the contract be closed? Contracts can be closed either manually by the end user or also through a periodic scheduled job. The difference is that the business may choose to execute different validations for manual vs. automatic closure. Some hard stops for automatic closure could be configured as an information or warning only for the manual process.
Example:
- Contract A had a total contract quantity of 100,00 BU with 10% over-/ underfill tolerance (= 10,000 BU tolerance)
- Actual delivered quantity against the contract 89,990 BU which is just barely outside the tolerance
- Contract closure validation is implemented that defines that only contracts within the tolerance can be closed:
- As the contract is outside the tolerance the automatic contract closure batch job would skip this contract
- If permitted the trader may choose to close the contract regardless as it is just outside the tolerance. The validation is set for him as a warning only and the trader may use his best judgement to decide to close the contract or not.
Other validations might be a hard restriction for both manual and automatic closure. For example, all deliveries must be fully invoiced and realized.
