Bulk Payments / Over Payments

psiiota

We have recognized a need in our system to make bulk payments, as often clients will send us one check for many invoices. @wrongecho @johnny, any certain way you see this being done in the backend?

johnny

Hi @psiiota what we do for now:

for example lets say a client has 2 outstanding invoices one invoice is 200.00 one invoice is 700.00. A client cuts us a check for 900.00 to pay both invoices. We apply the full 700.00 amount and reference the check number and then apply the 200.00 amount to the other invoice also referencing the check number.

The checks go into a cash account (Which is basically money on hand that was not deposited)

When we depot the check for 900.00 we do a transfer source cash --> destination Bank

We put the the amount of 900.00

In the transfer description we put the ATM Deposit - Customer Name - Check #

This is the way to apply one check to many invoices.

johnny

In the payments section we see 2 payments one for 700 and one for 200 but they both have the same reference number with the same payment date. So we could assume that 1 check was used to make a payments to the 2 invoices.

psiiota

So, this is what we are doing in the mean-time, yet it doesn't work very well when a client is trying to pay 8 invoices…

I want to have it function the same way for a bulk payment feature, where it shows each individual payment, as that is the correct way to account for it, yet I feel the UX would be massively improved if there was a modal on the payments screen to do so without 2*n clicks.

johnny

yeah I feel your pain point here We have a client that had 52 Invoices and finally decided to pay for it all after 2 years. This took way too much time to add a payment for each invoice and this is where I wished I had a bulk payment button

so here is my outlook on how bulk payments will work:

Under Customer Invoices listing you will be able to select the invoices that need payment click on the multi action button then click Pay

When clicked a modal will appear with all the invoices that were selected along with their balances

and total of all the invoices balance

then you can enter your payment amount, payment type, reference

Then when submitted via POST it will loop through each invoice and create a payment.

This will make it easier for large number of invoices.

Bigbug

johnny I think I'd reverse your logic..
when you receive payment from customer you +Add Payment when payment is entered the customer gets a credit which is directly bind to that payment then you'll go and select all open invoices and apply it to that credit.

I've worked with multiple bookkeeping software's in the past and all of them worked that way.

also sometimes a client writes out a check to you and they put in a little higher amount by error, if client agrees you can add his payment and he'll have credit on his account.

🙏

psiiota

Bigbug I think @Bigbug is on the mark.

We should add credits. The only way I see to do this would be a fairly massive overhaul of how payments are handled. @johnny any thoughts?

Bigbug

Also it would nice to see same option when customer pays online via stripe to pay for multiple invoices at once.

ov_vie

Hi,

this is a systematic issue, to be honest.

The most flexible approach would be:

have a table for invoices with date, cust, amount, amount_paid (this field is convenience, though)
have a table money with date, cust, text, amount (optional: TYPE: Payment, Credit, Refund,…
have a table invoice2money as a n:m with invoice#, payment#, amount (does not need cust)

In this structure, taxes are not relevant, in my opinion, as taxes are a part of the invoice only. Credits, Refunds etc are always for the gross amount, not the net amount.

When a payment is entered, there are 2 options:

Payment is for a specific invoice (this is mandated, at least in Europe. A invoice on the payment means it is for this invoice, primarily. It should not be booked against another invoice. This is important for e.g. a disputed invoice.)
Payment is without invoice

The form to enter (batch) payments should contain:

Customer (id, name as search field)
Amount paid
Invoice(s) - can be either specific invoice(s) or the default: Apply to oldest
Comment/Text

When a customer pays, this allows maximum flexibility for whoever does accounting. Also, this approach allows overpayments

Overpayments: When creating invoices, the customer payments need to be checked for overpayment, so the To Pay amount of the invoice is automatically decreased

Does that make any sense? If there is consens, I'd look into implementing this.

psiiota

ov_vie
I believe you've laid out a robust framework that addresses several key aspects of our current challenge. Your emphasis on flexibility within the payment and invoicing structure is particularly insightful.

Firstly, the idea of a separate table for 'money' alongside a linking table 'invoice2money' is a significant improvement. This structure not only simplifies the recording of diverse financial transactions but also enhances our ability to track and apply payments accurately. It's a more granular approach that gives us the needed flexibility for various scenarios, including partial payments, overpayments, and refunds.

Regarding your point on the 'amount_paid' field in the invoices table, I agree that it adds a layer of convenience. However, we might want to avoid this for the unneeded db writes.

Your approach to payment entry, particularly the differentiation between payments linked to specific invoices and those without, is crucial for compliance and financial clarity. In Europe, as you've pointed out, the clarity in payment allocation is not just a best practice but a compliance necessity. This distinction also helps in cases of disputed invoices, allowing us to maintain transparent and accurate financial records.

The idea of including a field for 'Comment/Text' in the payment form is also a thoughtful addition. It can provide context for the payment, which can be invaluable during audits or when reconciling accounts.

Lastly, I strongly support your suggestion regarding overpayments. Automatically adjusting the 'To Pay' amount of future invoices when an overpayment is detected streamlines the process and enhances customer experience by acknowledging their previous overpayments.

Overall, your proposed structure seems not only to address our current operational challenges but also positions us well for scalability and compliance. I'm excited about the potential of implementing this.