The thought process/work flow of the form was that I had a list of invoices to be paid, I tick and select which (not all) of the ones I want to pay and then by pressing a button, a payment record (from invoice payment table) will be created and then each of the selected invoices will have that payment table id placed in their foreign key field.
Making a group first just complicates the process. I don't know your business rules so I don't know if you commonly have partial payments or payments that cover multiple invoices and if those payments cover multiple invoices, must they all be paid in full or can there be partial payments.
I also don't know how you receive payments. Do you get checks in the mail? Do the customers use electronic payments? Do they call you with a CC or bank check number?
You haven't described the method you are using to calculate an invoice. Does an invoice cover multiple orders?
When you create an order, are you storing the total in the order header? When do you calculate the order total? Do you have guardrails in place that prevent you from updating the details of the order once the total is calculated and posted to the header?
You also seem to be using the same form for multiple purposes. Maybe you need to focus in a little.
There are so many moving parts to this type of a process that it is hard to give concrete instructions.
So, let me offer some ideas.
I don't like storing the order total when the order is placed. However, if you put the right procedures in place, you can probably get away with doing it. I would use a complete flag on the order. That way, you don't even think about updating the order total until the order is complete. This is the way most web pages work. They will frequently keep a running total of what is in your cart but no taxes or shipping or final total can be calculated until the order is complete. Once an order is marked complete and the tax/shipping and total are calculated and posted to the order header, NO CHANGES are allowed. If a customer wants to make a change, the order has to be "pending" or whatever you want to call the stage prior to shipping. Then you would change CompleteYN to no and set the calculated values to null. Then the user can add/change/delete whatever and when finished, mark the order complete again and calculate and post the calculated values.
I would make a payments form and not reuse an existing form. This form would have a listbox with all the shipped but unpaid orders. You can use a multi-select listbox for this process. You can enter the payment amount and method. Then select one or more of the unpaid invoices. As each invoice is selected, you check your accumulator to see if the payment amount has been reached or exceeded. If three items are selected and the total = the payment amount, you should prevent selecting additional items. You can then push a button and your code can loop through the selected items and update each record and enter the PaymentID, payment amount, and date.
If the payment amount doesn't equal the oldest x items and you have a remainder, you can update the fully paid records and apply the overage to the next order in line.
If the payment amount exceeds the total for the unpaid items, you have to put the payment amount somewhere. You can't just ignore the discrepancy so you need to update the payment record with a suspense amount.
You really need to get with your accountant to have him tell you how he wants to track payments and suspense amounts.
And finally to tie all this up, you need to run queries frequently to find partially paid invoices so you can bill again. You also need to find suspense amounts so you can refund the over payment as appropriate.