Some times, when I transfer cash between bank accounts the bank charges a “payment fee”. Presently there is no possibility in Manager (that I can see) to add this as part of the same entry. Basically I need to create an additional “Spend Money” entry to record this fee (or “fake” the entry and add the fee to the amount for the debit account entry and/or subtract it from the amount for the credit account entry - but doing this I would not get my accumulated bank charges account to match the reality)
I feel it would be more convenient and more intuitive if I could “Add line” in a “transfer” entry in the same way as it is possible to “add lines” in “spend money” and “receive money”.
I then see this complete transaction “as one” and it mirrors the physical Debit advice I receive from the bank (which I by the way always add as an “attachment”)
This is not possible for a simple reason. A transfer is between two bank accounts owned by the business. Therefore, no payee is entered. A fee, no matter how it is applied, is paid to the bank. So you need not just to add a line but add a payee. Since there is no guarantee the bank accounts are with the same institution, the fee could be payable to the bank where the withdrawal occurs or where the deposit occurs. And some transfers occur by wire, where more than one entity assesses a fee along the way.
@Tut is correct however I’m considering to get rid of Transfer money transaction and do it differently. The main issue is when importing bank statements, it’s not possible to set up a bank rule to categorize imported transaction as a transfer. So most likely I will be making it possible to select the second bank or cash account on Receive money and Spend money transactions. This will effectively allow you to create a “three-way transfer”.
Yes it is and its’s very simple, the bank rule posts the opposite side of the transaction to a clearing account.
Each leg of a transfer is a completely separate transaction so double entry must apply
Leg 1 - Bank/cash account A - Spend Money with corresponding contra debit
Leg 2 - Bank/cash account B - Receive Money with corresponding contra credit
Unsure how your import bank statement Spend / Receive Money transfer would work with timing differences.
You transfer out of Bank A on Aug 21 and the transfer is received into Bank B on Aug 23, how would the import bank statement process match up these transactions. Transfers are not instantaneous (same dated) in most parts of the world.
The current Transfer Money process (via button or bank rule) is the most simplest and clearest understood approach. Why complicated it ?
@Brucanna this is what I do actually but it seems like a workaround considering Manager has special Transfer money transaction which is right there and you can’t use it.
Transfer money actually supports situation where money is taken out on Aug 21 and deposited elsewhere on Aug 23.
Date of transfer is Aug 21 and clear date would be on Aug 23. This way everything is being accounted correctly from accounting point of view and bank reconciliation can be done as well.
It’s not a workaround at all. You have the option of either using the (manual) Transfer Money button or you use the (automatic) bank rule.
Otherwise you could apply the exact same logic to both the Receive / Spend money buttons when using bank rules - “but it seems like a workaround (using bank rules) considering Manager has Receive / Spend Money (buttons) which is right there and you can’t use them”.
They are alternate processes, not substitute processors.
No, this is not a cheque situation where you have a funds withdraw pending with the bank and cleared at a later date.
The transferred funds (spend money leg) has been withdrawn from the account, gone, so there is nothing pending to subsequently clear. The receiving transfer bank doesn’t know the funds are coming - so nothing pending for them either.
Spend Money can have uncleared transactions and Receive Money can have uncleared transactions.
But a Transfer Money button transaction (being a combined spend/receive) can’t be both - a cleared spend transaction with Bank A (Aug 21) and a uncleared receive transaction with Bank B (Aug 23).
This issue doesn’t arrive with the imported bank statement bank rule as each leg of the transaction is processed independently of such clutter.
In my opinion, the current Transfer money approach and structure is almost perfect, and could be improved only by adding the ability to clone a transfer, something that has been mentioned previously.
The back and forth on this subject seems to center around recognizing transfers in imports. A couple thoughts occur to me:
Possibly, more sophisticated bank rules might recognize transfers, but the method would have to account for the fact that not all transfers involve two importable accounts. You have transfers to/from cash accounts as well as between bank accounts.
Transfers might be divided into two types: (a) deliberate actions by someone at a business who moves money from one account to another and (b) automatic transfers, such as from a credit card processor to a bank account. Type (a) is always knowable by the business, but (b) might not be known until a statement import. Might the current style of transfer be limited to the first type and the second be dealt with differently? I don’t have a good suggestion right now, because all my transfers are of type (a) and are done when I decide the time is right. I would never give up control or detailed knowledge about them.
Just thoughts. I see @Brucanna posted while I was typing. Some of those ideas are similar to some of mine. I think we are both expressing the idea that the current transfer function should not be abandoned, though another approach might be added. Preferences for which to use will depend on the character of a business. Things that seem essential for a large, e-commerce operation would be unthinkable for a small services business.
Type (a) is a transfer - from yourself to yourself (internal of the business).
Type (b) is a spend money - from yourself to a third party (external of the business), probably setup via a recurring “direct debit” aka “automatic payment” rather then automatic transfer.