Levy Taxes - an introduction to

WARNING – This post is three A4 pages in length and may take 10 + minutes to read.

The following post is based on my involvement with various introductions of Levy taxes and relates to Taxpayers who are registered for Levy taxes. Non-registered Taxpayers have different circumstances and are not under consideration below.

GST / VAT taxes are a LEVY on supply and the reporting of that Levy activity was set up to be relatively straightforward. However, it is of increasing concern, that the clear separation / differentiation between Financial reporting and GST / VAT (Levy) reporting is not being clearly understood, that is, that somehow the reporting of the Levy activity is directly related to specific Financial reporting– it is not. The Levy is a standalone item but based upon accounting activity.

For a start, there is no legal requirement that the recording of the Levy’s activity must be done within an accounting programme, therefore this instantly separates / differentiates the Financial reporting and the Levy reporting from requiring a direct connection. However, for convenience, accounting programmes incorporate a plug-in so that the Levy activities can be recorded without requiring a duplicate process. For example, an organisation which is exempt from Financial reporting (or not requiring accounting software) could record their Levy activities in a spreadsheet.

Within the Financial reporting there are five locations – BS Assets, BS Liabilities, BS Equity, P&L Income and P&L Expenses and within the Levy reporting there are two locations – Levy Sales and Levy Purchases. Therefore, any Levy Sales activity could have had the related accounting transaction being allocated to any one of the five Financial reporting locations, just as any Levy Purchases activity could also have had the related accounting transaction being allocated to any one of the five Financial reporting locations. Albeit, the BS Equity location is unlikely (but it is possible under the “other wise claimable” provisions) to have any Levy activity allocations. Furthermore, independent accounting transactions which generate completely separate Levy Sales and Levy Purchases activities can be allocated to the exact same financial account.

Within Levy Sales or Levy Purchases there are specific sub-classifications, such as Export Sales or Capital Purchases, which are tracked independently of the general Levy Sales and Levy Purchases.

Furthermore, there is no legal requirement that a reconciliation between the Financial locations and the Levy locations must occur, because it is plainly impractical. For example, the BS Assets location can contain accounting transactions which generated both Levy Sales and Levy Purchases activities, just as the P&L Income location can contain accounting transactions which generated both Levy Sales and Levy Purchases activities.

The Levy (when a non-zero percentage) is only an add-on value to the accounting transaction and is reported based upon these events, if the Levy is being received then it relates to Levy Sales or if the Levy is being paid then it relates to Levy Purchases. The Levy values are recorded within the Tax Payable account. The Tax Payable account is nothing more than a tracking code, that is, it tracks the credit / debit values of the Levy. The Tax Payable account itself doesn’t track where the accounting transaction which generated that Levy value was allocated to. The Levy’s activities are transferred to the Levy reporting via the usage of Tax Codes.

The Tax Codes are assigned by the “Taxpayer” by allocating them to the line items of the accounting transaction. As the Taxpayer is the identity reporting to the Tax Authority the accounting programme should have NO say as to how the Taxpayer should or should not allocate the Tax Codes, that is, the use of any particular tax code is at the sole discretion of the Taxpayer.

However, if the accounting programme has adopted a single multi-use Tax Code, such as Manager, then it has a limited involvement but only to the limited extent of segregating credits & debits into Levy Sales and Levy Purchases.

Furthermore, there are NO expectations of there being either negative, contra or offset Levy activities, that is, you can only have positive (one way) Levy Sales and Levy Purchases activity.

Example (1): When the Taxpayer incurs a cash expense, then the Levy component of that transaction is a Levy Purchase, because the Levy is being paid. If the Taxpayer subsequently returns that purchase and gets refunded in cash, then the Levy component of that transaction is a Levy Sale, because the Levy is being received. Just because the two accounting transactions are being offset within the same financial account, that doesn’t automatically flow through to the Levies also being offset. The payment of the Levy and the receipt of the Levy are two separate independent activities of the Levy.

The same principles apply to a cash sales and any subsequent return being reimbursed in cash.

Example (2): When the Taxpayer receives a Recipient Created Tax Invoice then this invoice generally contains within it both income and expense line item transactions, therefore it can have both Levy Sales and Levy Purchases components. These separate Levy components should not be sanitised into being reported as a single type of Levy Activity, such as Levy Sales, as this would cause some line items to generate a negative Levy activity.

To illustrate how futile it is to sanitise a Recipient Created Tax Invoice via is this. Instead of the RCTI being processed as a single “New Receipt”, it’s data entry would be split into three processes, a Sales Invoice, a Purchase Invoice and a New Receipt. So all the accounting programme has achieved by attempting to dictate to the Taxpayer how their RCTI should be Levy reported, is this, the Taxpayer being enormously pissed off that their once simple single transaction has now forced them into adopting a three stage workaround process just so they can generate THEIR Levy Return correctly.

The one exception to “negative” is the Levy components of Credit Notes and Debit Notes. When Sales Invoices and Purchases Invoices are being created their Levy components are initially *intended Levy Sales and Levy Purchases and don’t become actual Levy activity until the Levy has been actually received or paid. For example, when you issue a Sales Invoice which includes a Levy component, then the intention is to collect that Levy at some future date and once collected will become an actual Levy activity even though the transaction doesn’t change, that is the Levy component stays with Invoice and doesn’t get transferred to the cash transaction…

As Credit Notes and Debits Notes are only invoice adjustments, their Levy components are not actual Levy activity (not being in cash), therefore they can be offset against the Invoice’s original Levy’s movement.

There are absolutely no problems with having credit transactions (Sales / Purchasing Invoices) functioning differently to cash transaction (New Receipts / New Payments).

  • Why intended, because technically a Taxpayer is only legally obliged to the Tax Authority for Levies that it has actually received and for the Levies that it has actually paid. This is why cash basis Levy reporting is the more correct approach as the Tax Authority only receives what you have received. This doesn’t mean that accrual basis Levy reporting is wrong, as it is convenient to match the Levy reporting basis with the Financial reporting basis.

With accrual basis Levy reporting the Taxpayer could be paying to the Tax Authority Levies which it has not yet received and getting refunded for Levies which it has not yet paid. Furthermore, if you have a substantial amount of non-received Levy, and yet you pay that non-received Levy to the Tax Authority first, then in effect your business is funding the government until the customers pay you.

In addition, the no need to reconcile is further emphasised where there are countries that can have their Financial reporting on an accrual basis while allowing their Levy reporting to be on a cash basis, that is, the Financial Tax Payable account for any given period will contain completely different Levy movements compared to the Levy movements within the Levy reporting for the same period.

Levy reporting for the cash or accrual basis is this, for any given reporting period, the Levy Sales is the accumulation of all the tax coded accounting transactions with credit values and the Levy received is the accumulation of all the credit values within the Tax Payable account. While the Levy Purchases is the accumulation of all the tax coded accounting transactions with debit values and the Levy paid is the accumulation of all the debit values within the Tax Payable account. The Levy reporting is unrelated to any account allocations of the accounting transactions.

Accounting software tax code methodology. You can have the single dual purpose tax code (Levy Combo) as adopted by Manager, or you can have the multiple single purpose tax codes (Levy Sales & Levy Purchases) as adopted by other accounting software. Both are perfectly valid and are acceptable by Tax Authorities as the majority (99% +) of Levy activity is reported identically.

The significant difference between the two is this, the other accounting software multiple single purpose tax codes (Levy Sales & Levy Purchases) means that there is zero interference with the Taxpayer’s decision on how a transaction’s line level tax code was applied, that is, what ever the Taxpayer decided at the transaction line level is exactly what ends up at the Levy Reporting level.

In the case of Manager, the previous model ( every credit is sale, every debit is purchase ) the Levy reporting was based upon (1) the tax code used and (2) if that tax code usage at the transaction line level generated credit (receipt) values or debit (payment) values. Which is almost identical except Manager has to break its Levy Combo tax code into Levy Sales & Levy Purchases for the purposes of Levy Reporting.

However, the new Manager model breaks that solidarity by now ignoring the credit (receipt) values or debit (payment) values at the transaction line level and has instead replaced them with a whole of transaction tax code. A world first in accounting software, which may also mean that Manager may no longer achieve that 99% + parity with the other accounting software.

How has this come to pass, well unfortunately it appears that there are accountants who apparently haven’t understood the basics of Levy reporting and have asserted / exerted their accounting transaction mentality upon the Manager’s Levy reporting process, is my guess.

For myself, what this change in model communicates is this - Manager has no respect for any of my past Levy Worksheets as all the data within them has now been recalculated so that they no longer support the Levy Returns which have been submitted to the Authorities, also, Manager is now dictating that I now have to use a workaround to process my transactions so as to avoid the impacts of this new flawed model so that I can present a factual correct Levy Return.

Manager neither has the right, nor the authority to impose or dictate to any Taxpayer how they should be reporting their Levy activities which is what the new model does by being transaction based. The Tax reporting relationship is between the Taxpayer and the Tax Authority. Manager is only a data collection centre, which is what appropriately occurred under the previous model.

I think the key take away point should be two things.

Which method covers most of the transactions and businesses correctly? The old/original way or the new/current way?

Secondly should an accounting program concern itself with tax reporting or merely financial reporting.

I can’t answer either question as I don’t know the answer to either.

But I think that those are the two questions that should be asked before making a final decision.

I will again re-iterate that Manager should remain user friendly for business owners who are not accountants as we have accountants to advise us on these obscure tricky transactions which would seem to be unusual transactions rather than the norm.

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.

Valued Added Taxes (VAT/GST) are based on trading activities not accounting entries/transactions.

GST in Australia is levied on supplies. The receiving of a supply is a purchase and the providing of a supply is a sale. The GST is applied (if applicable) to the arms length consideration associated with the supply.

There may be a number of accounting entries (lines) needed to record the consideration. Some of these lines may be a contra to the consideration of the supply. The taxpayer must decide (according to the tax law) if the contra is a separate supply (supply receipt or supply provision) and record the appropriate GST classification based on this decision.

A contra in a sales invoice that is recorded as an expense is not necessarily a supply receipt.

Recording of GST/VAT cannot be separated from the accounting process as it affects items of the accounting process such as cash accounts, receivables, payables, and cash flow.

Therefore an accounting software program needs to give the user flexibility to select the appropriate tax classification without lengthy convoluted workarounds to report correctly to tax authorities.

In fact, many of the modern valued added taxes exist because the use of computer accounting systems has allowed tasks, that would not be possible or cost effective using manual processes, to now be manageable. Therefore, a modern computer accounting system that does not facilitate accurate tax reporting is failing its users.

Both the models that Manager has used are inadequate and it appears that Lubos has realized that an improvement is required. I am hoping that this solution is not far away.

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 https://www.gov.uk/guidance/vat-how-to-report-your-eu-sales

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.