The ultimate guide for a successful odoo-ERP-implementation   Free Download

Differences and Processes Prepayment vs. Down Payment

Odoo Version: 16 Enterprise

Background

Good customer, bad customer, we all have those. Now, how do I create a customer in Odoo so that my colleague in sales knows what to do, and how exactly does the prepayment and down payment process work – and are they the same or not?

These questions are among the most frequently asked ones. If you search on YouTube, you may get all kinds of information. However, I have yet to find a video suggesting a process from data creation to final settlement.

It is essential to know that in Odoo, the confirmation of an offer automatically triggers the generation of deliveries (both internal and external if there are multi-level warehouse processes). These, in turn, may result in the recalculation of demand and corresponding feedback within the modules Purchasing and, if applicable, Manufacturing.

The question now is whether we– option 1 – want to demand payment before a delivery schedule and confirmation (prepayment) or – option 2 – have enough confidence in the customer so that a down payment can run concurrently with delivery scheduling (by creating a “merchant invoice with due date”).

Option 1 is commonly referred to as a prepayment or proforma process, and option 2 as a down payment.

The decision is not only crucial for the configuration and generation of deliveries. The timing and occurrence of the legal conclusion of the contract also differ.

In the proforma process (prepayment), we send a proforma invoice to the customer, representing an offer. With the payment, the customer accepts the offer. The payment, therefore, serves as the customer’s “declaration of intent” with which the contract is concluded.

The preparation of the down payment invoice already presupposes the declaration of intent and, thus, the conclusion of the contract.

Configuration

The first and probably most important task is the separation of the debtors according to these two categories.

As we have already learned from the blog on monthly invoices, the payment terms may be used to map much more than the term itself suggests, particularly since a) it makes a difference in terminology both internally and on the printed text and b) the default payment terms are visible when you create an offer.

Your best choice is to take advantage of the separation between internal and external text to allocate a name (or maybe an abbreviation) to the payment term and add instructions to the internal user (e.g. “only Prepayment, 30 days” or “30% down payment, 30 days”).

In this case, the most practical approach is to create two additional payment terms by duplicating or copying the default payment term. This will automatically apply all respective settings and translations.

For our example, that is sufficient. In reality, you can insert additional notes regarding the payment process into the external text. This way, the customer will already see that he has to pay a down or pre-payment when he receives the offer after placing an order.

Note: The default payment term should be at the top of the list.

Here is an example:
 Payment Terms

I created the two additional terms at the bottom of this example by copying “immediate payment” and “30 days net”. Consequently, there will be no visible difference in the documents, but the wording should tell my colleague in sales how to deal with the customer as soon as he places an order.

Master Data

In the next step, these newly created terms should be assigned to at least one customer each.

In this fictitious case, Deco Addict is a customer who passed our credit check and proved trustworthy. Thus, the delivery may be scheduled and a down payment invoice created once the order has been confirmed. On the other hand, Azure Interior has received a negative credit check, and the order can only be confirmed after prepayment.

The payment terms are stored accordingly in the master data record.

Customer Contact 01

Customer Contact 02

Let us now look at the two processes themselves.

Process Down Payment

We receive an inquiry from Deco Addict, and the sales department issues an offer. As soon as the responsible salesperson gets the offer, he will access Odoo and see in the customer’s payment terms that the order may be confirmed and a down payment invoice may be created.

He will proceed as follows:

Step 1: Order confirmation

Order Confirmation

The order has been placed by phone, and the offer has been sent. We see that a down payment invoice needs to be created in the payment terms. The example shows that the percentage to be paid should have been evident from the term’s name, but since it is not, we will assume 50%.

Step 2: Generating an invoice and entering the down payment

To generate the down payment, we need to click on the button “Create invoice”:

Create Invoice

This takes us to the draft invoice:

Draft Invoice

For the user in sales, the process would end here for the time being because, if the authorizations are set correctly, sales may create or draft invoices but not post them. You are (should?) only (be) able to do that if you are in accounting.

In our example, we are admin and may continue directly with the next steps.

Step 3: Posting the Down Payment Invoice

Next, we post the down payment invoice by pressing the “Confirm” button. This gives us an invoice number. The date will be set to the current day.

Down Payment Invoice

Using the “Send & Print” button, we generate a document image of the invoice, which we can send by e-mail.

In the sales order, the down payment is now also visible:
 Sale Order Down Payment

Step 4: Shipping and final invoice

The order is now shipped, and Odoo forwards it to the invoice run. If the order is now also transferred to an invoice, the result will look as follows:

Final Invoice

As you can see, the down payment is listed, reducing the amount to be invoiced.

Prepayment process

In our example regarding prepayment, we create an offer for Azure Interior. After sending the offer, we receive the order. In the terms, we can see that this customer has to pay in advance before the delivery is scheduled. Using the “Send Proforma” button, we send the proforma invoice with the payment request.

Step 1: Sending a proforma invoice

A quote has been created and sent to Azure Interior.

Proforma Invoice

Mr. Freeman contacts you and places the order. We immediately see that the customer has been set to prepayment, and we send him the proforma invoice via the “Send proforma invoice” button.

Send Proforma Invoice

A standard template text is imported into the e-mail that a) may be adapted by the administrator and b) may be individualized by the user according to the transaction.

The work is done for sales, and the ball is now in the customer’s court.

Step 2: Recording the payment on the bank statement

We are changing roles again because the payment now appears in the bank journal, and accounting takes over.
 Bank Statement

In our case, Azure has paid the total amount of 320.56 US$, using the quote number as the payment reference.

You will see an additional “Orders” tab in the posting proposals. This tab is only displayed if quote or order numbers appear in the payment reference. If you click on this tab, you will get a link to the open and sent quotes:

additional Orders tab

Clicking on the link will take us to our offer, for which the proforma document has been sent.

Sale Order via Bank Statement

Step 3: Confirmation of the offer

Now, of course, we need to decide whether to accept the payment or not. If the down payment needs to be higher, we recommend contacting the responsible salesperson via an internal note or resubmission and notifying them about the posted payment. In this case, the quote will remain in its current status. You can return to the payment and post it against accounts receivable, as suggested.

However, in our case, the customer has paid 100%, the offer can be accepted, and the delivery is scheduled. Just press the “Confirm“ button.

Confirm Sale Order

This can also be processed by a user in accounting. This way, we can create the down payment invoice as in option 1 above.

Step 4: Creation of a down payment invoice

This step is the same as the one described above, except that we do not enter a percentage down payment but the paid amount. You may import the correct data via Copy & Paste from the operation system clipboard.

Create Invoice Down Payment

Step 5: Confirmation and sending of the down payment invoice

We now generate the down payment invoice, which can also be confirmed directly.
 Posted Invoice

Of course, we can send the invoice directly to Azure, but we send it more conveniently together with the order confirmation, which has to be sent as well, after all. If the invoice recipient differs from the person ordering, we must do that anyway.

Step 6: Sending the order confirmation

Returning to the order via Breadcrumbs, we can see that the down payment is now also recorded.

Sending Order Confirmation 01

An order confirmation should be sent to the contact person via the “Send by e-mail” button to confirm the down payment and delivery date. 

Sending Order Confirmation 02

Step 7: Posting the payment against the down payment invoice

Now we go back to the bank statement, again using the Breadcrumbs. Under the tab “Reconciliation of existing entries,” we can see our created down payment invoice and are able to select it for reconciliation as the counter document.
 Posting Payment

Once you confirm the transaction, the down payment invoice is considered cleared.

The following steps are the same as in Option 1. I.e., after delivery, the order is placed in the invoice run, and the down payment is included in the settlement. In our case, the balance is 0. The merchant invoice has yet to be provided to the customer.

Conclusion

Of course, the process can be extended to include many more details. Moreover, we have entirely disregarded taxes in our example. Entering the fixed amount for the down payment invoice was easy since no taxes had to be discounted from the receipt. This and several other details need to be taken into account.

Our example was only meant to illustrate how a transaction can be handled in Odoo Standard. At first glance, it is a rather long click track that might be inconvenient if you have many prepayments. However, once a process is in place and you know the appropriate parameters, you can program it for automatization.

A point still open is that in option 2 of our example, the commissioned proforma offers are not followed up. This is also part of the process in most cases since the customer’s declaration of intent only occurs with the payment. Sometimes, the ordering itself can be already considered a binding commitment. In that case, you should create a filter in the offer overview that selects all offers sent according to whether a proforma e-mail has been sent and group the latest changes according to date. However, these would have to be followed up via the Chatterbox of the respective process. This can be done semi-automatically via an appropriate mail template.


Was this article helpfull information to you? 
Would you mind to leave us a review of your experiences with openfellas?

​​​​​review openfellas




Talk to our experts.

We will find the solution best suited to you and your products!


REQUEST CONS​​​​ULTATION




How to exclude customers from the follow-up process … while still keeping an eye on them