I installed version 20.2.73 and noticed that when i booked a refund for a purchase (returned goods/cost) that the amount of the refund is calculated as sales income and i beleive it should be calculated under item 5b (less vat refunding) and it is not sales. So all together the end result of the report seems to be ok but the item figures are wrong. Regards TV
Unfortunately this is a long standing design bug in Manager. It corrupts Tax reporting if receipts or payments are used with a negative line item without using Manager’s invoices. Applicable in all jurisdictions where any thing more that VAT sales offset by purchases (ie only the net difference) must be reported see:
or journal entries are used with tax codes see
The underlying issue is Manager guesses if a line item is a sale or purchase based on if it is a credit or a debit rather than using any transaction level information (eg linked to a customer vs supplier, or it is a receipt vs payment, or the user flags it as a sale vs purchase).
Resolution in Manger probably will have to wait for this idea to be implemented but it has been in the ideas category for some time and already has considerable votes
In the interim a cluddgy work around is possible but it involves giving up localizations such as Concept BTW rapport completely.
I created an example purchase invoice and then a debit note, and the result is OK. The units on the debit note are also correctly deducted from stock. But maybe you have done something different? Could you place some screenshots?
BTW, at the end of line 56 of the Concept BTW Aangifte it should be ‘ceil’ i.s.o. ‘floor’, what I already mentioned in another post:
You can easily change it yourself by going to Instellingen > Rapport transformatie
Manager invoices and debit notes both specify via the tab if it is a sales or purchase related line item, so Manager allocates the quantity to the appropriate Vat total.
The problem occurs when cost are allocated via line items in the “Receipts & Purchases” (or “Journal entries”) tab without the transaction being allocated to a Manager sales invoice / purchase invoice / debit note / credit note.
You keep publishing this FALSE and MISLEADING statement.
You have been REPEATLY requested to provide official government documentation to support your assertions and to date you have REPEATLY failed to do so.
WHY - because the documentation don’t exist.
Tax reporting is not being corrupted. What you continually fail to accept is that a Cash Receipt transaction and a Cash Payment transaction are two separate tax transactions even though they may have a relationship. That is, Tax reporting is based on transactions where Tax is Received and where Tax is Paid - it is not based on your perception of Sales and Expenses, because to do so would completely ignore all Balance Sheet transactions.
In closing, Manager is NOT breaking any laws.
The VAT account is what I call a mixed-account. VAT payable and VAT reclaimable are booked on the same account. All credit bookings are recorded as a sale and all debit bookings are recorded as reclaimable.
Let’s take this case.
A customer asks me to purchase for him Product A. I buy this product for € 60,- excl Vat and I sell it to him at € 100,- excl VAT. A couple of days later he returns the product because it is not what he expected it to be. I pay him back the price he paid and subsequently I return the product to my supplier and he pays me back the price I paid. All transactions are cash
This gives the following bookings:
The purchase of the product
Cost of goods sold 60.00
VAT 21% 12.60
@ Cash 72.60
Sale of the product
Cash 121.00
@ Sales 100.00
@ VAT 21.00
Return of the product by the customer
Sales 100.00
VAT 21.00
@ Cash 121.00
Return of the product to the supplier
Cash 72.60
@ VAT 12.60
@ Cost of goods sold 60.00
When I print a P&L sales and cost of goods sold are zero
The VAT report however shows a sales figure of 160 with corresponding VAT payable of 33.60
and it shows a purchase value of 160 with corresponding VAT reclaimable of 33.60
This is wrong. It is because of the mechanism in Manager. It treats all credit bookings on the VAT ledger as a sale and all debit bookings as a purchase.
The Dutch tax administration compares the sales value in the P&L and the sales value in the VAT tax return report. When there is a difference you can expect questions from them.
All accounting software I know, available in the Netherlands, do have two VAT accounts: VAT-Payable and VAT-Reclaimable. Per general ledger account you decide which one of the two applies. That is in my opinion the correct way.
I will send this case to the Dutch Tax Administration and I will aks them to comment in writing whether the mechanics in Manager are correct or that it is wrong.
@Hennie, your example clearly illustrates that Manager is fully compliant with VAT taxation reporting laws, whereas your assumed alternative would be in breach of VAT taxation reporting laws.
First, two things (1) Taxation reporting is not Accounting reporting and (2) a Tax Transaction (which has a single credit or debit) is not an Accounting Transaction (which has both a credit and debit).
Now using your example:
“The VAT report however shows a sales figure of 160 with corresponding VAT payable of 33.60 and it shows a purchase value of 160 with corresponding VAT reclaimable of 33.60”.
This data entered onto the Concept BTW would provide a truthful return as you have fully disclosed the “Tax transactions” that occurred within the reporting period which is the taxpayer’s obligation. The Concept BTW return is reporting taxation transactions, not accounting transactions.
However if we convert the example to the alternative:
The VAT report would show a sales figure of “zero” with corresponding VAT payable of “zero” and it shows a purchase value of “zero” with corresponding VAT reclaimable of “zero”
Then this data entered onto the Concept BTW would create a FALSE return as you wouldn’t be fully disclosing the “Tax transactions” that had occurred within the reporting period and therefore you would be failing in your obligations as you are in effect “hiding” those transactions from the tax authority.
While accounting can have contra outcomes, purchase v’s refund, Taxation can not because it distorts the taxpayer’s obligation to report the gross values of Tax Received and Tax Paid within the reporting period.
In sending to the Dutch Tax Administration, I hope you provide both examples and explanations used above.
Furthermore, this is why @Patch will never be able to provide any official documentation to support his continual false criticism of Manager processes, as tax authorities all over the world require GROSS reporting of tax received and paid. If tax authorities permitted NETT reporting of tax transactions then this opens a Pandora’s box to taxpayer abuse, such as the above ZERO return.
@mark thank you for the reply and my client uses Receipts and Paymentst and does not use the invoice capabilities of manager. I will await what @hennie gets back from the tax department.
I disagree with you. The tax transaction aren’t hidden. All transactions are still recorded and viewable in Manager. In both cases the balance due is zero. the difference is the way the figures are presented.
But let’s wait what the reaction of the Dutch tax authorities will be.
This can take some time before they will respond but we’ll see.
@Hennie When you create an ‘Inventory item’ for the product or service, you get the figures you want:
(The ‘Concept BTW Aangifte’ adapted by me. The original one states 33 in 1a and 5b)
In economic terms: in the end nothing happened.
I bought a product, I sold it, I took it back and I returned it. The way we record it in Manager decides how figures are presented.
When I enter only cash transactions, my P&L shows zero values. When like you did make it a stock item, the P&L shows values. The question is, is that consistent?
Let’s wait what the Dutch tax authorities will answer.
I never stated that the transactions were hidden within Manager, what I did state was this - “in effect “hiding” those transactions from the tax authority”.
That is, when you enter ZERO on the Concept BTW you are conveying / informing the tax authority that NO tax transactions had occurred during the reporting period, where in fact based on your example, four tax transactions had occurred but you aren’t transparently disclosing them so “in effect hiding them from the tax authority”.
The Concept BTW is the legal requirement to report tax transactions, not economic terms.
@Mark I have no idea what transactions you created to achieve that P&L Report.
The selling price is 100 and the cost price was 60.00 therefore after the initial sale the P&L would show Inventory Sales 100 and Inventory Cost 60.
Now if the item was returned / refunded then the P&L would show zero for both accounts. However you have both the Inventory Sales and Inventory cost showing 160, which is a combination of the sale price (100) and the cost price (60). Therefore how did you get the cost price added into Inventory Sales and how did you get the sale price added into Inventory cost ?
-
All tax departments have very specific requirements for a business to claim a Vat credit on a purchase, thus defining what the tax department defines as a VAT purchase for a business.
-
All tax department have very specific requirement for when a business must report vat on sales, thus defining what the tax department defines a Vat sale for a particular business.
-
There is no tax authority which defines a purchase or sale based on if it is entered into an accounting program transaction line item as a credit or a debit.
-
There is no tax authority which supports reporting a different sales or purchase amount based on how the data is entered into an accounting program. Entering a particular physical transaction in Manager via an invoice vs Payment/receipt results in Manager reporting different amounts in official tax department reports. Despite in both cases an identical physical transaction actually occurring outside Manager with identical external supportive documentation.
The only tax authority which supports Managers way is one which does not require reporting of sales or purchases, ie they don’t use Managers corrupted data.
Managers way of allocating sales and purchases was never correct, it was alway just a rough approximation, close enough only it you don’t look at what it is actually doing.
Agree.
There was an attempt to make a sale, the sale failed. In the case described the businesses sales for that period was zero. They have the same stock they started the period with. No customer has one of their products. The sales department spent money trying to sell stock but failed. Failure to make a sale can occur at many stages of the sales process.
In this case the seller was forced to reverse the financial transaction. The seller and purchaser did not reverse roles. For most goods and services in most businesses, the tax department definitions of a vat sale and a Vat purchase do not permit the return of goods to be reported as a new Vat sale in the reverse direction.
What an excellent idea. Lets all do this.
In the UK returns are explicitly required to be entered as negative sales amounts [Withdrawn] How to report EU sales made on or before 31 December 2020 for VAT - GOV.UK
This is exactly what Manger does NOT do in the above example. Manager fails to comply the UK vat law if data is entered via the Receipt/Payment tab.
In contrast a different result is reported if the data for the same transaction is entered as in sales invoice and credit note. Same physical transaction, different reported sales for the month.
And that’s exactly the shortcoming of Manager as it should reflect all the BTW/VAT transactions but it doesn’t do so.
Perhaps a description of the Manager use case would help
-
When a Manager user enters a Receipt or Payment with a tax code that means they are not using Manager to generate the substantiation documentation required in most jurisdiction. By which I mean the Manager user is not using Manager to generate the tax invoice.
-
As a tax invoice is required to be retained in most jurisdiction, that implies the Manager user is using another system to generate the tax invoice.
-
For a Manager user’s purchases the tax invoice is typically generated by their supplier. The document records who is the supplier and who is the customer. That relationship is retained for all line items on the invoice (including any negative line items). The Manager user verifies any other requirements specified for their jurisdiction are met and can attach the externally generated tax invoice to the Receipt/Payment in Manager. The only missing element is the user telling Manager this Receipt/Payment is a Business VAT purchase.
-
Similarly for a Manager user recording a sale in Manager via a Receipt/Payment (not generating a tax invoice in Manager), that implies they are using a point of sale system external to Manger to record sale details and generate the tax invoice. The external POS system records who is the customer and who is the supplier. The Manger user again must ensure all jurisdiction specific requirements for a VAT sale a met, typically via functionality incorporated in to the external POS system. The transaction result can be imported into Manager, such as via bank rules but again the missing element is informing Manager the transaction is a Business VAT sale.
In the above use case the sale vs purchase defining features are specified by transaction details external to Manager and jurisdiction specific legislation. Bank rules can be used to efficiently import the accounting data into Manager, the only missing element is the user / bank rule being able to specify if (external to Manager) the transaction is a VAT sale or VAT purchase.
Currently the work around is to open tabs in Manager for Sales invoice, Purchase invoice, Credit note, and Debit note. Then manually put all transactions with a negative line item through these. Alternatively give up on the localisations, use Receipt/Payment to flag transactions as Sales or Purchases, then manually correct Managers “Tax Summary” and then manually calculate Vat reportable totals.
Okay, I am going to clean up the mess created by users who obviously either don’t understand Manager or don’t understand the application of the GST / VAT taxes.
Firstly @Mark, the reason you ended up with the P&L (160 sales & 160 COS) as you did was because you processed the refund transactions incorrectly. If you had followed the Manager’s Guide on Refunds (Pay a refund | Manager) you would have ended up with a zero P&L as per @Hennie.
Secondly, @patch your various bloated commentaries are absolute garbage on two grounds, firstly it is obvious you haven’t read any GST/VAT Tax Acts and secondly your understanding of Manager is obviously very limited.
The Tax Acts first, if we use the Australian Act (A New Tax System (Goods and Services Tax) Act 1999) you will have the following exact quotations:
Note how the act refers to “taxable supplies” not sales and “input tax credits” not purchases. That is how I knew your repetitive references to sales and purchases in your commentary was garbage, that is, it wasn’t Tax Act based.
Now to further expand upon the notion of taxable supply (not sales):
Why the term supplies instead of sales, because supplies includes Balance Sheet transactions (asset purchases) whereas sales by terminology is limiting to P&L. To illustrate in accordance with the Act; the seller is suppling and the purchaser is being supplied regardless of the accounting outcome, be it a BS or P&L transaction.
Now for input tax credits, note again how there is no references to “purchases”
The above citations are generally equal across all GST / VAT Acts, especially as the Australian GST Act is broadly based upon the European VAT Acts, which came first.
@patch this is the type of Tax Act substantiation that you failed to deliver to support your false and malicious allegations against Manager’s handling and reporting of taxation.
Furthermore @Patch if you as a User had understood and applied the applicable Manager’s Guide for Refund Transactions to your phone example then you wouldn’t have resorted to your repetitive claims that Manager had corrupt taxation reporting
In addition, you have repetitively accused Manager within post #15 with the following allegation “When a Manager user enters a Receipt or Payment with a tax code that means they are not using Manager to generate the substantiation documentation required in most jurisdiction. By which I mean the Manager user is not using Manager to generate the tax invoice.”
This once again informs the forum of your naivety and ignorance of the features within the programme. If you had bothered to review the Receipts and Payments form you will have noted the option 
, this enables the user to rename the Cash Receipt to be anything, such as Tax Receipt or Tax Invoice or any other title required as substantiation documentation by the jurisdiction.
In closing, Manager isn’t responsible for users who can’t use the programme in accordance with the Guides and furthermore Users shouldn’t abuse and make defamatory comments about the programme because of the their incompetence to follow the Guides.