This discussion points out potential problems, regardless of how any specific bank would enter a multi-account transfer.
First, many users do not understand debits and credits, frequently reversing the two in their minds. That reversal comes from experience seeing bank transactions and statements, where the terminology is from the bank’s perspective rather than the business’ perspective. So different terminology would be required, probably withdrawals and deposits. So this problem is relatively inconsequential, and could be overcome through design of the entry form.
Second, things seem straightforward when you use an example of Withdraw from A and split Deposit to B, C, and D in the same institution. But what happens when B, C, and D are with different banks? Now you need to add the requirement to designate the bank associated with an account within Manager so the program can determine that a split transfer from A can go to B or D, but not to C. You cannot rely on the user to understand and make that distinction. And if you allow someone to enter such a transaction, you now have transaction amounts that cannot be reconciled with statements, regardless of the fact that the financial effect might be the same as multiple, separate transfers.
Third, think about what happens when you add the capability to withdraw from A and B and deposit to C, D, or both. The program needs logic and additional data to determine not only whether A and B are at the same institution, but whether the accounts are of types such that withdrawals could be combined. One might be a certificate of deposit and another a demand deposit account, for example. A bank is very unlikely to be able to combine those transactions. But determination will rest with the bank’s specific procedures, not some generic account categorization within the program.
Fourth, split transfers of either multiple origin or multiple destination accounts must obviously be balanced. The program could prevent creation of an unbalanced transfer, but once you put in the ability to choose more than one account on either end of the transaction, you have the potential for irritating arithmetic errors, etc. Compare this to the current implementation: you enter the origin account withdrawal amount, and as soon as you choose the destination account, the amount is filled; if you change the destination amount, the origin amount is modified to match.
To me this seems unnecessarily complex for very little utility. Since some, if not all, banks would split such a multi-account transfer into individual transfers to actually process a complex transfer, why not leave things that way in Manager? Adding the cloning capability will dramatically speed up entry anyway. It will probably be faster to clone and edit three or four transfers than do all the selection and entry necessary for a multi-account transfer. And it means you don’t need all the bank and account characteristic information and logic that will be required to prevent errors.