This month I made a concerted effort to not enter any of my bank transactions in Manager - even though this makes the program less useful, since it means it gives me a less accurate picture of my current finances. “I’m gonna try it their way!”, I said to myself. "I’m going to just import my statement all at once, and then I’ll be up to date, categorize a few transactions, and reconciliation will be a snap!
One place where this falls flat on its face is transfers. Since bank statement import only understands receipts and payments (as near as I can tell) and since it has no concept of matching with existing transactions, then importing instantly creates a receipt or payment which cannot be converted into a transfer except by creating a new account transfer by hand; this also means that the audit trail for those transactions is relatively complicated.
I continue to think that the missing piece here is a much more flexible and intelligent transaction matching algorithm, coupled with a better import UI that lets you review transactions BEFORE they’re committed to the ledger (Manager calls out things that need to be reviewed, but once you’ve clicked ‘import’ there’s no way to bulk-delete them from the review UI; you literally have to go through one at a time and hope you didn’t miss any.)
And as long as I’m nitpicking the import process: I have at least one bank whose QBO/QIF downloads ALWAYS contain 90 days of data, and provide no way to constrain it. Of course that’s the bank’s shortcoming, but being able to tell Manager “Ignore any transactions in this file before date X or after date Y” would be convenient.
Ugh, I feel like the guide is giving very bad advice there, because that seems like me to be a real misuse of the clearing account concept to make up for a weakness in the software - it complicates the audit trail substantially (the thought experiment: imagine someone importing a bank statement who puts every receipt or payment into a clearing account rather than using the pending/cleared flags; that would be obviously terrible. IMO using a clearing account in the credit card payment case just because the software is unable to categorize something as a transfer on import is letting your bookkeeping process be driven by the software, which is backwards from how it should be.)
The two concepts are completely unrelated. Pending or cleared status relates only to whether the transaction entered into Manager has cleared the bank. All imported transactions have cleared the bank or they would not be in the statement exported to you by the bank. A clearing account, on the other hand, is a temporary holding account. In this case, use of a clearing account is due to the fact that both legs of an inter account transfer are not available in the same bank statement. If they were, it would not be a transfer. The transactions related to a transfer are not allocated to a clearing account because they are pending, but because they are transfers between bank accounts.
No, both bookkeeping and the software are driven by accounting reality. The use of a clearing account is not due to any shortcoming in the software. It is necessary because both legs of the transfer (withdrawal from one account and deposit into another, possibly with a different institution or even in a different country) are not available in the same statement. So there is nothing to match. Remember that inter account transfers can take days, even weeks, to complete depending on the nature and mechanism of a transaction and location of the two accounts involved.
I think you and I consistently disagree on this, and that’s ok - any accounting package decides what workflows they’re going to prioritize, and what workflows they’re not. My major point here is that Manager may literally be the only accounting software I’ve seen which is unable to categorize a payment as a transfer during the statement import process. That decision isn’t driven by accounting reality; it’s driven entirely by the software.
You are right that we disagree. But since you believe creating inter account transfers from the import of a single bank account statement is feasible, please explain how Manager could possibly know that a deposit is one half of an inter account transfer. And where would it get the rest of the information it would need to populate the transfer form?
How would it know the date of the transfer, since the receiving bank only knows when it received the deposit?
How would it know the Paid from account, since that information is not imported?
Even if it could extract the Paid from account from the description or report header information (not available for all formats), what would distinguish the transaction as an inter account transfer as opposed to some other payment from a customer who happened to use the same bank?
Define, if you can, a receipt rule that could recognize an inter account transfer and populate an inter account transfer form. (Ignore, for now, any lack of capability in Manager. Just explain how the transaction information common to all the supported file types could be used to provide the information.)
Your wish is not new, by any means. Manager users have asked about this for years. If you can propose a workable approach for the general case, I will happily put your suggestion into the ideas category.
Already asked and answered in other threads: among potential ways to deal with this:
(1) UI during import that offers the user a chance to recategorize transactions as transfers,
(2) Removal (or adjustment) of the “bank accounts can’t be entered on line-items in receipts or payments” restriction (something that I have seen people on these forums confused about nearly every week.). (In fact, this is particularly galling – here’s an example where Manager already has UI for me to categorize a transaction, but because of the dedication to the existing UI, the user literally can’t provide the information Manager needs to do the right thing.)
(3) If not (2), one could allow the user to recategorize a receipt or payment as a transfer post-import (requiring that they select a target account), to at least save time
(4) Better matching algorithm - if a transfer of the same value near the target date is already in the ledger that matches the amount, it’s probably a match - suggest it and get confirmation as in (1).
So there are multiple paths to get there. I know you hate it when I compare to other software, but the fact that type of workflow is done successfully by GC, QuickBooks, Xero, MoneyWorks (can’t match these transactions, but allows you to batch skip on import and allows recategorization as de-facto transfer), probably AccountEdge (I can’t run it anymore so I can’t check) and other packages is an existence proof; not only that, I’d say that it’s also an existence proof demonstrating that the workflow is important.
Maybe it can’t be done without changing Manager but I prefer to focus on the workflow. The workflow is “When importing a bank statement, it should be possible to categorize some imported transactions as transfers.” Your answer focuses on the point that Manager can’t do this without user input. But that’s fine; Manager generally can’t infer the account a transaction goes into without user input either. I understand that Manager doesn’t do this today. I think it should.
That does nothing to address the absence of necessary information.
You do not want to go down this path. A receipt or payment can only apply to a single bank or cash account. The concept of choosing bank accounts line item by line item is nonsensical.
Now, you have unbalanced books, because you haven’t recorded the other leg of the transfer. Ironically, you suggest all this as a way of avoiding use of a simple clearing account, which can be automated with receipt and payment rules.
But there will not be—indeed, there cannot be—a matching transaction in the ledger for the bank account involved, because it would be in the ledger of a different account (if it has been entered at all).
No; this is incorrect. The other leg of the transfer is the other bank account or credit card. That Manager doesn’t allow this to be provided in a receipt or payment context is strictly a software limitation on its part (QuickBooks, Xero, and MoneyWorks, for example, will all happily allow you to specify another bank account as a source or target for a receipt or payment.)
There’s nothing about accounting that requires Manager’s restrictions on receipt and payment accounts. It’s entirely an own goal the software inflicts upon itself.
The ledger entry for a receipt or payment is a representation of an underlying journal entry. It’s absolutely the common case in accounting that a journal entry affects multiple accounts. Not only can there be a matching transaction in the ledger for the other account; there must be.
This is literally not true by existence proof. People do this all the time. I’m mystified as to why you think it’s exotic or unheard of.
Handling bank transfers via a clearing account with payment and receipt rules is the perfect solution. Any attempt to automate transfers will complicate the process and in my mind not be worth the effort. If you import the transactions of both bank accounts where transfers have been made between, and automate the allocation in any way, you will have to make use of a clearing mechanism otherwise the transfer will be duplicated in both bank accounts and neither will reconcile. I can add more software to your list, but if you conform to the double entry accounting principle and import all your bank accounts, you will be better off to use a simple ledger clearing account with payment and receipt rules in both bank accounts. No need to change Manager.
And what happens when the other half of the transfer is imported from the other account? Now you have a duplication.
You just proved the point I’ve been hammering on. It is in another account, one you are not importing.
Then prove it with something besides an assertion unsubstantiated by fact. When have you ever made the same deposit in two bank accounts at once? When have you ever received a check drawn on two bank accounts?
No need to apologize. But either you are mistaken, or we are misunderstanding each other. I certainly was not saying that uploading a bank statement “imports from multiple bank accounts”; I am saying that it’s trivial and common in other accounting apps for individual transactions contained within bank statement imports to be recategorized as transfers, without the use of clearing accounts, during or after the import, and I’m flummoxed that anyone would think this is unusual.
Here’s an image from QuickBooks Online’s categorization UI. As you can see, it allows you to categorize something as a receipt, to match an already existing payment, to record it as a transfer or credit card payment (in which case you provide the account). This happens to be from a bank feed, but the UI when you upload a statement is identical (I just tried it to make sure.)
If one chooses “Record as transfer”, the transaction absolutely shows up on both accounts (with each account on a different side of the transaction), just as you would expect.
In GnuCash, QuickBooks or Xero, the transaction is (usually!) recognized as a match, and no duplication is entered. I’m sure there are times when people (or the algorithm) make mistakes, and in those cases you will typically catch the error in reconciliation or on review.
Perhaps this is the root of our misunderstanding? In my example above, the other account is the other end of the transfer; it is the source (or target) of the receipt (or payment). I agree with you that the same deposit being deposited into two bank accounts is nonsensical. But a deposit being deposited into a bank account as the result of a transfer coming from another bank account is perfectly common, can and is often reflected by a single double-sided entry, and should be able to be handled with ease as part of statement upload.
No
What happens during import of the other bank account is already entered transactions are matched. Each existing transactions must match one of the imported transactions, if not differces should be shown. The matching should be progressive, aligning more exact matches first.
You are correct Manager is not currently strong in that area. The major limitation with Manager’s current approach is it discards the bank import concept at the import dialogue box then throws the transactions it has selected into the suspense account.
Manager’s bank import would be much more powerful if the bank import construct was maintained until after the transactions have been assigned valid Manager accounts. Missing / extra transactions on either side (external bank or Manager records) would then be displayed.
I too agree that bank import/reconciliation needs improvement, namely the matching part. But I don’t want the process to be overcomplicated. I don’t know about Gnu Cash or Xero but I am pretty sure I hate reconciling bank in QuickBooks. It’s too slow, too many menus, too much visual clutter, too many transaction types, none of them seem to fit the pegs and mistakes are very costly to fix.
That out of the way, there is a simple solution for the matching problem. Manager already matches previously imported transactions so this means that Manager has a built in mechanism for identifying those. What if the user can supply the same information used in that mechanism like:
Bank description in the description field.
Clearing status and date
Amount
Manager can then use these information to identify matches that were manually entered as if the have been previously imported? That seems possible.
To take things a step further, I already submitted a wordy proposal for alternative bank import/reco workflow that seemed to have been ignored by most for being tldr – much like most of my posts . You can check it here. This is pretty much what @Patch suggested here:
As for inter-account transfers, I don’t like them. They’re like the ugly duckling in Manager. The clearing account process seems more promising.
What if we were able to select the Receipt/Payment Payer/Payee to be Transfer so the new list becomes (Customer, Supplier, Transfer, Other) and then just copy the receipt to a payment or vice versa. This should link the two. Any unlinked transfer receipts/payments should have a status or a tag that can be used for follow up.
We actually do. We have so called POS Cash (from POS system) monthly totals that we import into POS Cash Account. Some of this cash is deposited into a Bank Acount while some is used for cash transactions. The deposit show in the bank account and we then assign the bank statement import part of that to an inter account transfer. This way both our cash account and bank receipts are correct.
. You can check it