Blerg, I hate being ignored, especially when the topic is so damn close to my Ph.D thesis.

At any rate, what you DON'T want is to generate the list of all possible combinations, because most likely, a lot of them are flat out undoable. Similarly, there's no point checking all combinations of elements of size up to N, since unless the average of the transactions is exactly total/N, you'll never use all N transactions. In fact, to calculate the absolute most you'll need, order the transactions in growing order, and sum until you reach or pass the total and count how many you needed. You could even do that at each step of your algorithm to know how many more max you'd need.

Anyway, your problem is pretty much the sum of subset problem (or subset sum problem). Traditionally, it uses integer values for the set values and total, but going from prices to integers is trivial (multiply x100, tada), and there are known best algorithms.

In C, one such algorithm is given here: Sum of subset problem in C (with a nice explanation to boot)
Basically, the idea is to recursively solve the problem for total-selected using the list of transactions with selected removed from it.
In Java, one could use this: How to implement the Sum of Subsets problem in Java - Stack Overflow (the last reply)

Aditionally, without any knowledge of algorithms, this kind of problem can be "easily" solved using binary/integer resolution programs, such as https://projects.coin-or.org/Cbc (open-source, freeware) or Cplex (proprietary, expensive) by modeling the problem correctly, feeding it to the program, then having it work the branching magic for you.