I can add that in many countries, at least in Africa, like Nigeria, Ghana, Cameroun, Kenya, Tanzania, Zambia to name a few that there are no banks that provide feeds. We only have PDF and in some cases CSV bank statements. I do not think it is fair to eliminate users in these countries just to benefit those in countries were things maybe more perfect, and yes @Lubos understanding of bandwidth and internet access is one of these as well.
Unfortunately no, since we donât have that in my country.
I may not be particularly good with words but it seems like @Patch has more or less the same idea here:
Itâs not something that I came up with, most other software do just that, reconciliation and import are the same thing, when you upload your bank statements the process goes like this:
- The system does its automatic matching
- Allows the user to do manual matching
- Import unmatched transactions
- Retain separate records of the entire bank statement uploaded with linkages to all matched transactions whether automatically matched, manually matched or imported. This way if thereâs been any unwanted future changes you just go to bank statement and reimport entries without a match.
You can check Odoo, MS Dynamics, NetSuite and even QuickBooks among many others to get the idea. But I strongly recommend Odooâs method because itâs the simplest, leanest, most streamlined and most transparent process.
What I am trying to get at is what exactly is the problem that you are trying to solve. What Patch is explaining is the process of how the new bank import/reconciliation would work. But that does not explaining what problem you are trying to solve. Maybe I donât have sufficient accounting knowledge, but I canât see what you are trying to fix? Are you trying to fix an audit issue because of complicated clearing account, live cash status issue because bank imports are done monthly or a bank transfer handling issue where the process is complicated and clunky?
This is main reason why many (myself included) do not like the idea of having to do manual transactions and do bank import. Bank import automates all this for me now and other than live cash status and confusing bank transfer issues (which I can relate to), I am not sure what problem you are attempting to fix.
Peterb - basically wants to have live cash status - this can be resolved with bank feeds, thus requiring no manual entries and everything is automated. At least that is what I understand his request to be. I am not sure what would be a good way to help users who donât have the option of a bank feed - but I would start with that as that is the future direction of accounting and banking.
In his other post, he raises the issue of bank transfers and again I agree with that - the clearing account process is a very clunky way to do it. The developer could review other programs to see how to fix that underlying issue (which is about integrating bank transfers into the bank import process, removing the confusing clearing account design implementation and making it easier to audit the accounts).
You donât have to convince me as I have no say in the matter anyway. The key issue that I am seeing is that most users donât understand what problem you are trying to solve. You are talking about different ways of doing it and different processes, but we are none the wiser if you are trying to fix an audit trail problem or a live cash status issue or the much discussed bank transfers problem or something completely unrelated?
My issue and @peterbâs issue are related since we both are trying to reconcile manual entries and the same solution would solve both of our problems.
I have all my problems solved one way or another, otherwise I wouldnât be still using manager.
I reconcile my bank statement externally, undo in manager whatâs not in the bank and then import bank lines without match in manager. Later I just create a bank reconciliation in manager just for namesake.
It would be really nice if this all can be done within manager though.
Sometimes I think what I am trying to push would ruin the easy and straight forward experience of using manager so I wait until I have a simpler solution, instead of importing faulty UI choices of other software packages. I believe this post in one of them but I think thereâs a simpler way to achieve this.
Anyway, none of these proposals should affect the workflows of users who donât post manual entries, it would only be an extra to those who rely on manual entries.
Manager currently supports
-
Fully manual entry of bank transactions
-
Entry of bank transactions only by âImport bank statementâ
What is proposed is Manager also supports
-
Entry of bank transactions using a mixture of bank statement import and another method such as partial manual entry
-
Entry of bank transactions using a mixture of bank statement import and another method such bank statement import from another bank ie a bank transfer
Supporting 3. and 4. requires matching existing Manager translations with the bank statement import and displaying any differences (in both directions). After which options 3. and 4. are similar.
A secondary benefit of not immediately discarding bits of the bank import, is you end up with a very useful auditing / change detection tool. (While nice it is not why I support the proposed enhancement).
-
Bank reconciliation show difference in the cumulative total at that time
-
Old bank import would show any differences in transactions for the bank import period
Yes I understand that you are proposing changing the way bank imports work so that you can reconcile manual entries as well as bank import. My question which I am trying to understand is what benefit there is to create any manual entries other than the points covered re live cash status, bank transfers etc.
Why do you want to create any manual entries in the first place. Why doesnât bank import cover your needs here?
Because for some transactions it is most efficient to enter the data immediately, such as when an online purchase is made. Entering the transaction and attaching the invoice immediately is the most efficient.
However for most transactions it is easier to use the bank import.
To allow both is thus an optimal implementation for my use case.
What I do is create a purchase invoice - so itâs on my system. I am not really concerned about whether the payment comes off today, tomorrow or the next day?
I am not familiar with bank live feeds - but would this not address the underlying problem? I acknowledge that not every country bank support bank feeds. But this is the future direction that things are moving towards. So my response would be to ask Lubos to implement bank feeds to address the problem of live cash status and in the other topic fix the problems with the bank transfer - which I agree is poorly implemented.
The viewpoint I am looking at this from is fixing the underlying problem with Manager that is making it such that you want manual entries. You are looking at it from the other way around, where you need this entered now and are wanting to merge bank imports and manual entries into one reconciliation. The direction that I think that Manager should go - eventually years down the line - is actually to prevent manual entries (other than edits) and automate everything with live bank feeds, bank imports. If you can automate it, all the better I eel.
The two problems I am seeing is that Manager doesnât support live bank feeds and the bank transfer design is really clunky. If those two issues were fixed - would there still be a need for manual entries? Thatâs the key I am asking. So again, not to belabour the point - if Manager had a live bank feed (and all banks supported it) and Lubos fixed the bank transfer clunky design issue - would there still be a need for manual entries.
I am of course assuming that live bank feed shows your transaction in real time? I have no experience of bank feeds so I donât know whether this help or further complicate your requirements? Of course this wonât address the problem with countries and banks that donât support live bank feeds. But that would be starting point as this seems to be the main issue that most users are concerned with.
- Immediacy: Some banks make statements available only monthly or update their web sites only once per day.
- Availability: Some users have intermittent or slow internet access, or their bank does not offer a compatible statement format. And many banks, while advertising compatible formats, do not follow standards, so their exports cannot be parsed correctly.
- Efficiency: Often, a transaction requires more detailed information than any bank statement includes. Since the resulting import would have to be edited anyway, it can be faster to enter manually than import and then edit.
- Suitability: When a receipt or payment is for a non-credit transaction, no imported statement includes inventory or non-inventory items. So an import is really only good at recording the financial aspect of transactions.
- Specificity: No receipt or payment rule will distinguish customers or suppliers with identical names. Likewise, none will include Managerâs customer or supplier codes when a business uses those to differentiate among customers and suppliers with identical names.
- Competency: Some users do not possess the necessary internet skills to download and import statements. Most business owners did not start their businesses to exercise IT skills, but to provide some other type of goods or services.
So there are a half dozen reasons I thought up as fast as I could type. Iâm sure I could think of others.
1 Like
You are asking Manager to support the equivalent of a different file format for every bank in the world. So yes that would work but it is unlikely to occur.
Then why are you arguing for the case that Manager does not allow reconciliation of bank imports and manual entries if you can list half a dozen reasons for having manual transactions.
You should be making the case for supporting both then!
Immediacy - Would live bank feeds not solve this issue?
Availability - acknowledged
Efficiency - Would super charged bank rules not be more practical. Improving bank rules to provide more details would be the direction I would go.
Suitability - No idea what bank imports has to do with inventory? But regardless, this could probably be addressed via improving bank rules etc? I donât know the user cases, so canât say.
Specificity - Thatâs more a design flaw of Manager. Businesses need a clear to differentiate this.
Competency - I will grant you that one because I myself did not start using bank import for a long time. However, bank imports is actually far easier and error free compared to doing transactions manually.
Why I am answering these points - Not because I think that this is how Manager should address the issues you have raised, but more to make it clear that there are solutions to these issues that donât require having Manager support reconciliation of bank imports and manual entries.
To me the idea of having both manual and bank import working together seems a step backwards. I would regard bank imports as using a washing machine to wash my clothes and someone is saying the washing does not wash delicates, so I have to do that manually ie manual entries. My response again, would be to add the ability for the washing to wash delicates (e.g. bank feeds) so it doesnât have to be done manually.
Thatâs on point. We donât have bank feeds in our country but even when I check accounting packages that support this feature, itâs usually limited to US banks or few other countries as well.
Bank feeds will be the best solution if and when itâs possible.
Like I said, I am not familiar with bank feeds. But my understanding is that there is only a few file formats that banks use - csv, ofx etc. Banks are not going to develop a proprietary format that nobody else uses. They wil use a well known widely used format - why re-invent the wheel?
Anyway - I personally donât care whether the program supports manual entries and bank imports as I would never use it. The angle that I am coming from to use the washing machine example is to add extra functionality to the washing machine so I donât have to wash anything manually. So if the washing machine does not wash delicates (eg support bank feeds), I would rather improve the washing machine to wash those delicates (bank feeds or bank transfers) than have to wash it manually (do manual entries).
Whether that is workable is up to Lubos. I just wanted to understand why anyone would want to do something manually if it could be automated. Now that I understand better, I still propose that there are solutions to these problems that donât require users having to manually enter transactions. Other accounting programs also encourage users not to use manual entries by supporting bank live feeds etc.
The key point, is I am not the one that needs be convinced. What does Lubos think?
Noted.
The program already does support both, so I donât have to make any case. You are the one who seems to argue that manual entry is not needed on the grounds that imports are available. I was merely pointing out why someone might want to make manual entries, even if imports are sometimes used.
I am perplexed by your sudden advocacy of bank feeds as a solution to shortcomings of imports given your simultaneous admission, âI am not familiar with bank live feedsâŚ.â Even if they were implemented, they would reinforce the problem of availability. And they add problems of security and cost.
That is because you operate only with credit sales, i. e., with sales invoices. When you import a receipt, it can be posted to Accounts receivable via a rule. But, if you make non-credit sales and skip the sales invoice, you need to list the inventory and/or non-inventory items on the receipt. You cannot do that on the basis of a bank import, no matter how âsuper-chargedâ rules might become in the future. Same with purchasing.
Iâm not sure what you mean. I think you left out one or more words in your response. But how is the need to distinguish customers/suppliers with identical names (which might come up in an import description or payer/payee field) a flaw in Manager? As I already wrote, the distinguishing information that can be incorporated in Manager is not going to be contained in the import, so manual intervention is necessary. Hence, a user might prefer to enter the entire transaction manually.
This argument is flawed as @Ealfardan and I made clear there a numerous countries where banks will not in any foreseeable future allow bank-feeds. Also because internet access is poor, expensive and most of these countries are still largely cash based for most smaller transactions. There are hardly and card payment systems made available by banks either, and so called transfers often are abused. So interestingly enough Manager ticks many boxes. You can work both off and online, on multiple platforms, it allows for many tasks including bank statement imports with rules that help assing them to accounts, etc. Are there things that need improving, sure but I think emphasis with Manager is on being tax compliant and less of a financial management tool. Some are much better but lack this focus on trying to meet your obligations with tax authorities in many jurisdictions around the globe. If you take away the extra fluff / bloatware / creepware you will see that this is one of the best packages to help you with compliance.
2 Likes
@eko and @Ealfardan I have already acknowledged that bank feeds is not supported in all countries and banks. I am merely suggesting bank feeds as the first step to addressing the underlying issue in Manager which appears to be the need for real time live status of bank accounts. Obviously this will not work for every user where bank feeds is not supported. But this is a good first step.
@Tut You have completely misunderstood where I am coming from. I only use bank imports so I personally could not care less whether Manager supports simultaneous bank imports and manual entries as long as it does not change the current design where I can import and three minutes later am complete with that job. I was simply trying to understand why people wanted the ability to do both and suggest a better way as I think having manual entries is a step backward if the solution to the problem could be another form of automation such as bank feeds.
And for the record, you are not in favour of both -
Which is exactly where I was coming from. Trying to understand why anyone would want both.
Anyway, the developer can read everything and decide how he wants to address the issue.
Not sure about that statement, for some sure, for all, I doubt.
No, I did not misunderstand you. You misunderstood me. You apparently have the belief I oppose importing bank statements. I do not. I was just answering your question about why people might want both approaches. Even someone who regularly uses imports might have reasons for wanting to enter some transactions manually.
Your idea that manual entries are a step backwards seems narrow-minded. Just because imports meet your needs does not mean they meet everyoneâs. And live bank feeds are no solution. They would have no more information than an imported statement. So they would address only the immediacy question. They fare no better than imports on any of the other issues I pointed out, and worse on several.
1 Like