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.