Check if you have entries in suspense. The newer versions require users define the account used by tax codes.
Go to Settings → taxcodes
Open the edit screen of a taxcode and check what account is set
Check if you have entries in suspense. The newer versions require users define the account used by tax codes.
The listings in your screen shots do not illustrate your situation adequately. They only show that your customers (apparently) partially paid their invoices. You need to post screen shots of the Edit screens for transactions related to a single sale:
- Sales invoice
Likewise, the list of transactions does not illustrate the problem. We have no way of knowing what these entries are connected to. Post screen shots of:
- Exchange rates in effect at the time of a transaction
- Edit screen of the transaction itself
Finally, please answer @Patch’s question about whether you have anything in your Suspense account.
Thanks very much Tut
Nothing in the suspense account
Let’s deal with the Sales Invoice issue first
Here are the screenshots requested:
You may conclude that the amount of 1654.06 shown in the receipt unit price is incorrect, but it is the extax amount and is correct if GST is applied to that amount, as it is in version 19.7.62
Here is the receipt as shown in 19.7.62:
The invoice and receipt balance in version 19.7.62:
You should not have GST on the invoice AND receipt
Manager has changed how it handles this error condition.
Tax codes on payment / receipt to invoices is now prevented byManager
In the past in made no difference or was a way of reducing the actual transaction depending on tax inclusive / exclusive setting.
See Receipts and payments exclude tax amounts after upgrading to 20.8.31 and Does anyone else fear updating manager as much as I do? - #6 by d3mad
Thanks for the link, yeah, it’s the same problem I have
I did do a search before I posted, but did not find anything
As I said, I was assured that backup files would always be compatible with future versions
It would appear that assurance has not been honored
If it is “incorrect” to apply a taxcode to receipts, why does the current version still have a “Amounts are tax inclusive” checkbox?
The older versions handled the taxcode situation correctly
They did NOT apply taxcodes twice
I literally now have thousands of invoices that will need to be amended if I am to upgrade
Any suggestions other than manually editing thousands of receipts?
- batch update
Because receipts can be posted to accounts other than Accounts receivable.
The tax code was simply ignored.
Your issue is that you entered the wrong amounts for receipts against invoices.
OK Tut, seems (as usual) the user is wrong
I stupidly did not foresee that the rules would change in future versions making my accounts not upgradeable
You say that the taxcode was “simply ignored” in previous versions
If that was true then the older versions would have had exactly the same problem as the current version
Older versions do not have that problem
In the older versions the extax amount in each line item of the receipt is adjusted by the taxcode rate of the line item if “accountsincludetax” is false
If you examine my screenshots you will see that is true
Any answer to my question on how to to fix this issue for the thousands of invoices I have that are not compatible with the newer versions?
One way that Manager could honor it’s assurance of upgradability would be to adjust receipts for the revised format when importing from a backup
Basically if the version number of the app making the backup is earlier than the version where the logic changed then:
If “accountsincludetax” is false on the original receipt then adjust any line item extax amount by the taxcode rate of the line item of the original receipt and make “accountsincludetax” true
Please advise if Manager would be willing to implement this fix
It’s not a lot of work
- Manager appears to be adding controls to limit user incorrect data entry but this will always be only a partial control.
- Manager is making it easier for future users to use the program and hopefully comply with new reporting requirements.
Both of the above mean Manager is changing and unfortunately all change comes at some cost / pain.
If you put yourself in the position of program manager of NG Software breifly, how would you allocate your limited resources
For small numbers of users correcting user specific data entry unfortunately I suspect the answer is
The “rules” did not change. The taxable transactions were always the sales invoices, not the receipts recording money received against them. What changed was that the program previously allowed you to apply tax incorrectly on a line item posted to Accounts receivable. This resulted in your invoices appearing to be paid in full, but it meant that the tax amount was being counted twice, once on the sales invoice and again on the receipt. So, if you relied on Manager for reporting output GST, you probably over-reported for all those sales. That means you have a bigger problem than the challenge of correcting thousands of past receipts (not invoices). You may need to correct past tax filings.
No, I did not say the tax code was ignored in previous versions. I just said it was ignored. But I could have been clearer. Your question about “why does the current version still have a ‘Amounts are tax inclusive’ checkbox” and your statement that “older versions handled the taxcode situation correctly” were in the same paragraph. I interpreted them (apparently incorrectly) as being about the same subject, the checkbox. You had not checked the box on any transactions you showed, so it really did not make any sense to me for you to be making the point at all. Since the comment did not seem important, I gave it only a brief answer. From my original understanding of your question, I should have said something like “the new version of the program would have ignored the checkbox if you checked it.” Based on what you have now written, I see that you thought I meant the program was ignoring the tax code itself when you erroneously applied it to receipts recording settlement of sales invoices. I apologize for not explaining in greater detail.
The program has always treated tax codes the same way as far as they affect this subject. The change is that it previously allowed you to apply them in situations where you should not. In other words, it assumed you knew when to apply a tax code and gave you the flexibility to make an accounting mistake—thousands of times. Now it won’t allow that.
All your sales invoices are fully compatible. Your receipts are what requiring correcting. Every line item on a receipt posted against Accounts receivable needs to have its tax code removed. And the unit prices need to be changed to match the full amount receivable on the corresponding sales invoices including the tax. This is best done, as @Patch said, using Batch Update. The tax codes are easily removed. Changing the unit prices will probably be easiest to change by adding some columns for extra calculations during the spreadsheet phase of the update, then removing the old unit prices.
As a forum moderator, I am the wrong person to ask. But I doubt the developer will incorporate code to correct users’ past accounting mistakes. You speak of this as a revised format. But it is not. The program no longer allows you to make the same mistake again. The program’s logic did not change.
Hhmm, that sounds like a big NO
You ask me what I would do in the position of the program manager
I am a (niche) software developer in a small company
To me, the most important thing I can do as a software manager (which I am) is to honor any commitment that I make to our users, even if it did mean a little work
But as a software developer I know there is very little work in my suggestion - maybe 2 lines of code and some testing before a new release
It was @lubos who gave me the undertaking regarding the future compatibility of importing backups from old versions, so perhaps it should be him that confirms to me whether ManagerIO will honor that assurance or not
Be objective. That undertaking was honored. You can and did import your backup. Your complaint is that the conversion script does not remedy your prior accounting errors. Had your receipts been entered correctly in the older version, you would not be in this situation.
How do you expect the developer to foresee and retroactively correct every mistake a user could make? Did you never look at your financial statements to see if they matched your expectations? Did you ever ask an accountant to verify your accounting practices? Manager is only a tool. It can be misused. The developer cannot realistically be held responsible for a user’s understanding of accounting principles.
Interesting estimate of the scope of work.
Not at all consistent with my experience.
I am absolutely objective @Tut
You are taking the route that I have seen you take so often over the years - blame the user!
Let me phase your question slightly differently
How do you expect the user to foresee changes that makes data from previous versions incompatible with future versions?
Anyway, it’s only a rhetorical question, I don’t want to get boxed around the ears by you any more
My financial statements using the old version perfectly match my expectations
Not only does my accountant verify our financial statements (for 3 entities), the auditor also accepts them
I repeat, version 19.7.62 works just fine
I also repeat I am very happy with Manager and its interface
It’s a great product
What I do find disappointing is you (@tut) are always blaming the user - it’s very predictable
Makes me feel sorry for the users I’ve seen you belittle over the years
But I believe you are doing your best, it’s probably just your style
More importantly what I find disappointing is that you seem to be saying this importing bug will not be fixed
This is not about whether the previous versions were right or wrong or whether I’m a stupid user or not
It’s about fixing the issue of past backups being compatible with current versions
Let me hear from @lubos regarding whether he is prepared to implement the small fix that it would take to make past backups compatible with the later (and future) versions of the app, as he assured me they would be
I don’t. There actually have been some reporting changes that did. But this is not one.
Does your accountant realize you are assessing GST on sales twice for every invoice? Or just looking at whether your books balance and filing taxes in the most advantageous way based on your statements? Likewise for your auditor? And what is the auditor’s role? Is the auditor working for you to verify that your books accurately reflect your financial position and performance? Has the auditor followed a sampling of transactions through your entire workflow? Or is the auditor working for the government, and therefore perfectly happy if you overpay taxes?
Sorry to have spent so much time explaining the problem you complained about. I also apologize for trying to help you avoid making the same errors in the future and possibly keep you out of trouble with your authorities. I can appreciate it is not good news to learn how much work you have before you to unwind the mistakes of the past. But my role is not to enable your continued use of incorrect accounting practices. And even if the developer were to reverse the change that triggered your discovery of the errors, your records would still contain those thousands of incorrect receipts. And your tax accounting would still be wrong.
Tut, you just can’t help yourself
I believe you mean well but you just have to throw blame to other people all the time
Even my accountant and auditor now
Well on their behalf I will explain to you how you are wrong in asserting that they did not alert me to the fact that I had paid tax twice (clue: I hadn’t)
Below is a series of screenshots made from version 19.7.62 using the fictional company SouthWind
You will see that the tax code for both the invoice and the receipt is GST 10%
You will see that in the Tax Summary report that the amount of GST is not reported twice
You will also see in the Tax Summary report that the amount of GST reported is actually correct
But you have asserted that I paid tax twice
I’ll pass your apology to my accountant and auditor
As I have said multiple times previously - version 19.7.62 works fine and reports GST correctly
However, in attacking my bookkeeping practices, you are missing (or fudging) the point
The point is that I was assured that past backups would be compatible with future versions
They are not - well, at the moment
The problem can be fixed relatively easily, yet you persist in making false assertions that have little to do with the main point
Honestly - it’s a bewildering attitude…
@lubos - please respond
And what is the balance of your tax liability account in your Southwind company after these transactions? what about Accounts receivable? I cannot replicate your example because I am many hundreds of updates beyond v19.7.62.
As you can see @Tut - no double payment of tax!