The VAT appears to be calculated individually for each line item, and then added up to get the total VAT. I’ve looked at previous threads about this - as per VAT calculation this is intended.
However this is not how VAT is actually calculated on many Invoices! Especially where all items are eligible for the same VAT rate, the VAT is often calculated over the full sub-total of all line items Excl. VAT.
In the example below, I have an invoice from my supplier for £96.30 total Excl VAT and £115.56 Incl VAT (115.56 = 1.2 * 96.30). With this difference in Manager (£115.57 total), the items don’t line up with what actually came out of my bank account.
I clearly can’t get a huge £million company to change it’s whole accounting practices for me - so I need to have an option in manager to account for this. What is the best way to get Manager to calculate the VAT to match these invoices?
That used to be the answer. With recent changes to the program, the answer is now “the same liability account to which you have assigned the tax code involved.” For you, that may be Tax payable. But it can now also be something else.
Though on trying this further I’m not sure it will work. Although the VAT Incl total is then correct, the VAT 20% rate is still not adjusted, and the Sub-total is adjusted which it shouldn’t be.
I suppose I can extend this approach and get all the numbers to work as below, but this is getting to be too much of a bodge!
The question of what comes out of your bank account is completely separate. When you pay off the purchase invoice, simply pay the amount the supplier charged you, inclusive of VAT. In the first screen shot of your last post, the total was 115.56, which is what the supplier expects to receive. The payment involves no tax codes. Your supplier will be happy. Your tax authority will know you paid 19.26 in VAT, because that is what your supplier will report. And that is what you will report, because your tax liability account will be reduced by the amount posted because of the rounding line, even though it does not show on the specific purchase invoice. (Remember, purchase invoices only serve to record your suppliers’ sales invoices to you. They do not go anywhere outside the company.)
The fact that the sub-total for the line items is off by a penny will not matter, because that number appears only on the sales invoice. It is not actually used to calculate your income—the postings to your income accounts are done from the individual line item amounts. And the difference occurs only in the 100% tax rounding line item, which only affects your tax liability account.
Another way to handle this is to enter tax-inclusive prices, adjusting them to match the supplier’s total. That method is described in this Guide: https://www.manager.io/guides/9499.
If you are worried about what an auditor might think, remember two facts:
Auditors are well aware of this situation. In fact, most tax regulations explicitly allow both methods. And they’ve seen it many times before. Since your VAT calculations will match your supplier’s, the auditors will not care what a sub-total says you paid for the items. If anything, they will check what the line item says you paid for an item.
Your tax liability will be the net of many transactions, both buying and selling. There is an excellent chance the rounding differences will balance out to zero. Even if they don’t, they will likely be minimal. If you are reporting in whole currency units, they will probably not even be visible.
So do not go the second step of your last screen shot. Adjusting the adjustment hardly makes sense. And your VAT worksheet won’t work with it anyway.
you do not have to select any account as the line item because the 100% tax code itself is assigned to the default Tax payable account or any other account of your choice when you create it.
all you have to do is enter the difference under the Unit price column and then select the tax code against it. if you drill down on the Tax payable account from your Summary page, you can see this value accounted for.
@sharpdrivetek’s information is partially outdated. As of version 19.11.85, the default Tax payable account no longer exists. You must now create your own tax liability account, if you don’t already have one. Regardless, you must select an account for any new tax code you define. See Create and use tax codes | Manager.
It is true that you do not select an account for the line item, only the tax code.
If you already were using the program prior to v19.11.85, you had a default Tax payable account back then, and it was automatically converted to an ordinary account with the same name upon updating.
Thanks for all your help! I’m actually doing it straight into a payment, not via an invoice (was easier to use the test purchase invoice I’d just created as an example) so not sure it’s all the same, e.g. the tax codes then do have to be entered in the payment.
But in any case I’ve reached my limit of time looking in to, so decided I’d should just not be so pedantic!! I’ve made sure the amounts match up coming out my bank account. I didn’t add any rounding line items as just seems like a bodge and still didn’t make all the numbers line up. The VAT is still off I think but that will just have to be how it is if there’s no native option in Manager.
this is not wrong. but when the descrepancy is usually because of tax rounding differences, having the rounding off value offsetting in the same account as the other tax codes will give a clearer idea of the tax owed or tax credit available for the business. else, a journal entry would be needed offsetting the P&L account and the Tax payable account.
Not necessarily. When you make the payment or receive the refund, just enter the Tax Payable account rounding adjustment as a line item on the Payment or Receipt.
Generally this is true except for countries where Manager has down stream processing such as tax calculation worksheets.
The user created 100% rate code will add the rounding to the “tax payable” account, but the rounding wouldn’t be incorporated into the worksheet as the tax code has been allocated a worksheet field to be associated with, so the rounding difference will remain between the GL account and the worksheet, hence the suggested usage of a P&L expense account.
However, this could be resolved when users can up load tax codes into localisation as they “should” be required to associate the tax code to a worksheet field.
(unless I’m missing something unexpected).
