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.
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.
@Tut:
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
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.
@Nicos
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.
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.
@Tut:
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.
âSome users will do this or that in an improper or stupid way with this featureâ is not, or at least it shoudnât be, an argument against a potentially useful features for other users.
If anything, on this forum, we have seen many examples of users improperly using manager with its current and explained in detail features.
Actually, when it comes to transfers between financial accounts (bank/cash), double entry as per your quoted example hasnât actually been applied and this is the constant flaw in your argument.
Take the following example based on your âdouble entryâ of Bank debit / Cash credit transfer.
Looks good except, neither the bank or cash account balances - look at the total lines.
Therefore to resolve that you need to add the true double entry to each account.
Now the total lines balance.
True, but not when the two accounts involved are âfinancialâ accounts - see above example. Each financial account has to have a balancing entry within itself, as each financial account also needs to reconcile to a balance.
No its not, as the account getting the spend money + is a âgeneralâ ledger account, not a financial ledger account, and this is where you are constantly failing to understand the distinction.
Hopefully the above illustrated examples have been specific enough for you. There has been no (borderline) trolling âhalf transactions" commentary, as all your own detailed debit / credit examples have only ever been - half transactions - one leg in the bank account and one leg in the cash account, whereas proper double entry accounting requires two legs within the bank / cash account, not just between them.
What you are not comprehending is this: Manger in the background is actually creating the other âmissingâ half of the transfer transaction, otherwise, if it wasnât, you couldnât reconcile any financial account balance.
One group who bang their head against a wall requesting features because they donât fully grasp the concept of double entry accounting and the other group who are living peacefully with the inbuilt feature.
Having said all that, when it comes to bank / cash account transfers I understand the âfrustrationâ
My solution is this. I have two clearing accounts, one for bank to bank transfers which is self clearing (hopefully), the other is for bank to cash transfers. In this case I use the imported bank statement for the bank side and for the cash side I do a single âmonthlyâ transaction based on the clearing account balance. As the Bank account statement is unlikely to have received a cash deposit or withdrawal transaction incorrectly, it can be reliable assumed that the cash clearing account balance is correct.
If the bank to cash account transfer bank rule could have a tick box, duplicate me. then this could resolve the issue.
Currently the topic heading is to broad as it applies to all inter-account transfers whereas the topic is more specially about bank / cash transfers so I will edit it to reflect that.
But you arenât and thatâs the point you are failing to grasp: If you are only putting entries into the cash columns of the bank/cash books, then the bank/cash book totals wonât balance (so you donât have double entry). As shown in the first example above.
Accounting principles require bank/cash books to balance, that is, that the cash column of the bank/cash book must have a contra entry in an analysis column ( true double entry). As shown in the second example above.
If you really insist that your logic is so correct then how do you explain this:
Using the first example, your preferred position, the cash column of the Cash Account states that it has a zero balance yet the analysis columns of the cash movements shows you should have a balance of 50.
You canât have both, zero and 50 balance, regardless of which backyard you hang out in.
Please donât mix your request for software functionality into lecturing others on accounting principles, as it only illustrates your accounting naivety.
Besides, if Manager is getting it so so wrong, then all other accounting software must also be getting it wrong as they are all following the same proven âuniversally understoodâ accounting principles.
