GST Worksheet not reflecting correctly

51

I agreed with everything that you wrote in your most recent post in this thread except for this part. The previous model does not always report VAT/GST correctly and this is why some other mechanism needs to be implemented for occasions where it is reporting incorrectly.

For example the previous model is incorrect when a sale includes some sort of promotion or discount which reduces the total sales revenue on the invoice. This should be accounted for in the sales section of the GST reports.

Another example where the previous model is correct is when a purchase invoice for purchase of a car that includes a reduction for a trade in vehicle. This would correctly report the cost of the new car as a purchase and the trade in as sale on the GST reports under the previous model.

The current model also has one of these examples correct and one incorrect. That is: the opposing examples.

The reason that I see the use of an editable S(sale)/P(purchase) field on each line is that the software already makes this delineation in the background no matter whether the current or previous model is being used (including separate entries to the tax payable account for each line). So, why not make this delineation visible and editable on each line.

52

So why it would be wrong for P&L accounts?

For balance sheet accounts, I agree, but consider this topic…

I’m not sure where this will ultimately lead but there could be a way to differentiate in the future.

53

Unfortunately, that is the misconception because the financial reporting and the Tax reporting aren’t being differentiated - particularly under a single tax code concept such as Manager’s

Let say a product is for sale for 100.
The business runs a 20%, sale. In this case the product is being marked down, so that is reduced financial sales and tax sales.
However, if the business offers a 10% loyalty discount, then the financial sale is 90, however the tax sale is 100 and the tax purchase is 10. The discount is an expense of doing business.

Expenses can’t be Tax Sales. Same with any other promotional activity where the business incurs an actual cost. Therefore the previous model (every credit is sale, every debit is purchase) was not broken or flawed.

The previous model has always functioned without any difficulty for 6 or more years, but has only recently become an issue since certain users have attempted to force their financial reporting narrative upon Manager’s tax reporting. The point that has been regularly missed, is that, those users could have always done their tax reporting as they required by editing the worksheet to suit their required Tax Return lodgement, not by having all other users being impacted.

Manager only has to address the Tax Authority requirements, not individual interruptions of those requirement.

Because a P&L account could have either a Tax Sale or Tax Purchase posted to it.

One possible solution is that Manager moves from a single combination tax code to a dual tax code, then the accounting software doesn’t have to be involved with any User decisions.

54

Technically yes, but practically don’t think so unless you can think of some examples.

That’s what I’m currently leaning to. I don’t think Manager automatically separating sales and purchases is that useful after all. Mostly because even if it could separate sales and purchases to everybody’s satisfaction, we still end up with duplicate tax codes with the same rate elsewhere.

For example, in Australia there are 3 reasons for sale being GST 0% - thus 3 tax codes with 0% tax rate (GST free sales, GST free export sales and input-taxed sales). In Europe, there are also multiple reasons why sale is VAT free and these reasons need to be tracked separately - thus tax code for each. UK has VAT Exempt, VAT 0% and VAT 0% (EU). The Netherlands has even more.

So this attempt to reduce number of tax codes is proving to be futile because it’s not just sales vs purchases. And therefore for the sake of simplicity and transparency, tax codes should simply match government reporting requirements.

55

In theory, you are right, but I have some customers who do their own accounting in Manager. Once a year, mostly in January, I check their accounts and make necessary corrections. I can’t correct the 12 invoices because then their VAT taxreturns are no longer in line with Manager so the jounal-entry is the only option. Infortunately it is day to day practice.

@Lubos
You wrote: “I want to ask about this cross-checking…How does it actually work? What if you sell fixed asset? The entire sale amount will not be shown on P&L. Only gain or loss which is usually different from the sale amount. How does government cross-references this?”.

They don’t have the possibility for an exact cross-reference, but on your income-tax return form you have to supply so much details about investments and disposals that they can make a quite accurate grade-assesment. In that way they can get a fairly right opinion about the validity of figures shown.
In case of doubts they will/can ask for more detailed information.

56

That is an excellent idea.
There are multiple requirement which must be met to for a business to legally claim a VAT credit for a purchase. Similarly there are multiple legal responsibilities which must be fulfilled when a business charges VAT. It does not just depend on the sign of a line item or any other statistically associated property in Manager.

With that direction from your accountant you can then enter the transactions in Manager. For cash Sales, receipts now behave identically to sale invoices. Similarly for cash purchases, payments now behave identically to purchase invoices. Significantly increasing Managers consistency and decreasing inadvertent user error.

I agree.
Your example is very similar to the following Private vehicle use - worked example And the journal entry has the same limitation. I’m not sure why you should have to justify using a journal entry to make a correction in any particular case, as that is the key function of journal entries.

The solution is to explicitly specify sale/purchase status either at the transaction or line item level. What is best depends on the degree of flexibility and functionality envision for journal entries in particular if future linkage to a customer or supplier should later be available at the transaction or line item level See Inconsistency in Tax-reporting - #20 by Patch

The current work around is to use zero valued invoices See Zero-amount invoices not posted to cash-basis general ledger Although now a dummy bank account with zero valued receipts and payment could also be used.

Manager program design options

Manager design currently assigns sale/purchase status based on the transaction type being entered. Sales invoices and related effect VAT sales. Purchase invoices and related transactions effect VAT purchases. A clear and predictable system minimizing user inadvertent error and ideal for the majority or users and their transactions. This maximizes data entry efficiency for the majority of users, but not all users.

Counter trade transactions

Counter trade transactions have a sales and purchase component. When using Managers invoice facility this has required entering the other party as both a customer and supplier, issuing a purchase invoice and a sales invoice, then a payment/receipt with line items to accounts receivable and accounts payable. A cash counter trade transaction is entered by a similar but simpler procedure; Enter the sales component in a receipt, the purchase component as a payment (readily done by opening a second browser window so both payment and receipt can be simultaneously entered).

Manager could offer enhanced support for counter trade transactions for both cash and invoice transaction by having transaction level support for counter trade transactions, this would make explicit the two transactions with greater data entry efficiency than the alternate line item level specification of sale/purchase see GST Worksheet not reflecting correctly - #43 by Patch .

Negative Sales and Negative purchase VAT transactions

Negative sales line items do occur in a sales transaction. As can negative purchase line items in a purchase transaction. Examples are discounts / inducements, returns / refunds, and currency conversion adjustments.

Using invoices, debit notes and credit notes these are readily processed in Manager. All result in a negative adjustment, including returns, refunds, discount line items and the examples give above. This processing approach is legally required See [Withdrawn] How to report EU sales made on or before 31 December 2020 for VAT - GOV.UK

Using Receipts and payment it is now possible to do the same thing for cash sales in a virtually identical manner to how invoices function. In contrast in the past it had been impossible to use cash transactions (receipts or payments) to replicate how Managers correctly processes invoice.

In another universe there could be a society where negative value sales or purchase entries were impossible. If that were the case then, Managers processing of invoices would be a bug.

57

I understand your situation clearly but there seems to be a contradiction with regards to your concerns about the correctness of VAT returns.

1 - You are concerned that your Journal Entry is not reflecting correctly - Sales instead of Purchases.
2 - You are NOT concerned that your customers are submitting incorrect VAT Returns by claiming VAT refunds for private usage which you are subsequently fixing with your Journal.

Therefore, if submitting correct VAT returns is your focus (such as with the Journal) then why not address the source of the problem - your customer’s original entry of the transaction.

For myself, I would be providing the customer with a template of the required entry, which would then eliminate the requirement for the Journal which doesn’t reflect correctly.
.
At any other time, we could be discussing this over one at La Trappe.

Because, by understanding the justification for the Journal, one can then review it’s validity.

Actually, by fixing the transaction at it’s source, one doesn’t need to waste time creating a work around.

This is a circular reference, as the topic you are referencing is the exact same topic which you have posted it in.

58

I hold you to that. :beers: :smiley:

59

Perhaps when the future allows we could have a “Dutch Manager’s Convention”
Venue: La Trappe - Agenda: Witte, Blond, Dubbel, Tripel, Quadrupel

60

Accepted and agreed but with a good lunch.

61

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.

62

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?

63

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

64

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.

65

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
66

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.

67

@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.

68

@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.

69

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.

70

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 %}