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
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.
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
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!
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:
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.