GST calculations on Purchase orders

Hi
When creating purchase orders with line items from inventory, AroFlo calculates the GST Tax on each line and not the total of lines. Our suppliers calculate GST on the total amount. You would think that this would not be a problem but you end up with two different amounts. We are only talking 1 cent but when you integrate across to Xero and use COGS, your supplier invoice in Xero does not match the actual invoice total. Normally I would not waste time on 1 cent error but it makes a difference with the paying of invoices. I can see how this is caused. It is a matter of rounding the tax amount on each line rather than the total. I have a way to workaround this but it is not ideal. How can I get AroFlo to calculate GST tax on the total rather than the individual line items?

Hi Keith,

According to the ATO, there are two ways to calculate this:

  • Total invoice rule – under this rule, the unrounded amounts of GST for each taxable sale should be totalled and then rounded to the nearest cent (rounding 0.5 cents upwards).

  • Taxable supply rule – under this rule, you need to work out the amount of GST for each individual taxable sale. Where the unrounded amount of GST has more decimal places than your accounting system can record, the amount should be rounded up or down as appropriate. You then need to add the individual amounts and round this total to the nearest cent (rounding 0.5 cents upwards).

We use the Taxable Supply Rule, as does Xero, but other accounting packages such as MYOB use the Total Invoice Rule.

This can cause very small discrepancies, these discrepancies occur with every type of financial system available as they all use different calculations. In this case, if you entered the invoice in Xero, or if you entered in AroFlo and sent to Xero, you would end up with the same calculations because we both use the Taxable Supply Rule. The only way I could think of around this would be to have a single line item in the invoice for the total amount.

Even if you were able to change the way it calculates in AroFlo, you would still have problems with Xero as it calculates the same way. Of course, any suppliers who also use Taxable Supply Rule will calculate in the same method, and you shouldn’t have any issues with those suppliers. From what I’ve seen out there, it seems to be something people have learnt to live with, but if you have a particular way of handling these types or discrepancies or suggestions for how we could offer a solution, I would be happy to hear it. At the very least we could create some solid documentation for other people experiencing the same issue.

Hi Adam
Thanks for the reply. This issue only comes up for us in purchase orders and has only just become a problem because we have started to use COGS. We have now implemented teh COGS function and creating POs for all inventory purchases. Aroflo is creating the bills in Xero through the integration link. This particular supplier (a big international company) is calculating the GST on the total of all lines where AroFlo does it per line. As I said it only makes a 1 cent difference but when we go to pay the supplier in Xero we pay them 1 cent different from their statement. My quick workaround is to add a product called GST error that is exempt GST . This allows our accounts person to add a single product onto a PO for 1 cent to make it balance. The 1 cent is irelevant from a tax perspective but makes the accounts balance. I guess if there was an opportunity to resolve it fully a supplier could have a option to be either form of tax rule but it is a lot of work for a 1 cent rounding difference

Keith

Hi Keith, thank you for your reply.

That is a great work-around, thank you for sharing that!

I suppose the main issue is even if we were to change the way it was calculated on a per supplier basis, the GST calculation would still revert to the Taxable Supply Rule when sent to Xero unless Xero also had the ability to change the method of calculation. Given they are a ‘strict’ accounting package (as they should be), this is unlikely to be changed.

I’m going to work with our documentation team to create an article on this particular issue as it is something which comes up from time to time. Would you mind me including your work-around as one of the suggestions to help others experiencing the same issue?

I’m happy to share any thing like that. Sharing info is how we all get to be clever. Noone has all the answers