Complex Payment Terms

[TTx]

I’ve just started assessing ERPNext to see if it’s a good prospect for us, and I noticed the Payment Terms as one place that could use expanding. I would love to do some development work, but I need to first determine if the core system will work for us and learn how to properly develop with frappe.

I’m not sure if this is useful, but just comparing it to other ERPs (2 in front of me at the moment) and accounting systems I’ve used, this is a quick synopsis of concepts that would probably be useful to a large portion of users.

Currently, terms are just set in the customer/supplier record, and if you choose “Fixed Days” you are allowed to enter the number of days. The only other option is “Last Day of Next Month”.

While betabrain’s scenario is very specific and complicated, it could probably be accommodated with a little more flexibility.

Ultimately, this will probably need to be master table data, instead of just a field or two in the customer or supplier. (But of course I’m not fully familiar with the system yet, so there could be alternate ways to achieve this…)

Basic ideas for a design to structure the terms:
A payment_terms table, with a terms code that’s referenced by the customer/supplier records.
Within the payment terms table, at first glance, there should be something like:

• terms code/name - (referenced by the customer or supplier record)
• sequence - (when needed for complex terms) (this would be the second half of the aggregate primary key)
• terms description
• method of calculation - (moved from customer/supplier)
  ** fixed days
  *** terms days (if fixed days is chosen)
  ** day of month - (better option than just “Last Day of Next Month”)
  *** terms day (1-31)(if day of month is chosen)
• percent due - (100% most of the time, as a default, but could be 20% sequence #1, 50% seq #2, etc as user example mentioned…

If “day of month” is chosen, either the system must always presume the following month, or some users may prefer a more flexible way such as including a

• cutoff day of month - To indicate how to evaluate whether to make the due date this month or next.
  For example, if the order was made on July 8th, and the “day of month” terms was set to the 31st, instead of that giving them the rest of July and all of August to pay, a cutoff day of the 12th would indicate that if the order was placed before then, to make the due date the 31st of the current month (July).

If ERPNext doesn’t include functionality to accommodate terms discounts, that could also be included in the sequence, with:

• days allowed - # of days within which the customer would receive the terms discount.
• percent discount
• discount calculation method (optional fancy feature)

Betabrain’s request about calculating terms from milestones might require a little more, though.
20% in advance would have to prevent shipment (and most likely production - if necessary) before payment is received.
50% when shipped is easy I think- just 0 day terms, really. Terms should already be based off of ship date.
20% when delivered is easy if using some method of estimating the delivery date, but could be very complicated otherwise.

Just seeing if this helps to spark some thought on a clean way to implement payment terms.

Travis-

[rafiemmanuelli]

Hi. I need the same feature. Advance payment discount in invoices and purchases. The standard in my industry is 2% discount in 30 days, net 31 days. Is there any way to set this automatically in customers and vendors?

[applepipe]

Hello @rafiemmanuelli

I think this is one of the most wanted features for people in Spain, Brazil and some other countries, I raised a feature request recently [Feature Request] Multiple due dates in the same invoice · Issue #6301 · frappe/erpnext · GitHub

And this is how it works on oodoo and others Payments due to 30-60-90 days (Very common Spanish Local functionality)

I dont have the skill to code it, but we could organize a paid development or something that could benefit us all.

[italjapan]

Hi all

even from Italy this is one of the most wanted feature asked from customers . I presume that tons of italian companies will base ther decision to jump to ERPNExt or not based also on this feature.

So please let’ us know if you will develop this most wanted feature in the short term (maybe next month deployments) or when if you have already organized plan.

many thanks

[Jammyinc]

I too have the same need and willing to pay for development as it will be integral to our upcoming implementation of ERPnext. Typical terms might be 1.5%-15 Days, Net 30; or 2%-10, Net 60; or the lesser common term of 30/60/90 days. These are quite common in USA and a needed accounting function that will automate the payment entry to avoid calculating and entering credits by user ad hoc.

[FredericLeuba]

Hello,

Same here in France and Luxembourg. We are dealing with European Steel industry companies, and it is mandatory to invoice downpayment, and wait for the payment to come before starting the production.
Sometimes too, we decide to start production anyway before receiving the payment.

Best regards
Frederic

[tundebabzy]

The payment terms features will be released in a few days.

[FredericLeuba]

I thank you Tunderbabzy.
Have a nice day.

[FredAtPlexant]

Hello. Any news about the release?
How can we get informed when it’s available?
Regards
Fred

[nabinhait]

The feature has been merged in develop, it will merged in master branch with the release of v10 (within next 15 days).

[Bas_de_Reus]

@FredericLeuba

Same here in France and Luxembourg. We are dealing with European Steel industry companies, and it is mandatory to invoice downpayment, …

I’ve got the same requirement here in The Netherlands. I’ve posted some thoughts and questions on the Github page of the feature request that started the led to the development of this module. You can read the complete treat here: https://github.com/frappe/erpnext/issues/6301

To sum up, this is essentially my remark/question:

… Am I correct that in your example you’re still creating 1 invoice with two payment terms with both the same due date?

I’ve done some searching on google and couldn’t really find any example of Dutch invoices with multiple due dates. For multiple due dates, they seem to send multiple invoices. This does make sense as the disadvantage of sending one invoice at time of order for the complete order amount with multiple due dates is that you have to pay the VAT for the complete order amount in the beginning of the project. If you would send multiple invoices, one for each payment term, you will pay the VAT of that particular invoice at the time you send it to the customer.
If it’s a small project with a short time frame it doesn’t really matter but if it has a bigger time span, you might end up pre-financing the VAT of the upcoming due dates for a long time.

The easiest solution would be to have an option to set the payment terms as suggested in this future request and have the option to choose if you want to make one invoice with multiple due dates or to make multiple invoices one for each due date. That way we can choose which approach would fit your situation the best.

As far As I know at this moment there isn’t a good solution to make multiple invoices for on order. I can make multiple invoices but then I’m facing the following situation:

Lets say I have the following order.

1pc Machine A €5.000,-
1pc Machine B €5.000,-
1pc Machine C €5.000,-
1pc Machine D €5.000,-
Payment term: 25% at order, 50% before delivery, remaining 25% within 30 days after delivery.

I could make the invoices as follow:

(invoice 1, 25% at order:)

1pc Machine A €5.000,-
1pc Machine B €5.000,-
1pc Machine C €5.000,-
1pc Machine D €5.000,-
1pc To pay later: 50% before delivery, remaining 25% within 30 days after delivery -€15.000,-
Total invoice amount: €5.000,-

(invoice 2, 50% before delivery:)

1pc Machine A €5.000,-
1pc Machine B €5.000,-
1pc Machine C €5.000,-
1pc Machine D €5.000,-
1pc Already paid : 25% at order -€5.000,-
1pc To pay later : remaining 25% within 30 days after delivery -€5.000,-
Total invoice amount: €10.000,-

(invoice 3, 25% at 30 days:)

1pc Machine A €5.000,-
1pc Machine B €5.000,-
1pc Machine C €5.000,-
1pc Machine D €5.000,-
1pc Already paid : 25% at order, 50% before delivery -€15.000,-
Total invoice amount: €5.000,-

This looks like a good work arround but:

item 1 to 4 are invoiced 3 times now so the turn over for those products is registered as 3 times the original turn over? (if it’s only one item that has been ordered it would be easy to solve by adding the same item with an other description and a deducting value like:
1pc, item nr 1234, Machine A €5.000,-
1pc, item nr 1234, To pay later: -€2.500,-
after sending the first invoice the order status will already turn to “paid” instead of “partially paid” so after delivery, the order status will turn to completed and there is no indication anymore that there is still an invoice to send and be paid.
I’m sorry for making such a long comment but for me, it’s an issue that I don’t know how to deal with and I hope someone has a suggestion how to deal with it. Hopefully, I’m seeing problems that are not really there.

I’ve given the Dutch Tax Authority a call to ask about the multiple invoices vs multiple due dates on one invoice issue.

They stated that the moment I send an invoice I’m required to pay VAT over 100% of the invoice amount, no matter what the payment term is. The invoice date is leading for the VAT period. The customer can pay me a down payment but I’m required by the Dutch law to send him an invoice within 15 days from the date I received the down payment.

They stated that the easiest and for me most beneficial way is to send multiple invoices, one for each due date. That way I can spread the VAT .

So it seems that unfortunately, the multiple due dates in one invoice is not going to work for me.
Is there a way to use this new payment terms feature to make and track multiple invoices?

Does the new module provide any way to handle the above situation? If not does anybody know a good workaround to make and track multiple Invoices against one Sales Order?

[tundebabzy]

Unfortunately, no. The Dutch tax laws makes ERPNext payment terms not ideal in most cases and I agree that you are better off with multiple invoices. In Nigeria for example, you only remit collected VAT.

That said, I think we can create a feature that allows users split invoices. The invoice that is to be split will be cancelled and two new invoices will be created in its stead - one that is to be sent out immediately and another for the balance.

[FredericLeuba]

Hello Tundebabzy.
I just tested the feature in the develop branch. It is great job and looks nice.

Nevertheless there is one annoying stuff that makes it unusable for us (and most of the users, I’m afraid):
the Due Date is based on the initial invoice date, and obviously you did not plan that there could be several invoices for a SO.
For us this is always the case, there is an invoice for each term.
And these invoices are emited at the end of a specific project step whose the date is not always exactly known at the time of the order.
For instance, we invoice 50% on delivery of the manufactured equipement.
The invoice for this term must be of the exact amount of the term, and not necessarily mention all the other terms.

That is not feasable with the current approach, which seems to make it unusable for us, unfortunately

Is there any way to work around this limitation?
Would it be possible to upgrade your module that let it generate an invoice for each term, in which case the Due Date based on invoice date would make sense (but no date would be calculated upfront)?

That is a real pain. We were waiting on this feature to switch to ERPNext.
We can’t as it is now.

Best regards
Fred

[FredericLeuba]

@tundebabzy

Unfortunately, no. The Dutch tax laws makes ERPNext payment terms not ideal in most cases and I agree that you are better off with multiple invoices. In Nigeria for example, you only remit collected VAT.

That said, I think we can create a feature that allows users split invoices. The invoice that is to be split will be cancelled and two new invoices will be created in its stead - one that is to be sent out immediately and another for the balance.

Sounds complicated and hard to follow, IMHO.
We need to see the all invoices attached to a SO, whose the sum, at the end of the project, matches the total amount.

[tundebabzy]

Good point. That means we’ll have to create a new Document entirely that inherits a lot of features from Sales Invoice. Sales Invoice cannot be used as you need because immediately it is submitted, it writes to your GL. You need some intermediary that will hold all the needed information that will ultimately be used to create proper sales invoices as needed. The same document will also list invoices created and show their status. Sound ok?

[FredericLeuba]

Thanks for your answer Tundebabzy.
I’m sorry, I can’t understand all points.

@tundebabzy

…it is submitted, it writes to your GL.

What is a GL ?

@tundebabzy

You need some intermediary that will hold all the needed information that will ultimately be used to create proper sales invoices as needed. The same document will also list invoices created and show their status. Sound ok?

Sounds ok. It is true that each invoice must properly mention the origin SO, and possibly the percentage of the total amount that comes from the related term.
Also, as you propose, listing all invoices of the SO and showing the status makes sense.

By the way, in relation to you update and your complexe terms module, how would it go along? It makes sense to me that each invoice is actually related to each term.
You should then make your term editor more flexible, by letting the user set the due date later, in relation to the invoice that will be specific to the term itself.

SO-0001 = one single sales order
→ Terms
- Term1 (downpayment) 30% → first invoice SINV-0001 → term due date based on SINV-0001 date
- Term2 (before delivery) 60% → second invoice SINV-0002 → term due date based on SINV-0002 date
- Term3 (post-commissioning) 10% → third invoice, closing invoice SINV-0003 → term due date based on SINV-0003 date

→ Invoices
- first invoice SINV-0001 of 30% of the amount for each item line → related to term1, due date based on this invoice date
- first invoice SINV-0002 of 60% of the amount for each item line → related to term2, due date based on this invoice date
- first invoice SINV-0003 of 10% of the amount for each item line → related to term3, due date based on this invoice date

The invoices could be automatically prepared when submitting the SO, ready to be edited and submitted at the appropriate time and event, by the responsible user.

[dufani1]

@tundebabzy first thanks for your efforts. And please is the new payment terms feature working with purchase invoce or just sales invoice.

[Bas_de_Reus]

@tundebabzy
Do you have any suggestion for a good workaround until a permanent solution has been developed?

The only way I can think of to handle let’s say an SO with different items with a total amount of let’s say €10.000,- and a payment term of 50% at order, remaining 5o% before delivery; is by making an item named “To pay later: 50% before delivery” and one “Already paid: 50% at order”

Create SINV-001 with all items in it and at the “To pay later: 50% before delivery” item and give this item a negative value of 50% of the total order amount so €-5.000,-

The second invoice SINV-002 will be created just before delivery and will again have all items plus the “To pay later: 50% before delivery” this item will have a negative value of 50% of the total amount again.

This give at least 2 problems I can think of

1. All your items are registered as being sold two times or even more if you have your payment terms split into more terms. this gives a wrong impression of which items are selling good and which not.
2. Only the first invoice will be tracked against the SO. as soon as that one is paid the status of the SO will change to “Paid” where in reality it’s not. Maybe this can be addressed by a custom script that looks at the amount that has been paid comparing that to the SO amount would give an adequate indication.

Maybe you have a better suggestion or other ideas how to address this.

[tundebabzy]

@dufani1

first thanks for your efforts. And please is the new payment terms feature working with purchase invoce or just sales invoice

Sales invoice and Purchase Invoice

[tundebabzy]

@Bas_de_Reus
I still think you are better off with multiple invoices pending when a design specification is developed for your use case. However, maybe my accounting is off although I don’t think I am wrong but when you invoice before delivery, you get Deferred Revenue (a liability) and I don’t know how the Tax authorities in Netherlands will treat that. Note that ERPNext Sales Invoice will immediate book a revenue immediately you submit the Sales Invoice but in reality you have a liability.

1. If I were the one, I would create a Quotation for the whole order specifying the terms and send that to the customer. At this point, no accounting entries have been made. At this point the customer can bail and if that happens, auditors won’t be asking me questions.

2. Next, If the customer pays the first 50%, I create a Sales Order and change the due date to present date. Still no accounting entries made.

3. I will also immediately create a Payment Entry for the advance that was made i.e line 1 in the Payment Terms table. (I just discovered that the split of Sales Order is not yet implemented so I’m working on that at the moment).

4. When the customer pays the pre-delivery fee (final 50%), repeat 3

5. After that create invoice from the sales order. You will see the two previously received payments as advances (which they are).

I hope I have not succeeded in confusing you