Bank imports and transfers

The core changes suggested are

  1. When a bank import is done, Manager retains all the imported records as a bank import. This is similar to when doing a bank reconciliation, Manager doesn’t throw away the reconciliation value after it is found to match.

  2. Manager uses progressive matching (from most exact to least exact) to dynamically link bank import data to existing Manager transactions for the bank import period.

  3. Manager shows the bank import hiding all transactions which match by default. This display would mostly look the same as the existing bank import display.

  4. This display would however also show any existing Manger transaction for which a matching bank import could not be found (ie failed matches in the other direction).

  5. There should also be an option to show transactions Manager has matched so users can check the automated matching if they believe there maybe an inappropriate match.

With this in place, a bank transfer becomes just another pre existing Manager transaction. Showing in bank transfers would be nice and still possible in my opinion.

1 Like

You overlook one critical factor. Because the earlier import will be, say, a receipt and the later import will be the corresponding payment, there will be no match. That has always been the root of the problem with converting imported transactions into transfers.

All the examples given require manual intervention to furnish the necessary information to complete entry of a transfer. Squeezing it all onto one screen like QB does not inherently make it easier than Manager’s approach of having a dedicated screen.

you are correct a bank transfer results in a payment in one account and a receipt in the other. That is what Manager would expect for a bank transfer so it would match.

correct, virtually no change was proposed to that screen. However after it has been finished, then for a particular bank import, Manager will have enough hints to repeat the match for the same bank import, hence not further user input required when reviewing a past bank import (unless the user changed the transactions elsewhere, which Manager would then show).

This can not be treated as a petty cash account. Petty Cash Accounts get replenished while the POS is an income and expense affair similar to a bank account. However, a mentioned we deposit part of the cash in the bank account as many suppliers and customers here only accept cash, not card nor transfer nor even have bank accounts.

To my my way of thinking, @Patch, what you describe asks too much of any program and offers too many opportunities for failure. In effect, you suggest that, because you previously imported a receipt in one bank account for $100, Manager should recognize a later payment from another account for $100 as the matching leg of an inter account transfer. I have trouble with that for two reasons:

  • When the first leg of the transfer is imported, there is no match available. It has not been entered. That is why you need a clearing account for temporary lodgment.
  • Receipts and payments could have identical values for lots of reasons besides being two legs of the same transfer. What happens when you import a statement from a third bank and have another $100 payment? And what would the program do if that were the actual matching leg, but the other, from the second bank, has already been erroneously identified as part of the transfer?

Here, you seem to hypothesize about irrelevant scenarios. You say, "…after it has been finished, then… Manager will have enough hints to repeat the match for the same import. [Emphasis added in all three cases.] But my point is, Manager does not have enough information during the import. And, in general, you are not going to import the same statement again, so there is no benefit to being able identify a match when the need has already passed. Further, the lack of a requirement for user input when reviewing past imports is not helpful. The impediment to identifying transfers is encountered when importing in the first instance. In other words, it is all well and good to say that after the fact, after you manually intervened in what is supposed to be an automatic process, after you furnished all the missing information, you can review the successful result. But so what? What have you gained?

Since there seems to be some appetite (and I guess need) for me to “prove” that this is possible, and since the example from QuickBooks wasn’t enough, let me give an example of this workflow in GnuCash.

I want to be crystal clear: I think that focusing on the details of the UI in these other apps is completely beside the point. Manager’s developers should follow their own UI principles and make the UI how they want it to work; they’re under no obligation to slavishly copy the UI of any other program. What I think IS at issue is this idea that categorizing transfers during import is somehow black magic, or impossible in accounting, or even particularly difficult. It’s not. It’s boring, standard, and should not be surprising to anyone. Pick whatever UI you want around this feature, but please just support the workflow.

Here’s a (trivial) statement imported into a savings account. I choose the file to import and am presented with the two transactions in that file:

The transaction in green happened to have been entered, manually, and thus has already been matched (worth pointing out: the description of the transaction in the bank statement and the transaction entered by hand differ! The Bayesian classifier, though, had no trouble correctly identifying this as a match; in Manager this would have been incorrectly imported as a new transaction). The transfer in yellow needs to be categorized. If I were to click “OK” at this point, that other side of that deposit would be put into GnuCash’s equivalent of the Suspense account. But instead, I double-click on it…

…and I’m asked to choose what account should be used for the other side of the entry. I do so and click OK, and…

…the transaction is actually put on the ledger (and it is not on the ledger UNTIL I click ok.)

And of course a matching entry has appeared on the other ledger (I realize the screen shot looks pretty much the same - that’s the point - but believe me, I navigated to the register for the counter-account to take it.)

If I were to import a statement for the brokerage account next, GnuCash would trivially recognize the matching transaction for the transfer as a match. GnuCash uses a Bayesian algorithm to determine when transactions match; it is certainly not perfect, but in practice is pretty good; I generally only have to touch about 5% of my imported transactions.

I don’t have access to MoneyWorks from the desk I’m at at the moment, but within a day or so I’ll post a walkthrough of how that app enables a similar workflow (although of course it’s different in the details.)

Correct.
A bank rule is set up which detects such (say payment) during the first bank import as a bank transfer which results when accepted in

  1. A payment in the first bank account
  2. A Receipt in the second bank account

Then when a bank import is later done in the second bank account, the already entered receipt is detected so not re-entered.

No user change during import is suggested other than Manger matching already entered transactions and showing already entered transactions which don’t match in the context of the bank import.
We agree user input will continue to be needed to achieve this phase.

The same function as retaining old Bank reconciliation.

  • Should later changes result in reconciliation going out of balance then there an error has occurred and is highlighted.

  • With retained bank imports, the bank transaction in error would be listed by Manager. So would be very useful in my opinion.

Thank you for the illustration, @peterb. In my opinion, what you showed is that GnuCash requires more work than entering an inter account transfer in Manager. It seems simple to you because you have been using it. But it is nowhere close to automatic.

I’ve made my points repeatedly. So I am going to bow out of this discussion.

All fair enough, @Patch. We have different preferences. As my final comment, I think it’s worth noting you and @peterb are advocating for different things. But, as stated above, I’m now out of this conversation.

Fair enough. I’ll continue to give examples from other apps just to provide context. As I said, the issue isn’t the amount of work; the issue is whether the workflow is supported at all. In Manager, one can only classify an imported transaction as a transfer by either (a) using an unnecessary clearing account(†) or (b) deleting the imported transaction and creating a new one. Each of those paths substantially complicates the audit trail, which is why I view it as a structural weakness. I’m fine if we disagree about which is easier, I just don’t want people to be left with the impression that doing better is impossible or forbidden by accounting principles.

†: For bookkeepers that want to use a clearing account, (a) is fine. For bookkeepers that don’t, requiring it just to make the software happy is a substantial complication.

Here’s the MoneyWorks flow to categorize an imported transaction as a transfer.

Load the file:

Screen Shot 2021-08-03 at 10.50.02 AM

Review:

and just type the account the transfer is coming from into the Account text box:

And then accept the import.

There’s just no comparison here. Doing the equivalent workflow in Manager (without clearing accounts) involves many, many, many more steps.

I hope this helps explain the workflow you weren’t understanding: nearly every accounting program that supports importing statements allows statement transactions to be easily categorized as transfers, without the use of clearing accounts.

It’s fine if Manager doesn’t support this yet - development cycles are limited - but please don’t kid yourself that the workflow doesn’t exist.

2 Likes

This only shows one of the bank imports. What happens when the second bank import is done and the transaction already exists?

1 Like

I’m not sure how MoneyWorks would deal with detecting matches; I haven’t used it much, honestly - but I’ll create a new test file sometime later in the week and give it a go.

I spot checked Sage Business Accounting (which I also don’t use much) and it works similarly to QB and GnuCash, though not quite as nice. On importing the first statement, you can classify things as transfers…

On importing the counter-account’s statement, you are asked to explicitly say if you want to try to match it (so presumably human error could make this go wrong, but then, that’s always true of everything.) On choosing “Match”, it did correctly suggest the appropriate match:

Anyone here an active Xero user who wants to run the test there and see how it handles this situation?

I think I get you better now, you were asking to better integrate transfers into bank imports so that it stops being the ugly duckling. And then the other leg should be matched and ignored during the import of the other bank.

Sounds fair enough. However to do this the transfer would have to consist of 2 separate transactions: one is equivalent to a receipt and the other is equivalent to a payment both charged to the same clearing account. Not manually but automatically off course and all of the cleaning stuff is hidden. But this would allow the transfer to appear in two banks.

As for the matching, the matching criteria and fields should be exposed to the user so that manual entries can be identified in bank imports.

I have been following this topic with interest and the one thing that struck me is that the people against the idea are actually against it, because they don’t see how it would work. That’s not their job - that is the job of the developer - to see if he could make it work!

I am not aware of anyone who thinks the current way of managing bank imports and transfers between internal accounts is a great way to do it.

@peterb I have just replied to the topic regarding bank imports and manual entries. I would still recommend a direction where you don’t enter transactions manually - just use bank imports, combined with bank feeds. This automates the work and with the live feed you get an up to date status of your current cash status. So I still advise you to pursue this direction. Entering transactions manually - when I was doing it, was error prone and time consuming to reconcile. I would never recommend manual entries as the best way to go. However I do acknowledge that the lack of a bank feed is problem with just using bank imports.

With regards to this topic, I fully agree with you. Using Bank Imports to manage transfers between two bank accounts in Manager is really poor and confusing. I don’t like it and it is a poor way to audit anything - if you have several bank accounts.

The key takeaway point that I am seeing here is nobody actually likes the current way that Manager handles bank transfers and bank imports. But users objecting to your suggestions are really objecting on the basis of the fact that they don’t see how it would work in practice. I would respectfully state, that is not their business nor problem. The developer has the necessary technical and accounting skills to know if something better could be implemented and how practical it would be.

I would suggest rather that instead of going round in circles, users simply acknowledge that the current bank transfers and bank imports design is clunky and ask the developer if he could find a better solution. Then point to some examples of how other programs deal with this issue - why re-invent the wheel?

As long as bank imports remain simple to use (as they currently are), I am not opposed to any suggestion that would improve bank transfers when doing bank imports. I agree with users who are against changing that is a difficult problem to solve, however they don’t need to worry about how to improve it. Leave it to the developer. The key point everyone agrees on is that the current design of using a clearing account is not a good way to do it. Make the developer aware and he can find a solution.

It seems that everyone is facing the same issue:

I just copy the four columns and their data from the original Excell Worksheet and Paste Special Values only into another Worksheet. I then save as Comma Separated Values (csv) and import into Manager.

Actually as long as I’m making comparisons, Sage did one thing that nothing else I’ve seen did, which I thought was a nifty quality-of-life feature, related to this thread

The very first time you import a bank statement into a bank account, Sage picks a random transaction from that account, displays it in a pop-up window, and asks “Is this transaction money going out, or money going in?” (The actual text was longer than this, and it gave 3 checkboxes to choose from, which I don’t quite remember.). From this, it’s inferring whether the positive and negative numbers on the statement transactions represent inflows or outflows, thus neatly solving the issue that different banks (or credit cards) in different countries may use different conventions for representing things. Once you’ve answered this question, it never asks you again (for that account).

Finally got around to checking the bank import workflow in Xero. It’s very interesting; similar to the other major players but with even more polish.

Xero has a very opinionated workflow, but it’s pretty easy to understand. Reconciliation is done on a per-transaction basis (so this is a different meaning than used in Manager, for example). The reconciliation flow is exactly the same whether the item came from your bank feed or via importing a statement.

If you click “Transfer” above, you get a simple UI to convert the transaction into a transfer, as you’d expect. You can choose “match” manually if you want, but in practice you never have to - every time so far I’ve imported a statement where I’ve already reconciled the other side, it has preselected the match for me, and I just have to click ‘ok’. It looks to me like only reconciled transactions are eligible for matching, which makes sense.

Other cool things:

  • The source of a transaction is remembered; so for any transaction on your books (at least for a bank account), it tells you if it came from a bank feed, from an uploaded statement, or from manual entry.
  • If you import duplicate transactions and delete some, it remembers the ones you deleted and has a view which shows you which one you kept, and where the deleted one came from:

The UI principles at work here are pretty sophisticated. If I had to boil them down to a few sentences they’d be

  • Defer items really coming onto the books until a human validates them.
  • Make it easy to undo mistakes.
  • Provide a comprehensive audit trail
  • Put all of this in one place - all of this is wrapped up in their ‘reconciliation’ concept - you’re never going to different tabs to try to clean things up. It’s always just the list of transactions for that account. (EDIT: I’m overselling this one a bit - all of these things are contained in the ‘reconciliation’ flow for a bank, but there are actually 3 tabs: Things that need to be reconciled, accepted transactions, and “statements”. I’m still unclear on the difference between the last two tabs - it feels like ‘statements’ is specifically the imported items but I’m not sure yet. Will poke at it some more.)
1 Like