Feature request: Imported statements > bank to cash account ransfers


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).



I did not say you were making a mistake, or would make one. I wrote that the “issue is not designing the potential for incomplete transactions into the program.” Some user imports a bank statement that includes an inter account transfer. They neglect to designate the other half of the transaction. (That’s the other half I was referring to.) So the transfer is incompletely recorded, yet the user does not understand why. And there is no trail to follow, because such a transaction is indistinguishable from an ordinary deposit or withdrawal. The current design of inter account transfers ensures they are complete.

I suspect you will argue that the program should not be designed to hamper yourself to prevent others from making mistakes. First, that is not my decision to make; it is the developer’s. Second, the large number of users who raise the very questions discussed in this thread suggests many do not understand all that is involved and would be prone to such errors. I know for certain it is the developer’s preference not to be dealing with such misunderstandings if they can be avoided through program design. He is interested in serving small businesses where there is often minimal understanding of accounting practices and principles.



@Tut, I see you are past the denial stage, well into the acceptance state. We are making progress with you, soon you will be asking for the support of this feature as well.

What (exact) information would you require to manually add an inter account transfer? Please be specific and stop with the (borderline) trolling “half transactions” hand waiving.
Before you hit the reply button with the list I’m asking you to provide, scroll up and you’ll see that every single one of the requirements is listed in the imported bank statement except the destination (in a widthdrawal) or the source (in a deposit) transaction of that statement, and that is where your logic is false: The imported transaction isn’t half the transaction with the information provided. The imported transaction is half the transaction due to the limitation of the software. That’s where the feature request comes in: Add an option to specify the other half of the transaction (the missing cash and/or bank account (if the account processes the transactions “in realtime” (no pending transactions)). Stop typing. That’s (read this extremely carefully): the same as manually adding the inter-account transfer: a source, a destination, a date, the amount, and a description. No half transaction there (see below, and please do stop typing). As a note: The functionality is actually there (wow, imagine that!): you just can’t select a cash or bank account. Yeap, as magically as this sounds: a bank account is the exact same as any other account! Amazing isn’t it? It uses the exact same logic as your car expense account! Money comes in, money goes out! Mind blown?

Before you go on with the “half transaction” hand waiving again: NO “half transaction” transaction is allowed (even in the current state) in the program. That’s where the suspense account comes in, because 1 transaction = 1 debit + 1 credit (always, that’s double entry accounting).

I agree that the software is designed for people to use without a PhD in accounting, so it is the logical step in the right direction. Hell, I’ll even settle for a bank rule for transaction XYZ to trigger an inter-account transfer if need be, anything but the current way of doing it (again, since it is apparently required: I’m talking about imported bank statements).

Now that we both agreed that such a feature isn’t a “nice to have” but a “must have”, how about you lend a hand to move this rock so the rest of us don’t trip over it every time? Or is it still “put there by the hand of $deity himself! thou shall not move it!”? Feel free to resume typing.