Purchase Invoice Value Different Between Input Screen and "Created" Screen

Hi,

I don’t know if this has been asked before so apologies if it has. I’ve been entering a Purchase Invoice today for a number of items that have to be broken down. E.G. A reel of cord is sold by the metre so the invoice cost has to be divided by the number of metres on the reel to get the unit price. All the calculations for this have been carried out in Excel and all work through to match the invoice value, and these unit values have been entered the Inventory module. The problem I’m having is as follows: -

Invoice value £409.82

Purchase Invoice Entry Screen Total £409.8199

Purchase Invoice Printed Screen Total £409.79
<img src="//discourse-cloud-file-uploads.s3.dualstack.us-west-2.amazonaws.com/business5/uploads/manager1/original/2X/c/c46f208cb9d47fc15b2cc96911fe0d3c406cbe0b.png" width=“436” height=“196”

I’ve tried rounding the decimal places up and down and there always seems to be a £0.03 variance despite the fact the entry screen suggests the rounding should go to the £409.82 value as per the invoice. The summary sheet is showing £409.79 in Accounts Payable but if I “Spend Money” I have to adjust the value to reflect the invoiced amount.

Adjusted Value Paid - Bank Payment Screen

Going back to the the Purchase Invoice View it shows £409.79 “Paid in Full”, not the actual amount on the invoice being processed. Also, the summary screen is showing a supplier credit of £0.03 which is clearly incorrect.

This is probably all to do with how Manager rounds values up/down but if anyone can confirm this or explain why I’m getting this difference I would appreciate it as obviously the accounting entries should match the paperwork.

Thanks for the help.

While its agreed that the 0.03 situation shouldn’t exist, Manager is correct based on the information that you have provided - a payment of 409.82 against an invoice for 409.79 leaves an overpayment of 0.03 which is stored in Customer Credits.

What if you round your spreadsheet calculations to only two decimal places, do you get the correct invoice total, if yes, then only use 2 decimal places for your inventory entry into Manager.

Your input screen is showing the total of the raw data as it has been entered but before clicking the Create button. The view screen is showing the result of how Manager has stored that raw material.

I would suggest that if you are entering your inventory with up to 7 decimal places, then possibly Manager is ignoring those values past a certain number of decimal places and therefore causing a differential in the rounding.

Hi Brucanna,

Agreed, Manager clearly sees the invoice payment for £409.82 as an overpayment compared to the £409.79 it perceives should be paid. However, this is still incorrect. To answer your question, I’ve tried using the ROUND function on Excel to 2,3 & 4 decimal places and still get the error, the 7 dp shot was the latest of many attempts to clear this issue. For just this instance I’m going to write off the supplier credit as the bank account on the cash tab reconciles to my bank account. I would still like to know why the error is arising and why it seems difficult to enter items which need to be broken down into unit costs.

This is the first time I’ve encountered this difficulty as I’ve carried out the same process on all my invoices in the past with no issues. I’ve just updated to the latest version as I thought this might help clear it but the £0.03 supplier credit is still there so I’m stumped at the mo!

The explanation is simple. When purchase invoice is posted, each line item gets rounded separately, then added up to total.

This is to make sure individual accounts don’t get debited or credited by amounts which are more than 2 decimal places.

The editing window should be more obvious what’s happening. But even if this is fixed, purchase invoice total will still come to 409.79.

The solution is to simply increase some figures on purchase invoice to arrive at 409.82.

Hi Lubos,

Thanks for your response; I’ll do this if the same thing comes up next time.