GNOME Bugzilla – Bug 443967
Allow Gross Revenue based Sales Tax Calculation for Brasilia
Last modified: 2018-06-29 21:38:27 UTC
Tax Charge works different from what the manual says. => THE MANUAL Tax Included? - has the tax already been included in the unit price? X means yes, a blank field means no. For example, if there is 1 item of $100 with a tax of 5% then: If Tax Included is empty, then subtotal = $100 and tax = $5. If Tax included is set (X), then subtotal = $95 and tax = $5. => WHAT REALLY HEAPPENS Scenario: * The final value of the invoice: 100.00 * Unit: 1 * Unit Price: 100 * Taxable?: Yes (X) * Tax Included?: Yes (X) * Tax: 5% The result is: * Subtotal: 95.24 (NOT 95.00) * Tax: 4.76 (NOT 5.00) Conclusion: On the calculation, the system is taken 5% out of 95.24 and not out of 100 as the manual says. In my case, specially, I need it to work as the manual says.
Thanks for reporting this problem. However, I don't fully understand your description. First of all, when you refer to the manual, can you please give a precise section number or URL of the on-line version http://www.gnucash.org/docs.phtml ? Secondly, I rather think the description in the manual has wrong numbers. 5% of 100.00 are 5.00, but 5% of 95.00 are surely *not* 5.00 but instead a little bit less. In fact, if you have a $95 subtotal and $5 tax, then the tax is rather 5/95*100 % which is 5.26 %. Is this what you were looking for?
Following is the link to where you can find it in the manual: http://svn.gnucash.org/docs/guide/bus-ar-invoices1.html#bus-ar-invoiceedit2 Here is how it works (at least here in Brazil and in most countries) and how it is described in the manual. You have 2 ways to charge your customer: 1. The TAX is INCLUDED in the agreed value for the service/product (this is the case that is wrong on the software and right on the manual) In this case the sum of the items in the invoice is exactly what your customer will pay. So if you have a total tax of 5% out of $100, your customer will pay $100 and you will pay $5 to the government. 2. The TAX is NOT INCLUDED in the agreed value for the service/product In this case the sum of the items in the invoice is NOT what your customer will pay. So if you have a total tax of 5% out of $100, your customer will pay $105 (yes, it is 5% out of $100) and them you will have to pay 5% out of $105 to the government. Actually here in Brazil, the government let you charge $105 from the customer, but you will pay 5% out of $105 and not out of $100 as in most countries. Here in Brazil we still have another way that mixes both 3. You have many taxes here so some can be included and some must not be included But I am not going to discuss this at this point. Maybe for further discussion I would recomend: * Each group of taxes has its formula, instead of having TAX INCLUDED and TAX NOT INCLUDED only. The formula would be based on the following variables: $value_of_the_item, $tax and any other number that can be entered by the user * Each item on the invoice can be associated with 1 or more group of taxes This two items will probably solve any need for tax calculation around the world.
In my opinion, first of all the software should be fixed to do exactly what the manual is telling. That is: > Tax Included? - has the tax already been included in the unit price? X means > yes, a blank field means no. For example, if there is 1 item of $100 with a tax > of 5% then: > > If Tax Included is empty, then subtotal = $100 and tax = $5. > > If Tax included is set (X), then subtotal = $95 and tax = $5. "Tax included is set (X), the subtotal = $95 and tax = $5" => this is not working as the manual says. This is a MAJOR problem because many users may be paying wrong tax values.
I'm not sure who wrote the documentation because GnuCash has ALWAYS computed "taxincluded" this way and nobody has ever pointed out an error. It's been this way for over half a decade, since the gnucash 1.7 series. If anything the documentation should get corrected to explain the current implementation, which is: (1 + Tax%) * Val = Total This is always how it's computed; it's just a question of which value is entered by the user, the Val or the Total. The "Val" entry is the US way. The "Total" entry is the "Taxincluded" way. If this is incorrect for some locales then please forward me real government tax documentation that shows that this is the incorrect calculation. Until I see such documentation I believe this is just a GnuCash Documentation bug.
Ok.... I understand.... But at least here in Brazil it will be impossible to send you this documentation, because the formula (calculation) is defined for each tax, and we have almost 80 different taxes here (but there are less than 10 that companies normally pay). But there is a pattern for that. After your comment I decided to study further more about taxes here and I realized that for one type of company (that represents the majority here) you should compute tax as following: (Tax% * Val) + ((1 - Tax%) * Val) = Total => This would be our Tax Included For example: * Sum of services charged: $100 * Tax: 5% Result: * Total on the invoice: $100 * Tax: $5 This would be perfect for most of our companies here. The kind of documentation that I can send you are websites that have links for each tax and some websites that tries to summarize this issue. List of all taxes http://pt.wikipedia.org/wiki/Lista_de_tributos_do_Brasil http://www.portaltributario.com.br/tributos.htm Summaries about the issue http://ultimainstancia.uol.com.br/artigos/ler_noticia.php?idNoticia=32091 http://www.leigeral.com.br/oquemuda.asp Maybe an option to create a new tax calculation based on variables TAX and VAL would solve any kind of problem regarding this issue. Thanks for attention as allways
Unfortunately my Portuguese isn't sufficient to understand these articles. but it sounds like we need TWO "tax included" computation methods, the existing version: (Val * Tax%) + Val = Total and (Val * Tax%) + (Val * (1 - Tax%)) = Total This wont happen in 2.0, and probably wont make it into 2.2, either, as we're already in string freeze. Even worse, this will require a change to the data file format in order to store this. :(
(In reply to comment #6) > Unfortunately my Portuguese isn't sufficient to understand these articles. but > it sounds like we need TWO "tax included" computation methods, the existing > version: > > (Val * Tax%) + Val = Total > > and > > (Val * Tax%) + (Val * (1 - Tax%)) = Total > > This wont happen in 2.0, and probably wont make it into 2.2, either, as we're > already in string freeze. Even worse, this will require a change to the data > file format in order to store this. :( > Exactly. It solves most of Brazilian companies needs. I will try to look after any other possibilities to help you out, but for now that is it. It is sad that it will take that long. I have been using gnucash for quite some time as my personal finance software (it is awesome) and I was intending to start using it as my company financial software so that I could have more financial control as well as budget control. Anyway I will look forward to see this in a future version. If there is anything I could do to help you out just tell me. Thanks in advance
I found 2 documents in english about brazilian taxes 1. This document is from our government website http://www.receita.fazenda.gov.br/principal/Ingles/SistemaTributarioBR/BrazilianTaxSystem/default.htm 2. This document is from a lawyer firm http://nbb.com.br/public/memos2.html
Thanks for the links. Unfortunately neither of those links seem to provide an insight into which tax calculation to make.
Regarding this issue, the ICMS does not appear to be a True sales tax, which is why it is causing the problem our Brazilian friend is talking about. However, if the resources I'm reading our correct, it should be calculated at time of sale. As for a workaround to allow for it, would it be reasonable to define a limited "Tax Equation" language that could be maintained within GnuCash which would allow a user to define the Equation used for a given Tax Classification? GnuCash would, of course, ship with a selection of 'standard' tax calculations. If this seems like a reasonable solution, I may check out HEAD, and investigate implementing it.
It is not only the ICMS, but definitely your solution would solve every problem related to taxes (at least as far as I can imagine). Creating a "Tax Equation" with variable such as "Tax", "Val" and "Total", besides numbers of course, I believe would solve it all.
It's a BIT more difficult than this, but I do think that some language would be useful. Once you start running down this road, however, you need to start thinking big, like "Payroll Taxes". In this case you need to be able to support an arbitrarily complex set of pre-tax and post-tax deductions from the gross value. Personally I was thinking that this could be done in Scheme. I'd certainly be interested in seeing your approach to the solution. Keep in mind that datafile changes need to be WELL thought out a priori.
Yes, Scheme would probably be a good choice, since it's already well integrated into GnuCash, and it doesn't require a separate parser for a small tax language. I've been meaning to learn Scheme anyway, are there any good resources one could suggest? I'll begin investigating the other Tax Issues as well. I use GnuCash for business, but I'm the only employee, so Payroll isn't really an issue. I'll have to run some test cases.
The MIT Scheme Reference is a good resource. (google for "MIT Scheme", maybe add "manual")
For the record, I've updated the documentation to reflect the current implementation. See http://cvs.gnucash.org/docs/guide/bus-ar-invoices1.html#bus-ar-invoiceedit2 under "Tax Included?"
Hi guys, How is the evolution on the code of this topic? How may I help you guys? I still have lots of interest in using GnuCash as our main finance application, but I still can't because of this problem. Just to remember the problem and give you guys a real example that we have here. Real Situation: - I have just issue an Invoice for a client for the value of R$6.000,00. - Out of this value my client will have to retain part of the money to pay some taxes. Here are the taxes and values: - IR (1,50%) => R$90,00 - PIS (0,65%) => R$39,00 - COFINS (3,00%) => R$180,00 - CSSL (1,00%) => R$60,00 = TOTAL (6,15%): R$369,00 - My real income on that will be R$5.631,00 (R$6.000,00 - R$369,00) - When I generate an invoice I create a commitment with the government to pay some more taxes out of the total value of the invoice (some in the next month and some from 3 to 3 months) - ISS (0,60%) => R$36,00 - IR (0,90%) => R$54,00 - CSSL (1,88%) => R$112,80 = TOTAL (3,38%) => R$202,80 - My result after the taxes will be R$5.428,20 (R$5.631,00 - R$202,80) Summarizing - Invoice Total Value: R$6.000,00 - Total Taxes (9,53%): R$ 571,80 - Income: R$5.631,00 - Result (after taxes): R$5.428,20 I know.... This is absurd.... Brazilian taxes are amazingly stupid.... Unfortunately this is how things work around here.... Thanks again.
Comment #15 said the documentation is fixed to say what the program will do. The rest of this report is about implementing a new feature (some part of the Brazilian schemes), but this is not an error anymore.
I think, it is simple algebra: net value + tax = gross value. So in most countries the formula is 100 + t = gross value, but in BR net value + x = 100, so x = t / (100 - t), in your case, if I understand the above right, t = 9,53% -> 100 - t = 90,47% IR (1,50%) => 1,5% / 90,47 = 1,658...% net based PIS (0,65%) => 0,65 / 90,47 = 0,718...% net based : Total_Tax_Rate: 9,53 / 90,47 = 10,53...% Now you should put for better precision the formulas instead of the numbers in your tax table: Taxas_9_53: 9,53 / 90,47 I think, in a first step we could simply add a checkbox option "gross value based tax rate" with the hint "currently only known for Brasilia" to the tax table dialog and do the conversion between gross value based and net value based rate in the dialog before storing the net based rate. The inverse function would be: t = x/(100+x) But if the tax rate should be shown on the invoice, the option should be stored in the data file and the inverse function must be called before the display.
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=443967. Please continue processing the bug there and please update any external references or bookmarks.