This is probably not true.
It is unlikely that a for-profit business is going to spend the exact same amounts of money that they receive (otherwise you probably wouldn't be earning a profit), and as a result of this, it is likely that you will need to send a BTC to a change address for each transaction that you send. Sending to 10 change addresses in 10 transactions is going to be more expensive than sending to 1 change address in one transaction. If you split up your transactions so that you have one transaction for each payment, then you are going to have to eventually spend the money that you sent to these change addresses, which would cause you to have an additional input for each change address.
With limitations, for each transaction you can eliminate to combine multiple payments into one transaction, you will save the cost associated with one input and one output.
Part of it is similar to a web wallet. Each user has their own keys and addresses rather than just a number in a database that shows how much they have. Instead of sending each transaction to the network as soon as it is made, I will add them together into one larger one saving on overhead.
The exact working out of it all is yet to be figured out. At the moment I am writing software for card terminals
Well that will change things a little bit. Probably most importantly, you need to understand that you cannot simply "add transactions together," all of the inputs in a transaction need to sign the entire transaction -- this means that if you have a transaction in which 7 users are sending funds, but only 5 of those users sign the transaction (assuming 1 user = 1 input), then you will not be able to send any of the transaction until the remaining two users sign the transaction, or alternatively you create a new transaction spending funds from the 5 cooperating users, that each of them sign. This will result in you having a tradeoff in that it is likely that many of your transactions will fail because users refuse to sign a particular transaction for one reason or another, and depending on how many users you have/how frequently you are creating transactions, this may lead to long delays in being able to even broadcast a transaction.
Additionally, if each user has their own address and own private keys, then I would presume that if a user does not spend an entire input, that they will also have their own change address, which would mitigate the savings that I described above.
Under my understanding of your setup, you would save about 40 bytes per transaction that you can eliminate, and you would have the tradeoff that there might be delays in broadcasting transactions.
One other thing to keep in mind is that having large transactions might result in you having to pay higher tx fees rates (on a per byte basis). For example, if your transaction is only 0.24 kB, then your transaction might be the cheapest transaction confirmed in a block if you are paying 0.0000012 BTC per byte because there are no 0.24 kB transactions that pay that high of a rate. However if your transaction is 150 kB, you might need to pay something closer to 0.0000018 BTC per byte because you will need to outbid many more transactions competing for that greater block space.
