I fall into the category that I couldn’t care less about which method is best as long as it doesn’t affect my VAT return amounts that I send to HMRC. Perhaps I misunderstood the topic but I thought that the whole issue is that the changes do affect the VAT/GST return value that one sends to the taxman making previous tax returns inaccurate. I am ready to be corrected on that point.
All the changes being discussed have no effect on “Tax liability” reported in the “Tax Summary” or report transformations of this. Similarly in the “Tax reconciliation” there is no change in the “Total”.
The issues being discussed do effect the break down of sales and purchases in both reports.
If the later actually effects you, you will need to decide if you are most concerned about
- If your reports reflect your understanding of the transactions your business has been involved with, ie are the numbers correct in past or future reports.
- Or are you most concerned that the numbers a different.
As the solutions are different for these 2 issues. The later is solved by some form of backup / archiving. The former by understanding what you believe the numbers should actually show.
Thanks for your reaction in this topic.
As Manager is a professional tool, It should work as a professional tool, which means that it should calculate VAT the proper way, even if this means that complexity could increase. As a matter of fact Manager.io is not a toy. If people start using Manager.io not having any clue what accounting is, it is a pity for them. I sincerely hope @Lubos will come up with a new model which takes away and eliminates the current ommission.
The issues being discussed do effect the break down of sales and purchases in both reports.
Does anyone knows what the appropriate IFRS says about issues like these?
Pretty sure this would be out of scope for IFRS since none of this affects standard financial statements.
The problem with this example is that the second line is using the wrong Account.
The promotional buy is NOT a reduction in total sales but a marketing expense, hence the debit.
In effect, the business is “purchasing” the third pair on behalf of the customer.
.
What if the promotion was buy 3 and get cash back for one.
The total sales would still have been $360, and the marketing expense $120 would have been a purchase (debit) when the cash back was paid. The cash back does not reduce total sales.
Once again, the business is in effect “purchasing” the third pair on behalf of the customer.
The accounting result (income $360 expenses $120) doesn’t change just because the transactions were conducted differently,
Therefore “Under previous model, this would result in $360 in total sales and $120 in total purchases (because every credit is sale, every debit is purchase)” was totally correct.
And furthermore why “Under current model, this very same transaction will result in $240 in total sales (because every line item on receipt is a sale)” is totally incorrect because you can have genuine line items that are purchases on a receipt, nothing to do with sales.
Take this example of a Livestock sale, where the Stock Agent sends you the sale proceeds.
Now “Under previous model, this would have resulted in $4800 in total sales and $426 in total purchases (because every credit is sale, every debit is purchase)” which is totally correct
However "Under current model, this very same transaction will result in $4374 in total sales (because every line item on receipt is a sale) which is totally wrong.
Now lets review the BAS lodgement perspective. In the March quarter under the previous model I would have reported Sales as $4800 and purchases as $426 which accurately reflected the nature of the transactions. However the June quarter under the current model I would have reported Sales $4374 and purchases as $0 which inaccurately reflects the nature of the transactions.
Furthermore, as a Taxpayer I am NOT going to start reporting genuine purchases as negative sales therefore the current model worksheet, for a Livestock Producer, has become totally USELESS as it doesn’t contain one accurate value, which was not the case previously.
This model change doesn’t just affected the Livestock Producer, it also affects all these other industries, Property Rentals, Produce Markets, Auction Houses, Publication Distributors plus many others, where ever Recipient Created Invoices are used as they ALWAYS contain both sales and genuine purchase line items - not negative sales items.
I don’t understand why Manager has to do anything for any particular user group. The previous model produced by Manager had a solid uniform basis (every credit is sale, every debit is purchase) and where ever a User had a transaction which didn’t suit this basic model, then the User always has the freedom to make amendments to the worksheet so that it correctly reflected their position / interruption with regards to those transactions. The worksheet is just that a worksheet and Manager just has to educate Users to that fact and not attempt to manipulate the basic worksheet into something to suit every possible User because it will just becomes to complicated / cumbersome.
It appears, in my opinion but I could be wrong, that Manager could be reacting to the promoted falsehood (in fact stupidity) that a single transaction can’t be both a sale and a purchase at the same time. All the examples above clearly prove that to be wrong.
1 Like
And this is a great example.
When users use manager that way and it currently works, and other users have adapted to it being that way, then if you decide that it should now work “the other way”, you must expect there will be problems.
You shouldn’t make changes to the underlying fundamentals that users rely on. @Brucanna’s example above classically illustrates this.
Fundamentally you have changed what manager reports to users, which they invariably report to their accountant/tax authorities.
I posted about similar issues in the past with RCTI type entries.
I know a single vat/GST code would be nice. But perhaps it’s time to ask why other products have multiple tax codes. Perhaps they got it right and there is a reason for it.
I’m not suggesting that you blindly copy other products. But sometimes we can learn from others mistakes and successes.
After a lot of struggles I now enter a sale, a purchase and then a single receive money entry ( with positive amount against the sake and a negative amount against the purchase. Much more effort but it does seem to report correctly in manager.
Note you need two copies of the 3rd party. One as a customer and one as a supplier.
Further to my previous post, at the time the reporting engine reported against a receipt or payment entry (but could not report per line item). This made things difficult to report. Not sure if that has changed.
In some jurisdictions, the supply of goods on a buy one, get one free etc is not considered a gift and would bot be treated as shown above
It shouldn’t matter if you use the single code tax or the multiple tax code, the results are the same as long as the principle - every credit is sale, every debit is purchase - is maintained.
However when that principle is broken - “every line item on receipt is a sale” - then you have created a complete disconnect between the single tax code and the multiple tax codes approaches.
The above examples are reproduced below adopting the multiple tax code with principle:
The above examples are now reproduced below adopting the multiple tax code, but broken principle:
The broken principle has converted all expenses into negative sales.
The minor advantages of the multiple tax code are these.
- A User could toggle between GST Sales / GST Purchases tax codes, if the transaction required a particular code allocation, whereas with Manager’s single code the User has to edit the worksheet to achieve the same result.
- With Journal Entries each line can be assigned a tax code which suits the transaction regardless of it being a debit or credit.
In my view Manager had it almost 100% perfect with the previous model, and where Users had a difficulty, it had more to with Users trying to force their tax reporting transaction to match their accounting transaction when in effect there was no matching to be done because they didn’t understand the difference between financial reporting and tax reporting - unfortunately most of that misunderstanding was promoted by accountants, who in fact should have known better.
For myself, nearly a third of my receipts are Recipient Created Tax Invoices and Manager has unnecessarily imposed upon me a very difficult situation. Fortunately I had completed my June quarter / year end worksheets before this arose.
Sadly, but so very true.
Actually no.
Both IFRS and IAS specify that you have to present the sales net of discounts. Sections IAS 18.7 and IFRS 15.47.
I know the current model falls apart when you have a transaction which is mixing both sales and purchases. Previous model falls apart when credit is not a sale and debit is not a purchase. Both models are flawed. I know this is a problem.
One solution is that line item would be determined whether it’s a sale or purchase based on the account being used. I think that would bring us closer to the solution which would satisfy both sides.
1 Like
Maybe, but I can see that this solution would force users to create different accounts and restrict the way they report some items. (e.g. discounts as negative contra amounts in income(sales)/expenses(purchases).
Am I missing something here? Would not the best solution be to add an extra 2 option field to each line (S(for sale) and P(for purchase)? This field could default to S for sales invoices, credit notes and receipts, and default to P for purchase invoices, debit notes and Payments. In a journal default to P for debit and S for credit. The user could then have the option to change the default if desired.
This way the current criteria is maintained but gives the knowledgeable user more flexibility without compromising the simplicity, too much, for the less knowledgeable and indifferent users.
There is a fundamental difference between an ordinary invoice and an invoice describing a barter or countertrade transaction.
Ordinary sales or purchase invoice
In on ordinary invoice the sales / purchase status applies to all line items ie the seller and purchaser are the same for all line items. For ordinary invoices the value of individual line items can be artificially modified provided the overall transaction is consistent with a fair market value as adequately reflecting the money value or arm’s length value. For example when a seller offers a item at a discount price the “official” price can be inflated and an artificial discount shown however the overall pricing still fulfills the fair market value requirement. Similar an bonus linked to volume or the sale can be offered. The discount or bonus line item is typically not offered at a fair market value, an accepted practice provided the overall transaction is at fair market value.
Counter trade invoice
In contrast when a barter or countertrade transaction occurs then there is actually two underlying conventional transactions. Both must independently satisfy the fair market value as adequately reflecting the money value or arm’s length value requirement.
From ATO Bartering and trade exchanges
As a general rule, when valuing the payment arising from barter or countertrade transactions, we will accept a fair market value as adequately reflecting the money value or arm’s length value, as applicable.
…
Transactions where the values are set at artificially high levels for the purpose of establishing an inflated income tax deduction may indicate fraudulent activity. Parties to transactions that involve inflated credit unit values may have consequences other than an adjustment to the amount of income returned or the amount of income tax deductions claimed.Personal purchases are not deductible for income tax purposes and a GST credit cannot be claimed, whether the purchase is made using trade dollars or Australian currency.
Some simple examples of which are:
Buying a new car and trading in the old vehicle. Assuming the new car’s true market value is $60,000 and the old car has a true market value of $20,000, and a change over price of $40,000 is offered. Assume also the old car has been almost fully depreciated with say a book value of $1. The countertrade invoice could be written as shown below however option 2 is fraud despite having the correct total.
- New car purchase $60,000 minus old car trade in $20,000, Total owing $40,000
- New car purchase $40,001 minus old car trade in $1, Total owing $40,000
Another example, is buying an item and paying for it partly in money and partly via a perk. For example a business could buy an air conditioning system (value $22,500) and negotiate a $2,500 discount for providing a free week stay at the business owners holiday house valued at $5,000 (or other tradable goods or services). The countertrade invoice could be written as shown below however options 1 & 2 are fraud as it fails the fair market value test.
- New air conditioner $20,000 minus $0 One week at holiday house Total $20,000
- New air conditioner $25,000 minus $5,000 for one week at holiday house Total $20,000
- New air conditioner $22,500 minus $2,500 for one week at holiday house Total $20,000
The definition for a barter or countertrade transaction, VAT sale, and VAT purchase also means a line item in a transaction can not be arbitrarily swapped between being a sale or purchase as in many cases doing so will violate other requirement associated with the sale / purchase.
Managers Design
-
Managers current design ensures both the component of a counter trade invoice are explicitly shown, highlighting the difference between ordinary and counter trade transactions.
-
Moving forward, any proposed change should function throughout Manager, not just as side effect of sale / purchase determination in receipts / payments
-
For the majority of businesses which do not routinely perform counter trade transactions, the current design is optimal. So in my opinion supporting counter trade transactions should be an option switched off by default, consistent with Managers design philosophy elsewhere.
Don’t know if anyone has thought to look at other accounting programs and see if anyone else has resolved this issue in such a way that you don’t need multiple tax codes but everything works as it should.
Or perhaps all of them use multiple tax codes because there is no other way to get it right every single time?. My opinion is - don’t re-invent the wheel - maybe somebody else has solved this riddle and it would be worth looking at other accounting programs specifically the modern or less known ones like xero, Adminsoft Accounting or quickfile as they may have come up with a different way of resolving this.
I think from what I have read, sticking with debit/credit as the mechanism is better than using receipt/payment forms. Basically what Brucanna said in one of his posts.
I think we all agree that the majority of the credit entries on the VAT account come from sales and the majority of debit entries come from purchases. But there is also, like always, the exemption to the rule and that is where problems arise…
A solution could be that the user gets an option where he can change the standard behaviour for a particular entry in case this could lead to a mistake in proper VAT registration.
Maybe my idea helps Lubos to find a solution.
Several approaches can be used to guess how a user will require line items in a cash purchase or sale (payment / receipt) to be classified in terms of purchase/sale. The aim should be to have a system which can be used to achieve all user’s Legal transactions, Including when using Manager’s invoices. The system should facilitate the transactions done be most users but enable extensions for the requirements of some users.
To support purchase line items on a sales invoice some form of optional line item sales/purchase specification is required. Similarly for sales line item on a purchase invoice. In my opinion this should be a option a business can enable if they use counter trade invoices.
Using expense account would not work for balance sheet accounts and some profit/loss transactions and doesn’t address Manager’s invoices.
Using credit debit does not work for negative Sales line items in a sales invoice or negative purchase line items in a purchase invoice. Examples of which are returns, discount line items and 50% of currency fluctuation adjustments. It is wrong in about 50% of Journal correction entries. It doesn’t address non cash transactions (Sales or purchase invoice entered into Manager). Most importantly many users are likely to make inadvertent errors in classification as they are confused be what is a credit/debit or how Manager would classify the line item they are entering.
As an example of how complicated it could get, Sage Accounts have customised VAT tax codes for Ireland - we have 5 VAT rates: Standard Rate, Reduced Rate, 2nd Reduced Rate, Zero Rate and Livestock Rate
In order to properly categorise VAT payments they have a set of 38 tax codes to cover purchases, imports, etc etc and to produce the required VAT returns
Admittedly not all businesses will use all the codes but all the codes are required to correctly account for VAT calculations and VAT reporting.
You knows how many of the VAT codes are used correctly or incorrectly?
So trying to create a simple system that meets all requirement is probably not on and the best that can be done is to have a system that covers 80% or 85% of the businesses that use Manager
Actually there is another way.
Transactions could have an option / check box to specify it is a counter trade (purchase invoice, sales invoice, cash sale, cash purchase). In each case a (second) counter trade section would be opened where all line have reversed sale/ purchase status. This could be enhanced by showing sub totals when multiple line items are added to either section.
Hence my suggestion of looking at other accounting programs to see how they handle this issue without using multiple tax codes. Maybe one of them have come up with the perfect solution!