Usually, the due date is 14 days after the invoice date. When the invoice is overdue, send a friendly reminder. Then, the fun, a dunning process, starts:
Send the first warning notice (“1. Mahnung”)
Charge a warning fee
Set a new deadline, say 8 days
In order for the debtor to be officially in delay of performance, the creditor generally must provide the debtor with a warning notice. […] Irrespective of a warning notice, the debtor is in delay of performance at the latest after 30 days following the payment due date and presentation of the invoice.
From now on we charge interest on the invoice total
If the debtor is in delay of paying a money debt, then the creditor may claim the interest on arrears as so-called loss caused by delayed performance.
Second deadline arrives, send next warning notice.
Charge a warning fee
Set a new deadline, say 5 days
Third deadline arrives, send a final warning notice.
Charge a warning fee
Set a new deadline, say 3 days
(Fourth deadline arrives, hand the case over to a lawyer.)
Each stage should result in a new PDF document that references the original invoice but with a different title (“Warning Notice 1”, “Warning Notice 2”, …), new due date, fees and interest.
So, first, the customer owes € 100.00, then € 103.00, then € 106.00, etc. The amount continues to grow until payment is made. However, there will be no additional GL Entries until payment.
If we get paid – finally! –, we book the following:
We have some differences that we apply, which I think are important. The dunning is maintained as a separate payment reminder document. In this, we aggregate all unpaid invoices from one debtor. Same as you, we keep a payment reminder level on each sales invoice and raise this (typically up to 3) at each reminder sent. This will impact the text blocks used for the payment reminder. Your print format looks very nice! As for the charges, they should not be applied on the sales invoice; they have to be accounted for separately in accounting, we do this at the payment entry.
So to your question, I guess most of our customers would keep the current implementation (at least for now, I don’t see v12 productive too soon). However, your feature is absolutely relevant and should be considered for the core. If we can help to improve it, let me know.
@rmeyer thank you for doing this and for making it available, we just forked it and we will install it. If there is anything we can contribute we will PR it. It would be great to get this in CORE in a generic way.
Let’s try to get this as close to done as possible before we try to PR against the core. Also it is very important that perspectives of other countries are added. We are currently doing this from a German perspective but maybe dunning is done differently elsewhere and we can easily incorporate that.
I believe our dunning app is close to being done. I have made an 8 minute video walk through for those who are interested. Watch it here on Youtube.
We don’t really want to maintain this as a separate app. My goal is to now clean this up and get it ready for contribution to the ERPNext core. It is probably a day worth of work to get it merged, is anybody willing to financially contribute so we can pay Frappe to get this in Core?
POLL: Is this useful to you and should we try to get this into ERPNext core?
Great work, thanks a lot! Do you still plan to enable multiple invoices per dunning?
I’m ready to make the PR to the core, once we’re ready. There would be still some work needed to better integrate it with Sales Invoice (“Create → Dunning”, dashboard entry, sales invoice status according to dunning type).
I really like the approach and the way to get some feedback via this poll. I think this is a great example on how to get a matter like this moving forward and not letting it rot(*) inside a Custom App.
(*) no negative vibes implied. Just lack of ability to find better wording
We currently are not planning on multiple invoices per dunning, that could be useful but we were focussing on getting what you created to the level we need it at with single invoices.
Thank you for that, we noticed some more small stuff with currency precision and we might notice more bugs during our productive use. I think you can take what we have created by the end of the week and then work on getting this contribution ready.
I think it shlould be generic so that it works for a single or multiple invoices. Usually it achieved by a table containing a list of overdue invoices, with a subtotal and interest calculated per line. I think my supplier has sent me a few over the past 10 years (they are Swiss, no excuse even for a single day… ). I will post a scan here during tomorrow.
I like the work done here. We actually use a slightly different process, which aggregates invoices by customer to reduce number of payment reminders (we actually don’t call it dunning): implementation is available in the ERPNextSwiss app: