Why is there a rounding difference between Promotional Office and my Sage 50/200 system?

You are here:
  • KB Home
  • Invoice
  • Why is there a rounding difference between Promotional Office and my Sage 50/200 system?
< Back

So this is a long-standing “issue” with Sage50 itself and its method of VAT calculation.
(I found an article here from 2011 that goes into these rounding differences)

In short:

Sage50 has decided that it will take the net total price of a single invoice line, (round this off to 2 decimals) then calculate VAT off of it and then also round the VAT total off to 2 decimal places. It then repeats this for every line on the invoice.

Promotional Office does not do that, as specific to our industry, products are often priced up to 4 decimal places. This means rounding is often inevitable.

Therefore, it takes the complete net total of all lines (rounds this to 2 decimals) and then applies the relevant VAT. Thus, minimizing VAT rounding issues.

Here is an example that does not work well in Sage50:

If I would sell 50 different product lines each at £0.02 and would apply VAT per each line and then round to 2 decimals:  0.02 X 20% = £0.004 => rounded to 0.00 VAT per line.  Each line is separately calculated so the VAT total for the invoice is 50 x 0.00 = 0.

Within Promotional Office it would first add all the net pricing together: 50 X 0.02 = £1  and then it would apply Vat: £1 x 20% = £0.20

Sage50 is fully aware of this, and even has the same “issue” within their own software:
here is an article off of their own website explaining why there is a possibility for a couple of p difference between a Sage Sales Order and an Sage Invoice.

http://desktophelp.sage.co.uk/sage200/professional/content/sop/How%20VAT%20is%20calculated%20on%20sales%20orders.htm

Apparently the only “solution” sage offers for this is within their sage200 package, where there is a setting to use gross instead of nett. (thus calculating VAT backward from the gross value, so that the total value never changes)

We at Promotional Office have found a way to get around this conflict by creating a single line import into sage, rather than importing each product line individually it will import the invoice as a singular value and prevent the rounding inconsistency within sage.