Levy Taxes - an introduction to

Do we know which version of Manager introduces the new model?

This is a statement that is not true for the Italian legislation. Levy, ie Italian IVA, is not in any way sub-classificated in this way but in many other different ways based on the nature of the item or the service bought and sold. There are also super-classification (on top of IVA) linked to the nation of the counterpart (EU or not EU) and if they levy purchases are not recoverable, ie they should be considered a cost.

In Italy there is a clear distinction between a 0% levy and a levy exemption and are sub-classificated with an infinite list of codes. This ends up with a different % amount of the Levy Purchases you can recover.

Again in Italy we have a clear distinction between what happens before one year from the original invoice and after.

To be clear I don’t won’t to demonstrate that your wrong. Given the fact that the new engine had zero impact on my past tax declarations (but I had so many other issues linked to reporting recent change!), what I want to say is that since we live all around the world, levy taxes are similar but they are not the same. So every decision @lubos will take will make some people satisfied and other not.

I don’t think, unless we will get the possibility to program a plugin for each nation (which I won’t think will ever see the light since plugins made a quick apparition on the top menu of Manager a couple of years ago but they immediately disappeared), that we will ever have a perfect solution that will automatically achieve 100% of right classification.

I made my proposal in this thread:

It is based on my Italian experience and I think it is the most flexible.

Another solution that comes to my mind is to have a specific tax module tab in which one can check all the transactions and in which, if needed, one can make manual adjustments on some of them, ie change the rules dinamically.

This is why I need to figure out what’s the lowest common denominator for all countries.

As far as Italy goes, I think tax codes combined with custom fields would provide enough data for the system to be able to generate Italian tax reports.

For some countries where reporting requirements are simpler - tax codes would be imported. For other countries such as Italy, custom fields would be imported and users would be expected to create own tax codes and select appropriate values in custom fields.

Most likely I’m going to abandon Manager trying to determine whether tax amount is a sale or purchase and will simply have two separate tax codes if tax authority requires these amounts to be reported separately.

2 Likes

I think that a better implementation, that from what I understand is already ongoing, of custom fields will give Manager all the flexibility needed.

Manager needs:

  1. custom fields shared between different tab/module;
  2. every type of custom field (numbers, date and expecially drop down) at line level.

No it is based on business activity.

Many small business started using an accounting program purely to meet VAT/GST reporting requirements. As such accounting software which fails to achieve accurate VAT/GST reporting would not be fit for purpose.

Agree, the tax payer must have ultimate say as only the tax payer knows if the requirement external to the account software have been meet.
I disagree the accounting software should have no say, as the software if intelligently designed will be able to predict the tax group or actual tax code in by far the majority of cases.

Also not true. Many jurisdictions require negative GST/VAT adjustments for specific transaction types.

See [Withdrawn] How to report EU sales made on or before 31 December 2020 for VAT - GOV.UK

Similarly in Australia the same is required as a business will typically not meet the associated GST requirements when a line item in a supply is arbitrarily changes between sale and purchase based on the sign of the amount.
Specifically a business obligations are different if a line item is recorded as a sale or purchase

GST Sales / Supplies

  • you make the sale in the course or furtherance of a business (enterprise) you carry on
  • Production of a “Tax invoice”

GST Purchases / aquisitions

  • buy for use in your business
  • Retain a “Tax invoice”

For example if I buy some equipment for my business at the hardware, and enter the cash transaction in Manager. I later return parts not needed to the hardware and get a refund. The shop assistant crosses the items off the original tax invoice. The returns must be entered as a negative purchase as I now no longer have a tax invoice for the returned items so can no longer legally claim a GST credit for them.

Similarly I buy building insurance. Later I revalue the building, and contact the insurance agent re the altered insurance requirement. The insurance company cancels the remaining term in the old insurance contract (and refunds the remaining insurance), invoices me for the remaining term at the new insurance rate. I must enter the refund as a negative purchase and the new invoice as a positive purchase. The refund is not a sale as my business does not have an insurance branch and I have not provided an insurance service to my insurance company.

Understanding this is more complex than the British reference above but the outcome is the same.

In Australia the following are all reported (not just the “Tax liability”). In addition G1 is used for JobKeeper so the distinction between sales and purchases matters

  • G1 Total sales
  • 1A GST on sales
  • 1B GST on purchases

For users who commonly use this type of transaction, I agree Manager could provide enhanced functionality. A solution based on a side effect of cash transaction however is poor implementation. The solution should also work efficiently with invoices.

  • That has been necessary under the old model / worksheet for several years for the opposite reason to your logic. A correction I have been doing.
  • Other users have been entering entities as suppliers and customers, then creating a sales and purchase invoice for similar transactions. I see no reason a Manager enhancement should exclude them.
  • This is exactly what you have recommended users with a work flow different to you should do

I guess most will require two separate taxes. Would it be possible to sort the tax codes by Sale/purchase and order them with the most likely at the top of the list. Hopefully this would minimizes the downside during data entry of having significantly more tax codes.

Providing the required tax code for all countries (even if their generation is trivial from defined custom fields) would decrease the barrier to entry for new users. It may increase your workload but the time investment maybe offset by new users ease of use and apparent level of support for each country.

Having said that I have not seen how the new system works so I may well be wrong.

I hope that for “create” you also mean Batch Create/Update since the list is very long and also the quantity of custom fields.

How about a simple flag to invert the automatic determination of Manager inside a Tax Tab? You will have inside a new tax tab a list of all the tax values and a possibility to change the allocation and the sign. This will save us from entering twice the tax codes.

If Manager can use sub menus when selecting a tax code, then instead of putting the contra tax codes at the bottom of the list, they could be put in a sub menu. Imo that would provide a better interface and result in no increase in menu length compared to having combined purchase and sale tax codes.

I agree that call them Tax Subaccounts, Tax Sumenus, Tax Ledgers is the way to go

I did consider this idea but it would increase complexity for user.

Consider Dutch example where government wants to see very detailed break-down of VAT 0% purchases (there are 9 tax codes convering that) but only 3 tax codes covering VAT 0% sales.

You’d be just shifting choices from tax code field to tax code subclassification field and in the process, you’d increase number of possibilities from 17 (number of tax codes) to 40-50 (tax codes multiplied by subclassfications). Not good.

So what I’m thinking now, we should have tax codes which exactly match reporting requirements. I know it feels like a step back because that’s what other accounting systems do. I’ve tried to come up with something better and it’s not working out.

I think we are talking about different things.
If I understand you correctly, you are suggesting the user selects the axes of a tax code rather than having an enumerated list of tax codes eg the axis values could be

  • Sales, purchase
  • 23%, 13.5%, 9%, 4.8%, 5.4%, 0%
  • Domestic, EU, non-EU
  • For resale, not resale

As resultant any combination could be selected using only a list of a few items for each dimension. The total combinations selectable being the product of each dimensions size (in the above example 2 x 6 x 3 x 2 = 72)

Lubos is currently looking at the other extreme ie

  • Create tax codes for each coordinate (in the above example 72 tax codes)
  • Merge any points where separate identification is not need to fill out that jurisdictions official VAT report. Or looking from the opposite perspective, only retain individual tax codes where the subdivisions effects a reportable quantity, otherwise group them.
  • the end result is the user only needs supply information essential to filling out their VAT return, so minimizing data entry complexity.

The optimal approach depends on the length of resultant lists the user has to select values from. Last time I looked a list length of about 7 was thought to be near optimal for the average human brain.

What I was proposing was separate to the this. Manager often has contextual information which could be used to dynamically reduce the list length. For example on a sales invoice

  • In a line item with a positive amount, the tax code will be a sale tax code. So purchase tax codes could be completely hidden.

  • Most line items will have a positive amount. So purchase tax codes could be less accessible.

  • For negative amount line items users preferences for Sale/purchase will vary depending on individual work flow. So both must be capable of being accessed however as this is a relatively rare occurrence for all uses, how the list is presented is not critical.

  • Edit: In theory a double negative is possible ie a negative line item in the counter trade. In practice this would be extremely rare. However for user and program simplicity it would probably be cleaner to display sales / purchase codes as listed here at the top level and have the contra tax codes in a sub menu at the bottom of the list. For journal entries displaying all tax codes at the same level would preferable.

The same logic can be applied to other screens. What I was proposing is partially hiding tax codes users are unlikely to want to select. For example putting them at the bottom of the list or better still in a sub menu at the bottom of the list.

In summary, as long as all valid options are available, Manager optimizing selection of the most likely option is an excellent design feature.

In my opinion adding explicit support at the transaction level for Counter trade and Recipient-created tax invoices transaction would be better again. Doing so would more clearly display the underlying transactions to the user and this could be shown on invoices Manager generates. It is however a larger risk as it is different to other software packages, and I assume would involve more of your time to implement. Perhaps it maybe a later enhancement at which time it would enable further trimming of the tax codes displayed to the user.

My suggestion is a little intermediate. Only two dimensions: Tax Codes * Tax Ledgers with:

  1. a further implementation of tax code so that we can set to post Tax automatically (as it is today) or to force Tax to Payable or Receivable
  2. a clear indication inside Tax Ledger of the Tax Codes to which it is linked

The Tax Ledger is basically a layer upon Tax Coode with the same fields. If a field is declared inside Tax Ledger this one prevails on the one inside a Tax Code.

Inside a Tax Ledger one will declare all the Tax Codes to which it can be applied.

If no Tax Ledger is created Manager will ask to set only a Tax Code, so everything remains like today. If there is at least one Tax Ledger in your Business you will have to select a Tax Code and a Tax Ledger (only from a reduced list of the ones that are linked to that specific Tax Code). You will have an additional column for Tax Ledgers besides Tax Code when you will set the transaction.

In this way you won’t have n*m codes and you will have even less than the one set by @lubos in the example since the permutation is set only for the necessary Tax Codes.

BTW this is not my idea but it was was copied from the software for Italian Tax Declaration of my accountant.

For example, you have 10 Tax Codes and 3 Tax Ledgers.

The first TL apply only to 7 TC, the second one to all 10 and the third applies to 6.

  1. If you do all the permutation you will have to create 30 TC.
  2. If you do the @lubos’s compact one you will have to create 7+10+6 code, ie 23 TC.
  3. With this new way 13 Entries (10 TC + 3 TL)

And you have to keep in mind that if you don’t create a TL you can still work in the old way.

And if you need to add an additional TL with only a single entry you will create something from 1 to 10 TC.

Thanks for the insight. That is a little more involved that I had assumed.

  • From a data entry perspective the length of the selection lists matter. Too short or too long is inefficient. Trying the two approaches for a range of jurisdictions would be the only way to see how well each really works. Being aware of a range of options is an excellent idea though.

  • I haven’t tried to fit several jurisdictions VAT tax system into that form of encoding, it does sound as it may take some skill to get right.

  • There is a possibility a method as involved as that is covered by a patent. Probably the easiest way to check is look at what patents cover the software you got the idea from. May not be an issue.

  • I’m not sure how cleanly it could be extended to jurisdictions where multiple authorities can simultaneously levy independent VAT tax on a single item. Full enumeration may work better for that.

You keep repeating this factually incorrect statement even though time after time you have been continually corrected - but don’t take my word, refer to GST Worksheet not reflecting correctly started by another user. Their opening post:

"I have been using Manager desktop version 15.0.68 for some time. I get recipient created invoice where there are three items mainly. Most of the income is GST free with a small amount of Income with GST. The client deducts his Service Fees + GST and remits the balance to my Bank account. I have been using Bank receipts . . . .

This worked fine with the correct amounts reflecting in the GST Calculation Worksheet at the respective labels."

That is, for the past 5 years the user has been entering their Recipient Created Invoices as a SINGLE cash transaction and have had the Worksheet reflect everything correctly. They DID NOT have to resort to splitting their transaction into separate Sales & Purchase Invoices. They then go on to say:

“However, when I started to use the current version 20.8.1, it adds the Income with GST and Service Fee (one being Sale and the other being Purchase - in GST terminology) and reflects the Net (a -ve figure in this case) at label G6. Also the G1 Label, which is the Total income, shows incorrect figures.”

That is, after the update the Recipient Created Invoices could NO LONGER be entered as a single cash transaction, if you wanted the Worksheet to reflect correctly. Refer to posts #4 & #5 of that topic is see the before and after impacts of the model change on the Worksheet.

Take special note that the Worksheet in post #5 is just a re-write of the Worksheet in post #4, that is, the re-write was solely due to the changes in “models”, programme update, no user action occurred.

For myself, up to Ver 20.6.nn I also could enter all Recipient Created Invoices as a single transaction.

Don’t know where this is coming from as no Manager enhancement has ever attempted to exclude them. They can continue to function that way without any impact or restriction. It’s the users who were using the single transaction who are now impacted and EXCLUDED from doing their previous data entry.

There is a significant difference between having a different workflow from other users to being forced to have the same workflow as other users - hence the “Manager is now dictating”

Then you are in conflict with all other major accounting software, but more importantly with Lubos who in post #6 of this topic stated “Most likely I’m going to abandon Manager trying to determine whether tax amount is a sale or purchase” so it becomes User determination only.

@lubos, just posing the question, does Manager really need to create a “new” Levy reporting model, whereas, the previous (old) model could be re-instated as it had functioned / performed solidly over the long term albeit for issues with a very minuscular, negligible number of transactions.

Not forgetting the fact, that the huge advantage of the previous model was the simplification of the tax codes, which shouldn’t be overlooked due to the large number of non-accounting Manager users.

The transactions with issues are principally Journal Entries and Cash Refunds, maybe others.

Journal Entries were 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. (Without searching, this approach may have been suggested before)

Cash Refunds were a “perceived” issue as there were two schools. School one, that the transactions be reported in accordance with the Levy being received or paid (the old model default). School two, that the transactions be reported in accordance with the accounting allocation. Now by my reckoning, there have been less then a handful of vocal users in School two and they have always had the option of reconciling their differences between the Manager tax reports and the lodgement of their Levy Returns.

The impact of any new model would be the increased number of tax codes, for Australia alone:
GST 10% becomes GST 10% Sales and GST 10% Purchases
GST Free becomes GST Free Sales and GST Free Purchases.

Now in saying this, doesn’t take away from other tax code situations such as with Italy, but it appears if I understand the posts correctly that Custom Fields could assist there.

Anyhow, your call.

This two layers method will leave everyone completely free to choose to implement it or not.

No patents cover issue since (a) it only an abstraction layer used in many software (think of users and groups inside every OS or software) and (b) it is used in every different accounting softwares in Italy since VAT ledgers are required by law.

Simultaneous levy is a completely different field that has nothing to do with this kind of implementation.

I am keen to revert to the old format and just implement changes required to fix the transactions that were wrong in the old format as this seems to affect a very small number of users. The new design seems to have caused more problems than the old design. Hopefully a working solution will be introduced soon.