VAT Rounding
Last updated
Last updated
Since first writing this article we came to understand that although the unit method, although perhaps the most straightforward, just isn't that popular in the wild. I suspect it might be because it is the method that most amplifies rounding discrepancies. In our experience, UK customers prefer the line method whereas our customers in Spain tend to prefer the totals method where VAT is calculated right at the end, on the grand ex-VAT subtotal.
For this reason, we implemented user control over this setting, so customers could choose which rounding technique to employ. You can find this setting in Account Settings > Rounding Method.
In order to reduce complexity, we eventually removed user choice of which VAT rounding method to use.
After running our variant of the line method throughout 2022 and taking feedback from users, we decided to switch to a method closer to the totals method. We now round in the final stage of transaction total calculation. We sum each unrounded line Ex. amount to reach total transaction Ex. (unrounded). We then sum each unrounded line tax amount to reach the total transaction tax (unrounded). We then sum these two amount to reach the total transaction Inc. amount which is finally rounded.
This method is the most accurate (since it removes all compounding rounding errors) and also allows perfect "pretty pricing" (where you have a target Inc. tax amount, such as £69.99, that cannot be achieved when rounding happens earlier in the chain).
If you've got here because you've worked yourself up into a state of rage because the fancy accounting/ERP/web system you pay all that money for each month has produced an invoice that doesn't match up with an invoice you've been given, or a customer has complained that the totals on an invoice you've produced are incorrect - take a deep, calming breath and know this: there is no single, correct way to calculate VAT.
Right now that might sound plainly ridiculous to you, but stay with me for a rock-and roll-tour of VAT and rounding and at the end of the article I'll point you to some hilarious forum discussions where people really lose their shit over this.
Yes and no. It all comes down to when you perform rounding. If you can't remember what rounding is, you're going to struggle with the rest of this article, so here's a refresher.
The result of a calculation involving amounts of money and fractions (or decimals, or percentages etc etc) can result in numbers that don't make sense within that monetary system. That's a mouthful - here's an example:
In the UK, standard VAT used to be 17.5%. So a £1 + VAT product should cost £1.175 right? But what does that even mean in a monetary system that gave up 0.5p coins donkeys' years ago? And that doesn't happen just with funky VAT rates involving 0.5%s. VAT is 20% right now, so a £3.21 + VAT product should be £3.852 inc. VAT, which is even more meaningless.
So for a monetary amount of 3.852, what do we do? Well, most modern monetary systems divide their primary unit (e.g. Euro) in hundredths (e.g. Cents), which means we need to round to 2 decimal places.
Now, there are a few ways rounding can be accomplished:
always round down: 3.852 -> 3.85
always round up: 3.852 -> 3.86
commercial (common) rounding: round up or down depending on the rest of the number - without going into technical detail, this is probably what you remember from school as "round down if it's below 5; round up if its exactly or above 5".
None of these are technically 'correct', but commercial rounding is the one normally used, well, commercially. It's the safest bet and usually the one either allowed or mandated by accounting standards. It's the one Pakk uses. For uber-geeks, we round -0.125 to -0.13 not 0.12, which is how 'commercial' rounding applies to negative numbers.
If you're starting to already see how things could get gnarly, buckle up - we haven't even fired up the engine yet!
OK, so we understand that we need rounding because we know prices like 3.852 just don't make any sense. Let's dive deeper into how the simple act of going from 3.852 to 3.85 can cause mayhem in an accounting system. We'll used a worked example. I won't include any specific currency, just imagine this applied to your home currency, like GBP or EUR.
Let's say there is a product, we'll call it Product A. The ex. VAT price is 13.25, the tax rate is 21% and so the inc. VAT price is 16.0325. If you went into a shop, picked up the product, went to the counter and were asked to pay 16.0325 you'd rightly be confused. Luckily, that would never happen. You'd be charged 16.03.
Let's just step back a minute and philosophise: what actually happened to the 0.0025 that got lopped off the end of that price? Where did it go? In the game of money there are always winners and losers right? So who won? and who lost? Well right off the bat, we can see that you, the consumer, saved yourself the princely sum of 0.0025. That's a lot of cash. To put that in perspective, if you did that 10 times, you'd have saved 0.025 which is....hmm, also in need of rounding. Forget it. You saved some money. So who lost out? Maybe the retailer - after all, he collected 0.0025 less then he would have done without the cunning rounding stealing his income. That's true, but remember, the VAT that the retailer collects goes to the tax authorities eventually, so really it was the tax man who lost out here. Shame. Well, you win some, you lose some, as we'll see later.
Right, so we've established that the effective inc. VAT price of Product A is 16.03. Cool. So you go back to the same shop to buy 4 of them to complete your set. You take them up to the counter, and as you are counting out your coins to pay exactly 64.12 (16.03 X 4), the cashier throws you a curveball and asks for 64.13. Did you think you were always going to be a winner in the game of VAT and rounding? Sorry to burst your bubble. But what just happened there? It's actually quite simple to understand. The till system used by the store did the multiplication of quantity (4) first, then calculated the VAT. So: 13.25 X 4 = 53; 53 X 1.21 = 64.13.
So who's laughing now? Earlier in the day, when you'd paid only 16.03 for a single unit of Product A, you'd left the shop highly contented with the bargain you'd scored. Now, as you trudge away after having to scrape together that extra 0.01, you leave the store highly discontented. Surely you've been scammed out of a penny? Where did that penny go? Well, assuming the merchant accounts for VAT in the same way the till calculated it (which might not be a valid assumption, even though it would be a mini "fraud" if they didn't), she will pass on 11.13 to the taxman, leaving 53.00 as her net income. That represents exactly 13.25 per unit, which is what you paid in the morning for the single unit. So, as you probably already guessed, that penny went to the taxman. Like I already said, you win some, you lose some.
So, the difference between these two examples is down to where the rounding was applied. In the first transaction, since there was only one unit, the inc VAT price of that single unit was rounded. In the second, the line total (i.e. the total price after multiplying by quantity) was rounded. If the same method had been used in the second transaction, we would have multiplied the already rounded 16.03 by the quantity of 4 to reach a total of 64.12, which is what you were expecting to pay, right?
From now on, we're going to refer to the above methods as the unit method and the line method, respectively.
OK, this is where it gets really complicated and working an example through is too hard to follow in an article like this, so I'll include a spreadsheet if you are interested in looking up particular combinations of numbers that can cause the scenario I'm about to describe. For now, just trust me.
In the second transaction I described above, and in transactions of its kind, we refer to lines. A transaction is composed of multiple lines, each line refers to a product and quantity. So in the above transaction, there was only 1 line, with a quantity of 4. Simple.
However, in a commercial setting, transactions tend to have many lines, so there's now an extra level of complexity. In a multi-line transaction, it's entirely possible to leave each line Inc tax amount in its raw, unrounded state, add them all up and then round the total!! This gives the same result as just adding up all the line Ex VAT prices and doing a single VAT calculation right at the end. Predictably, this can give a result that differs from both of the methods described above. I'm going to call this final method the transaction method.
From the previous article I wrote about rounding, I can think of all these approaches to rounding, and I'm sure I haven't got all of them:
Round the unit ex price, multiply by quantity, apply tax, round again
Apply tax to the unit ex price, round, multiply by quantity (the “unit” method)
Multiply the unit ex price by quantity, calculate tax, round tax, add to line ex (variant of “line” method”, with rounding of tax)
Multiply the unit ex price by quantity, calculate tax, add to line ex, round line inc (variant of “line” method”, with rounding of line inc)
Multiply the unit ex price by quantity, round, apply tax, round again ( “line” method but with rounding of line ex, and rounding of tax, this is what we do)
Multiply the unit ex price by quantity, apply tax (no rounding at all)
Round the line inc. amount, sum those to get to the transaction inc. total
Round the line inc. amount but ignore those and add all unrounded line ex and line tax, then round that, to get to the transaction inc. total
No rounding anywhere (leads to 'unreal' transactions amounts like 67.452, that can't actually be paid)
The right way to do is consistently. That's pretty much the only answer I can give you. Once you understand that, you'll start to understand where the torrents of rage you can find online come from.
Most tax authorities are happy for you to just choose a way and stick with it. As long as you're not doing open fraud or have discovered a way to cheat them out of millions in tax revenue, rounding is going to make very little difference in the long run. I know this to be the case in the UK (link below), and I suspect it is the case in most countries, but at the end of the day, I'm not a certified accountant or tax guru, so you'll have to try to find out how it works in your country. PS: good luck with that - this is such a minefield of complexity that 'experts' will probably not be able to give you a straight answer and it might even be totally ambiguous in your country's tax code. In the UK it has sometimes gone to court!
The really irksome scenario is where different systems do it in different ways and I believe this is what drives most people nuts. Given the complexity I described above, most casual users could be forgiven for not understanding the layers of accounting assumptions that are baked into any ERP/accounting/transactional system and so when they find that a transaction their system produces doesn't match up to the "same" transaction on someone else's system, they assume that one of the systems is "wrong" or "broken" and get into forum or helpdesk flamewars (see links below for some real nutters).
We use the unit method. We think it makes the most sense for most users. If you round "early", then the numbers that result down the chain just make sense, and you don't end up charging your customers 64.13 for 4 items that cost 16.03. We like that simplicity, but we also know that it will often mean that people used to the line or transaction method might complain that their invoice is "wrong".
It's not wrong. And if they don't believe you, point them here. In the worst case scenario they'll see how long this article is, not bother to read it, and just decide to leave you alone about it.
https://www.gov.uk/guidance/vat-guide-notice-700 (see 17.5.2)
