Idea: Advance Payment Reconciliation Method

Hi

Currently ERPNext reconciles advance payments to invoices by modifying the source document’s (Payment Entry or Journal Entry) GL Entries and changing their against_voucher and in some cases even splitting the GL Entries into multiple rows.

With this current method, the information about that fact that a payment was made as an advance against a Sales Order or Purchase Order or an Unallocated Advance Payment is lost. I would assume that accountants and people who advocate for immutable ledgers would not approve this method.

So while working on improving Employee Advance I got the idea that there could be a Voucher Type (Document) that acts as the document that gets allocated with the advance payments. And instead of reposting/modifying the original GL Entries we can post GL Entries like this:

Advance Voucher Types: Sales Order, Purchase Order, Employee Advance, Advance Payment (new DocType)

Payment Entry/Journal Entry → Advance Voucher Type
Advance Voucher Type ← Invoice/Expense Claim

Example:

Payment Entry ($100)

Bank                100 Dr
     Customer             100 Cr (against Sales Order)

Balance of Sales Order: of 100 Cr
Balance of Payment Entry: 0 (of course)

Sales Invoice ($200)

Customer           100 Dr
Customer           100 Dr (against Sales Order)
      Sales              200 Cr

Balance of Sales Order: 0
Balance of Sales Invoice: 100 Dr

This way a Payment Entry/Journal Entry/GL Entry will always show that it was paid for Sales Order and not Sales Invoice.

And yes I am working on this, however, currently only for Employee Advance and Expense Claim documents.

Let me know what are your thoughts on this.

1 Like

I like the fact that you think of all kinds of advance-payments alike. And I agree that the logic and workflow for all kinds should be the same. So I’d vouch for developing this not as an island solution for employee advances, but for all possible advances in general.

Can’t really judge whether the way you want to achieve that works due to lack of in-depth technical understanding, but it sounds reasonable.

1 Like

Thanks vrms. Technically it is definitely possible and I’m already using this on Employee Advance with Expense Claim and Purchase Invoice.

My point is to get the opinion of accountants and users whether this is a good idea or not, since I’m not an accountant

1 Like

Advance payments today is a big problem at erpnext.

There are related issues at github but they are not being given priority, so I don’t understand how companies that need this handle it.

Advance payments, if made from Payment Entry, create a negative balance in an account that you don’t owe.

If it is made from an accounting entry, to a Advanced Payment account as it should be in accounting, it cannot be used to connect with the payment reconciliation tool.

To this must be added the fact that credit notes on an invoice that is paid cannot be used as an advance payment.

A retailer that uses all these movements on a daily basis will be unable to carry something as simple as advance payments.

I do not know if the solution you propose is the best, but it is a serious issue that I do not know how to do to give more relevance in github.

https://github.com/frappe/erpnext/issues/16697
https://github.com/frappe/erpnext/issues/16879

Regards

3 Likes

Saif, creating a SO is not a mandatory requirement. So if you make a solution tagging to SO then it won’t solve larger use case.

Also, the accounting entry gets posted on SI and not at SO, I don’t quite understand your point of linking it to SO entry?

Even if it gets reposted, system might be creating additional references of ‘against xyz’ and not remove the basic entry… Is my understanding right?

Please explain this little more. I’m getting lost in the arrows flowing in different direction :blush:

Of course it should work with all cases. The user should be able to make payment against either SI, SO, or keep it unallocated. My point is that IF the user makes payment against Sales Order, then reconciling the Payment Entry to a Sales Invoice will not modify the Payment Entry’s GL Entries. Rather it should either modify the Sales Invoice’s GL Entries’ against_voucher only as in the example or create GL Entries from Sales Order to adjust the Sales Invoice.

Essentially the idea is that there should be no reposting, but there are some caveats to that. I’ll post about it soon.

I get this point. What i’m saying is creating SO in the Sales pipeline is not a mandatory.
So, what happens to cases where there is no SO, but only SI and Advance payment entry to be allocated to it --which is happening currently, so how is the proposed changes going to work in this use case

Only this should happen as the expected behavior and do not connect it to SO.

Currently you can create Payment Entry/Journal Entry to that Customer and do not allocate the to any document.

There could be another document that gets allocated with the advance payment… Lets call that DocType Advance Payment. Either the invoice can make the GL Entries to reconcile with the advance payment or the Advance Payment DocType can make the GL Entries to reconcile with the Invoice.

Lets discuss this in the Account Working Group call.

1 Like

Continued as a proposal here: [Proposal] Payment Reconciliation Improvement

1 Like

Currently, I am suffering from Advance payment issues. I have had clients who rejected implementing ERPNext because of this issue. Everyone is asking for the advance payments to be reflected in the “Advance payments” instead of Creditors/Debitors.

1 Like

Agreed. Advance payments should be treated a a special general case. It is a liability account and nothing else. A separate ledger or advance journal or similar should be available for dealing correctly with advance payments. Advances can be paid back, transferred, allocated to more then one project or client and there is no correct accounting method at present to handle advance except by the introduction of manual journal entries which is error prone and time consuming.

1 Like

feat: Record Advance Payment as a liability by GursheenK · Pull Request #35609 · frappe/erpnext · GitHub

1 Like