>Well, you just write some code to determine where partial payments should be applied with only the total payment amount and one invoice number as your inputs. If you can do that . . . you GOOOOOOOD! (that's good, not god <g>)

(of course not, there are too many of the latter already)

>Then you just patent it and bring in the royalties.

Um, not one invoice number. You have a history with your customer. There's possibly multiple invoices and multiple payments. There's the laziness of payment, where you have an invoice charging $1323.22, and the guy pays $1323.00, because he's handwriting is "crow's legs" (as we say in Serbian) and he can't fit the cents on the check, or just won't bother with them pesky decimals. Then you have the guys who always pay a bit so they don't owe too much, but never get in the clear. Then there's guys who don't pay anything for months until they come up with a huge amount and they pay it all... almost, they forgot one invoice two months ago. Then there are advance payments, credit notes etc etc.

The trick is to do automatically what you can. In my case, it caught between 70% and 90% of possible matchings, depending on the user's business and habits of their customers (and their habits towards suppliers - worked on those too, and a few other cases).

Then you provide some interface for the user to do the rest interactively. Automatic binding only handles so much that the remainder is manageable.