GST Worksheet not reflecting correctly

What I think is missing from the discussion is what the target market Manager is for - which I believe is for business people like myself who are good enough with accounting to do invoices, payments and receipts and vat return reports. All the examples illustrated in this topic would be things that I would ask my accountant advice on how to do.

So why not have Manager working as it was before as this would be applicable to the majority of transactions and for those exceptions the accountant who supports that business owner should be advising them on this point!

With all the discussions about the correct way to handle those rare instances I think people have lost sight of the fact that most businesses managers would be asking their accountant.

I don’t worry about tax reporting per se. I am more concerned with financial reporting. My accountant deals with the tax reporting as it were.

Maybe manager could have a review filter that flags transactions that the accountant should review and verify. I don’t know.

@Brucanna

You wrote: The definition of a GST Sale or GST Purchase is based upon, is the GST being received or being paid. It has nothing to do with the financial definition of the sale or the purchase.

This is where I fully disagree with you.
I’ll demonstrate it with an example:

My telephonecompany sends me a monthly bill of € 30.00 excl 21% VAT.
These 12 purchase invoice are booked on telephone expenses for a total of € 360.00
The VAT paid is booked on the VAT account for a total of € 75.60. So far so good.
Because of tax rules I have to make a correction for non-deductable expenses of 25% and I make that correction via a journal-entry being the only possibility.

Debit: Capital withdrawal 25% of (12 x 36,30) equals € 108.90
Credit Telephone expenses 25% of (12 x 30.00) equals € 90.00
Credit VAT-account 25% of (12 x € 6.30) equals € 18.90

The P&L and the Balancesheet show the proper amounts. The GST Worksheet however not.
On the GST worksheet the withdrawal (correction on expenses) appears as a Sale with payable tax of rounded € 18.00.

Here is where I fundamentally disagree with you: I didn’t recieve any VAT. I made a correction on the VAT paid but it is registered as a VAT sale.
As already mentioned before the Dutch taxadministration makes cross-references between reported VAT sales and the reported revenue for income taxes it is now quite clear that we have a difference between these two values. By the way,that was my exemptions to the rule

Kind regards,

Hennie.

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?

I’m pretty sure there could be more examples, when you make sale subject to VAT but it’s posted to balance sheet account, not P&L.

But this is where your processing is not correct. When you post the monthly bill is when you make the necessary adjustment so the monthly transaction is this:

Total Bill 30 + 21% = 36.30
75 % is allocated to telephone expenses, so 22.50 + 21% = 27.23
25 % is allocated directly to the capital, so 9.07

The tax authority doesn’t require you to take up the private usage proportion as business expenses first and then require you to reverse that back out. By using this method you eliminate all VAT Sales implications.

Yes but that exemption has been artificially created by the method of your processing.

Yes it make cross references, but they don’t do exacting reconciliations.

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.

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.

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.

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.

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.

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.

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.

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

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

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.