@dalacor as far as I know, all the programs which can separate tax transactions into tax sales & tax purchases are simply using separate tax codes.
@Patch if it comes to that, I’d rather have more tax codes than adding extra fields capturing the same information.
I don’t know so much about GST but in Italy, the land of burocracy, we have a solution in localized softwares achieved by adding an “extra layer” over taxes that overrides some or all the setting only if selected.
Think of this layer as a group of taxes. Each group can contain different or shared (with other groups) taxes.
If you select a tax group besides the tax code the settings that were set in it will override some/all the settings of the tax. If you don’t, everything will work as before.
If you then add a extra settings inside tax code (and consequently inside tax group) to decide, only if you need it, if it is only a tax receivable or payable the job is done.
In this way:
It is something very similar to how user groups and users works under Windows and Linux.
Let me know if it is of your interest and you want to deepen this argument… I can do some mockup to explain it better.
How it is achieved is not my concern. I would like to see Manager cleanly handle the range of transactions performed, fulfill reporting requirements, and preserve the intuitive interface Manager has.
I probably did not describe what I was envisioning clearly. Below is a mock up for a Sales invoice or Receipt with the suggested “Counter trade exchange” option checked. The equivalent screen for a Purchase invoice or Payment would be identical except the new “Sales” and “Purchases” labels would be reversed. Un-checking the “Counter trade exchange” option would result in the current layout.
Think for example if you have 10 tax codes (in Italy we have even more!) and you want to have them differentiate from receivable an payable. With the tax group you will have to create 10 tax codes + 2 groups instead of 20 tax codes
Perhaps, but that is for Financial Reporting. But Financial Reporting and Tax (GST & VAT) Reporting are not the same thing.
The previous model did not fall apart While the credit may not have been a financial Sale, it is always a GST Sale as the credit implies that GST is being received. Vice versa for debits.
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.
Manager’s previous model had the Tax (GST/VAT) reporting absolutely 100% correct in accordance with any Tax Authority’s requirements and that is the only standard which Manager should be meeting. Instead it appears that Manager is currently attempting to have the Tax reporting in accordance with particular User interruptions, and that is why Manager is now getting into such a mess. Other accounting software which use dual primary codes instead of Manager’s single primary code never have this conflict as they don’t attempt to impose a particular tax code outcome on to a User’s transaction.
This may be cute (but wrong) for P&L accounts but it could never work for Balance Sheet accounts. Take for example this set of circumstances:
An organisation Receives a Grant for a particular project. The Funds as received are allocated into a BS > Liability account called Funds held in Trust. Any expenditure on the project are also allocated to this same account. So what you have is a single financial account being used, however for GST Reporting purposes the various transactions would be reported separately under GST Sales (for the GST received transactions) and GST Purchases (for the GST paid transactions).
Exactly, and that is why this solution should never get on to any drawing board.
No you are not, in fact, you are one of the few forum members who are seeing this issue with clarity.
What you are suggesting is the exact same process that other accounting software uses except they use separate tax codes instead of your S and P fields.
Right on the money and that matches @lubos earlier comment - “Other accounting systems are simply addressing this issue by using separate tax codes for sales and separate ones for purchases.”.
But there are no exemptions to the rule. Where a transaction implies that VAT is being received then it is a VAT Sale. For example, VAT being received can’t be a VAT Purchase and vice versa.
Sorry but the essence of this statement is the root cause of the problem on this forum. THERE ARE NO GUESSES INVOLVED. The legislation provides very simplistic and basic solutions. Tax reporting is based on the Taxes being received and the Taxes being paid. Tax reporting has nothing to do with the allocation of the transaction within financial reporting.
Why reinvent the wheel as your suggestion is EXACTLY how the previous Manager model (every credit is sale, every debit is purchase) worked. Therefore there is no need for an optional line item specification, we just need to return to that previous model.
And that could be the end result unless Manager Users can educated into the fact that the Worksheet is only a draft of the Tax Return, and if Users require a variation to that draft, then they have the complete freedom to make their amendments before submitting their actual Tax Return.
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.
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 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 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 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. 
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.
