Journal Entries should have Bank and cash

Journal Entries should have Bank and cash for transactions

It has already been discussed. It is against the basic logic of operation of Managerā€¦

1 Like

So Iā€™m new to Manager and have some comments about this.

Letā€™s take it as read that not allowing journal entries to have access to Bank and Cash transaction is good. My feedback is this isnā€™t really explained well. It is in the guides as a sort of throwaway sentence or two, and itā€™s discussed here in the forums all the time when people complain, and I want to politely suggest that ā€œpeople keep complaining about itā€ is evidence that itā€™s not explained well.

ā€œYou canā€™t write journal entries against all accountsā€ is a major change from how nearly every other ledger program Iā€™ve used works. Maybe itā€™s great! Soā€¦emphasize it. Really hit it in the features of the program. Explain more fully the tradeoffs between using the Banking subsystem (and effectively gaining granular access control over various functions) and the ability to simply use general ledgers for everything by structuring your chart of accounts that way. Itā€™s clear to me that thereā€™s a lot of history and context behind the decision but I promise you as a new user I havenā€™t found any of that context, and Iā€™ve been searching the forums for it, which I promise is more than most users will do

There is not only restrictions to bank and cash in journal transactions, there is also restrictions to other GL accounts scattered around other transactions.

I would class this as a sensitive topic.

A major philosophy (and an honourable one) of the developers is to make the program as easy to use as possible, especially for users with a limited knowledge of accounting. The restrictions are there to help to avoid these users getting into practices that they later find is causing issues which have to be rectified by using a huge amount of time and effort.

The trade-off for this is that knowledgeable users are sometimes restricted in doing legitimate things that, because of the restrictions, require a convoluted workaround to achieve. You will notice that many threads have objections to some of the restrictions as a result.

Another observation that I would make is that sometimes restrictions and idiosyncrasies of the program donā€™t seem to have any benefit for either type of users. These can sometimes be associated with the programming platform being used, but not always.

Also, you will notice in forum threads that some users find extremely innovative ways to use the program (legitimate or not) which often causes issues when improvements to the program are promulgated.

All said and done, the program is extremely functional and more intuitive than many other similar programs that I have used. That is why it seems to be very popular and why I continue to use it.

2 Likes

When I started using Manager I also expected to see cash and bank account in journal entries. But I do not think that is necessary. I like how the program forces users to use the right tools for the job.

@Armaghan_Mehmood Kindly post a transaction or a situation for which you think you cannot use a Payment Or Receipt transaction to capture.

2 Likes

I believe that Manager is clearly focused on Accounting for tax purposes and facilitates the related bookkeeping functions. That it can be used for other purposes even points of sale is a bonus for some and pertain the flexibility and reconfigurability. It is much less suitable for financial management with only a simple budgeting capability in P&L reports. It has no real forecasting capability although you could fake this by setting up a ā€œfutureā€ business, etc, but it is not good at it. However, it in my view excels in Accounting which records the past and not allowing messing about with Journal entries Bank and Cash, and facilitating Bank Statement imports and Bank rules to eventually make Bank reconciliations a breeze as there is no pollution from any rogue entry (if sticking strictly to only importing statenents and assigning them to accounts. This really has been an enormous time-saver and it is the most practical way of meeting the legal requirements. I use other applications for proposal development with 3 and 5 year budget forecasts and set these against the actuals (the past) provided by Manager. Preventing Bank and cash in Journal entries makes in this practice lots of sense and I agree with @peterb that this is a USP that could be much better communucated.

The reason bank & cash accounts are off-limits for journal entries is the same as for accumulated depreciation/amortization.

There are simply other entry types which are serving these accounts (in this case payments, receipts & inter-account transfers).

Butā€¦

There have been a few instances lately where I thought journal entries should be able to debit/credit bank and cash accounts after all. For example, setting up starting balances with journal entries would be more flexible and more intuitive than fairly convoluted process that Manager has now.

3 Likes

Maybe this could be a a ā€œstarting upā€ component in settings where a Journal Entry capacity for just such purpose would be allowed, ie setting up starting balances through an Initial Journal entry to Bank and Cash.

I like the tidiness I see in the cash and bank ledgers. Iā€™m against allowing users to use journal entries to capture transactions involving cash and bank accounts.

@lubos you only set up starting balances once. We should aim at limiting the use of journal entries and improving the current transaction types.

2 Likes

Update: If I understood well then starting balances only get activated through setting a start-date (existing business that transit into Manager). So if you change this from Start Date to setup Statrt Balances and use a Journal style form to populate the starting balances then this would be solved.

I agree, there should be a separate budget ledger that reports against the GL in P&L report.

I donā€™t know of any comparable accounting software that does. Big business will often pay huge amounts to software developers to set up a forecasting module as there are many, many variables required for forecasting. Also, it has to cater for changing the forecast data to the live data at the end of each month. I worked for a business that paid $40,000 for a forecast tool in an excel spreadsheet that had been adapted from one they created for another business. Once we got it we were on our own (no back-up) and it was very slow and clunky.

I agree, this does not cause any concern for me. It is some of the restrictions, to GL accounts, in other transactions that cause me problems. I will admit though, there has been 1 or 2 opened up recently after requests have been made.

1 Like

You should not look at accounting packages as mentioned but Business Plan packages such as Liveplan, which for example works well with Xero and Quickbooks, but can also be used without any.

There is a flexibility vs use complexity in most software products.

The more flexible a product is, the more applications it could be used for in theory however in practice the smaller number of users who can actually drive it to do their task.

There is a balance. Imo Lubos appears skilled in finding that balance.

Btw
What transaction journal entry transaction can not be entered as a multi line payment/ receipt to achieve the same thing.

I find the current starting balance system intuitive and easy to use without having to think about how the underlying double entry accounting system is actually accomplishing what I want to do.

1 Like

I will check out ā€œLiveplanā€.

Just focus on the financials.

I think it is better the way it is - it is easy for non-financial users to record and enter transactions.

Allowing journal entries to bank and cash accounts would open the door to all kinds of unwanted errors - see this comment from a user just yesterday Receiving merchant credit card payments - #5 by JHNC

1 Like

I understand where you are coming from to an extent. It probably does need to be explained better in the guides given that most accounting programs (if not all), allow you to manage any transaction in Journal Entries.

@Tut - just a suggestion, but perhaps with regards to the help guide for Journal Entries, it may be an idea to provide examples of how common Journal Entry transactions in other accounting programs such as bank and cash are handled in Manager. This makes sense as Manager is just about the only accounting program that I know that does not allow bank entries in Journal Entries. Newcomers used to using Journal entries for bank transactions should have examples of how Manager handles it and more importantly why.

However, I think it should be up to users to justify why they need bank and cash transaction to be done through Journal Entries. I have been using my business in Manager since 2015 and admittedly my business does not do advanced account - but neither myself nor my accountant has ever needed to use Journal entries for a bank/cash transaction. All I have ever used Journal Entries for to be honest is end of year returns such as dividends, corporation tax, accruals and reverse journal entries etc.

I am in full agreement with other users. The major benefit of Manager is the simplicity of the program and this is largely why Bank transactions etc are not allowed in Journal Entries. It forces users to use payments/receipts/ inter account transfers etc thus ensuring mistakes are not made as too many people (myself included) never know which way round to do the debits/credits. Other programs I believe support journal entries for bank transactions because it has always been done this way. This does not make it a good way to handle these kind of transactions and Manager does a better job of making transactions more simple to use and more importantly to prevent user errors which is common when you can do too many things in Journal Entries.

The target market for Manager is small businesses like mine where the vast majority of people using the program are business owners not accountants. So it has been designed with simplicity in mind and to prevent as much as possible user mistakes creeping in. I support removing the need for using Journal entries as much as possible to keep it as simple as possible for people like myself.

The key question is what transaction do you need to use bank or cash in a journal entry? You should be able to do everything relating to bank/cash outside journal entries and far more error free?

Another example, the developer @lubos mentioned many years ago that he wanted to remove the need for reverse journal entries - although this has not yet been implemented - My Accountants Feedback of program - #17 by lubos

Just like @Abeiku, I didnā€™t like not being able to effect cash and bank in journal but I have kind of grown into it. In fact, now Iā€™d go as far as saying itā€™s genius. Itā€™s much tidier, especially since most of the entries will be handled by other people and they might rely on journals way too often.

However, thereā€™s this to consider

I couldnā€™t agree more but this can be achieved by either:

  • An exhaustive linked list in the settings just like the old days or just a fancy special form, either way
    works great.
  • A special kind of journal entries in the settings as well where you can effect all accounts, barre none. But, this will not create invoice object ā€“ which sucks and thatā€™s why I prefer the linked list.

Edit: Also, who said you canā€™t use journals for cash and bank? You can create a regular balance sheet cash and bank accounts, or even create special accounts for cash and bank and post journal entries to them. But then you will have to forgo the special features of the cash and bank tab.

2 Likes

And reconciliation will fail too.

Iā€™m not sure how this would work from a UI standpoint, but I do think something like this would address my concerns - even if it was coupled with a dire warning about how you probably shouldnā€™t be doing it. I absolutely agree with the principle of ā€œdoing things through the bank UI is better than using the journalā€, but iā€™m a little nervous about not having the journal available as my ā€œhammer of last resortā€ in case I hit a truly intractable use case.

One way that would fit within the existing UI would be to allow the accounts to be targeted, but only by going ā€˜throughā€™ the associated control account - sort of like how Special accounts work now. You can even put up a :warning: sign in the UI to indicate that maybe this is a bad idea. But I still think it should be possible, even if difficult and/or discouraged. Just a thought.