# Tax rounding unclear

After putting in my order, and manager returns tax as 2.73 which isn’t same as I am getting on my invoice from vendor.
Should there be an option to calculate tax based on whole purchase invoice rather than each item separately ? 11.90 x 0.23 = 2.737 ~ 2.74

Is this due to rounding mistakes and what would be the best way to work around it ?

Manager purchase order view:

Vendor invoice:

This is also happening on multiple occasions

And calculation is really straight forward - 2.35 x 0.23 = 0.5405 ~ 0.54
Not 0.53 which manager gets from somewhere ?

Purchase invoice:

Vendor invoice:

The correct way to do VAT calculations is line by line, so the VAT calculations are

0.14 x 23% = 0.03
0.10 x 23% = 0.02
0.15 x 23% = 0.03
1.96 x 23% = 0.45
Total VAT = 0.53
Calculating the VAT on the total is not correct, but often manual invoicing is done this way as it is quicker.

See here for one method to avoid this problem Adjust rounding differences on purchase invoices

Thanks for assistance, way of changing them to include VAT works, but it’s not very convenient solution.

Many companies still calculate VAT on sub-total rather than per product basis and that could cause rounding issues in Manager, so then we have to calculate every product price + VAT and replace it on purchase invoices at our end to work around it.

It would be handy to have something like this

I understand it would take a lot of time to change and cause other issues in system so I am not saying to implement it, just suggesting this can make someones life a bit more easier

This thread can now be closed

Manager is tax law compliant, those who are calculating tax on the sub-total are not tax law compliant, so I can’t see Manager changing to accommodate non-tax law compliant invoices.

You don’t need to re-calculate every product, just add a line to take up the rounding adjustment.

1 Like

G’day @Brucanna, I have just spent some time searching for this since this is my new hot topic for the moment.

As I hope everyone appreciates, I have grown to LOVE manager and I love the fact manager does it line-by-line. Most of my suppliers do.

## But some don’t!

As I recently mentioned in another post, I have a multi-national company operating in Australia who do it on the invoice total (well, for only those items that incur GST. It is a very sad invoice indeed). What makes it worse is that some line items don’t have GST and others do and some prices I get from them are ex-GST and quoted to me as such, and others the GST is calculated on a GST inclusive price (so it works backwards). It’s a VERY painful invoice when it comes time to enter it.

Short version: I HAVE to enter the invoice NOT “tax inclusive” (since some items are ex-GST price, and if I ADD GST line-by-line the calculation is incorrect) and have some lines that ARE “tax inclusive”, so I have to manually work it out and add it myself (I possibly said those the wrong way around there). Point is, their invoicing is a right royal pain in the butt! And I’m forever \$0.01 out on the GST calculation.

Back to your point that “those who are calculating tax on the sub-total are not tax law compliant”:

about a week ago I went searching for this exact reference within the ATO website. I didn’t think to bookmark it and the closest I can find at the moment is this (this refers to a pdf I did find from the ATO, but it does not appear in my search history, which sux, because this was the title exactly as it appeared on the document “certainty for business in gst calculations and rounding”:

http://www.thewebdudes.com/webdude/work/supercorp/TheWebdudesWorkAtSupercorp/SINews/news/articles/news-2000-04-19_001.htm

Now I’m not sure if this is still current, and I’d like for anyone to prove that it’s not, because I’ll hand deliver the relevant ATO documentation to them personally.

My point being, and as far as I can tell, just because someone doesn’t caluclate the GST line-by-line, doesn’t necessarily make them non tax compliant.

If you can find me any reference that specifically says otherwise I would be most appreciative. I have more than one supplier I could send this too

@lubos, I think @anony253’s suggestion of having a “calculate tax on sub-total” option per invoice may in fact (mostly) solve this problem, especially in jurisdictions that do allow either method of calculation, like Australia.

Unless I am misunderstanding you, there is no reason to do this. The fact that only some items are taxable is immaterial. Choose the appropriate tax codes (e. g., 10% GST and none), mark the invoice as tax-inclusive, and Manager will back the tax out of only those lines with the code applied:

Tax rounding is an unrelated issue.

As I mentioned, it’s a VERY bastardised invoice. I have sent them an email about it, but I don’t expect anything to change. You are correct, it IS immaterial whether GST is applied or not, but what isn’t is that I am given nice rounded ex-GST prices on some lines (without a line-by-line GST calculation appearing on that line), AND other lines have GST calculated from a GST inclusive price.

So I either have to click “tax included” and manually add it myself, or leave it NOT “tax included” and calculate an ex-GST price myself from the GST included prices on those lines.

(Did I say this was one bastard of an invoice? To clarify, it’s a “document” which contains several “parts” and each part is detailed enough in itself, but the totality of the document doesn’t line up with either line-by-line or total. In diagnosis, it appears each section uses different methods! AFAICWO it’s an issue that in one part of their accounting system prices are simply quoted ex-GST, yet in another part that relates to each user, there are values that have GST already applied and it is back-calculated and then it is all compiled into one document. It really does suck as far as invoices go. A high school economics student could do better).

That and the fact GST doesn’t appear line-by-line it is IMPOSSIBLE to get this to line up. I’m currently looking at @Brucanna’s suggestion here which might work as a work around, and may even be better than the suggestion above.