In some topics this was part of the discussion. With this new topic I want to make the situation clear to everybody especially to Lubos
On the website Lubos wrote: “Everything is designed. Few things are designed well.”
In my opinion there is an inconsistency in the VAT reporting due to a let’s say a mistake in the design
This hasn’t anything to do with transparency to the tax-authorities, it is a thing of how figures are presented and whether the presentation is correct or incorrect.
Let’s make it clear with a case:
Customer A wants me to buy product A for him. My purchase price € 60.00 excl. 21% VAT. The product will be sold to him for € 100 excl. 21% VAT. After a couple of days my customer returns the product
and on my turn I return the product to my supplier.
There are a couple of ways how in real life the transactions can happen:
All transactions are done by cash (Receipt and Payment)
2 a My supplier sends me a purchase invoice, I send a sales-invoice to my customer, I send a credit note to my customer and I create a debit note for my supplier
2 b My supplier sends me an invoice, I send a sales-invoice to my customer, I send a negative sales-invoice to my customer and my supplier send me a purchase invoice with negative values.
Method 1 results in a Tax-Summary report with Net Sales value of € 160.00 with Tax on Sales of € 33.60and Net purchases of € 160.00 and Tax on Purchases of € 33.60.
Methods 2a and 2b result in a Tax-Summary report with zero-values.
Business-wise there is no difference between method 1 and methods 2 in what happened in the business: no business at all.
In Manager however it is recorded in a different way. The Tax-Transactions Report show it very clearly
In my opinion method 2 its the correct representation and method 1 not.
All Dutch accounting software I know have two separate VAT-accounts: one for VAT Tax Payable and one for VAT Tax Deductable both with their own VAT-codes. e.g. BTW 21% Payable and BTW 21% Deductible.
You can link these codes to the general-ledger accounts. The payable codes to the sales accounts and the deductible codes to all expense-accounts, regardless whether it is a debit or credit transaction on that account.
All transactions are treated the same way so there is no difference between a sales invoice, cash transaction journal entry or whatsoever.
The design mistake in Manager is with cash and bank and journal entries. All credit transactions are recorded as a sale transaction and all debit transaction are recorded as a purchase transaction. That is the inconsistency in Manager.
I entered transactions Method 1 in Q1 and Method 2 in Q2 and below you find the corresponding reports that show the inconsistency.
Hopefully Lubos will find a solution to eliminate this inconsistency.
Hennie, shouldn’t you be busy celebrating Kingsday?
Thank you for pointing out this matter. Your examples make it very clear and easy to understand. Interesting to read in method 2b you use the words “negative sales-invoice” and “purchase invoice with negative values”. I also prefer method 2b.
Method 1 (=2a) implies that I have sold goods at 72,60 which I bought for 121,00. Sounds nice when you have to explain these figures during the management meeting…
So Method 2 (=2b) is to be preferred. Reverse the sales and reverse the purchase. In my 40 years of doing administrations in the Netherlands and Germany I have always worked this way.
Also I have always been working with administration programs which have two VAT-accounts. (Added a third account myself which represented the tax paid. Adding the totals of those three accounts should give a total of zero, at a certain point of time).
For credit business scenario number 2 is there by default in manager.io, that is if you use Credit and Debit Notes for Refunds and not receipts and payments.
However, in case you were dealing with cash all the time or you do not want to record refunds using two steps (i.e. issue Credit Note and then issue a Payment), then you can follow the guides for refunds Pay a refund | Manager which shall automatically give you the treatment in the second scenario.
Using payment to reverse a receipt or invoice will definitely yield wrong results. You should instead use negative receipts for sales refunds and negative payments for purchase refunds.
With respect to allocation of transactions to (Tax received, Tax paid or deductible), I am all in for that, anything that gives the accountant more choice. I suggest that each tax code has two checkboxes 1) used for sales; and b) used for purchases. This would give the accountant the choice to use one tax code in one account or multiple tax codes in different accounts.
I’m sorry, but when I book the refund to my customer as a negative cash-receipt and the refund of my supplier as a negative payment, the VAT report doesn’t change due to the fact, as I already wrote, that bookings are recorded as I described earlier. So the inconsistency is still there. Let’s leave it up to @Lubos how he will solve this problem. He is the developer and knows best how to settle this.
Manager is trying to figure out whether transaction represents sale or purchase without having separate tax codes for it. I know all other accounting packages have just separate tax codes and it’s up to user to select correct “sale” or “purchase” tax code.
Automatically determining whether tax transaction is a sale or purchase is easy for most transaction types except for journal entries and receipts/payments. Sales invoice is always a sale but receipt can be sale but it can also be refund from supplier which should offset purchases rather than inflate sales.
I still think Manager approach is better because it decreases number of tax codes but there are still blind spots to make it work 100%.
One idea to solve this issue for receipts & payments is that eventually it will be possible to select customer or supplier instead of free text Contact field. If you select supplier on receipt, then Manager knows it’s negative purchase (supplier refund) rather than sale.
The same could be applied to journal entries but what I’m worried about is this is introducing more non-standard elements into Manager and sometimes it’s better to keep the system dumb and simple which can be easily understood rather than having too much magic in it and now hardly anyone understands how Manager decides whether something is a sale or purchase.
So I know this is a problem, I just don’t know which direction to go yet.
Then there is the possibility that a payment from a supplier is not a refund. One example is that a supplier may have a promotion that offers a cash payment for introducing some new business. Another is the supplier may be returning an over payment that you have made (which is different from a refund).
Then there is the issue of a refund on return of inventory as highlighted by this post:
I have given this problem some thought and would like to offer this solution:
Have a default customer of “Spot Customer Transaction” hard coded in the system.
Have a default supplier of " Spot Supplier Transaction" hard coded in the system
Create 3 additional transaction forms for customers called Customer Receipt, Customer Payment and Customer Refund.
Create 3 additional transaction forms for suppliers called Supplier Payment, Supplier Receipt and Supplier Refund.
All of the new customer forms will have a field to select customer. If the hard coded “Spot Customer Transaction” customer is selected a field will be made available to enter payer details and proceed with a non-invoice transaction. Otherwise if other customer is selected an option will be provided to receive against an invoice, pay against a Debit Note, or refund against a Debit note or if none selected proceed with an non-invoice sale, payment or refund for this customer.
All the new supplier forms will have a field to select supplier. If the hard coded “Spot Supplier Transaction” supplier is selected a field will be provided to enter payee details and proceed with non-invoice transaction. Otherwise if other supplier is selected option will be provided to pay against an invoice, receive against a credit note or refund against a Credit note or if none selected proceed with a non-invoice payment, receipt or refund.
The existing Receipts and Payments would no longer be needed.
I have avoided using the word “Cash” as it has different uses and is confusing. e.g. Cash(as in Bank notes) vs other types of payments (EFTPOS, cheque, bank transfer, credit card, etc). Also, Cash (as in immediate payment) vs some form of terms payment (invoice, on credit, etc).
You may think that this idea is a bit presumptuous, but even if it doesn’t “float your boat” there may be something that may assist in making the necessary changes and it would solve the issue of linking customers/suppliers to “cash” (there’s that confusing word again) receipts and payments.
in these tabs alone, why not provide a sub-account selection for customer/supplier on a line-item basis just like we have for the capital accounts. this would determine if it is a refund affecting tax or a promotion or return of over payment like @AJD mentioned. (BTW i do not think return of an over payment is a taxable transaction)
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)
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
For Journal entries or Receipt / Payment where a tax code is used
A Type which can be “Tax Payable” or “Tax deductible”
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.
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.
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? - #56 by Patch 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.
