Inter account transfer enhancement

Yes, but that is a Spend Money to third parties not an internal transfer between your own accounts where you are both the payer and the payee.

However I do agree that you can do one withdraw and have the bank do multiple deposits to other accounts as a counter service - this is not applicable to user created online electronic funds transfers.

Therefore your suggested enhancement only needs to have a 0 Add Line - one button added to both the “Paid from” and “Received in” plus Journal Entry like balancing indicator for added input control.

I will convert this to Ideas Category.


I agree with your first point that it would be useful, but I’m struggling to understand how this would work.

If you’re taking 100 out of Account A, and 200 out of Account B … it’s not clear which source account paid which destination account. There is no way for Manager to know how to record it accurately.

AccA - Spend 100
AccB - Spend 100
AccC - Receive 50
AccD - Receive 75
AccE - Receive 75

Did the $75 for AccD come from AccA or AccB … or a bit from both? etc.

You don’t have to worry about that. it just like a compound journal entry. Think of it like two or more accounts combining to feed other accounts with funds.

If adding more lines to the spending accounts is not possible at least adding more lines to the receiving account side will be easy.

Yes. In hindsight, I think I was making it a bit more complicated in my mind than it actually was.

I had a thought on this / just brainstorming the idea - did you consider editing?

Either this interface you’ve proposed would just be a shortcut to creating multiple regular transaction records… and you would then edit them individually after that. Or, the more complex approach would be that you can edit it in this mode again afterwards (similar to a journal entry).

I assume that both of the above methods would suit your requirements… and I wonder, if this were to be implemented, which option the developer would choose.

No, but i thought about cloning. Inter account transfer doesn’t have cloning. Maybe if it did, my owrk would have been easier and I wouldn’t have made this suggestion.

The narrations were the same I only needed to change the amount and receiving account. So @lubos please add cloning capability to inter account transfers please.

This was already added to Ideas months ago: Clone inter account transfers.


Well, what is happening on a bank statement?

You instruct bank to transfer 1,000 from bank account A and deposit 200 each into bank accounts B, C, D, E, F?

Then on bank statement of bank account A, you will see single withdrawal of 1,000 or five withdrawals of 200 each?

Yes, the teller (technically) withdraws 1000 from A and makes individual deposits into the other accts.
If the instruction is accompanied by a cheque, then only one withdrawal occurs.

There will be a withdrawal of 1000.00 on account of A.
Because the bank will withdraw the amount into a suspense account and distribute from there with a narration that the funds is coming from A.

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.

1 Like

I think that one in over thinking and creating problems which don’t exist - study the Inter Account Transfer form

0000000 Bug 6

Point one : the terms Debit and Credit aren’t used - in fact the current terminology is extremely clear.

Point Two : Currently different institution accounts can be specified without any issues, including ones in different countries

Point Three : (lost for words) The user is specifying the actual institution account to be used - so no additional logic is required. The User is simply instructing Manager how they want to move the funds within their bank / cash accounts, how the banks play with the tiddly winks is relevant.

Point Four : The required controls would be absolutely no different to the current Journal Entry methodology.

Because you continue to confuse a user’s basic instruction within Manager - shift these funds - and how the banks may function.

EG: “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”

If these accounts are setup as Manager Bank / Cash accounts, then they are equally available for the same misuse via both Receive & Spend Money.
If these accounts are not setup as Manager Bank / Cash accounts, then they can’t be specified for Inter Account Transfers.

NOTE: My mother-in-law does this type of transaction at the bank teller counter every fortnight - withdraws a lump sum from one account, deposits some to the credit card account, some to other specific purpose accounts and the balance into her pocket. Managing her accounts would be far simpler (26 times a year) if this enhancement was available.

That’s true with regard to current form. But @Abeiku’s illustration used those terms. As I said, it’s a small issue.

Yes. But now you’re limited to one origin and one destination account. Problems arise when you start doing this with multiple banks, and no bank is going to process a multi-bank transfer as a single transaction. They couldn’t do it.

The user is only specifying the accounts according to what he or she has named them. That doesn’t guarantee the accounts are or are not in the same institution. So the logic is required to prevent entry of transfers that cannot happen in real life. It isn’t an issue until you raise the possibility of multiple banks on either the origin or destination end.

I don’t confuse them at all. I’m just predicting that users will be confused and have difficulty correctly entering transactions that, in real life, cannot occur the way they’ve been entered in Manager. The program is filled with features that are there only to try to prevent errors. (Think of the prohibition on bank/cash transactions in journal entries.)

Your mother-in-law example illustrates what I’ve been saying all along. She withdraws one lump sum, then she makes deposits to other accounts. From Manager’s perspective, that would be a spend money transaction from the origin account. The teller’s counter serves as a clearing account. The multiple deposits would be individual receive money transactions in the destination accounts. What do her teller vouchers look like? Does she end up with just one or are there several? And what would she do if she wanted to transfer some of that money to the bank next door where she took out a credit card because their rate was better? She would not be able to combine such a transfer.

You keep arguing from the banks operating perspective - how the banks internally process events is totally and utterly irrelevant. You, not the bank, make a series of withdraws and deposits which are recorded on their statements which align with your “single” Manager Inter Account Transfer transaction - with everything being reconcilable.

Or put it this way - you go for a walk, in bank A you withdraw from the cheque account 250 and deposit 100 to the saving account then you go to bank B and deposit 100 on the credit card, at bank C you withdraw another 150 from the transaction account and at bank D you deposit 200 on the overdraft. On arriving home you open Manager and create a “single” Inter Account Transfer covering all events.

The mechanical movement of the funds (walking / carrier pigeon / electronic) is as mentioned - irrelevant, the recording of the funding transactions - the accounting entry - is very relevant.

(1) True
(2) Does it matter if they are or not in the same institution. We are not discussing a user’s online electronic transfers within an institution here.
(3) If the user has created a Manager Bank Account, then Manager by default accepts that it can be transferred to/from - Manager can’t validate its actual usage in real life
(4) Why does multiple over single make it an issue - if the account can be selected, it can be selected in both single and multiple, once again we aren’t talking user online electronic transfers.

Generally users record the events that have already occurred in real life, uncertain as to how many users create a transaction scenario first then try to make it fit real life.

Which is exactly what Manager’s Inter Account Transfer is doing in the background - serving as a clearing account, it doesn’t post the “teller’s” double entry contra transactions.

(1) Doesn’t know, she never sees them as they are bank internal documents.
(2) None, single electronic withdraw entry
(3) The credit card is with a different institution but payable at the withdrawing institution.

You seem to want to argue over how many angels can dance on the head of a pin. All the things you say are technically correct. My concern was that multi-account/multi-bank transfers are likely to get many users into trouble and will be difficult for them to reconcile. My point of view boils down to two things:

  • Most if not all banks will do single account to single account transfers, so why not follow that pattern.
  • Cloning is where the big savings of effort will occur. So I’d rather see that than multi-account transfer capability.

But this is not my decision to make. And if the feature is added, I won’t be able to use it because my banks don’t operate that way. Despite your claim that we are not discussing online electronic transfers, I specifically was. That’s almost the only kind I make, both within and between institutions. And I do it several times per week. But if I physically go to the bank, they use the exact same software screens I do. So their capabilities are identical to mine.

Enough said.

Yes, which was contrary to the thrust of the topic. “Inter Account Transfer Enhancement” is about expanding the scope / usage of the feature beyond being limited to users simplistic electronic transfers where required - whereas banks do a single “statement” withdraw to create multiple “statement” deposits both internally and externally of the paying institution. Cloning wouldn’t suffice here.

Inter Account Transfer Cloning has been added to the latest version (17.11.15)

@Abeiku, do you still think your suggestion makes sense after addition of cloning? If not, I am going to remove it from the ideas category.

It still does, transferring cash to different cash accounts will be faster.

It would be useful for me, and for many of others.

But depends on the work that will needs to be done to get it. There are more important features needed (Enhancing Limited user access, Purchase/sales order balance tracking, etc)

1 Like

That’s what I thought you would say. Just wanted to clarify. I’ll leave it as an idea.

1 Like