Does anyone else fear updating manager as much as I do?

Every year this happens. I thought I’d be smart and updated several months ago, but printing documents this month on 20.5.17 and reprinting them again today on 20.8.28 my P&L and Balance Sheets are different. The tax owing to the ATO is significantly different. All discovered within hours of walking into the accountant.

very tiring because now when I re-process last years P&L and balance sheets in the current version of manager, the values are different to what we filed.

I get the need for bug fixes and I realise you can’t just fix bugs for new versions after lock dates (I do realise that ata. programming level, that is hard), but now identifying the changes on the locked side of the records is a headache I didn’t want today.

So now I have learned that when I file my BAS statements and yearly tax return, don’t worry about locking manager, because that won’t stop the software recalculating new values for old data, what you have to do is:

  • backup the database
  • backup the software used to access that database (being mindful it’s not easy to run older manager software on a computer where manager is already installed)
  • create a new database and bring forward the opening balances

This is the only way I can see to protect the data from previous years that bug fixes and improvements bring.

I think I’ll be backing up and purging a lot of data over the coming days.

1 Like

This issue has been discussed here - GST Worksheet not reflecting correctly

I am in agreement with you that updating Manager can be a bit dangerous sometimes, which is why I only ever used the Desktop version and now the Server version. It was a factor (but not the only factor) in my not wanting to use the Cloud Version. I wanted to be able to control updates to prevent this precise problem occurring.

I would recommend locking the previous years because it does prevent accidental cloning mistakes for example where when you clone an invoice for last year to re-use this year and you forget to update the date. So locking does have it’s uses.

What I would recommend (which is what I do) - update far less frequently, but before you do, backup your data (if you are using desktop or server version), update on one machine and see if everything is as expected and if necessary revert back. So always make sure you have the previous install file as well as your backup. Which is basically what you are thinking of doing. I have long since come to the conclusion it is the only safe way.

Programming is difficult and unfortunately changes can have unintended effects, but I do feel that the developer tends to roll out major changes like this without proper testing and consultation with users before release with the result that a lot of people end up getting frustrated because their GST and VAT returns have suddenly all changed.

Apparently there is a newsletter which you can subscribe to which advises of updates like this. I think that I will subscribe to that so at least there is some warning, but I do think more than a newsletter is required as I have been Manager for five years and I have only bee made aware in the last few months of the existence of this newsletter which many people are updating Manager without any idea of how it will change their figures.

The subscription link is at the bottom of every page on the Manager web site:

Screen Shot 2020-08-04 at 9.08.14 AM

To be clear, subscribing does not provide software updates. The newsletter includes information about updates. There is no danger your software version will change as a result of subscribing.

Yes I found it thank you. My point is not that it’s so difficult to find, but I was never looking for it in the past, never needed it in the past, so never noticed it at the bottom. What this means is that many other users are using the program without being aware of the newsletter which results in posts like the OP. Hence my point is that the newsletter is not the most effective way to handle upgrades like this one.

Having said that, @Brucanna has stated in the GST Worksheet not reflecting correctly topic that the issue that is causing so many people distress at the moment is that the latest Manager releases are now making GST/VAT return figures inaccurate that were accurate before the upgrade which is really worrying.

The most important thing about an accounting program is to have confidence that the figures shown are accurate. However they are no longer accurate and also no longer meet international accounting standards!

This update should never have been implemented until all problems relating to it were resolved. I won’t be upgrading for some time until this bug has been fixed!

1 Like

So what exactly is different? It comes down to specific accounts. As far as I’m aware, there was no fixed bug which would have changed your tax liability amount on balance sheet.

This issue cannot be possibly related as it’s not impacting balance sheet or profit & loss statement in any way.

There are several:

  • it seems zero balance invoices may be one problem, I was using that as a way to convert GST to non-GST sales. I would create a sales invoice where there was a negative qty with tax and a positive equal quantity without tax, balances to zero and it (did in 20.5.17) create a GST credit (yes, I know it’s probably not the best way, but in the way manager use to account for things, it worked… until it didn’t, lol. I will manually go back and fix those).
  • (I’m not going to articulate this well, apologies in advance, and this one is probably my error, but) Applying tax in/on line items that are capital accounts > personal contributions > drawings… I probably shouldn’t have allocated a tax code on these lines, this was in error, but with a tax code applied, it is treated differently between manager versions. Even though the payment is entered “tax inclusive”, the reported entries under capital accounts is different. One is in total regardless of tax code, the other is after removing the tax value. (Again, I realise there shouldn’t be a tax value on this particular entry, but there is and manager is treating it differently between versions).

Here’s just one example of the second point:

Ahhh, it wasn’t until I dove into the payment / edit screen and noted it’s no longer payment & receipts but it is specifically a payment type. Have you finally separated the payment and receipts as far as tax implementation is concerned? That might be what it is. This had proven an issue in the past where other users had reported problems with returned items and the fact it was considered tax credits/debits (depending on supplier or customer)…

Funny thing is, that particular tax input on my part is incorrectly applied anyway, it was a drawing and should not have any tax implications whatsoever, so this has highlighted where I need to fix the entry, but what I don’t quite understand is it appears to me that one appears as an adjustment to a capital account with tax applied and one without, yet both entries are identical, after all, it’s just the backup database.

I’ve only attached one screen shot below, because they are both identical:

I just checked the BAS related to that particular entry and there is a difference in the total amount owing to the ATO of $2. I’m not about to go and edit a BAS of 4 years ago, but that ripples on through to today, highlighting my initial point that users should not only lock the database, but probably backup/save it, create a new one and transfer the balances so that mistakes like this don’t plague us in the following years.

I also found that $200 has been converted from the top G1-G9 section to the bottom G10-G20 section. The net effect is the same, but it has changed the reporting amount for those sections.

My tax liability as at today’s date has a net difference of $300 (and not in my favour).
If I take the date back to the end of the last financial year, every major figure is out:

  • my assets have increased by $60
  • liabilities up almost $270*
  • equity down almost exactly $200
  • my income to that year end is also down $265

* I think this means that although my tax liability today is $300, that’s based on an adjusted tax liability at the end of last financial year of $270, which I think means the adjusted liability of this year is just $30…

What I think I am going to have to do is split this database in two: create two backups, in one purge all entries prior to last tax lodgement and in the other purge all entries after tax lodgement and bring in new opening balances based on the old version, since that’s what I’ve used to lodge my tax and I’m not going to piss off the ATO at this present time :wink:

Arrrgh… I’ve only just picked up (in a re-read of this before posting) my retained earnings are out in the top screen shots. I didn’t pick it up because the format of the summary report is slightly different and I thought it may have just been calculated differently, but in looking at it again, all these entries ($454 worth) are related to several payments over the date.

This is the same database open in two different versions of manager.

I’m only more confused now, shutting down for the night

In previous versions, if you’ve used tax code on capital accounts, the tax code would be ignored and the tax amount would simply be put into capital account as well.

For example, here is one of the topics discussing the issue:

This has been fixed which means if you use tax code on capital account transactions, tax amount will be put into tax account.

For example, you have put GST 10% tax code on your drawings. That’s incorrect.

As per Simpler BAS GST bookkeeping guide | Australian Taxation Office

For the proportion of private expense not related to your business, GST credits are not claimable.

The previous versions of Manager were guilty of trying to quietly “save users” when they’ve done something incorrect. Newer versions are making it more obvious when something is done incorrectly.

In your case, generate Tax Audit report for the entire history of your business and check how much GST is being allocated to Capital Accounts account. You probably shouldn’t have any GST allocated to this account. So fix these capital accounts entries by removing GST tax code - especially from drawings as these transactions are not GST reportable and thus should have no tax code selected.

Which highlights the significance of this thread. Although you don’t consider it a “bug” that you fixed, it is something that you did in fact “fix” and change what’s presented to the user based on their previous input. Manager now processes the same information differently, which changes the resulting reports, propagating several years, and it’s this that heightens my fear of updating.

I did state numerous times that I now realise I have recorded the information wrong, and I have only learned of that error because manager changed the way it processes that information and the fact that I had just re-printed the documents from the laptop and the numbers didn’t match.

At any rate, that only clarifies one problem, I’ll work the rest out as I go along. Good idea with the tax audit, that’s not a report I’ve used before. Thanks for the clarification re personal contribution taxes.

Just checked the release notes for this, I don’t see anything about this tax change or the tax changes in:

You’ve made a fundamental change that has caused me (and I suspect others) some grief.

Users have had to develop ways to account for things that manager couldn’t do, or poorly implemented, in the past. When that breaks, you really can’t blame users for doing it wrong to begin with.

I think you need to develop a tool to identify to users “stuff” (entries or outputs) that will change as a result of how manager implements features and accountancy principles. Because those sort of fundamental changes can have legal implications.

This change was introduced within new general ledger engine.

General ledger was completely rewritten to address performance issues, all known inventory / forex bugs, expanded custom reports and many other subtle improvements (e.g. when drilling-down into transactions, you will see more relevant columns based on the context).

This was a case when a bug has became a feature for some users. When you rely on broken behaviour and it gets fixed, it will cause some grief.

In your referenced topic, the user was using GST 10% on accounts receivable as a way to multiply tax-exclusive amount.

If you need to multiply tax-exclusive amount, just use formula within the field as per:

For example, instead of entering 100 and selecting tax code to get 110. You could have just typed 100*1.1

I too only noticed the Newsletter info a couple of months ago. I had no idea it existed before. The heading was “Subscribe to Updates” and I have been careful about controlling when I updated, and how often, so I did not investigate that further, thinking that it meant signing on for auto up-dates. I tend not to read through the whole Manager homepage on a regular basis - I just go to it when I want to update. Can’t remember what prompted me to look for it - may have been something on the forum.

Tried to edit my earlier post and got the message “The requested URL or resource could not be found.”

Clarification of previous post:

I too only noticed the Newsletter info a couple of months ago. I had no idea it existed before. I’ve been getting the “Manager Forum Summary” emails all along and I thought that was your “Newsletter”.

I think when I saw the heading “Subscribe to Updates” I thought it meant signing on for auto-updates. I have been careful about controlling when I updated, and how often, so I did not investigate that further. I tend not to read through the whole Manager homepage on a regular basis - I just go to it when I want to update. Can’t remember what prompted me to look for “Newsletter” - may have been something on the forum.

I think you meant creating a tax entry without any sales or purchase. If that’s what you meant, this is working fine for me.

Yes I dread updating Manager - update as little as possible

1 Like

Allow me to disagree. The error previously was that people used tax codes with receivables and payables which duplicated tax. The core of that problem was that settlement of pre-recorded invoices should have had no impact on taxes.

What should have been done is to A) leave the situation as-is since any entry errors are the user’s fault and not Manager’s; or B) disable taxes on receivables, payables and capital accounts altogether (which is not ideal because what if the user has custom receivable and payable accounts? This control will not be present)

Personally I preferred (A) but any of those options will show the correct total on the receipt.

The fix that was actually made was even more buggy because it confuses the user to what amount has been received. Yes, the user has made a mistake of not recording the receipt properly but the view screen gives them a false confirmation that (amount+tax) was recorded when in fact the tax on the receipt has no bearing on the books.

I say let people deal with their own mistakes because there is not point of taking this responsibility on their behalf.

I hope you reconsider this @lubos and chose an other method that preserves the integrity of receipt totals.

The TL;DR:

When you fundamentally manipulate a report to generate any result that is different to before because of any change in the backend… well, it’s never going to end well. Not everyone using the software is an accountant, has a degree in accounting, etc and my whole point is simply based around the fact that manager works one way and when everyone has adapted it to work with and present their data in a required or usable way (and is subsequently used for submitting documentation to the tax authorities), that then when you “fix broken behaviour” you “break” those documents. They are our legal documents.

For example, and I suspect this will come into its own in the near future, this whole debacle about “receipts vs payments” dual tax codes and tax reporting etc:

How many things are you going to break when you finally decide on how you are going to implement that? And is it going to be our fault because we relied on broken behaviour?


  • The old general ledger engine was a bug?
  • The old engine (that we relied upon) was providing broken behaviour?

We rely on manager to provide us with consistent reports, sheets, exports and views etc that we use in our business scenarios.

You need to look at how manager is used by the community.

We shouldn’t be blaming users because they entered the data the “wrong way”, the tool shouldn’t be making use case decisions the user has already made.

We create work arounds for managers deficiencies and you can’t consistently blame users for those work arounds because you now have a better idea on how to implement or “fix” something.

You are constantly tweaking reports, modifying queries, upgrading and experimenting with users data, and the presentation of that data, and we are being told consistently to stop relying on managers flaws, but we don’t see them as flaws, we see them as features. And you break them. It’s quite disappointing.

You need to stop “tweaking” and breaking the users experience because you are messing with our legal documents. You are causing frustration and anxiety in dozens of users. Every week there are dozens of threads about database corruption, data loss, reporting errors and deficiencies, debates over best practices and how one person sees it differently to everyone else.

You can’t keep saying we are relying on broken functionality. We are working with the tool you have provided us and you break functionality and it’s becoming a burden on users.

I know it’s not a democracy, it is not open source, it’s not up to a vote, and it is your software to do as you please, but now you are alienating users, breaking databases, breaking reports, user generated custom reports, exports, inventory and stock management, tax reporting and all manner of “bugs”… All these things create frustration, anxiety and despair. Last tax time my mental health deteriorated so much so that I was hospitalised, partly due to managers changes, updates, bug fixes, improvements and updated reports at the time. I screamed out for help in these forums but kept getting shut down and deleted. Mods said one thing, and you said the opposite.

The reports I gave my tax accountant two or three years ago do not marry up with the reports that manager creates today. Yes, they are mostly bug fixes or improvements (or broken behaviours, whatever), the point is, manager will generate a different output today to what it generated a couple of years ago. I have re-submitted multiple BAS entries over the years because the GST Worksheets were wrong, in the end, I threw my hands up and walked away. And yet, I can’t even generate those same reports anymore to satisfy an auditor because “you fixed it”.

From what I read elsewhere you have the intention to change the exporting capability again, so what users have put in place now probably won’t work in the future.

As mentioned above, you are going to implement a payments and receipts tax reporting change that will most likely break what users have been doing for years.

Just like reports, just like custom reports… The general ledger engine, balanced invoices, inventory control, tax reporting, GST worksheet calculations, etc etc. It is not all our fault and you need to provide a methodology to provide integrity of reporting (I have submitted a feature request for explicitly that).

I feel sorry for the cloud users who never know what to expect when they wake up tomorrow, and whilst you might argue “if you don’t like it, don’t update” but users are quickly told “you are dozens or hundreds of versions behind” as if it is our fault.

I could not agree with this more.

regardless of the shortcomings of manager, when a user uses a tool to achieve an end, the tool shouldn’t change anything that was previously put in/reported out because those previous reports generated original documentation that is now different.

I said this above, but manager shouldn’t be making and overriding use case decisions that users have already made.


A difficult problem.

  • Everyone wants the work they have done to be correct and not change.
  • to have access to new features

But what do you do when

  • the prior work was wrong for many user because of old Manager limitations
  • some users find the pain of the transition to better functionality worse than the current benefit.

My management method is a good backup protocol. Both of the data files, program files, and attaching PDF copies of important reports. Which is the process I have followed with all of my programs for many years.

With that protection I look forward to trying new features on my test system, updating my work system when I’m happy with the functionality.

Old versions of the Manager program are available

I too relay on many layers and typology of backups. But only one thing should be a mantra in every accounting program: data from the past, once a period is closed, should never ever change. It’s illegal!

PS: I know that someone may not like the termin “closed”… let’s call it locked since Manager is a perpetual accounting program… but the tax authority doesn’t care of it!

The archived version of Managers data file viewed with the archived version of Managers program has not changed. That is what you show to the tax authority when asked.

The current version of the data file viewed with the current versions of the Manager program can be different for many reasons

  • User changed something
  • Old report was wrong, and fixed in later versions
  • Functionality improved, old method depreciated or bug fixed.
  • data file corruption

All of which must be managed.

The only way to keep everything exactly the same is not change anything, including every entry in the ideas category of this forum.

But managers paradigm is to break archived versions. You must either use it on a different computer or you must delete the hidden files on your computer.

And while validating those archived versions, the newer version is unusable because it will just re-break the old version.