After having multiple discussions on both how the reconciliations are handled as well as how receipts, payments and transfers are entered. I was thinking there might be a better and simpler way to handle all of this which is also much more efficient for bank entries and provides better audit trial over bank reconciliation and matching.
Instead of maintaing clearing date (which is good but imperfect), why not import bank statements as a separate record which is outside the general ledger records. These records should be matched to receipts and payments and interaccount transfers in a many to many relationship which should involve a matching table.
The process:
Enter receipts and payments and interaccount transfers manually or in batch.
Import bank statements.
Verify the bank balance movement analysis.
Manager identifies direct matches and leaves the remaining for the user to match.
The user will match all what is there to match and then there will remain Transactions in bank not matched to books which can be batch entered to suspense and Transactions in books not matched to bank which will be flagged for the user to correct or delete.
Advantages:
Manager keeps track of the entire bank records as an external record.
Manager forces the user to post all bank entries at the time of reconciliation.
The reconciliation equation Bank balance = Book balance + Transactions in bank not matched to books - Transactions in books not matched to bank will always hold true as long as the bank records are complete.
Using a unique matching reference that can accomodate many to many relationships is far superior that the use of a one way cross-reference (i.e. clearing date) that is not unique and provides no help in case of a mistake.
Many to many can also mean that we can reconcile individual entries to batch entries both ways which should accomodate for differences in granularity of records.
This way it will be easier to correct mistakes in the reco easily by tracing matching reference to bank statement. Basically fool proof.
Another discrepancy that this method can uncover is if the amounts matched are different, which the cleared date cross reference fails to identify.
This should keep import of bank statements outside of receipts and payments so that the cashier cannot access this function.
Disadvantages:
A very big departure from what manager is doing right now and might require a lot of work to pull off.
There is currently nothing in manager similar to the matching function proposed but I believe @lubos is smart and can make it work.
I have implemented this method in my firm 3 years ago and this has made my life much easier since it broke down reconciliation into bite sized chunks for employees to understand, lowered my training efforts, no need for rework since there is a trail to go over mistakes and imperfect matches and it works every single time.
Your feedback is welcome guys.
Note: I will soon share the excel sheet to show how this works.
You are both entering receipts and payments manually and importing statements. Why do both? The entire point of imports is to avoid manual entries, if that suits your needs.
Why should Manager maintain an external record of all bank transactions? It has an internal record. The bank has the external record. You are only introducing an extraneous, secondary source.
What is the use of many-to-many matching? When reconciling accounts, you can only match one to one.
What difference does it make that clearing dates are not unique? That is only one thing you match when reconciling. You also match payer/payee and amount.
Why should there be differences in granularity of records? You called this an advantage, but it seems irrelevant.
Users may not use Bank Reconciliations at all. For one of my businesses, for example, I compare the cleared balance in the Bank Accounts tab to my online bank balance. If they match, I consider them reconciled. If they don’t, a quick drill-down in Manager can be compared to the online transaction list for the bank account much quicker than navigating through Manager’s reconciliation correction process. And I have no need to produce a report for myself as the sole proprietor of that particular business.
I have no doubt you have worked out a process that meets your particular needs. But as a general suggestion, this looks like a solution in search of a problem.
This is probably the only time that @Tut and I would agree whole heartedly.
The whole point of bank imports is to automate the process of entering payments and receipts. Why do all the work manually and then import the statement as well? You are just creating extra work for yourself.
By attaching the bank statement pdf document to the bank reconciliation transaction in Manager, you have both the external and internal records.
I would suggest that you clone your business and one month do just weekly bank imports in the cloned business instead of manually adding payments and receipts. Obviously you still need to create sales invoices receipts or whatever you give to the customer. Try that and then see.
I can tell you that it would add a huge level of complexity to the program to create many to many relationships in the way you suggest. It would not be a trivial programming task and I just can’t see many people using such a complicated way of reconciling bank accounts when bank imports does it in two clicks as it were.
Is there a way that you could simply import the bank statement and handle whatever it is you require another way? For example, perhaps receipts for cash transactions could be done in the same way as sales invoices - where you can create the receipt to give to the customer without actually creating the transaction in the bank account.
One flaw in your current design is that your payments and receipts does not match up with what is on your bank statement so when the taxman is looking at your bank statements, it is much harder to see the transactions in Manager matching up with what your bank says you have earned.
I think the question you need to ask is why do you need to process bank transactions manually. What are you trying to achieve that cannot be done with a bank import.
Agree this would work well as it enables the user or use what ever mixture on manual entry and importing bank transactions they find optimal for their work flow.
For a summary of a possible implementation and work flow see
I agree this is the major disadvantage, which is why I didn’t bother to further describe how it would increase user efficiency so increase the value of Manager. Particularly given other limitations of manager I consider more pressing such as Inconsistency in Tax-reporting - #25 by Patch and Improvement to payment and receipt forms and for Managers international appeal working out a way to make localisations work and real support for multi part tax codes Future Tax code structure ideas
For my use case I can just give up on manual entry, so it doesn’t really worry me either way.
This is true in Manager, but not necessarily in other systems.
To give a specific example, GnuCash’s statement import has surprisingly good matching of imported entries with manual entries. So if I’ve been entering information manually, but missed 5 or 6 transactions, the best way to correct the situation is to import a bank statement; GnuCash will happily match all the transactions that already exist (and not double-import them), and then the only things that get imported are the 5 or 6 transactions I missed. It’s the best of both worlds!
If I try this in Manager, then seemingly every transaction on the statement is imported and I have to go through and manually delete them one by one. So while we can pick at the details of the proposed implementation, the basic idea of “Hey, recognize when a transaction has already been entered, and don’t import a duplicate” is a very reasonable suggestion and one that deserves consideration. (The Guide claims that Manager recognizes duplicate transactions but I did an import tonight and I don’t think it caught a single duplicate out of 50 or so, probably because the matching conditions are too stringent. So perhaps what I’m really saying is “duplicate detection should be better?”)
Anyway I’m on this thread largely because I am really enjoying Manager but feel that the reconciliation flow is noticeably more clunky than many other parts of the system.
Try to import the same bank statement but add 1 new entry into it. You will see it imports only that new one. It does not match manual entries with bank statements as this as explained by @Tut is not how Manager works with bank statements. The question you do not answer is “…why bother at all with manual entering of bank payments and receipts as you can import the bank statements?..”
This has been bothering me for a few days, so I wanted to circle back around to it, because it’s such a bad question. It’s a question that is defensive of Manager’s shortcomings instead of engaging with the reality of those shortcomings. I think Manager is a fantastic tool, but it’s not perfect; and the way it gets better is by being open about the things that need to improve (which is not to say that this reconciliation flow must be top of the list!)
Manual entering of bank payments and receipts, and import of statements, serve two completely different needs.
Manual entry: the need to have an up-to-date knowledge of the current balance of all accounts, to avoid inadvertently overdrawing, sometimes to catch bank errors, and to know when moving funds in advance is necessary.
Import of statements: the need to easily reconcile accounts with many transactions, errors from transactions that were manually entered, and catch bank errors.
Different accounting tools have different ways of dealing with these needs. QuickBooks, Xero, and Wave, for example all discourage manual entry by providing an alternative tool that addresses the need: bank feeds. If using Xero, I can confidently refuse to enter a single bank transaction by hand, yet be confident that my balances are up to date. The bank feeds also prevent duplication when importing statements at the end of the month, if you decide for some reason to do it by hand.
GnuCash takes a different tactic: it has no bank feeds, but its import flow uses a Bayesian algorithm to match imported transactions to manually entered ones, so in the common case you’ll avoid seeing unnecessary duplicates.
So the answer to the question “Why bother at all with manual entering of bank payments and receipts” is “Because Manager doesn’t have bank feeds, and some businesses need to know their balances on more than a monthly basis, and an accounting program should be able to serve as the hub for the financial state of one’s company”.
Now given all that: “Manager doesn’t match imported statements with manually entered transactions yet, so if you do both, you’re in for a world of hurt” is a perfectly accurate and acceptable description of the current state of the program. But I don’t think “Why do you want to your account books to be up to date on a daily basis, just wait for the end of the month” is a great question when talking about a perpetual accounting system.
Despite your comment, importing a bank statement accomplishes none of these things:
There is a single reconciliation process, no matter how the transactions were entered or how many there are. Ease of reconciliation depends only on the accuracy of entries.
Importing a statement does not catch manually entered errors. The transactions will not match, and therefore the imported transaction will be judged to be a different transaction and will be imported.
No bank error will be caught, because there is nothing to compare it to during import. If you have manually entered the same transaction, it will be different than the bank’s erroneous transaction. This is just the reverse case of the situation above.
Manager’s developer has rejected bank feeds for three primary reasons:
Cost (in some cases)
Security
A commitment to allow internet-free operation
Except that statement is not accurate. Statement imports are merely a way of creating receipts and payments. Once they are created, the program does not distinguish between them. Manager will attempt to find duplicates during importation, no matter how they were added to the database. Failure to do so stems from differences in dates, amounts, descriptions, etc. In other words, if you know exactly how your bank formats statements and would characterize a specific transaction, you could mimic that when entering transactions and all duplicates would be found on the next import.
But understand this: Manager is not looking to compare and correct imported transactions. It tries to exclude obvious duplications. But, in keeping with one of its underlying design principles, it errors on the side of keeping information for your review and action.
In any event, if your description is accurate then I guess my comment is “Manager’s matching algorithm needs a lot of work,” because it aaaaaabsolutely silently fails to match the great majority of my transactions that GnuCash’s matching algorithm finds.
Ehhhhhh sort of? Again, the main thing I’m comparing it to here is GnuCash, where an import of a bank statement has three phases:
(1) Pick a statement to import to an account (manager has this.)
(2) Show a sheet showing what GnuCash thinks is matched, what it’s importing, what it’s not importing, and allow the user to review and correct them, or even bail out of the import with no changes. (manager does not have this, or I haven’t seen it.)
(3) Commit the import (manager has this.)
Unless I’ve somehow completely missed part of the ui (it’s possible!) all Manager really shows me post-import are the things it already decided to import. This does offer me one place to correct / delete incorrectly imported items, but at the cost of actually committing the changes (which, due to the seemingly worse matching algorithm, are likely to be more extensive than something that does better at detecting duplicates). Note also that GnuCash’s “show matches before importing” also helps you review and take action on false match positives, which if I understand the Manager workflow isn’t possible there.
I definitely feel like I’m being a complainer and I don’t want to be; as I say every time I criticize, I really think Manager is a great achievement. But I urge you to spend an hour trying bank import flows in any other major tool before coming to the conclusion that Manager’s import flow is just as good. It isn’t; in my (limited) experience, the “review and action” phase of the import is substantially clunkier.
I assume that you did not mean to be insulting. I do not understand why you moved to Manager if GnuCash does what you need. It is freely licensed under the GNU GPL while Manager is not. We all have issues and wishes but unlike GnuCash can not control what the single developer will adopt and code. When you go for Manager as we decided to do you need to take advantage of some of its time saving approaches and one is to use bank imports and assining them through rules to accounts rather tha first doing manual entry of payments and receipts and then compare them to bank. The bank reconciliations are much easier because if this. In essence if we “trust” the banks payment and receipts records and asked questions while transactions may have been doubtful to the bank than the bank’s record is the most accurate one and superior to manual entry.
I’ve never believed that comparing one software product to another means you shouldn’t be using either one of them; that kind of partisanship gets people nowhere. Neither Manager nor GnuCash are sports teams, and I don’t feel that either one needs me to be its booster, supporter, or defender.
They’re both just tools. If I observe that a screwdriver does some things better than a saw, I wouldn’t expect people to say “Why don’t you use screwdrivers for everything, then!”
I think that it’s super-important, in fact, for developers to be looking at what their competitors do right and borrow where appropriate. To the extent that my explanation of the workflow on this thread is aimed at anyone, it’s aimed at lubos. Not because I’m demanding that he change it, but because hearing how people are trying to use his product, and where they find it lacking, is important feedback for him - even if he decides to put effort elsewhere. If everyone else finds it perfect and impossible to improve, then that’s good feedback for him too.
Why I’m using Manager when GnuCash works well for me isn’t really on-topic for this thread, I think? But I’d be happy to opine in some other thread if there’s a good one. There are very few small business accounting packages I haven’t at least tried, because of both professional interest and because I’m always on the lookout for tools that can improve productivity.
I definitely wasn’t trying to be personally insulting, and I sincerely apologize for sounding that way. But, also, think a bit about how it sounds to someone when you ask them why they want the workflow they want. Sure, maybe they’re completely wrong for wanting it - but maybe they know more about their own business needs than you do.
Which is the essence of the suggestion.
Having the ability to compare imported and manually entered transactions would significantly increase Manager’s functionality.
My use case is I mostly use bank import. However some transactions are better entered when I manually process the payment. Being able to enter it at that time and attach support documentation would be a significant improvement.
A completely separate question is what priority this suggestion should be given.
@Patch, the only reason I had for writing what you quoted was that several of @peterb’s comments led me to believe he might think Manager was doing what he is suggesting, but doing it poorly. In fact, Manager does not do it at all, and I wanted to be sure he understood that.
There is a tendency, often seen, for new users to think Manager works like other programs they know. That can lead to frustration, so I try to nip such misconceptions in the bud.
I found the best workflow for me was to do manual entries for receipts and payments and then to import my bank statement at month end and reconcile. The manual entries mean that my accounts receivable and accounts payable are always up to date, so it’s easy for me to tell customers at any time what their account balances are and see what I owe my suppliers. When I import the bank statements that brings in all the bank charges, etc, and enables me to reconcile. I’ve never had problems with duplicates – Manager always recognises those transactions that match the manual entries I have already done, and imports only the remaining ones I haven’t already entered.
So for me Manager’s statement import and reconciliation process has worked well. The problem is that my bank changed their digital platform and I now only receive PDF statements, so I do all the entries manually. Thankfully I don’t have a huge number of transactions to enter every month, but I will keep checking to see if I can download my statements in a more usable format that allows me to import them into Manager again and revert to my previous workflow.
I’m not sure why my experience with manual and imported entries seems to be so different from @peterb’s. It has been several months since I last had a CSV statement, so perhaps there have been some changes since my last successful import.
Unfortunately, our experience is similar to @peterb. One bank allows CSV and PDF and the other only PDF. As for the CSV we have to reformat it to how Manager likes the import and it then imports as expected and applied payment and receipt rules (formerly bank rules) correctly. However, it never finds an already existing entry and I guess that this is because the bank does not record payee nor ref numbers as entered in the transaction but puts these in a long description with additional numbers and always truncates the descriptions we entered when making payments. In essence the bank statement description does not match the way a payment and receipt are manually entered in Manager ad hence will not identify the duplicates on import.
Having read the comments of @peterb@GrahamvdR & @eko, it seem like there are other users understand the need for manual bank entries.
I was thinking there might be a simpler fix for now, how about reserving a column let’s call it “Manual Matching” or whatever which can be filled manually by the user. When the matching column is not empty for any one row, that row will be ignored during import.
This will make importing of transaction easier for the user since:
The user will have to go over the manual entries which are much less in number than the total bank transactions + duplicates.
Marking the rows in the bank statement only requires minimal work and also preserves the integrity of the imported csv statements.
Since no bank rows are deleted, in case of any error the user can still see the matching done in the csv file that has been imported.
This solution might not work for other formats but as far as csv goes, this seems promising to me, but I would like to know what others think? @dalacor@eko@GrahamvdR@Patch@peterb@Tut@lubos
@peterb and @Ealfardan I am in full agreement with you Peterb that sometimes it is an absolute battle to get ideas (that do have merit) into the ideas category and eventually implemented. You won’t believe the difficulty I had getting my status of quotes and purchase orders into the Ideas category initially. Unbelievable is all I can say. I am now trying (unsuccessfully I might add) to get the concept of Delivery fees implemented as part of the program in the say way VAT is part of the program.
However, I must advise you, the problem is not that everyone is not willing to consider your idea. The root cause of the problem is us (I can definitely speak for myself) not understanding what it is that you are trying to achieve with having both Manual entries and Bank Imports.
To give you case history of my use of the program, for the first few years of using Manager I used the receipts and payments forms to enter transactions and every few weeks I had to waste at least half an hour tracking down missing entries in order to get my Manager and bank accounts to balance. On my personal (business) where I record my home expenses, because it was time consuming to enter in payments for every time I went shopping - the end result is that I just did not use the home (business) aspect much.
The reason I never used bank import is because I had never done it before and I thought it would be horribly complicated. I eventually decided to try it and was pleasantly surprised how easy it was. Since I have moved to bank imports, I have not entered in a single transaction manually! At the end of the month I simply download my bank pdf statement and create a Reconciliation entry on that day to have somewhere to save my monthly bank statement. That way, my bank records are in my accounting program - so from an audit point of view I have both internal/external records.
Having spent years manually entering payments and receipts and a: seeing how time consuming it was for me and b: having to waste time trying to find missing entries at the end of the month in order to get everything to reconcile, I will never go back to that. My home finances is now so simple - I just do bank import - I try to do it every week for both business and home - and everything is there. I don’t have to do any more work.
So when this topic was raised, I was like - why on Earth does anyone want to have to enter transactions manually? I don’t think that is a bad question, nor defensive of Manager’s shortcomings. It literally is based on the fact that since moving to bank imports, I have saved so much time with not having to enter manually and get it on the right date etc and it is error free at the end of the month.
My view point is - why do something manually if you can automate it. So it’s good question - why do you want to have both?
@peterb You have answered the why here - a lot more clearly than the advantages listed by @Ealfardan as I didn’t really follow what he was trying to achieve.
In short what I am seeing here - is the underlying problem with bank imports is that if you only do imports once a week or month, you will have a large numbers of days where you don’t have an accurate representation of your cash status. I actually can relate to this - I have occasionally done an adhoc bank import simply to get a more up to date status of my cash.
My question to you would be this - why advocate manual entries which is time consuming (and from my experience error prone), when you should be making the case for bank feeds?
@lubos When the question of bank feeds was originally proposed, I myself was against it on the grounds of security and because I don’t really need it. However, I can and I do agree with Peterb here that if you only use bank imports, you either have to do it every day to ensure that your cash status is accurate (effectively live) or you need something like bank feeds. So I am now suggesting that bank feeds be implemented because it is a very valid point and if there is a cost, users who want this feature, will be more than prepared to pay for it.
Peterb, I would suggest you make a new topic requesting bank feeds if this would solve your problem. It would not address bank errors (however I am not convinced this is an issue), but your purchase invoices and sales invoices should catch any bank errors - assuming you use them.
@Ealfardan would a bank feed address your underlying problem. I don’t actually understand why you want or need things like having the bank records as an external record etc. Your list does not help to understand what problem you are trying to solve. Peterb has explained it that his issue is that with bank imports, you effectively don’t have a live status of your cash. I am not clear on what your underlying issue is? Would bank feeds solve this?
I am still opposed to the idea of manually entering payments and receipts on the grounds that Manager should move the users in a direction where as much as possible is automated. Why anyone would want to do something manually if it could be automated is a valid question. What I would rather suggest is looking at automated tools like bank feeds to address the current shortcomings rather than create more work for yourself. So I would agree bank feeds should be implemented. Make a new topic feature request stating your case for this. I agree a live cash status is lacking.
None of the banks we use in different African countries allow for bank feeds in Xero, Wave and/or Quickbooks, so this point is mute.
It is interesting that you recommend being “open” while at the same time labeling a question as “bad”. Maybe being open only refers to being in agreement with what you like to change and criticize, and all else is bad. So far it seems that you are not being open to the way things Manager does things and resort to older alternatives (except Wave) that have their issues also. Turning Manager into one of its competitors is not really a good idea. People need to have a choice and everyone has their own preferences. No application ever provides exactly what we need but you choose one that fits you best.
I shared enough criticism and ideas in other posts about how things are done or like recently with history search eliminated that are no longer done. There is also very little insight into the many changes each version introduces and even though I buy into the argument that no data are lost the real cost is related to have to often have to adopt and adapt to the user interface changes some result in. I also feel compared to when I started using Manager that it is trying to simplify and dumb down but with users so diversified the customization, configurability, programmability, and flexibility are not an option but a must. From a pure accounting perspective, it is too bloated with things that can better be done by other applications be it Inventory Management and POS sales.