Tax rounding issue

Version 14.10 - Tax added 10% rounding issue for purchase order. Amount without tax $1731.35 with 10% tax added becomes $1904.485 ,so should round to $1904.49 but is instead rounding to $1904.48.

I saw you solved this on an earlier version of Manager, but I just downloaded this version today and the issue popped up.

I can’t reproduce this issue. It rounds correctly to 1904.49 when I try it.

Could you show screenshot of the purchase invoice with amounts?

Attached are two screenshots, one is of a purchase invoice and the other is of a sales invoice, both of these are old invoices that I have brought into Manager (using Saasu and testing Manager) and both are now out by $0.01

Yeah, the reason why the invoice is out 1 cent is because GST 10% is calculated on each line item separately, rounded and then totaled. It is not calculated on total amount.

Most accounting systems are using this method (I’m pretty sure Saasu is doing it this way too). There are technical reasons why this method is generally used by accounting systems.

Also ATO permits it so there is no issue as far as tax compliance goes.

One way to avoid this issue is to enter invoices with amounts that are already “tax inclusive”.

Hi @lubos

I’m having the same issue in my GST Sales Invoice from customer and my Purchase Invoice in Manager.

Supplier Invoice


When I make the Manager Purchase Invoice it does this:

Subtotal: 391.30
Tax: 23.478 (instead of rounding it to 23.48, it maintains it at 23.47)
Total: 414.77 (total comes -1 cent of the suppliers sales invoice)

After reading the forum, I recalculated all items to include tax and did a tax inclusive invoice to match the total value, but still my GST figure is 23.47 and not 23.48

Manager Purchase Invoice

So how do we go about it? When I do this in Excel also, it does the rounding off and shows GST figure as 23.48


Manager calculates the tax for every line item and shows the total rather than calculating the tax on the subtotal.

if you want to match with the actual invoice received, just add a line with the difference amount either as a positive or negative.

Your first step when you have questions should be to look in the Guides, even before checking the forum. In this case, there is a specific Guide addressing our issue: Manager Cloud.

1 Like

Fully concur with you, Tut.

Although, I keep a set of spoons to hand just in case someone needs a bit of spoon-feeding!

@Tut @Joe91

I read that specific guide too and in that specific guide too, it mentions that:

If a discrepancy occurs due to tax calculations, enter into the Unit price field the tax-inclusive price and check the box on the purchase invoice form to make the amounts tax-inclusive.

I did the tax inclusive part too (as you can see in the screenshot) of my original posting, it’s till -0.1 in the tax calculation, though the total figure of tax included PI value tallies with the supplier.

My question or rather curiosity was whether @lubos had found a fix for this. That’s all.

Thanks for commenting and spoon feeding too!

In reality, your supplier is calculating the tax incorrectly. It should be calculated line by line. There is no solution to the problem other than getting everyone to do the calculation line by line which is not going to happen.

There is no fix possible, because this is not a bug in the program. In some jurisdictions, you are allowed to calculate tax either way. In others, you must calculate line by line. All modern double-entry accounting programs calculate line by line because of the necessity to allow returns or adjustments of individual lines, and also to allow for the possibility of different tax rates applying to various goods and services.

I don’t know the specific law in your country, but I suspect line by line is allowed. Think of this from the tax authority’s perspective. In your example, you paid your supplier 23.48 in GST. If you claim 23.47, you will have a lower offset against taxes you collect from your customers. So you will end up remitting .01 more to the government. The government will not complain about that.

If you enter 100 transactions from suppliers who calculate on the subtotal, some of them will result in .01 more, some .01 less. Statistically, you would expect these to average out to zero.

Also, remember that you are not the only business who experiences the situation. The tax authority has seen this thousands, possibly millions, of times before. As long as you can show a rational, correct tax calculation method in your records, and apply it consistently, you will have no problems.

That’s not entirely correct and whilst this is an extremely annoying occurrence, there is no “one way” fix that gets this right every time mostly because as @tut mentioned, it can be done either way is some systems.

Generally most big suppliers use the line-by-line rounding method and so this is great, but a lot of suppliers (especially using manual invoicing) don’t.

I come across this problem repeatedly as I have suppliers that do it on a total, some give invoices where GST is added at the end (therefore the invoice is ex-GST) and others that give it line by line, and the problem persists.

Even using the the suggested method of “tax inclusive” isn’t a fix as it can still fail by this $0.01 because of the suppliers use of one of the tax permitted approaches.

Not directed at Joel91 and just a generic comment (Hi @lubos ! lol) I still feel strongly there needs to be a way of adjusting GST on an invoice by invoice basis, because you can’t simply create one line of adjustment since in most of my cases it’s ONLY the GST that is out. Adding an adjustment may make the GST correct, but then puts the invoice amount out.

I am not able to change the mind of my suppliers in this regard, and because the ATO (Australian) allows both methods, I can’t say to them they really should do it this way or that. I just suck it up that it’s one cent out.

And trust me, this OCD brain of mine doesn’t like it.

I thought I would add, that one of my “suppliers” is a multi-national multi-billion dollar company that services thousands of clients in Australia alone. It’s rare that i can get past a Filipino call centre let alone anyone that will actually listen to, and understand my frustration with their billing :confused:

Yes you can create a one line that will only adjust the GST which is out.
Enter the rounding amount under Unit and use a 100% tax code, so that the invoice and the GST balances.

So if the amount is 0.10, then using the 100% tax code will add 0.10 to the GST total.
You may need to create under Tax Codes the custom 100% rate.

I really couldn’t get this right in my head so I just created an EXTREME example.

(to anyone else, BEFORE you comment: yes these numbers are stupid, but I’m doing that to try and get it right in my head and so I can CLEARLY see which way things are happening.)

Let’s say the sale is $100 but the GST is incorrect and should only read $5 (again, I know we’re suppose to be only talking in cents, but I want to clearly see what’s happening here). I want the GST amount to reflect $5 but the total including GST to be $100.

I created the tax code as suggested but the application of it isn’t modifying just the GST amount. In fact, it isn’t modifying the GST amount at all!

removing “tax inclusive”

I’m wanting to see GST $5. This way I know it would apply ONLY to the GST amount and not the item amount.

Could you provide an example? I feel that what you say is right, I just can’t apply it (yet) lol




The GST is never incorrect, it just the rounding difference of the GST between the invoice and the entry within Manager that is being adjusted.

Your Invoice is for 100.00, but the initial entry in Manager shows 99.99 or 100.01, so you create a +0.01 or -0,01 adjustment using 100% code to bring the Invoice and Manager entry into alignment.

But to use your example:
1 - It only works with tax exclusive
2 - Set up the tax code as follows

Don’t use 0000000%20Bug%201a

Then you get the result - GST = $5 0000000%20Bug%202

1 Like


as always, a champion, a gentleman and a scholar!

Notwithstanding the different GST tax rates appearing, the tax payable is correct!

Trust me, this WILL help this OCD brain at the end of the day. I will be far easier able to move on with this simple fix.

It was all in the setting up of the tax code. I had it set up as in your “Don’t use” example. Using what you had right above that made it work and I won’t pretend to know the difference or that it even existed! LOL

It definitely existed. As explained in this Guide:

  • Choose 100% to create a tax code for line items that are all tax… Forms will show the tax amount as a regular line item rather than an addition to the subtotal….

In other words, the built-in 100% tax code adds a line item with Unit price as the full Amount. That amount appears in the subtotal. In the following illustration, assume you have purchased 100.00 worth of goods, taxable at 10%, but the supplier rounds differently (ignore the fact this could not happen in this simple example) and invoices you for 115.00. You enter the purchase invoice with a tax adjustment line using the built-in custom tax code rate of 100%. Your purchase invoice matches the supplier’s sales invoice:

In the second illustration below, a custom tax code defined as Custom => Single rate => 100%, as illustrated by @brucanna, is used instead. This taxes the Amount at 100% and adds that tax to the subtotal. Now your purchase invoice does not match the supplier’s sales invoice:

Which approach to use depends on what you are trying to match.

1 Like

Thanks @tut, that’s a good example (with obviously bad data for my example).

When I said about not knowing it existed, I didn’t mean to infer that it didn’t exist before, just that a) I didn’t know that it was there, and b) I wouldn’t have known what that meant if I did. (it was more at the lack of my knowledge than actual disbelief).

I’m serious when I say this is going to save me more than a few minutes of manic OCD behaviour. Yes, it’ll only be used in those $0.01 scenarios. But it will save me from spending half an hour trying to marry up what is a simple miscalculation. Trust me, I get anal about those single cent errors! I’m just glad I can now do something about them.

The sad part is, I REALLY want to dig through the database and find where they all occurred and fix them.

I’m taking a deep breath. I should be ok! lol