How Severstal Optimized Contract Payment Monitoring in SAP MM
Various software solutions for optimizing Severstal processes are our passion. We are constantly thinking about what else to write or customize for our tasks in order to solve them faster, easier and more conveniently. Today we will talk about software that allows you to control payments to suppliers and contractors.
Such large-scale production as ours cannot do without monitoring: failure to comply with payment obligations can lead to huge losses, serious reputational risks and other very unpleasant consequences for a giant company.
Valeria Perova, SAP Material Management (SAP MM) consultant at the Severstal-Infocom information and communication technology center, will talk about how Severstal monitors the fulfillment of payment terms for contracts with suppliers.
Severstal has various payment terms that the company negotiates with suppliers and contractors. Often, this is not one payment. Often, suppliers work on an advance payment basis, which can also be divided into several payments. And we or we can provide delivery services that are not included in the cost of delivery of inventory items (I&C), and delivery is paid for differently. In general, tracking the execution of all possible payment options under purchase agreements is not so simple – you need to think through the logic.
We implemented the first ERP based on SAP back in 2011. That's when the idea of a solution that could track the fulfillment of payment terms for procurement contracts was born. After development, it evolved for ten years, acquiring additional functions, not on its own, but along with changes in the company's business processes. In 2021, we switched to SAP S/4HANA, but the conceptual solution moved to the new system unchanged. Of course, there was a refactoring of the technical implementation, but this is not the story, but how you can refine the payment terms settings in SAP MM to suit the nature of the company's payments.
Standard setting of payment terms in SAP MM and why we didn’t like it
SAP, based on best practices, provides a standard solution for the procurement process. Without much detail, it looks like this:
In the system, you can create such a reference element as a payment condition. The settings allow you to set discounts for it when paying before a specified date of the month, as well as determine the date from which the specified days should be counted to calculate the payment date. This can be, for example, the date of the transaction, document, input, or simply a specific date of a month.
The created payment condition will be specified in the counterparty reference book setting for a specific supplier. This can be specified at the stage of creating a contract or purchase order.
When creating a purchase contract, the payment term will be automatically pulled from the counterparty settings or it can be specified manually. The term is then moved to the purchase order and is ultimately inherited to the incoming invoice. There, the base payment date will be determined and the payment date will be calculated based on the parameters specified in the payment term.
What's wrong here? Conceptually, the idea of maintaining a payment terms directory with customizable calculation parameters is great. But for solving control problems, the standard implementation of the directory in the purchasing section looked quite limited for the following reasons:
The payment terms directory does not allow for a full reflection of the structure of complex payment terms. For example, there is no way to formalize the presence of an advance payment and subsequent payment in one payment term.
It is impossible to organize the calculation of the payment date depending on different dates. For example, from the date of transfer of ownership, the certificate of work performed, etc. The entire countdown is based on the dates in the incoming invoice.
The solution does not allow you to set more than one payment condition for a contract, and there is no way to maintain its validity period.
No controls are provided in the purchasing chain. We dreamed that as one payment condition was specified in the contract, it would be inherited in the specifications and incoming invoices without the possibility of change.
An analysis of the standard reference book and our requirements showed that it will definitely need some revision, the question is how?
The options boiled down to two concepts:
Refuse the payment terms reference book in favor of the dynamic constructor when creating a contract.
Modify the directory.
And then in both cases it is necessary to develop inheritance and controls.
How we improved payment terms in SAP
The dynamic designer is not the worst solution. In one of the variations, we have 1C users living on it. But still, it is SAP. Firstly, when choosing a solution, you should not forget about the features of the platform in which it will be implemented (SAP). Secondly, the terms of payment are a reference book that is intended not only for the procurement module, but also for sales and finance, so it is necessary to make a unified solution for all modules, and not to breed different implementations. So we leaned in favor of developing a standard SAP reference book and adding the payment terms we need to it.
The structure of elements in the standard payment terms directory and how we optimized it
In the SAP paradigm, a payment term consists of a header and a contribution list, i.e., a percentage indication for splitting accounts payable or receivable when posting an incoming or outgoing invoice. The payment term can be used either in the sales module, or in purchasing, or in both modules.
To this standard story we added two tables: one for storing long texts in different languages, and one with additional contribution attributes. Here are some of the attributes:
percentage of contribution in the total amount of the document;
days of payment grace period;
form of payment (prepayment, postpayment);
control event (determining from which date of the system document to count the days of the deferment).
The result is a reference book that can be conditionally divided into two groups:
Simple or elementary payment terms – have one payment of 100%.
Compound – have more than one contribution. The sum of the percentages of all contributions cannot exceed 100%.
The contribution of a compound condition must include a reference to a simple payment condition. Thus, when “assembling” a complex condition, you need to find a simple one with suitable attribute values and do not forget to specify the percentage for each contribution.
Our option for using payment terms at all stages of procurement
The subsequent use of the payment terms directory in purchasing documents in the SAP MM system looks like this:
Contract. The digital contract card with the supplier or contractor specifies the elements of the payment terms directory and their validity periods. At the same time, they must correspond to the payment terms specified in the contract. This document is the basis on which all subsequent controls are based.
Purchase order (specification). When creating a purchase order, a reference to the contract is mandatory. In this case, only one payment term must be specified in the order, and it must be valid in the reference contract. If a payment term containing advance payments is specified, the advance payment amount is calculated in the order in accordance with the percentage of the payments specified in the payment terms, as well as the planned date for payment of the advance payment.
Advance payment request (APR). If the specification provides for prepayment, then you can declare an advance payment via a TAP document. We abandoned the standard ME2DP transaction for entering this document, since it was important for us to implement control over the amounts of advance payments for contributions that correspond to the payment terms from the specification. For this purpose, a separate monitor was developed that does not allow you to declare a larger amount for payment than is required by its terms.
Incoming invoice. When entering an incoming invoice from a supplier, the payment term is inherited from the specification (and cannot be changed). Then the base payment date is automatically calculated based on the contribution attributes of the payment terms. So if the contract requires the invoice amount to be paid in two payments, say 30 and 60 days from the invoice date, then we will have two debt items, each with its own payment date.
An example of calculating a payment in SAP “in a North-West manner”
Let's say we have agreed with a supplier to purchase some inventory items for the amount of 10,000 rubles without VAT. We will pay for the delivery according to the following principle:
advance payment of 10% of the cost of inventory items within 15 days from the date of specification;
advance payment of 30% of the cost within 20 days from the date of specification;
final payment in the amount of 60% of the value of inventory items within 30 days from the date of transfer of ownership.
In order to regulate such payment, a corresponding composite payment condition with an installment indicator (standard requisite for splitting) and three installments (in the diagram below, this is the NSI block “Composite UP S002”) must be created in the system, consisting of three simple payment conditions (in the diagram, this is the NSI block “Simple conditions” A001, A002 and K001).
When creating a contract in the system, the purchaser must indicate the payment condition code S002 (in the diagram – block MM “Contract for the purchase of inventory items”).
Next, a delivery order or specification is entered into the system (in the diagram, the MM block “Delivery order”) for 10,000 rubles excluding VAT from 10/01/2022. Payment term S002 is inherited from the contract, the total amount of the advance payment is calculated, according to the terms of 40% of the cost of the specification – this is 4,000 rubles. The planned date for the fully paid advance is 10/19/2022. The second advance will be 20 days from the date of the specification, we count it, including the starting date itself.
According to the specified condition S002, we declare payment via TAP (in the diagram – block FI, “Documents TAP 1 and TAP 2”) separately 1000 rubles + VAT with the payment date of 14.10.2022 (the first installment of the condition is 10% of the cost of inventory within 15 days from the date of the specification). And separately declare 3000 rubles + VAT with the payment date of 19.02.2022 (the second installment is 30% of the cost within 20 days from the date of the specification). It is not possible to declare payment for more than is required by the terms of the contract.
When reflecting the fact of delivery in the system, the date of transfer of ownership is filled in. In the example under consideration, this is 01.11.2022 (in the diagram — the MM block “Document of receipt of materials”). There is no such date in the standard SAP version, but Severstal has its own solution for automatically calculating this date (which we will discuss in another article).
After receiving an invoice from the supplier for 12,000 rubles with VAT, an incoming invoice document is entered into the system (in the diagram, the MM block “Incoming invoice”) with a link to the purchase order. The payment terms from order S002 are copied into it (it cannot be changed). The basic payment date is automatically calculated based on the post-payment contribution of 11/29/2022 – 60% within 30 days from the date of transfer of ownership.
When posting an invoice, an accounting document is created (in the diagram, the FI block “Financial document of the invoice”). In it, the invoice amount is divided into three lines by the number of contributions in the payment condition in proportion to the interest in the contributions. Each contribution has its own basic payment date, and it is assumed that the first two lines should be aligned with advances, and the third line for 7,200 rubles is paid.
In conclusion: there was a fly in the ointment, but we were not upset.
It should be said that during the initial development of the solution back in 2011, due attention was not paid to the normalization of the payment terms directory. Because of this, 10 years later we received an excessively large directory and dissatisfied users. When switching to S/4HANA, we did not repeat the mistakes of the previous implementation.
To migrate the reference book to the new system, our NSI, sales and procurement teams (both IT and business) worked to remove duplicates. Only attributes of reference book elements were taken into account. If there were conditions with the same attributes and different text, we left only one of them and blocked the rest. In addition, the reference book itself was maintained in the SAP Master Data Governance system, observing the principles of normalization and transferring verified payment terms to SAP ERP.
____________
Your companies probably have their own payment control solutions. Please tell us about them in the comments.
