I just updated to v20.8.31 and my bank balance is now incorrect. I think I was on v20.5.40 prior to the upgrade. This appears to be caused because Receipts and Payments amounts do not include the GST portion. See attached screenshot.
Can you please point me in the right direction to fix this?
GST should be applied on the invoice.
If you specify applying it also on the reciept and payment you are asking Manager to apply it twice ie about 20% not 10%
In my opinion Manager should disable the tax selection on a line item with accounts receivable or accounts payable selected
The equivalent for journal entries would be as shown in Inconsistency in Tax-reporting - #20 by Patch
I understand that, however, this reported correctly in previous versions and made it easier to enter. It appears it has now changed. I would need to audit every transaction every done. Seems and odd approach by devs
Seems to be a common issue.
Back up your Manager file and use Find and recode bank transactions to
Patch,
That did not work as the amounts are all 10% too low.
In my example the âamounts are tax inclusiveâ checkbox was not selected.
As such, adding the tax code added 10% to the total. The batch update effectively removed 10% from all items.
I guess it will be a slow day of manual updates.
I Hope the following is not the case
And I repeat my preference that user should not be able to enter tax codes on payment or receipt line items where accounts receivable or accounts payable is selected
The business received the correct amount of money.
Rather than entering a receipt of $110, we entered a receipt of $100, marked it as 10% GST and left the amounts are tax inclusive box unchecked. This was a faster way to enter the data.
This resulted in a receipt of $110 in prior versions.
However, in this new version it results in a receipt of only $100. Hence, as a result of upgrading to the new version, the bank account balance in manager no longer reconciles with my actual bank account.
All impacted transactions are understated by 10%.
Whilst I agree, I may not have entered the information in the preferred manner, the fact is it worked perfectly and balanced perfectly until this upgrade.
I will manually update the impacted records. Luckily, I only have about 80 impacted records.
Hopefully nobody with a large set of entries is impacted.
Manually pasting in â*1.1â and deleting the tax code would be the most efficient.
I had a brief look at batch update but that is likely to be non trivial given your multi-line receipts.
Thanks for your help and ideas. I think I will resolve it manually.
Hopefully there is nobody impacted with a very large database.
So this is a bug right? I mean if it worked perfectly fine before and now after an update it does not work anymore then that is a bug - no?
No, this is not a bug. The user who started the topic was not entering transactions correctly, combining receipts and payments on a single transaction, applying tax codes incorrectly, and posting to the wrong accounts.
Properly entered receipts and payments do not exclude GST.
Iâm not interested in pushing the debate as to whether this is a bug, fix or feature and am not requesting the functionality be changed. I just wanted to understand the change, fix my accounts and make others aware that they may experience the same issue.
After the upgrade my calculated bank balance in manager.io changed. This was unexpected to say the least and shows a significant change to manager.io in relation to the way it calculates totals. I have manually adjusted the impacted entries to resolve the issue. But I wanted to make others aware of the significant change.
Effectively, the âamounts are tax inclusiveâ tickbox has no effect in this scenario. Whereas, previously if it was unticked, the total amount was the sum of the entered amount and the calculated tax. After the upgrade, the button has no effect. This is a fundamental difference to the way the program operates. It also affects existing transactions which now have a different total as compared to prior to the upgrade.
I chose to enter the data this way as it fast-tracked the data entry. I believed automatically calculating the tax proportion was a feature of manager.io to simplify my life. Why else would the option be there. Keep in mind all the data was accepted and all balances and reports were correct prior to the upgrade.
In regards to your comments about entering both accounts receivable and accounts payable on the same entry, this was the suggested approach from the support team on this forum. I believe it is still the correct way to do the entry.
In regards to comments about posting to incorrect accounts, that is not the case. All transactions were posted to the correct account and all reports were correct prior to the upgrade.
Whilst you state that the tax column should not be populated for receipts and payments, I donât believe your statement is correct. I believe this statement is only true where the receipt or payment is against accounts receivable or account payable. Where a receipt or payment is entered directly, tax codes should apply.
The ability to enter a pre-tax amount into manager.io and allow it to calculate the total was a time-saving feature. It seems it has now been removed or is broken. I have adjusted my entries and others will probably need to do the same too.
I have to disagree although we are probably only arguing semantics here.
It doesnât matter what you call it.
Manager has changed how it deals with tax and initial âamountsâ. It was always the case users had to enter the data in a particular fashion now it appears manager is deriving the amount. It should not have changed that.
This is exactly how I have always understood manager should have worked in the past. Why does it not work this way now? How is it the way it worked before was right and acceptable at the time but itâs wrong that we do it that way now?
This exactly leads into my other thread where manager has changed my balance sheet. This is probably why, I have done it this way myself. So this is a third major feature change I have to fix in my data in recent history.
The amount you enter into that column (whether it be debits, credits, amount etc), that flag has always indicated whether the amount entered includes or doesnât include tax.
Why has that changed?
By whose definition? There are valid use cases for entering them as such. I have suppliers that provide tax exclusive invoices that I pay immediately and enter via payments and receipts.
Users have had to work around poorly implemented manager âfeaturesâ for years. You shouldnât say users are doing it wrong because manager has updated how it decides to handle it or how they have had to previously work around such problems.
Itâs very wrong of @lubos to make such changes without some form of being able to rectify the affected entries and if it is not determinable at managers end, then it should not be implemented without warning.
Hence my thread about fear of updating. Because unless your brain and Lubosâ brain are in complete sync, something will break.
You can still do it for amounts where tax code is not applicable.
See: https://www.manager.io/guides/18222
For example, you can just type 1,000*1.1 which will give you 1,100 without doing calculation manually.
I donât know how feasible that precisely is or what implications it would have elsewhere, but that does sound like a good option.
if it is possibly an option I would request that manager implement a âtestâ where it indicates to users, âyou have entered tax on this record in other placesâ and itemise the double dipped entries
This is not true. If the tax-inclusive box was ticked, the entered amount (the product of quantity and unit price) has always been interpreted to include tax. So the tax amount was backed out to determine the effective tax-exclusive price. This has not changed. But you would certainly have seen incorrect results if you mistakenly applied the tax code to both invoices and receipts/payments, as you were doing.
I do not understand this claim. Can you illustrate it?
To allow for other situations where the option was appropriate.
Manager does not protect you from mistakes. There is no logic to prevent erroneous entries.
And that is exactly the context in which the comment was made.
That is true.
Lubos and others.
Iâm not trying debate whether this is a bug or not. Iâve adjusted my entries and have moved on. Others will need to do the same.
Thanks for pointing out the ability to put a formula in the amount field. That will be helpful in future.
âIt also affects existing transactions which now have a different total as compared to prior to the upgrade.â
I meant that all existing transactions that are affected by this issue also need to be corrected. It doesnât just apply to newly entered transaction - but also to existing transactions. Just letting others know they need to fix all impacted transaction - not just future transactions.
