GST Worksheet not reflecting correctly

Accepted and agreed but with a good lunch.

The latest version (20.8.67) is reversing back to debit/credit scheme to determine whether transaction is a sale or purchase.

This is not something I’ve intended to do but it’s a side-effect of making reverse charged tax codes to appear in general ledger correctly. Reverse charged tax code is an example of “mixed” transaction where single transaction is both sale and purchase at the same time.

Oh, we are back to different behaviour for cash vs invoice transaction.

Does that mean the recommended work around for users who have negative amount sale or purchase line items is to create dedicated tax codes and edit the report transformations themselves?

@Patch Definitely not. I need to think this through though.

With the prior way, the work around for users with counter transaction was the same as users with invoice counter transaction ie enter a purchase and sales document. Not ideal but consistent with Managers behaviour elsewhere.

In contrast there is no user work around for v20.8.67 where a user has a negative amount cash sale or purchase entry.

Please take care.

I think you will find you are miss interpreting the majority. It is more likely the majority assume an accounting program gets tax accounting accurate for them when processing transactions the recommended way.

Most users will care a lot if either method produces results which are different, particularly it they are wrong for their use case.

THANK YOU especially on behalf of all those Users who have Recipient Created Tax Invoices.

That is why the old, now current scheme is superior. The accounting for “sale and purchase at the same time” as a single transaction had always existed prior to the introduction of Levy taxes, therefore the accounting for those transactions shouldn’t be forced to change after the introduction of Levy taxes, as those taxes are only an ADD-ON to the transaction.

I just wish you would STOP promoting that the difference between cash v’s invoice is somehow wrong behaviour - IT IS NOT. Levy Reporting is about the ACTUAL receipt and payment of the Levy, it is not about the accounting transaction’s posting.

That difference in behaviour, which was clearly explained in the topic “Levy Taxes - an Introduction” is how it was designed to be when I was a member of GST implementation teams, which in turn, is strongly based upon the European VAT model.

Users who have negative amount sale or purchase don’t require a work around.

Exactly true, that is why Lubos had to revert back to the CORRECT model so he could make “reverse charged tax codes to appear in general ledger correctly” - that is (in your words) “gets tax accounting accurate”.

2 Likes

Sorry to say, but at least not for the users who want to make use of the “famous” Concept BTW Aangifte.
I think it’s better to warn those users that by making a credit note (sales) or debet note (purchase) or journal entries like @Hennie has described, the figures mentioned in the Concept BTW Aangifte are useless.

I can give you an example where Concept BTW Aangifte says I have to pay taxes (which is not right), whereas the standard tax reports and the general ledger tells me I can claim BTW (which is right).

Until @lubos comes up with a solution to this problem, I implement extra tax codes with corresponding accounts. Like, among others, tax code [VAT 21% Sales] linked to general ledger account [VAT 21% to be paid] and tax code [VAT 21% Purchase] linked to general ledger account [VAT 21% to claim].

Indeed, extra tax codes means more chances bookings go wrong, which burdens the control mechanism.
(It would be nice if the user could determine the order of which the tax codes are shown in the program when making sales and purchase invoices and journal entries).

So until solution is found, I don’t make use of Concept BTW Aangifte anymore, but I am using the standard tax-reports to complete the tax form.
Maybe [Custom Reports] can be helpfull in near future.

@Ries, I agree with you.
This has all to do with the fact that the VAT-mechanism in Manager treats every credit entry as a “sale” and every debit entry as a “purchase”. This is per definition wrong. A creditnote is a negative sale and a debitnote is a negative purchase. In the P&L it is shown correctly but not n VAT-reports. @Lubos is aware of this. As long as the mechanism isn’t changed by @LUbos, we have to deal with this ommision as well as with the problems with journal entries where you can have negative VAT entries as per the examples I have given on this forum.
Anyway I am glad that “reverse charged VAT” is now working fine, but there is still some work to do to have a correct VAT mechanism. I sincerely hope that @Lubos will solve this in very due course as there are in the time between a lot of threads on this forum about this problem.

@ries there is going to be new set of tax codes and new Concept BTW Aangifte report for Netherlands by end of this week.

During transition period, there will be two versions of Concept BTW Aangifte until we can all settle on new one.

Lubos

  • Managing the transition is probably just as complicated as defining the final solution.

  • If Manager is eventually going to have independent tax codes for sales and purchases, then ideally a script would be run which converts dual function tax codes to single function tax codes for each line item. Using the assignment Manager has been using for the longest time would be best as that would minimize program changes to old reports (of benefit to other users & I can adapt to any true solution).

  • I have serious reservation moving forward with Manager using a different method in invoiced compared to cash transaction to determine sales / purchase assignment. Doing so deceives most users.

Good job. Now that you’re at it, please consider changing lines 55 and 56 to:

  • {% assign 5a_omzetbelasting = 1a_omzetbelasting | plus: 1b_omzetbelasting | plus: 1d_omzetbelasting | plus: 2a_omzetbelasting | plus: 4a_omzetbelasting | plus: 4b_omzetbelasting | floor %}

  • {% assign 5b_omzetbelasting = taxOnPurchases[BTW_6] | plus: taxOnPurchases[BTW_9] | plus: taxOnPurchases[BTW_21] | plus: 2a_omzetbelasting | plus: 4a_omzetbelasting | plus: 4b_omzetbelasting | ceil %}

I maybe asking something obvious, but can someone write a summary post about what actually is now the default behavior in Mangager, what has changed, or not… etc.?

With Manager versions v20.7.30 - V20.8.66 “Cash” transactions were handled in an identical manner to invoice transactions.

With Manager versions prior about v20.7.30 after v20.8.67 cash transactions depend on if the line item is a credit or debit but invoice transactions depend on if the invoice is a sale or purchase invoice.

The effect of which is summarized below

Invoice transaction behavior

Manager versions All existing Proposed
Tax codes Both sale & purchase Only sale or purchase
Sale purchase assignment Sale invoices are sales, Purchase invoices are purchases Dependent on tax code type
Sales Invoice line items all sales Line items with Sales Tax code are sales. Line items with purchase tax code are a purchase counter trade
Purchase invoice line items all purchases Line items with Purchase Tax code are Purchases. Line items with sales tax code are a sales counter trade.
How counter trade is entered Requires 2 documents Enter other party as supplier and customer. Enter purchase & sale invoice Enter sale component with sales tax codes, purchase component with purchase tax codes
How negative amount line item is entered Direct entry on a line of appropriate invoice type Direct entry on a line of appropriate tax code type

Cash transaction behavior

Property Prior about v20.7.30 after v20.8.67 About v20.7.30 - V20.8.66 Proposed
Tax codes Both sale & purchase Both sale & purchase Only sale or purchase
Sale purchase assignment Credits are sales, debits are purchases Receipts are sales, payments are purchases Dependent on tax code type
Cash Sales Credit line items on receipt or purchase line item on a receipt Line items with Sales Tax code are sales. Line items with purchase tax code are a purchase counter trade
Cash Purchase Debit line items on receipt or purchase line items on a payment Line items with Purchase Tax code are Purchases. Line items with sales tax code are a sales counter trade.
How counter trade is entered Enter counter sale a credit or counter purchase as a debit Requires 2 documents Enter purchase as a payment & sale as a receipt Enter sale component with sales tax codes, purchase component with purchase tax codes
How negative amount sale or purchase line item item is entered No user method, requires created contra tax codes & editing report transformation Direct entry on a line of appropriate payment or receipt Direct entry on a line of appropriate tax code type

Note

With the proposed use of different tax codes for sales and purchases there will be more tax codes, but not double as only those needed for a jurisdictions reports will be created. Manager user interface can be optimized to facilitate the most likely tax code selection. As a result tax code menus will not be twice as long.

The most likely tax codes (sale or purchase) can be put at the top of the menus and the other type put in a sub menu at the bottom. Alternatively an invoice (or payment/receipt) could have an option to open a counter trade section where the alternative tax codes could be selected.

1 Like

Are we supposed to implement this on our own or something is being rolled out within Manager?

@novica I don’t fully understand this topic and exactly what transactions are affected. But my understanding is that 99% of the entries in Manager are not affected - regardless of which method Manager is using. The reason being that most sales are credits and most purchases are debits and likewise those same entries on sales invoice are sales and those same entries on a purchase invoice are purchases.

The problem has been very specific entries where a supplier is a customer or vice versa as well and/or something about levies as well as negative sales and negative purchases (basically when you refund I presume?). Neither of these are relevant to nearly all entries in Manager for most businesses.

So I speak under correction, but I believe that nothing will change for most users. But I am not entirely clear on this point as so many of the examples raised are not examples of accounting that I would ever use. I don’t really understand the difference between financial and tax reporting which seems to be the cause of all the problems.

So I am admittedly unclear as to whether these changes will affect most users or not, but my impression is no based on what I have read and understood. Not being a charted accountant myself I can’t say for sure though.

What I believe is proposed is that Manager will continue to use a single tax code for the vast majority of transactions and add additional (but not double) tax codes for those specific entries which seem to require a different approach. Although how end users like myself will know which entries fall into this category is way above my understanding. So I would have to rely on my accountant for that support.

Then the creation of the “Concept BTW Aangifte” report itself is the problem and not the tax code model. Let me illustrate: first with a sales invoice, then with a credit note plus the tax reports.

Therefore, if the “Concept BTW Aangifte” is not showing that result, then the construction of that report is wrong, not that the tax model is in correct.

So as I originally stated “Users who have negative amount sale (credit note) or purchase (debit note) don’t require a work around”. But perhaps the reports which are built from those transactions aren’t representing the transactions correctly.

This is not true, refer to above examples where the credit note (a debit entry) appears as a negative Sale. However, it appears, based on @ries comments, that the “Concept BTW Aangifte” report itself is not translating those credit notes as negative sales. Now to illustrate that point, lets compare those same transactions with the Australian equivalent report - the GST Worksheet - before and after the credit note:

Everything is being handled correctly, so this emphasizes that the problem facing Dutch Users is within the “Concept BTW Aangifte” report itself, not the tax model, which is further confirmed by @ries comment “I don’t make use of Concept BTW Aangifte anymore, but I am using the standard tax-reports to complete the tax form”.

On this I can concur and in the topic “Levy Taxes - an introduction to” I highlighted this with:
“Journal Entries are a “real” issue, however that could be addressed by having a mandatory dialog dropdown with these three selections - Sales, Purchases, Financial. The data entry lines would only appear after the selection had been made and for Financial, no Tax Code fields would be displayed.”

Thank you for finally confirming that the old, now current, model - “would be best”.

Definitely not. Please don’t get suck into the irrelevant distraction between invoice and cash transaction behaviour. Levy reporting is based on law, not accounting software behaviour as some would have you believe.

Financial reporting is Income v’s Expenses whereas Tax reporting is, in your case, Vat received v’s Vat paid.

@Brucanna You somehow manage to get these figures, which look normal, all is Sales:

Why do I get these figures:



Where the amount of euro 150,- reflects a purchase invoice, so correct.

Where the amount of euro 200,- reflects a sales invoice, so correct.

Where the amount of euro 10,- reflects a credit note of sales, made by the system Tab Credit Notes,so not correct, as it is in the column [Net Purchases] and should be in [Sales] with a negative amount.

Where the amount of euro 50,- reflects a credit note of sales, made as a negative sales invoice, so not correct, as it is in the column [Net Purchases] and should be in [Sales] with a negative amount.

Is it because I am a Cheesehead… :crazy_face: or do you have a solid explanation?

This is what I was referring to. When I do a sales or purchase invoice, I just put in the inventory item and vat etc. I have no idea what the difference between financial and tax reporting is in this context of creating purchase and sales invoices.

I’m closing this topic because I think I came up with the solution to retain dual purpose of tax codes and at the same time made it possible to provide enough information about transactions to determine whether tax transaction is a sale or purchase.

See: