Inconsistency in Tax-reporting

Hi Guys we are again only talking about cash, but how about journal entries ?
In my opinion the easiest way to solve this is: when the transaction is a payment, receipt or journal entry and a VAT-code is used, that Manager asks whether the tax is payable or deductible. In this way it is up to the user to select the right method. It would help the user that when the g/l account code is an income account Manager comes up with the suggestion to book it as payable, when the g/l code is an expense code it could come up with the suggestion to book it as deductible and when the g/l code is a balance account no suggestion is shown.
I hope my suggestion helps @Lubos which direction to go.

Impressive amount of lateral thinking happening here, quite inspiring.

All sound OK to me however another idea to throw into the mixing pot. It is hard for me to judge how intuitive it is as I know too well what I want it to do.

Receipts & Payments

Payments are made to Suppliers much more commonly that to customers. Similarly money is received from customers much more commonly than from supplier. There are rare occasions where these associations don’t apply. Manager could use this statistical information to optimise the user interface / set default behavior. For example

When entering a Payment in Manager

  • Rename the “Payee” label “Payee or Supplier”
  • Enable linking the transaction to a Supplier
  • Any tax code used result in changes to the Purchases shown in the “Tax Summary” report (or associated report transformation), and do not effect the Sales shown in those reports.

Similarly when entering a Receipt in Manager

  • Rename the “Payer” label “Payer or Customer”
  • Enable linking the transaction to a Customer
  • Any tax codes used result in changes to the Sales shown in the “Tax Summary” report (or associated report transformation), and do not effect the Purchases shown in those reports.

For the much less common transactions where the money is flowing in the opposite direction and the Manager user wants to enter a negative adjustment to sales or purchases, these are entered by:

  • Paying money to a customer / a negative sales adjustment: the Manager users chooses the transaction Type “Receipt” showing & enabling linking to a customer. A negative amount line item is entered.
  • Receiving money from a supplier / a negative purchase adjustment: the Manager user chooses the transaction Type “Payment” showing & enabling linking to a supplier. A negative amount line item is entered.

A warning could be displayed if a Manager user enters tax codes, a supplier / customer link on a Receipt or Payment where line item accounts are Accounts payable or accounts receivable (invoice, credit note, or debit note)

I thought this would enable relatively efficient data entry for the usual case and involves a relatively small change to Managers user interface / existing user base training. Manager makes an intelligent guess at what the user is trying to enter but ensures the use verify that the usual situation applies. The Manager user chooses links from the Customer or Supplier database not a combined database (which if combined would need an indicator showing if it was a supplier or customer link).

Journal entries

A possible solution is, when a Manager users enters a tax code

  • A “Type” Menu field is shown which can be either “Sale” or “Purchase”
  • A field is shown enabling selection a customer (if type = Sale) or supplier (if type = Purchase).
  • Manager sets the initial value of Type field when it is first shown (or software upgrade) base on if the tax code applies to a credit or debit line item.

I thought this user interface would be similar to how Manager behaves elsewhere. Manager has a reasonable guess at what the user is trying to enter but again the user could readily change it if required. It also enables the user selection from either the customer or suppler database (not a combined address book)

Would it not just be simpler to have tax codes 15% Input, 15% output etc?

In any case, I imagine that a lot of small businesses get this wrong when reporting - and maybe large ones too

Some of you are constantly thinking in terms of customers and suppliers but that is not always the case.
What @Joe suggested: Input and Output codes is more in line with what I wrote in my opening that all Dutch accounting programs do have separate codes/accounts for tax payable and deductible.
Anyway @Lubos is now fully aware of the problem. Let’s hope he comes up with a solution in due course to solve this issue. He is a brilliant guy, let’s leave it up to him.

So @Hennie are you saying to meet the work flow requirements in Holland you need

  1. For Journal entries or Receipt / Payment where a tax code is used

  2. A Type which can be “Tax Payable” or “Tax deductible”

  3. Ability to associate a customer or supplier independent of the type listed in point 2.

That surprises me.

  • Do you really use both “Tax Payable” and “Tax deductible” codes for customers. As well as both “Tax Payable” and “Tax deductible” codes for suppliers. That would mean you would have problems with Manager even if you created an invoice for every purchase and sale. I can see how an entity which is both a supplier and a customer of a business would use both types of tax codes but that is handled by having separate sales and purchase invoices in Manager, so the same could be done with receipts/payments.

  • Do you think “Tax Payable” / “Tax deductible” is understood by most non accountants? Would not “Sale” / “Purchase” be more widely understood, particularly as it is the terminology used in the Tax Summary report?

I’m not suggesting you are wrong, my knowledge of your accounting requirements is extremely limited. I just wanted to be sure I understood what is actually needed to do your job, as opposed to the features of other accounting software.

The kind of transaction, sale or purchase is decisive for what to do with VAT.
Sales = sales, whether it is a positive or negative transaction and regardless the way it is recorded. The same applies to Expenses and Stock Purchases regardless whether it is a purchase or a return of the purchased goods.
The purchase of a fixed asset is a purchase as well as the sale of a fixed asset is a sales transaction.
Then you have a different kind of booking in Manager: journal entries. They can be of any kind. A correction on an entry made earlier for instance private usage as a percentage of a year-total.
As it comes to the terminology: Manager is used in more than 50 countries and is translated by translation teams in every country. They will certainly translate everything in the terminology which is common in their country. So don’t worry about that. I will take care of the Dutch translation.

1 Like

I have thought of an example that doesn’t fit the current sale/purchase VAT which presumes that customer entries are always sales and supplier entries are always purchases and so this would support having separate VAT codes to distinguish between sales and purchase VAT.

I go to my car dealer to buy a new Toyota Landcruiser for $88,000 and I am trading in my existing vehicle a Toyota Prado for a trade in consideration of $33,000. The Car dealer issues me an invoice for $55,000 being $88,000 less the trade in allowance of $33,000.

I enter the purchase invoice and code the first line to new MV fixed asset for the $88,000 and code a second line to the existing MV fixed asset for negative $33,000.

The line for the new vehicle is classified correctly as a purchase. The line for the trade in vehicle is also classified as a purchase which is incorrect. It should be classified as a sale.

If the entry is split between an purchase invoice and a debit note it produces the same incorrect result.

The only way to get a correct result is to create a sales invoice for the trade in and create a dummy receipt to a cash account clearing account.

When a business interacts with another business as both as supplier and customer, I believe the normal procedure is to enter them as both a customer and supplier.

In the above example in Manager you could

  • create a sales invoice for $33,000 (for your trade in / disposal of your current asset). This is a stand alone transaction, the valuation is appropriate for the goods you are delivering and is part of your normal business. It is arms length, you could sell the car for a similar value privately or to another dealer.

  • Create a $88,000 purchase invoice for the purchase of your new car. This is also a stand alone transaction, the value is appropriate for the goods you are receiving.

  • When entering the bank transaction for $55,000 allocate $88,000 to the purchase invoice and -$33,000 to the sales invoice (all tax codes on the invoices). Offset simultaneous sales and purchase invoices discusses doing a similar thing with journal entries.

To enter the same business interactions without invoices in Manager I would suggest

  • Create a payment for $88,000 with tax codes for the purchase of your new car, allocate it to the appropriate Fixed asset sub account. Indicate the transaction is a purchase by what ever means is decided.

  • On the same date create a receipt for $33,000 with tax codes for the disposal of your old car, allocate it to your “Fixed asset - Loss on disposal” account (as per Dispose of fixed assets ). Indicate the transaction is a sale by what ever means is decided.

In both cases the Sale and Purchase component need to be separated. You are correct entering such business transactions is a bit less efficient than entering a pure sales or pure purchase transaction. However in my opinion that is reasonable as barter type transactions are less common.

Hennie thank you for clarifying, I agree with every thing you have said.

I’m unsure what is the optimal solution for Journal entries. As they are a general low level input that means they could be used to do most things in Manager. From a software design perspective, the issue that causes is:

  • What are users actually using Journal entries to do, and so what are the associated desirable reporting consequences.

  • What should users use Journal entries to do, so what data entry should be optimised.

The reporting consequences I can think of are

  • Effect on Tax summary Report

  • Effect on Customer & Supplier reports

If journal entries are principally used by an accountant to make a mass corrections to a business once a year, then optimising for low level flexibility would be optimal. For this use case, most accountants would probably prefer line item specifications.

An example layout looks more complex than what we currently have but would be more flexible. In this example layout Tax code entry and linkage to a supplier/customer appear when type sale or purchase is set.

In contrast where a Manager user is routinely using individual journal entries to capture or modify a single real life transactions with an external party, then defining sale/purchase tax codes and customer/supplier at the journal transaction level would be optimal. Using journal entries in this manner is probably common. This use case is similar to the functionality provided by receipts/payments. As such using a screen layout similar to what the receipt/payment tab becomes would be optimal.

One example is a sole trader using using their private bank card/account for a business transaction. In practice I find it is cleaner to enter these as zero value Receipts/Payments with a balancing entry to Owners Equity as then all work transactions can be found by searching the transaction records of the business bank account in Manager.

Manger generally encourages uses to use specific tabs rather than journal entries. Again raising the issue of what individuals find most efficient to leave as journal entries.

If transaction level Sales/Purchase is used, then an arbitrarily complex journal entry will some times need to be split into separate Sales and purchase journal entries. In practice transaction level specification would be sufficient for the journal entries I use but others no doubt have different requirements.

1 Like

Patch thanks for your reply.
I agree that journal entries are commonly used by the accountant to make (year-end) corrections on earlier bookings in Manager. Some examples: non tax deductible expenses for private usage of telephone costs, accommodation costs as a % of the annual expenses. You could enter these transactions via a zero value receipt or payment but that is in principal more or less a kind of work-around.

Thinking further about Journal entry level vs Journal line item level specification of Sale/Purchase and Customer/Supplier. I’m not sure it is possible to reliably specify these at the Journal entry level.

To explain, consider a relatively simple example: A sole trader goes to one of his suppliers

  • Makes a “cash” purchase
  • Pays an outstanding invoice
  • Uses his personal credit card instead of the his work card
  • Chooses to later enter the transaction as a journal entry rather than a net zero value “Payment”

With Journal entry level specification of Sale/Purchase and Customer/Supplier, the edit screen would look something like

The issue which concerns me with this approach is how Manager will know how to update “Suppler 1” reports to incorporate the transaction described it this journal entry.

  • The second line item is payment for a “Cash” sale so should ideally be added to the “Suppler Summary” and “Suppler Statements (transactions)”.

  • The third line item has Type = purchase, and Supplier = “Supplier 1” specified in the account selection. Tax codes are specified in the invoice. Having the ability to specify anything else would at least be potentially confusing both to the user and program behavior.

  • The first line item is the equivalent of the bank account specification in a Receipt/Payment and should have no effect on the supplier’s reports.

In contrast with line item level specification of Sale/Purchase and Customer/Supplier the above line item properties would be explicitly shown:

It maybe possible to code Manager to make a good guess at these relationships most of the time but journal entries are used for all sorts of things including correcting prior errors. I worry there is a risk Manager would get it wrong some of the time so recreate the current problem.

Edit
Note suggesting line item level specification in Journal entries rather than transaction level is the opposite conclusion I came earlier in Why do the costs on a journal entry show in the net sales column? I think transaction level is probably more efficient on average for sale/purchase specification, but I’m less convinced when identifying entries to add to supplier/customers reports.

The disadvantage of using a linked Supplier/Customer to determine if a tax code applies to the Sales or Purchase component is:

  • A Manager user must enable the “Customer” and “Supplier” tabs and at least create a dummy customer and supplier before they can specify if a Journal entry or Receipt/Payment is a sale or purchase.

  • When a selecting a Customer/Supplier, the user would need to select a contact from a database combining all customers and all suppliers (a longer list). The combined database would need to show which entries are for customers and which are for suppliers (as an entity can be both a supplier and customer of a business). In practice a Manager user will know if they are looking for a customer or supplier entry so specifying this first may make data entry more efficient.

  • Correction of this thread’s topic “Inconsistency in Tax-reporting” must wait until Improvement to payment and receipt forms is implemented, which is probably a larger task.

  • An alternative would be to add a drop down Sale/Purchase to journal entries (at what ever level was thought to be optimal). For Receipts/Payments, instead of using line item credit/debit status to determine line item Sale/Purchase; a transaction level Sale/Purchase drop down could be added or use the existing Receipt/Payment drop down. A change which would only effect the “Tax Summary” Report and only for negative Receipt/Payment line items. In both cases these changes would only be an incremental improvement in Managers functionality if they corresponded to the vision of where Manager is going, something I’m not privy to.

Is this topic here and this topic - Concept BTW rapport (Dutch VAT report)
relevant to us lesser mortals who don’t have advanced accounting skills :grinning:?

I only do VAT Returns every quarter using the VAT Calculation Worksheets. I don’t use the other VAT reports. I have read both topics and I think the second topic is only relating to the Dutch report based on your having two Vat accounts - Vat Payable and Vat Claimable.

The gist of the two topics I guess is down to how to enter the VAT when refunding a client for a product sold or getting a refund from a supplier. But I don’t really know whether this affects the VAT Calculation Worksheets.

I ask this because more than once I have had issues with Manager where at the end of the financial year or a particular quarter where the amount I need to pay in Vat Calculation does not match the amount owing on the summary tab despite the fact that they should match. I wonder if it is related to this where I have been refunded purchases etc.

@dalacor
Whether or not the topic is more or less relevant to lesser mortals is not the reason why I started the topic.
It is a question of whether or not Manager is dealing in a correct way with VAT.
We don’t have two VAT accounts in the Netherlands. You have VAT which you have to pay because you sell goods or services and there is VAT which you can reclaim because you buy goods or services. This all can be booked on one “mixed” account but the VAT Calculation Worksheet should show in the correct way the VAT amounts as a result from sales and the VAT amount as a result from purchases. That is where the discussion is about.
Manager should in all cases represent the correct figures, so basically it affects all of us. That’s why forummembers with more accounting skills try to get it right and that benefits all of us.

I believe this may also relate to my issues at Bug: Negative invoiced amounts missing from GST (tax) reports

Manager reports at the invoice summary level (not per line item). And as you mentioned, does not differentiate between get on purchases and get on sales.

My situation is even worse because a card file cannot be both a custoner and supplier in manager.

Perhaps a rethink is due here.

The short answer is, your problems mybe different to to what is discussed here.

The “VAT calculation Worksheet” is a report transformation of the “Tax summary” report. Which means the information in the “Tax summary” report has been used to calculate local reporting fields with the results formated in a similar manner to local forms. So if the “Tax summary” report is indeed correct then so should the reformatted report / “VAT calculation Worksheet”.

To try and clarify what is being discussed here, lets assume you go to one of your suppliers collect some goods or receive a service and they issue you a invoice. You pay your 166.66 and leave. I have intentionally left out the details of the two line items so we can focus on how Manager processes them and later decide the result we actually need for particular cases.
Official tax invoice

Option 1
We take the invoice to the bookkeeper our business uses who recognizes it as an invoice from one of the businesses suppliers so creates a matching purchase invoice in Manager

As we paid while we were at the supplier the bookkeeper also entered the payment into Manager

In Manager it the invoice now shows it has been paid

As we are a new business and that is the only transaction it is visible in the summary screen in Manager

But more importantly for this thread it is visible in the “Tax summary” report. The entire transaction has only effected the Purchase for Vat reporting

Option 2
Now suppose our book keeper had decided to enter the same invoice as a “cash” purchase in Manager. So didn’t create an invoice in Manager but entered the same information directly as a payment.

Looking at the Summary screen in Manager, it is identical to option 1 above

However when looking at the Tax Summary report it has changed. The Tax liability has not changed but now we are reporting more Purchases as well as some Sales.

There is at least an “Inconsistency in Tax-reporting”, the subject of this thread.
What Manager has done is assume

  • Line item 1 and line item 2 are independent stand alone transactions
  • Line item 1 is a purchase as money is going from an external party to the business
  • Line item 2 is a sale as money is going from an external party to the business.

This type of transaction is a barter type transaction, which jurisdictions define and require treatment as a sale and separate purchase when that is what is occurring (eg Australia ). The correct way to enter them in Manager using invoices is to create a Purchase invoice for item 1 and a sales invoice for item 2. When the payment is entered into Manager 266.66 is allocated to the purchase invoice and -100 to the sales invoice (or they can be settled with a journal entry as described in the guides).

What sales and what purchases should be reported to your tax authority depends on exactly what item 1 and item 2 are and local tax laws. Importantly though this is a decision the business owner makes to comply with local laws. The suggestion in this thread is it would be helpful if a Manager user could specify if a transaction was a sale or purchase and that specification would then apply to all the line items in a transaction. The facility is particularly useful where most data data is entered into Manager via importing bank transactions rather than first entering invoices (“cash” sales / purchases in Manager terminology).

An equivalent issues occurs with sales if a point of sales system external to Manger is used. The POS generates the sales invoices. When the transactions are imported into Manager via a bank statement import, most will be assigned a sales however if any negative sales adjustments are used, Manager will record it as a purchase.

@Hennie Yes I agree that there is an issue that affects all of us using Manager. What I actually meant was whether there an issue with regards to VAT returns - i.e. am I filing my VAT returns accurately. The discussion was not clear on this point as it seemed to be more about a specific report and a specific set of circumstances e.g. when you sell something and then refund the client type scenario rather than just a general buy something from a supplier then sell to client type of Vat reporting.

So I was not really sure if I needed to worry about my Vat returns in that respect given the fact that I twice (to my knowledge) had issues where the Vat calculation report amount owing did not match what was on the summary page.

But looking at what Patch has shown in the latest comment it is easy to see that there is definitely a problem with certain reports showing discrepancies. My key concern when I posted was about whether I am paying/receiving the correct amount of tax as calculated by the VAT calculation worksheet.

@Patch Very well explained. I have a far better idea of what you are talking about here now and as you say probably not related to my issue although it may be as the “refunds” were done via journal entries. Anyway my accountant is looking into that.

Very interesting how the result changes whether you are doing a purchase invoice versus cash payment direct.

Manager allocates sales/purchases in journal entries identically to how it allocates them in Receipts/payments. So exactly the same issue occurs. With your problem the important thing is if the “Tax Summary” report is really correct or if the error is just easier to see in the “VAT calculation Worksheet”

  • If the Tax summary is indeed correct then maybe there is a problem with the report transformation.
  • If the tax summary is not actually correct then you maybe experiencing the issue describe in this thread.

This inconsistency has been fixed in later versions of Manager
It now shows the same result as if a purchase order.

That is still in the ideas category, but clearly Lubos is aware of the issue.