Tax error by supplier

1

I just run into another variant of this same problem: bad tax calculation on the part of the supplier. This is the receipt in question:

hb-btw
hb-btw1512×4128 1.02 MB

Now, it doesn’t matter whether you enter 10,08 tax inclusive or 8,32 tax exclusive; in both cases Manager calculates the tax as 1,75 instead of 1,76 (VAT 21% and decimal commas). It also makes no difference whether you just enter the totals in Manager, or enter each item separately.

Manager’s calculation is correct; it’s the supplier’s that is wrong. Nevertheless, that rogue cent must be accounted for. I ended up creating a new tax bracket of 21,1% which, applied to 8,32 tax exclusive, gave a tax of 1,76.

This is by definition the wrong way to fix the problem. The right way would be for the default tax account to be usable in the receipts & payments pane, so that an incidental correction of +0,01 tax could be added as a new line on the same payment without having to create completely new tax in and tax out accounts. As it is now, adding a cent to the tax payable account does not change the tax that’s calculated by Manager.

Question: is there a better way to solve this?

2

@zenon, please do not divert topics with unrelated issues. Your situation has nothing to do with rounding. You claim an actual error by the supplier, which is a completely different thing. So your post was moved to its own topic.

Your solution is the wrong approach because the Concept BTW Aangifte worksheet will not pick up your custom 21,1% tax code. The worksheet functions only with in-built tax codes imported with the worksheet localization. The worksheet will exclude the entire purchase. Then, you would have 10 Euro problem instead of a 1 cent problem.

Here is the good news. Your supplier’s invoice is not actually wrong. There are dozens of ways to calculate tax when you have multiple items, including variations on applying tax before or after summing line items, choosing your rounding method, etc. See the discussion here: Adjust rounding differences on purchase invoices | Manager. Your situation is interesting because you had two items that were offered as “buy one, get one free.” The way the merchant handled this was to charge you full price for all items, then give you full-amount discounts for one of each of the items on special. So they actually had six line items in their calculation. VAT was calculated on all six lines, whether they were adding to or subtracting from the total. All prices were tax-inclusive. But the merchant evidently selected the option of rounding all tax amounts to the next larger (more negative or more positive) cent on every line item when backing out the VAT amounts. (The government likes you to round up so it gets as much tax as possible. I don’t know if this is a legal requirement in the Netherlands.) If you duplicate this calculation with upwards rounding, you will see that the VAT backed out of the 10.08 total is 1.76.

So, what should you do about this? Nothing. Get rid of your 21,1% tax code and apply the real 21% tax code. Enter the tax-inclusive prices for the payment so your bank records match the receipt. Ignore the one cent difference in tax for two reasons:

  • The next transaction is just as likely to be one cent off in the other direction. Over time, these things cancel out.
  • Tax authorities are well aware of issues like this. That is why they have us report and pay in whole currency units (Euros in your case) rather than cents. They do not want to worry about such small amounts either.
3

@zenon, please do not divert topics with unrelated issues. Your situation has nothing to do with rounding. You claim an actual error by the supplier, which is a completely different thing.

Well, it is a rounding issue, as you yourself note in “VAT was calculated on all six lines, whether they were adding to or subtracting from the total. All prices were tax-inclusive. But the merchant evidently selected the option of rounding all tax amounts to the next larger (more negative or more positive) cent on every line item when backing out the VAT amounts.” And it is also wrong on the part of the supplier, because Dutch tax rules stipulate rounding 0-4 down and 5-9 up, either on each item or on the total, but consistently using the same method. So both things are true, rounding error and fault of the supplier.

Your solution is the wrong approach because the Concept BTW Aangifte worksheet will not pick up your custom 21,1% tax code.

My solution is wrong because it is not a solution in the first place. It is one of the ugliest workarounds imaginable. As for conceptaangifte, it is only a help tool which I don’t even use. I want the ledger proper to have the right amounts, I take out a report with decimals, do the VAT declaration manually while rounding to my favour, and then use a journal entry to move the saved cents from tax due to financial profit. You see, legally speaking, you are allowed to round the VAT to your own favour, but then you still have to pay corporation and divident tax on the cents that you thus saved.

So, what should you do about this? Nothing. Get rid of your 21,1% tax code and apply the real 21% tax code. Enter the tax-inclusive prices for the payment so your bank records match the receipt. Ignore the one cent difference in tax for two reasons

Both reasons you give are valid per se, but I can’t do that, lest I want to be chasing ghosts at the end of the fiscal year. You see, human booking mistakes are inevitable, so if the books don’t close exactly to the cent, there is no way of knowing whether you have a single 10-cent discrepancy somewhere, or multiple serious errors (like inverting credit and debit) that just happened to almost cancel out each-other. In other words, pedantry is necessary not because the tax authority would penalise you about a cent (especially not the Dutch tax office, which is particularly relaxed about much bigger but honest errors), but because when things begin to slide you can no longer rely on your own figures.

With all that said, my original question was “is there a better way to solve this?”. I would appreciate any reply other than “don’t solve it”, including “no, there is not” and “yes, like this”.

4

The topic where you originally posted was about rounding of figures when calculating tax. Your question was what to do about bad calculations by a supplier. That is why I moved your post to a new topic. I only got into rounding to explain that there was no mistake.

In that case, I don’t see why this is even an issue for you. Your complaint seemed to be that things were not going to match somewhere. But if you’re entering tax-inclusive prices and doing everything manually, where will the discrepancy even show up?

5

It will show up when Manager presents me with a €1,75 VAT credit with the tax office and a €1,76 VAT payment to the supplier. There will be an unaccounted-for €0,01 discrepancy and nobody will know where it came from.

In any case, this is not an issue of whether errors show up or not. It it is an issue of not having errors. What you’re saying is tantamount to “why not just sweep it under the carpet, who would ever look there anyway?”. That’s not what accountancy is about.

6

My point is that if you enter tax-inclusive prices, the 1.76 never shows up. But I have said enough.

7

My point is that if you enter tax-inclusive prices, the 1.76 never shows up.

Correct, except for the fact that I have paid it and I have the right to reclaim it.

But I have said enough.

Yes, I agree. I asked a simple question, “can this be fixed or not?”, and you have answered everything on the face of the earth except for the question that I asked.

9

Zenon
If you want manager taxation programming to help you have to use Manager built in tax codes.
It will round to whole cents so introduce a rounding error. In theory the rounding could be done at different levels producing slightly different answers. There are pros and cons for each. The method used by Manager introduces a random rounding error so it averages out over time and is accepted by taxation authorities

10

As far as I have seen so far, there is no random error. Manager does the rounding perfectly according to the (Dutch) tax office’s rules and, in all cases so far except this one, Manager’s rounding matched perfectly that of my suppliers. In other words, the rounding error in this case is not with Manager, but with this particular supplier and this particurar receipt.

What I’m looking for is a way to add a line in the booking of the expense (receipts & payments pane) for “extra” VAT that could be positive or negative. Something like

goods € 10 exclusive VAT 21% (or goods € 12,10 inclusive VAT 21%)
extra VAT € 0,01
bank payment € 12,11

leading to a booking of

goods 10,00 debit
VAT 2,11 debit
bank 12,11 credit

The problem is that if I add the cent in a new line against tax payable, it does not show up in the total tax payable of the transaction. Nor is there a way to choose whether to credit or debit tax payable for that cent (unless Manager would accept -0,01, which I have not tested).

This whole problem would be solved forever by creating new VAT in and VAT out accounts and booking all VAT manually, but that solution would entail a whole lot of unnecessary work for 99,99% of all bookings. That’s why I’m looking for a way to avoid it.

11

If you can have an inbuilt tax code of 100%, then the + or - 0.01 entered on a new line will show up in the total tax payable of the transaction.