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.
Hallelujah
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:
- never update Manager?
- open a new business every fiscal year?
- 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:
- 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).
- 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.
2 Likes
There is new History log which allows you to undo individual operations and eventually it will allow you to undo any period of time. So you will be able to go back in time. Even to previous versions of the program.
The History is great, but can it undo changes in the way the system works? Even if it does (which I doubt it will) how many entries will I have to manually undo?
But the problem is that we should be always be able to update the program without changing the locked numbers in the past if I don’t agree. So this kind of invasive changes should be managed inside the software. We are not talking about reports today. We are talking about being compliant to the law. I don’t want to be sued by tax authorities!
1 Like
Manager works on the principle that every figure in the program is clickable and you can drill-down to individual transactions you have entered and see justification why the balance is what Manager reports it is.
If some transaction has been interpreted incorrectly in the past version and the amount applied to the account should be different, it will be reflected regardless of period.
I mean what’s the alternative? The balance of your account says $1,000 but sum of transactions is $999. And the excuse is? Yeah there is $1 discrepancy because there was a bug in older version and the balance of the account should be really $999 but it shows as $1000 because past balances “are locked”.
Anyway, this topic is scarier than the situation really is. The fact is that only two accounts have been problematic. Forex gains / losses and cost of goods sold (due to negative inventory). It took a lot of effort to get multi-currency and negative inventory cost of goods sold in Manager right. Now that I’m confident all bugs in these two segments of the program have been fixed, I do not anticipate problems when upgrading.
In fact I said that I have no argumentative intent and I don’t even know if my numbers had any changes. Hopefully nothing changed.
I’m just scarred of the shallow approach to these changes since I haven’t check often if anything changed in the past since I’ve locked the periods.
Here here.
1 Like
I find it interesting that so many people use the term here here nowadays instead of the original hear hear!