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

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.

This is not going to be the case soon. A lot of work has been done this year to get there. You will be able to launch two different versions of Manager side-by-side.


Sorry but this doesn’t work at all. If you update the program you may each time have a different opening balance. So you are showing to the tax authority something that than you, or I better say Manager, may have then deliberately changed.

Everything that should be solvable just using lockdate saving reports and a simple continuous backup of the database.

“Old method depreciated” should remain into the system for its whole lifetime but not be usable from a date clearly stated and viewable inside Manager.

Come on. We are talking of altering opening balances from the past. It’s illegal. And the most serious thing is that the user may not even notice it. We are not here playing to the little accountant.

Since it’s a perpetual accounting software the way the Manager calculates anything before each closing date should never ever change, ie the detailed opening balance, ie each ledger and subledger of the BS, cannot be altered. From that date Manager can do anything it wants being compliant to law and giving me notice of it.

And beware we are not talking about reporting but only of numbers.

So you are telling me that the only way to be sure that everything remains compliant to law is:

  1. never update Manager?
  2. open a new business every fiscal year?
  3. change software to another one that is compliant to law?

I lost all my custom reports, and worst the possibility to reproduce some of them, with a recent update of Manager. I was a little upset but I created all of them with the new engine and in the end it was not an issue… the new custom reporting engine is better then the previous one. But we are talking of reports!

This is a completely different issue. Someone, with a cloud or server version, could even, reasonably, sue Manager for damages for fraudulent alteration of tax data. In the end the programmer changed his fiscal data without his permission.

  • Keep an archived versions of Manager and the data file at the end of each financial year.

  • In a perpetual accounting system reports with comparison dates for the end of successive financial years enable rapid identification of changes from and errors in archived versions.

In all archival systems if you want to be sure everything is the same you can’t change anything. By definition a perpetual system is not and archival system.

So you are telling me that Manager is deliberately not compliant to law?

And be aware I’m not talking about archived numbers but of detailed closing/opening balances of each fiscal period.

@Davide you are simply not correct that past figures cannot change. It’s happening all the time, even to the biggest companies where reported figures turned to be wrong due to software bug or user error (sometime the differences amount to millions of dollars). If that happens, the company is obligated to provide corrected figures. The idea that software bug will be fixed only for new periods is simply not acceptable.

Let me give you an example why…

Let’s say there is a software bug which causes your VAT liability to be underreported. When bug is fixed, it turns out you underpaid VAT to government by thousands of euros. By your account you say fixed bug must not affect past periods, you want this to be fixed for future periods only.

The government is not looking at it this way. As far as they are concerned, you owe them thousands of euros and they won’t accept your pricinple that past figures are not to be adjusted. They will want you to submit correction to your past figures and pay the difference.

Manager works on this principle. And this is why reaching bug-free status for Manager is so important so this never happens.

Dear @lubos, that’s not correct.

By law, every kind of review, even deriving from the past, should be put in the current year BS or P&L with a clear description that it is a contingency.

In only very few cases, with big relevant amounts, you should do a review of the past years and you should open a special and specific review procedure which also includes a fine, ie you should deposit again all the numbers to the tax authority.

But you cannot do this at home by yourself.

1 Like

What I want to clarify is that I have no argumentative intent but i am really scared by what i am reading in this thread. On Monday I will check all past balances to verify that nothing has changed without my knowledge.

So Manager does the right thing. If figures change due to a fixed bug, then you make a reversing journal entry in past period to make figures consistent with lodgement figures and add it back in current period.

If Manager would not affect past periods, you’d not know what those figures in reversing journal entry should be.

You wrote it correctly. Everything should be rappresentanted in the correct way and if we find an error we should fix it.

But we should know immediately the changes and where they impact in our numbers expecialy in the past (also to do the reverse journal entry you correctly prospect).

Sorry to be pedantic but I am very frightened since the tax authority is very aggressive here about this kind of things. On Monday I’ll do the review and I hope it didn’t impact my numbers.

However there should be at least:

  1. a clear way to crystallize the closing numbers in a report and to check immediately the changes. I’m thinking of an extension to the Budget tool that should cover also the BS with the possibility to clone numbers from a certain period (maybe with a drill down function).
  2. a register in the website, of only the relevant changes in the calculations, with the date, version of Manager and the clear explanation of these changes.

One last question… does those changes appear in the History tab? I think that they should. And in this sense should be read my request of drill-down.

Sorry but I don’t want to be a victim of my tax authority for changes I didn’t apply to the numbers.

@lubos you are only partially correct here in that past figures do change but it’s not the way you described. It’s only up to the financial management of the company to determine whether the past figures should be restated, not even the auditors can force their “correct figures,” they will have to report whatever management tells them to report and just make remarks on what they think is right.

As far as tax authorities, they do care about consistency of your tax reports because: 1) they want to match your filings to your books (which is impossible if things are constantly changing); 2) See what you made wrong; 3) See whether your mistakes were corrected according to your next filings or subsequent amendments.

In case you have a difference in your figures, tax auditors (as well as any other auditor) would want to know exactly what happened by means of a full reconciliation between the reported figures and the new figures.

In my country, the tax audit can go back as far as 5 years back and I know there are countries with greater tax document retention periods.

Just imagine every time Manager decides that my previous figures are “wrong” (which is another debate, but I digress for now) you would have to go back at least 5 years and reconcile everything. What a nightmare.

I mean most accountants can’t keep up with their normal workload with all the other departments mistakes, ad-hoc requests by owners, customers, banks, government … etc. all while staying on a strict closing and reporting deadlines. A task of this size (5 years of full blown reconciliation of books) is a huge wrench in the works, which 9 times out of 10 will not be completely resolved because the previous state is gone forever and there’s no undo button for that.

Back to the old tax calculation, the old method was not wrong but some users were using it wrong. In fact it’s better than the new method because it preserves user input unlike the new method.