Hi, since we are making some updates,
came out the old argument about the discount/taxing order. We need to agree on how to proceed.
As of right now, IP calculates discount on “gross prices”, which is fine for DE but a problem to everybody else,
who I hear, are using negative price rows to discount.
Look at this example,
Example Discount-Before-Tax:
price: 100 euro
discount: 10 euro discount
taxes: 19% taxes
price: 100 euro
discount: 10 euro discount
taxes: 19% taxes
final price = (100 + (100 / 100 * 19)) - 10 = 109 euro
In the first example, the customer is paying 90 of the item, plus 19% of 90 euro of taxes.
In the second example, we are basically still paying 90 for the item, but we are paying 19% of 100 euros (not 90!), giving the govt. more money then they deserve.
Should IP have a setting that switches “discount net amount”, “discount taxed amount” or something similar?
What should be the default?
I suggest to not push such a heavy change into a patch version like 1.5.10.
As I said, the change was planned for 1.6 and should be implemented to let the user choose how the calculation should be done, because there simply is no single correct calculation.
The defaults were always the standards used by the US market because most of the users come them the US.
We can make the change behind a setting and not change the default.
If I am not wrong the US, taxes on the net amount, so we would have to change things later on.
I agree with @Kovah in that once we decide how this should work, it should be planned for a future release. We don’t want to get in the habit of rushing features into a release and not have it fully vetted or tested. @Luca_Pellizzari, do you have access to https://development.invoiceplane.com? If so, add this request there so we can properly plan it.
I know you want to be steady, but think that every discounted price right now comes out wrong, if you don’t handle manually (all of our invoices are discounted).
I can use my own fork for now, but let’s not have this going for months, ok?
Hi,
My understanding is that’s only a way to present things : looking back at the 2 examples given, I could say that if I look at it in a customer point of view (in net prices including taxes), I get a 11.9€ discount in the first case, and I get 10€ discount in the second case.
And looking at it in a professional manner I get 10€ discount in the first case (and a professional is not interested in the second case).
So at the end of the day it all depends on who your are sending invoices to. My 200+ clients using an ERP (mostly small businesses) are mainly dealing with professionals so they are happy with a discount before taxes. For the businesses dealing with end customers, most of them are also happy with discounts before taxes as this is the way it is done in France, even in big shops (like DIY shops). However, some customers in a highly competitive area, wanted to make it clear to their customers, what was the final discount (including taxes) for the customer. Also they wanted to be able to type a round net discount (e.g. 10€) so the customer could see the discount clearly.
However, in France (and I suspect it’s the same in any other country), you can not apply a discount on the amount including the taxes (as the taxes go to the government). So you need to apply the discount before tax, and in that case, recalculate the amount to make sure you get the result you want (a 10€ net discount) … but again it is not allowed to discount taxes.
So the example is (100-8.4) + ((100-8.4)/100 *19) = 109€ (compare to 119€ catalogue price)
.In this example, the IP user would type in 10€ and then IP would calculate the discount before tax 100-(100-(10/1.19)) = 8.403…
On the invoice, you could show a 10€ discount after taxes (or more likely on the quote to get the customer interested), but you will have to word it properly to avoid confusing an accountant who won’t be happy with a discount after taxes. If you display on the invoice (which I never did, I always displayed only the discount before taxes on the quote), you might want to display both discounts (before taxes and after taxes), but then again, that might confusing as this can be taken that you are applying both discounts.
To sum up, in France (and I assume in most-all ?- countries) you can not apply a discount after taxes, but you may type in a round amount of net discount that will recalculated as discount before taxes. Then you can create a nice quote with net prices and a tag like “you save X€” (where X is the net discount that has been typed in -10€ in our example), but as an accountant point of view the discount is 8.403… and that should be displayed on the invoice (then again you could have the same tag “you save X€” with the net price as long as you don’t write discount).
Sorry for the long post, but this is quite important to get it right. Still I don’t pretend that this could satisfy everybody, as the one thing I know for sure is that every body need is different (but then again, for the most part it is identical).
Let’s set aside the habits or the laws in the various countries,
what you say has sense, and I’ve done it before.
To discount a taxed price until it matches a number that sounds good in the customers ears,
that’s ok. I would not have in the ERP, but that’s ok.
What you market to your customer and what you save in your database is kind of different,
and if you really care that when you say “-10 euros”, you can make that happen with math.
It’s important that an invoice solution has right number in the DB.
Adding discounts after taxes is wrong because the tax amount in the price does not match the net amount.
So you are giving more to taxes in the price, unless you reverse the math and keep the difference, while sorting your taxes.
But the data in your database are off, then. It’s making your life more difficult.
Am I making myself clear?
I saw your PR, and it’s frankly how I would have done it. We can recover it, tweak it and test it.
It matters that we all are on the same page.
you are wrong here.
If you calculate your discount AFTER taxes they are paying 91.60€ for your product. and 17.40€ (19% of 91.60€) taxes. Together its the 109€ you already mentioned.
No brother, you are simply redistributing the proportion of what is item price and what is tax, but this will give you nonsense numbers.
We are not doing math for number’s sake, the numbers actually stand for something.
If you take the example from before:
-price: 100 euro
-discount: 10 euro discount
-taxes: 19% taxes
You’ll never be able to obtain the numbers you gave from the actual data:
In my price book, this item minus the discount should be 90 (100-10), but in the result I get 91,60 euro. What is 91,60? What does it stand for?
In my price book, this item should be sold for 100, but I’m selling it for 101,60 if I remove the discount… What is 101,60?
The result is different from the sum of the parts.
In the current Italian e-invoice XML, I have to specify the tax base, and if I put the number that IP gives me it will be wrong.
For reasons like this, like @ComputingFroggy said, in most countries, you cannot discount after-tax, period.
If you do solve both ways, it’s clear that with this system you are taxing the wrong amount, look:
Step 1:
Before tax: ((100 - 10) + ((100 - 10) / 100 * 19)) = 107.1 euro
After tax: ((100 + (100 / 100 * 19)) - 10) = 109 euro
Step 2:
Before tax: (90 + (90 / 100 * 19)) = 107.1 euro
After tax: (90 + (100 / 100 * 19)) = 109 euro
The tax bases are both 90, but you are taxing in the second case the full amount and not the discounted amount.
The difference between the two prices is the 1.9 euro in excess you are adding, look:
This is the reason why this change should be made as soon as possible,
cause aside DE and how is done there, for the rest of us, the calculation is literally wrong.
In the same breath, the different interpretations of how the taxes and discounts are applied is a good motivation of not rushing into the completion of the process while it is not properly speced out.
Since this will be new functionality, I would rather all possible scenarios be specified and build, instead of catering for one market and re-coding later on, which become expensive (in terms of time, complexity, stability etc).
You are wrong with this statement.
Taxes in the secon example are 17.40€ not 19.00€! So we are not taxing the full amount.
Pls understand this. This is how it works in germany and I can say that its not working the same way in other countrys.
(I marked what you did wrong)
Here is how “After Tax” is done right:
After tax: (91.60 + (91.60 / 100 * 19)) = 109.004 euro
But as 91.60 stands for 91.5966386555€ (as it is rounded) so its basically :
After tax: (91.5966386555 + (91.5966386555 / 100 * 19)) = 109.00 euro
Now you also know what the “91.60” stands for.
To leave a few words about it:
If you give a discount, who are you giving that discount for? For you or for your client?
Most probably for your client. So if you give a discount of 10€ the client in the end should pay exactly 10€ less then before, right?
So in the end he should pay 109.00€ if the product costs 119.00€ (with 10€ discount).
If you calculate discount after taxes you will make more profit.
I understand that this is not the case in other countrys. But this feature will not make it into IP before v1.6.0. Other countrys are working differently and InvoicePlane should aim for statisfying the international market. There are open Feature Requests and they will be implemented.
To make this happen we first have to get IP back on track. IPv1.5.10 is a big step for this, as its the first release since abount 2 years which will make sure IP is up to date. IPv1.5.XX will not include any new features or any new functions, its a maintain release.
We are not getting anywhere with this discussion, anyway like it is right now most people cannot use it without jumping the discount system all together, it’s fine to do it at v1.6.0, leaving v1.5.9 as a fixup, in the meantime I’ll fork from our end, until fixed.
Since it’s America the first user base, and America uses before tax by default, I would consider this a priority.
I also ask myself how the program does/will do accounting, since the subprice from the article side and the calculation side are different? Offsetting all the calculations?
Back on the discussion:
I think I know what you are doing @Martin_Anonym, I think I got it:
This is the problem! You are definitely not doing after-tax! you are doing before-tax equating to the discounted amount.
Look:
final_price_not_discounted - discount = before_tax(x) --> x is the amount needed to arrive to that price, but you are using before-tax formula!
So @Martin_Anonym you didn’t understand the point of the conversation, you are still using before-tax formula but you are offsetting an amount to get the 10 euros from the final price. This is not like using after-tax discount. IP is using after-tax discount. And this is wrong.
