WO2025104710A1

WO2025104710A1 - Purchasing system

Info

Publication number: WO2025104710A1
Application number: PCT/IB2024/061476
Authority: WO
Inventors: Yechiel YONGREIS
Original assignee: Individual
Current assignee: Individual
Priority date: 2023-11-16
Filing date: 2024-11-17
Publication date: 2025-05-22
Anticipated expiration: 2026-05-16

Abstract

A computer-implemented method for synchronizing between methods of payment of a second party [customer] to a first party [the user / a retailer] for items supplied by a plurality of third parties [suppliers], and subsequent methods of payment by the first party to each of the third parties for additional goods, the method including: receiving a record of purchasing activity at the retailer for a predetermined period of time; organizing purchased items according to [supplier] each third party that supplied the items; for each third party, listing immediate payments and deferred payments separately for the purchased items; calculating a total value of the immediate payments and an interim value of the deferred payments; generating a message indicating the total value of the current payments for each third party; and outputting the message via a graphical user interface (GUI) or an application program interface (API).

Description

Purchasing System

FIELD OF THE INVENTION

The present invention relates to purchasing systems, and, more specifically, to a purchasing system that synchronizes payments from customers with payments to suppliers.

BACKGROUND OF THE INVENTION

Payments for products are made using different payment methods, for example, by credit cards, checks, cash, etc. The current payment systems do not provide synchronization between the products being purchased and the method of payment. For example, as shown in Figure 1, customer A buys basic products such as bread, milk, eggs, fruits and vegetables, etc. and pays with a credit card in three installments, while customer B buys consumer products, for example, washing powder, toiletries, cleaning products, perfumes, etc. and pays in cash. The business owner does not distinguish between the products which are purchased and the payment method, and uses the cash paid by customer B to pay the supplier of the products paid by customer A with the credit card. Consequently, the business owner requires additional credit from the suppliers, increasing the debt with the suppliers, such that the purchasing system is out of synchronization between the products it sells and the products it buys.

SUMMARY OF THE INVENTION

According to the present invention there is provided a computer-implemented method for synchronizing between methods of payment of a second party [customer] to a first party [the user / a retailer] for items supplied by a plurality of third parties [suppliers], and subsequent methods of payment by the first party to each of the third parties for additional goods, the method including: receiving a record of purchasing activity at the retailer for a predetermined period of time; organizing purchased items according to [supplier] each third party that supplied the items; for each third party, listing immediate payments and deferred payments separately for the purchased items; calculating a total value of the immediate payments and an interim value of the deferred payments; generating a message indicating the total value of the current payments for each third party; and outputting the message via a graphical user interface (GUI) or an application program interface (API).

According to further features in preferred embodiments of the invention the method further includes providing a machine learning (ML) model configured to predict a ratio of immediate payments to deferred payments, per month, over a predetermined number of months.

According to still further features in the described preferred embodiments the method further includes training the ML model on historical financial data and ongoing financial activity of the first party.

According to further features the method further includes predicting, by the ML model, a ratio of immediate payments to deferred payments for items supplied by each third party, per month, over the predetermined number of months, wherein the prediction is based on the historical financial data and the respective interim value of the deferred payments for each of the third parties.

According to further features the method further includes generating a message with a respective suggested deferred payment plan for each of the third parties based on the respective predictions. Outputting the message via the GUI or the API

According to further features the historical financial data includes changes to trends in payment methods around cyclical events.

According to further features the method further includes receiving a deferred payment plan, for a given time period, from one third party of the plurality of third parties; monitoring ongoing purchasing activity, over the given time period; generating predictions, by the ML model, of interim values of deferred payments per month over the given time period based the ongoing purchasing activity; comparing the predictions to the deferred payment plan; generating suggestions for increasing the purchasing activity, if necessary, to match the deferred payment plan; and outputting the suggestions via the GUI or the API.

According to further features increasing the purchasing activity includes providing discounts for items supplied by the one third party that provided the deferred payment plan.

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments are herein described, by way of example only, with reference to the accompanying drawings, wherein:

FIG. 1 is a prior art depiction of a common purchasing system;

FIG. 2 is an example of a method of payment to suppliers;

FIG. 3 is an example of a method of payment to suppliers; FIG. 4 a flow diagram 400 of the processing steps employed according to an embodiment of the system;

FIG. 5 is a flow diagram 500 that is linked to the flow diagram 400;

FIG. 6 is a flow diagram 600, linked to diagram 400.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

The principles and operation of a purchasing system according to the present invention may be better understood with reference to the drawings and the accompanying description.

The present invention refers to an automatic purchasing system which synchronizes the method of payment used by buyers of products (in some embodiments this occurs at the time when the products are purchased) to payments made to suppliers of those products, based on the method of payment used by the buyers. The system includes means to automatically enter data associated with the products sold and the payment methods used by the buyers when purchasing the products, and a control system which includes an algorithm that associates the entered data and a corresponding supplier of the product.

Payment received from a buyer for a product, for example, a cash payment, will be transferred to a dedicated area, such as business cash register or other dedicated point of sale (POS) unit. This case will be allocated for paying the supplier of the product in cash. This may be particularly advantageous as the business may receive discounts on the products it purchases in cash.

Payments received from buyers in a deferred form, for example, by credit card installment payments and/or postponed checks, will be transferred to a second dedicated area, such as a business credit register, and will then be allocated for paying the suppliers those purchased products in a deferred form.

Examples of these methods of payment to suppliers are shown in Figures 2 and 3 which show the different types of payments received distributed to all the suppliers based on the manner of payment received for purchased products. Exemplary scenarios are described below with reference to Figs. 2 and 3.

Example 1.

Figure 2 shows Customer A paying for products in 3 installments (incidentally using 3 forms of payment) 1/3 cash, 1/3 with a postponed check, and 1/3 with a credit card. (Alternatively, the customer could have paid using three checks, two of which being postdated, or a credit card payment in three installments.) The business pays the suppliers of the products purchased by Customer A according to the same payment schedule that the customer paid for the product (e.g. 1/3 in January, 1/3 in February, and 1/3 in March).

Example 2

Fig. 3 shows Customer B paying for products in a single installment (e.g., cash). The business pays the suppliers of the products purchased by Customer B according to the same payment schedule that the customer paid for the product (e.g. in a single installment in January).

The system of the present invention is particularly advantageous in that the business, by automatically allocating payments received in cash and in deferred payments to the product suppliers according to the payment method used by a customer for a product provided by the supplier, enables the business to be more profitable by using the cash payments to obtain better pricing from suppliers. It additionally enables the business to increase its customer base by providing lower prices and improved payment terms.

Logically, it would make sense for a customer to pay for perishables in cash and shelf items in installments. Assuming that the term “installments” refers to equal payment portions, paid monthly, adding up to the total cost of the product. If the customer consumes the perishables completely each month, then this perishable / consumable product should be paid for in cash (single installment, single check). If the product lasts for a number of months, such as floor cleaner, washing powder, light bulbs, washing sponges, etc., this is termed herein a “shelf product”. Shelf products can be paid for over a small number of months (e.g., three months), in installments (with no interest).

Long-term products, such as buckets, furniture, tools (hand drill, broom, screwdriver, etc.), washing machines, televisions, cell phones etc., can be paid for over an extended period of time, in installments (some of which may be charged with interest).

Supermarkets usually sell perishable and shelf products all mixed together. Accordingly, they have daily or weekly suppliers and monthly suppliers. For example, bread and milk are provided daily or weekly. Cleaning products may be supplied monthly or even quarter-yearly. Following the logic above, it would make sense that daily or weekly products are paid for in cash, while shelf products are paid for in installments, with highly priced items having longer payment terms.

There is provided herein a system and computer-implemented method for an owner of a business (retailer, also referred to as the first party) that has multiple suppliers and multiple customers, where payments are made by the customers in various modalities and payments to the suppliers are made in various modalities. The terms modalities, payment methods and variations thereof, as pertinent to the present invention and therefore as used herein, refer to whether payments are current (i.e., similar to cash changing hands, but may also refer to a currently dated check or a credit card payment) or deferred (e.g., a post-dated check or credit card installment from the second installment and on).

The present system uses a computer-implemented method to synchronize between the customers’ (referred to as the second party) methods of payment for products of a given supplier and the methods of payment to the suppliers (referred to herein as a plurality of third parties, each supplier being a separate third-party or third- party entity). Such synchronization allows the user (business owner / retailer) to leverage payments from the customers in the most efficient and profitable manner.

Working capital is money that is reinvested into the company on an ongoing basis (in most cases this happens over a periodic cycle such as a monthly cycle).

Gross profit is the pool of money from which all business expenses are paid. Monies remaining after business expenses are referred to as the net profit. The gross profit may not actually be realized at present due to the fact that the customer paid in installments, such that user / owner does not actually have the money in hand yet. If there is a short fall in the working capital, it is not uncommon to draw funds from the gross profit to cover. Therefore, by effectively managing the working capital, there is less draw on the gross profit funds and an increase in the net profit. If the working capital is handled effectively, good payment practices can help leverage better deals from suppliers and thereby grow the profit margin for products from those suppliers without raising prices and/or allowing the user to be more competitive by lowering prices without lowering the profit margin.

When a user sells inventory to a customer, the products are usually a mixed batch. For example, a shopping cart in a supermarket is full of products that originated from many different suppliers. The user may know exactly how much inventory he has at any given time (this can be determined, for e.g., when every purchase is itemized on the bill, and X number of units that were just sold are deducts from the known number of Y units in the current inventory). Even though this generally does not work in the exact same manner for weighed goods, nonetheless similar processes can be used to estimate inventory based on itemized sales of these weighted goods.

However, there is no process or system to date that manages, or even attempts, to correlate the method of payment that was used to the items that were sold. The term ‘method of payment’ is being used here to generally refer to whether the payment was immediate (cash / money in hand) or a deferred / partially deferred payment.

Retailers (an example of users of the instant system) often work with suppliers in a very dynamic manner. A shop owner often orders products on credit and then has to deal with the supplier who demands payment for products already supplied (and possibly even sold by the shopkeeper). Each supplier has their collection apparatus (usually one or more staff members) who send out reminders, call frequently, and/or issue threats of embargo if payments are not received in a timely manner. Conversely, the store owner may bargain for better prices by promising / providing prompt payment as opposed to installments or outright deferred payments.

The present system and method allow for the user / owner / retailer to leverage cash payments and/or give realistic repayment plans by providing synchronized data to the user. Additionally, some products have a high markup price (i.e., the owner is making a large profit on this item) whereas others have a lower markup price or are even sold at cost. As such, what will often happen is that monies received from products with a higher markup will be used to pay suppliers for products that potentially have a lower markup, thereby spending the higher revenue instead of banking it. As an additional tier to the system, products can be separated by markup level.

In addition, predictive models, e.g., Al or other machine learning models may be pre-trained and/or simultaneously/consistently retrained to recognize patterns in, for example, customer payment trends, and predict or suggest payment methods to offer to suppliers based on forecasted payments / collections.

For example, over religious holidays, there is usually a predictable uptick in certain purchases, such as costumes and candy over Halloween; poultry, meat, and groceries over Passover; dairy products over Pentecost, etc. While the higher volumes of purchases of these products are predictable, the payment methods may vary widely from place to place and customer to customer. Trained and locally running Al and machine learning models adapt to the clientele and predict, over time, the ratios of payment methods. The AI/ML can then generate suggestions for payment plans for each supplier based on the predictions. These suggestions, when presented to suppliers, give the suppliers reasonable payment schedules and increase the user’s reliability, and hence provide leverage or bargaining power for getting better prices for products.

The Al-based predictions / suggestions enable the owner/user to devise better strategies for interactions with the suppliers. In the meantime, the system automates the real-time calculations for allotment of funds based on actual immediate and deferred payments.

If a delta begins to form between a prediction and the actual collections, i.e., after a certain time from the initial prediction (e.g., two weeks into the month, when the prediction was made at the beginning of the month), a new projection of the payment ratios is made, based on real collections to date, the system may suggest, based on the Al model, to place certain items on sale in order to drum up either immediate or deferred / installment payments as needed.

In some example embodiments, the Al / ML models may monitor current affairs and incorporate new data into the predictions. The current affairs may be a news item announcing a rise in fuel prices which affects the pricing of goods. Alternatively, a news item may report that a local factory is laying off many workers, which is likely to affect the payment methods of a large group of people.

Figure 4 illustrates a flow diagram 400 of the processing steps employed according to an embodiment of the system.

At step 402 a record of the purchasing activity for a predetermined period is received. The purchasing activity includes the item name

At step 404 the purchased items are separated by supplier.

At step 406 items for each supplier are separated into immediate and deferred payments.

At step 408 a tally / sum of currently available funds per supplier and a second, interim tally of deferred payments are calculated.

At step 410 a message is generated indicating currently available funds per supplier.

At step 412 the message is displayed / output via a graphical user interface (GUI) or an application program interface (API). Some methods and systems include Al modules or trained machine learning models to provide predictions. Figure 5 depicts a flow diagram 500 that is linked to the flow diagram 400. In an example embodiment, the interim tally of deferred payments, calculated at step 408 is expanded in step 510 to separate deferred payments by month.

At step 512, the Al / ML model calculates, estimates, or predicts amounts of funds that will be collected, per supplier, for each subsequent month after the current month.

At step 514, the Al / ML model generates a suggested deferred payment plan for each supplier based on the estimates / predictions in step 512.

At step 516, outputting the suggested plan in a message via a graphical user interface (GUI) or an application program interface (API)

In some embodiments, the estimates / predictions are further based on cyclical data (e.g., payment methods or trends around special dates such as civil or religious holidays) from previous years. This data can be used to pre-train the Al / ML model and/or is gathered on a continuous basis of monitoring the payment methods (current payments or deferred payments) over time. Therefore, according to embodiments, at Step 502 the Al /ML model is trained on generic financial data and/or, at optional step 504, [further] trained on specific financial data from the preexisting financial system of the user.

Figure 6 depicts a flow diagram 600, linked to diagram 400 and 500. Alternatively, in some embodiments, the process depicted in flow diagram 600 can be a standalone process, but employing relevant steps from flow diagram 400 for isolating purchases per supplier according to immediate and deferred collections.

At step 616 the system receives a deferred payment plan from a supplier. Hopefully, this plan is the same as the suggested plan. Whether or not the payment plan is the suggested payment plan, or when dealing with a payment plan that is not a product of the instant system, the system receives the payment plan and, at step 618 monitors the collections over the deferred payment plan time period.

At step 620 the Al / ML generates projections based on the actual collections during the monitored period. The monitoring includes matching the projections generated by the Al / ML model to the payment plan (step 622), to detect whether there is a deviation from the projected collections that is beyond a predefined threshold.

If there is a deviation, then, at step 624, the AI/ML model generates one or more suggestions relating to one or more products, from the same supplier, that can be offered at a discount price and/or other suggestions for increasing collections. Proceeds from the discounted products / increased collections are then earmarked for payment to the supplier, and not included in any of the aforementioned tallies or interim tallies.

At step 626 the suggestions are output / displayed via the GUI or the API.

Machine Learning and Artificial Intelligence cover a vast range of mechanisms, methods, and techniques. It is made clear that any type of machine learning model may be used. The term “machine learning (ML)” and grammatical variations thereof is intended to convey method of machine learning known in the art (e.g., artificial intelligence (Al), deep learning, neural networks, etc.) and/or combinations thereof. One example of a machine learning model is a neural network. The linkages in a neural network are generally pre-defined. Over some number of training examples, the strength of different relationships emerges by being reflected in the weights of each edge of the neural network as the weights of the edges are adjusted with each training example. In a neural network, an edge exists between two nodes and then over time it will develop a large or small weight reflecting a strong or weak relationship between the variables represented by the two nodes that the edge connects.

Another example embodiment of the machine learning model is a Convolution Neural Networks (CNN). The instant example is not intended to limit the method or system in any way, rather it is merely intended to portray one way of implementing the method and/or system.

Depending on what the ML model is trained for, the dataset is used to refine the model’s ability to make the best decisions. It is true that market valuation and financial investment is a complex science-slash-art. However, training a model on certain aspects of the market can prove to be very successful. Also, following successful investors and investments, investment strategies that have proven themselves over time, and other proven wisdom can arm the model with many reliable tools for creating / successfully running a multi-generational savings fund. For example, US20190378050A1 to Edkin et al. discloses a non-transitory computer readable medium storing computer-executable instructions that, when executed by a graphics processing unit, cause an ensemble of machine learning subengines to: train a machine learning model of the ensemble of machine learning subengines using a corpus, where the corpus includes a training data and a test data; classify a plurality of nodes in a graph, which includes nodes and edges and is stored in computer memory, based on the machine learning model, by setting a classification attribute of a first node and a second node of the plurality of nodes to one of a plurality of classifications; and insert an edge in the graph between the first node and the second node in response to the machine learning model detecting a pattern, where the first node corresponds to a first entity type and the second node does not correspond to a second entity type. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods. US20190378050A1 is incorporated by reference as if fully set forth herein.

Implementation of the method and/or system of embodiments of the invention can involve performing or completing selected tasks manually, automatically, or a combination thereof. Moreover, according to actual instrumentation and equipment of embodiments of the method and/or system of the invention, several selected tasks could be implemented by hardware, by software or by firmware or by a combination thereof using an operating system.

For example, hardware for performing selected tasks according to embodiments of the invention could be implemented as a chip or a circuit. As software, selected tasks according to embodiments of the invention could be implemented as a plurality of software instructions being executed by a computer using any suitable operating system. In an exemplary embodiment of the invention, one or more tasks according to exemplary embodiments of method and/or system as described herein are performed by a data processor, such as a computing platform for executing a plurality of instructions. Optionally, the data processor includes a volatile memory for storing instructions and/or data and/or a non-volatile storage, for example, non-transitory storage media such as a magnetic hard-disk and/or removable media, for storing instructions and/or data. Optionally, a network connection is provided as well. A display and/or a user input device such as a keyboard or mouse are optionally provided as well. For example, any combination of one or more non-transitory computer readable (storage) medium(s) may be utilized in accordance with the above-listed embodiments of the present invention. A non-transitory computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable non-transitory storage medium may be any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.

A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

As will be understood with reference to the paragraphs and the referenced drawings, provided above, various embodiments of computer-implemented methods are provided herein, some of which can be performed by various embodiments of apparatuses and systems described herein and some of which can be performed according to instructions stored in non-transitory computer-readable storage media described herein. Still, some embodiments of computer-implemented methods provided herein can be performed by other apparatuses or systems and can be performed according to instructions stored in computer-readable storage media other than that described herein, as will become apparent to those having skill in the art with reference to the embodiments described herein. Any reference to systems and computer-readable storage media with respect to the following computer-implemented methods is provided for explanatory purposes and is not intended to limit any of such systems and any of such non-transitory computer-readable storage media with regard to embodiments of computer-implemented methods described above. Likewise, any reference to the following computer-implemented methods with respect to systems and computer-readable storage media is provided for explanatory purposes and is not intended to limit any of such computer-implemented methods disclosed herein.

The flowcharts and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware — based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The descriptions of the various embodiments of the present invention have been presented for purposes of illustration but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

As used herein, the singular form "a", "an" and "the" include plural references unless the context clearly dictates otherwise.

The word “exemplary” is used herein to mean “serving as an example, instance or illustration”. Any embodiment described as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments and/or to exclude the incorporation of features from other embodiments. It is appreciated that certain features of the invention, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable sub-combination or as suitable in any other described embodiment of the invention. Certain features described in the context of various embodiments are not to be considered essential features of those embodiments, unless the embodiment is inoperative without those elements.

The above-described processes including portions thereof can be performed by software, hardware and combinations thereof. These processes and portions thereof can be performed by computers, computer-type devices, workstations, processors, microprocessors, other electronic searching tools and memory and other non-transitory storage-type devices associated therewith. The processes and portions thereof can also be embodied in programmable non — transitory storage media, for example, compact discs (CDs) or other discs including magnetic, optical, etc., readable by a machine or the like, or other computer usable storage media, including magnetic, optical, or semiconductor storage, or other source of electronic signals.

The processes (methods) and systems, including components thereof, herein have been described with exemplary reference to specific hardware and software. The processes (methods) have been described as exemplary, whereby specific steps and their order can be omitted and/or changed by persons of ordinary skill in the art to reduce these embodiments to practice without undue experimentation. The processes (methods) and systems have been described in a manner sufficient to enable persons of ordinary skill in the art to readily adapt other hardware and software as may be needed to reduce any of the embodiments to practice without undue experimentation and using conventional techniques.

While the invention has been described with respect to a limited number of embodiments, it will be appreciated that many variations, modifications and other applications of the invention may be made. Therefore, the claimed invention as recited in the claims that follow is not limited to the embodiments described herein.

Claims

WHAT IS CLAIMED IS

1. A computer-implemented method for synchronizing between methods of payment of a second party to a first party for items supplied by a plurality of third parties, and subsequent methods of payment by the first party to each of the third parties for additional goods, the method comprising: receiving a record of purchasing activity at the first party for a predetermined period of time; organizing purchased items according to each third party that supplied the items; for each third party, listing immediate payments and deferred payments separately for the purchased items; calculating a total value of the immediate payments and an interim value of the deferred payments; generating a message indicating the total value of the current payments for each third party; and outputting the message via a graphical user interface (GUI) or an application program interface (API).

2. The computer-implemented method of claim 1, further comprising: providing a machine learning (ML) model configured to predict a ratio of immediate payments to deferred payments, per month, over a predetermined number of months.

3. The computer-implemented method of claim 2, further comprising: training the ML model on historical financial data and ongoing financial activity of the first party.

4. The computer-implemented method of claim 3, further comprising: predicting, by the ML model, a ratio of immediate payments to deferred payments for items supplied by each third party, per month, over the predetermined number of months, wherein the prediction is based on the historical financial data and the respective interim value of the deferred payments for each of the third parties.

5. The computer-implemented method of claim 4, further comprising: generating a message with a respective suggested deferred payment plan for each of the third parties based on the respective predictions.

6. The computer-implemented method of claim 4, wherein the historical financial data includes changes to trends in payment methods around cyclical events.

7. The computer-implemented method of claim 2, further comprising: receiving a deferred payment plan, for a given time period, from one third party of the plurality of third parties; monitoring ongoing purchasing activity, over the given time period; generating predictions, by the ML model, of interim values of deferred payments per month over the given time period based the ongoing purchasing activity; comparing the predictions to the deferred payment plan; generating suggestions for increasing the purchasing activity, if necessary, to match the deferred payment plan; and outputting the suggestions via the GUI or the API.

8. The computer-implemented method of claim 7, wherein increasing the purchasing activity includes providing discounts for items supplied by the one third party that provided the deferred payment plan.

9. The computer-implemented method of claim 5, further comprising: outputting the message via the GUI or the API.