Feature request: Imported statements > bank to cash account ransfers


Wouldn’t things be made easier if when activating the inter account transfer tab a system account for transfers is also created?



That would result in an unnecessary account for many users, with no way to get rid of it. Many would probably wonder what it was for. Meanwhile, it does not seem unreasonable to expect those who import bank statements to set things up to accommodate their own practices. Some might like to use a clearing account. Others might like to manually exclude inter account transfers. An automatic system account forces you to do things one way. A one-time account creation doesn’t seem like a large burden.



A one time account isn’t a large burden, and neither is adding the feature (which by the look of it a few people want).

This is what I (and others) want to do:

  1. Import the bank statement
  2. Use a bank rule to tag “CASH WIDTHDRAWAL” and set up the inter-account transfer to the cash account assigned (it’s not "one leg of the transaction, that breaks double entry accounting, it is in fact both legs of the transaction right there: a debit to one account and a credit to a different one).
  3. Tick the tagged transactions and process them. Finished.

What you want to do:

  1. Import the bank statement
  2. Use a bank rule to tag “CASH WIDTHDRAWAL” and assign it to the clearing account.
  3. Tick the tagged transactions and process them.
  4. Manually add transactions to transfer the already transferred money to the cash account (because in your case, double entry isn’t applied to the two “affected accounts”, but instead applied to a third account that now shows a positive balance).

Taking a step back and looking at the bigger picture, it’s the documented scenario (of a clearing account) that actually “breaks” the double entry and only contains “one leg of the transaction”, not the requested feature. As a reminder, the functionality requested is already implemented in manager (it’s the inter-account transfer we are talking about), it’s just not exposed to the user in a user-friendly manner, and does not break the double entry (debit one, credit another). A clearing account simply adds an extra manual step into the equation. I understand that it “doesn’t seem like a large burden”, but processing a few hundred transactions turns from a 10 second job of simply ticking the highlighted transactions into a 2 hour job of copy/pasting dates, descriptions and sums. That (to me) is a large burden.



@deZillium, you are missing my points, possibly because of duplication of the term account. I was not speaking of two legs of a transaction in terms of double-entry accounting, but rather of two different bank accounts. If you want to think about double-entry accounting, and imported receipt (as an example) is already two postings: a debit to the bank account and a credit to some other account, such as Accounts receivable. It is this second account you are identifying with a bank rule. There is no second bank account involved.

When you make an inter account transfer, you have two completely separate bank accounts involved, and you have no information during import for the second one. Yet, in addition to the two account postings for the origin account, you also would need two postings for the destination account, for a total of four database entries. There simply is not adequate information in an imported statement to determine which other bank account is involved.

This may seem trivial to you. I assure you its more complex than you seem to think.



Let me help with the complexity: When processing a transaction with a bank rule, the destination account can be manually selected. Complexity problem solved!

I cannot select another cash or bank account as the destination, which is exactly my point (with all due respect, it is you that is missing the point).

If you need 4 database entries for inter-account transfers, you are doing something extremely wrong and this needs to be fixed now before it blows up 5 years down the line. A single transaction (on ANY account) is a 2 database entry: A debit (or credit) from the source account and a credit (or debit) to the destination account. Double entry is still applied (source entry + destination entry)


I hope I got my point across. This is a legitimate feature request. Just because everyone else is doing it the “X way”, does NOT mean that the “X way” is correct. It is one thing I’ve learned from my job watching “enterprise IT persons” cowboy-ing together “enterprise” solutions.



There is no need to shout. Your point and request has been made by previous posters

They key problem is that if you import a statement from two banks accounts with transfer between them, then the import will double up the debit and credit in your scenario ie Importing a statement from bank account one will create a debit in one account and a credit in the second account. Importing a statement from the second account will create another debit in account one and another credit in account two

Admittedly, if the inter-account transfer is to or from a cash account there will be no second importation as cash accounts do not generally have statements to import



No. As it currently works manager recognizes already imported / present transactions.

I handle inter account transfers by making the transfer first and then importing the bank statement and it always says something like 5 transactions in the bank statement 4 to be imported one is already present.

I can post a screenshot of that once I have a transaction like that.

1 Like


This is me shouting: I AM SHOUTING
This is my capilizing for emphasis (ie as I said above “let me put it into capital letters”): THIS IS AN EMPHASIS

Joking aside, exactly what @novica said. Already imported transactions are automatically excluded, so that’s not the “barrier to entry” for this feature request. Neither is the “unknown destination account” (it will be handled exactly the same as an expense account). Any other strawmen that we need to take apart? :smile:



That will only function for bank to bank transfers if they are of the same date.
If you import Bank A statement that has a transfer to Bank B dated 1/1/1 then when you import Bank B statement it must also have the exact same transfer date 1/1/1 for Manager to recognise the existing Bank A imported transaction against Bank B.

However, if Bank B has that transfer dated 2/1/1 then when imported Manger will see this as a whole new transaction, so the single transfer becomes two imported transaction - a nightmare if your suggestion is adopted.

That is why it is essential that intra bank transfers (not necessarily inter bank transfers) which happen over night or days MUST be handled via a clearing account so the User doesn’t get trapped by date differentiation.

Bank to/from Cash transfers can be of a different situation with Cash being non-importing, but having duplicate / alternate processing systems between bank to bank and bank to cash just brings complexity which contradicts Manager’s simplicity.



Hi guys/girls

I search through all the Forum threads and topic and ideas and this seams to be the closest one to the problem.

I will attach the screenshots so that all can see what the problem is and then, please guide me how to rectify the problem or how to solve the problem because I seams to overlook it some where.

This screenshot is where I import my bank statement and all will see that the description is numeric that comae from the bank and you can not use bank rules to solve it because I will have thousands of bank rules over a couple of months because I do transfers between these accounts quit often.
I can use edit to solve interest received but the inter bank transfers is a issue, and I believe for many others also.
If in the account column was a new inter bank transfer rule or something it will make processing data faster.

These transaction get done and cleared on the same day, except for the interest of cause.

Here I done inter bank transfer already.

This is my imported bank statement for my main account.

In Bank Rules I can not set up this account rules and in edit to create a Asset account will bring forward extra journal transactions to solve 1 simple programming future that we need.


NS. Our power is to be shut done now for the next 2 1/2 hours so I will look later if someone shed some info for me.



Hi all

I found the solution self here
Please take note of this:
You should use the Inter Account Transfers tab or import bank statements in the Bank Accounts tab, but not both. Using both will result in duplication of transfers. Correction of duplicates requires deleting either (a) the inter account transfer entry or (b) both the corresponding payment and receipt from imports from the two banks.




I think there is little chance that this important change will ever be made! At some point in the early stages of development, I assume, someone wrongly decided that this entry:
Bank a/c 1 debit
Bank a/c 2 credit
was incorrect. All subsequent development has been based on this silly assumption. Furthermore, any justification for this principle which you might read in this forum uses a circular argument which begins with this assumption and thus cannot be challenged! To change this now would, I believe, require an extensive if not a complete rewrite. By way of context, I am a home user with 7 accounts using 2 different currencies in 2 different countries and I have made 20 inter-account transfers in the last 2 months. If I lose track there goes half a day. In addition, I would suggest that while OK for the small user this program will never graduate to the big time with this limitation



I just found this thread after trying to do the exact same thing, very interesting.

I also don’t like having to do all my Inter account transfers manually and must agree that there is reason for this request from me also. Had 20 to do already this month and more will follow as businesses increases. I can understand both sides of this but believe the speed this feature would add to inputting transactions would be invaluable to me personally. As long as the end user understands double entry then they should not get themselves into any situations using this feature.

An example, I transfer many times from PayPal to my main bank account and this is always done instantly so no worries on my side regarding dates etc. If this feature was available i could import PayPal statement and assign all the inter transfers via the rule suggested and then just delete all of the transfers from the main bank CSV before import and i would be done :slight_smile: No double transactions to worry about. It would be so simple and as its always the same kind of transfer, a bank rule to do this would be a really great feature. I understand it would not suit everyone but it would save lots of people hours of valuable time.

At present i just reference all the transaction in the PayPal CSV sequentially, make note of dates, amounts and references of my inter transfers and then delete them from the CSV and enter them manually after finishing the import. When doing Bank CSV i only take note of the reference i want and delete all the transfers before importing. This seems to be the quickest way i can figure to do this but i have only been using Manager for a little over a year so still learning :slight_smile:



Sorry, @rungek, but your assumption is wrong. You seem not to have read the earlier posts in this thread (or the many other topics and Guides in which this subject has been extensively covered). To explain once more, an imported bank statement only has information on one of the two lines in your example, either the debit or the credit, never both. So processing an inter account transfer represented in an imported statement without a clearing account or manual deletion of duplicates is impossible. And that is true no matter how many accounts, currencies, countries, or transactions per month you have.

The explanation is neither silly nor circular.



There are not two sides to this issue, @Nicos. There are users who understand what is required to process an inter account transfer and those who apparently do not. Without the debits and credits from two accounts simultaneously in one statement, the only way to process an inter account transfer from an imported statement without manual deletion of duplicates is via a temporary clearing account. There, the debits and credits can offset from sequential imports from different bank accounts.

Users often fail to see that the reason inter account transfers are so simple is that Manager handles deposits to and withdrawals from two different bank accounts, which you nominate to the program, simultaneously, forcing equivalence in the amounts as it does so. No imported statement from a single account can do those things. The clearing account is the enabling step.



Your description fits the scenario where Bank A’s imported statement gets imported, but Bank B’s statement doesn’t match it (as mentioned before).

We (as in most of the people that asked for this feature) are asking for this functionality to enable fast(er) imports when cash accounts are involved. In that scenario, Bank A’s imported statement says:
I widthdrew X amount on ABC date with description "cash widthrawal"
Since the cash account doesn’t have any statement to import, manually adding the transaction is exactly the same as asking the program to treat the transaction above automatically. Account A gets debited, Account B gets credited, same amount, same date, same description. Double entry applies, everyone lives happily ever after. It is the exact same treatment as any other transaction (ie a spend transaction): one account gets -, one gets +. Actually, it’s the exact same treatment as a clearing account, only the clearing account adds an extra step that now you have to balance it out with yet another transaction. It literally is the same treatment when you manually add the inter-account transfer, we are just asking for that step to be automated, and no, a clearing account isn’t the only way to do this.

Why is this so hard to understand? Having the default functionality for the 1% of the transactions that may not have their dates match (understandable) while leaving the other 99% of the transactions that could be handled automatically left to the (tired) hands of the one doing the manual entry means something isn’t headed in the right direction. How about we flip those percentages around and that 1% can still go about their business as they did before (nothing will change as far as they are concerned) while the rest of us enjoy the added freedom it offers?



Not two sides but different perspectives then :smile:
One believes the only way to do this is the straight line from A to B and the other that believe that they would be happy to take a different route as long as it speeds up the process and yields the same result!

For me, Importing Bank A “paypal” statement with this feature available and then deleting all the inter account transfers lines from BANK B’s CSV before import would much faster than manually entering the transfers. I think that is what people are getting at. Not so sure its about people not understanding how the transfers work, more about people knowing they can get the same result faster. After all there are always multiple ways of doing things and they can all be right.

1 Like


More like two groups: One group says “hey, I’ve been tripping on this rock for the past year or so, can you lend me a hand in moving it?” and the other group saying “This rock was put there by the hand of $deity himself! It has a purpose! Thou shall not move the rock!”. On top of that, each group turns around and says (at the same time) “wow, people are crazy these days”.

@the group supporting the $deity side: relax, it’s something to lighten up the conversation.

1 Like


Yes, it does, because that was the example @rungek gave: two bank accounts, not one bank account and one cash account.

Date matching is not the issue. The issue is not designing the potential for incomplete transactions into the program. When an imported transaction is unallocated, it can be temporarily lodged in the Suspense account. While the transaction may not be correctly posted yet to the right account, the money itself is known to be inside or outside the company. But when only half of an inter account transfer is imported, the source or destination for that money is unknown. In your cash withdrawal example, money is shown as gone, while it is actually still within the company. One of Manager’s design philosophies is to make it more difficult to make mistakes, not easier. Were that not the case, everything would be done with journal entries and only accountants could use the program.



At least we are getting somewhere, talks are good for de-escalation. The nuclear holocast has been averted.

Next step, @Tut please explain what, in my cash widthrawal scenario (bank account -> cash account), fits your description for a mistake, because honestly I do not see it. Please be specific, it will help me show where your logic isn’t applied to this scenario (which was the original feature request btw (first post by me in this topic)).

Source account? check (the bank account)
destination account? check (the cash account)
date? (check, date from imported statement)
amount? (check, amount from imported statement)

I see the entire transaction there, not “half of it”. The source account shows a debit, the destination shows a credit (2 transactions (one debit, one credit) in 2 different accounts = double entry).