Re: [Ledger-smb-devel] 1.3: Taxes, sub cent invoice amounts and non sub-cent payments
On 02/20/2014 05:29 PM, Chris Travers wrote: In 1.5 I think we need to have currency-specific display precisions, plus the following: 1. Tax-specific rounding precisions (so we can unify the Rounding and Simple modules). 2. A rule which says that the total invoice amount, unless specified otherwise, will be rounded to the default currency precision. The difference would need to be recorded against a rounding balance account (equity?). This should be sufficient to cover every case out there. Agreed, this seems like a fine approach. Cheers, John Locke http://www.freelock.com -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
[Ledger-smb-devel] 1.3: Taxes, sub cent invoice amounts and non sub-cent payments
Hi all, The other day, John and I were chatting on IRC, discussing the issue of sub-cent transaction amounts that may be calculated and posted by 1.3+ So, let me start to explain the issue: when LedgerSMB calculates taxes, it doesn't round the resulting tax amount. This means the tax liability is increased by sub-cent amounts in such cases. On the other hand, the AR or AP summary account is also posted with this sub-cent amount. The printed invoice doesn't show this accuracy, not is the customer expected to pay with sub-cent accuracy. By consequence, the AR account has a lot of sub-cent items which are to be considered closed. They will never be cleared beyond the level that they are. So, why does LedgerSMB work this way? Imagine owning a business with many small transactions. Let's assume they ask get rounded down with respect to the tax. Since the tax authorities calculate the total tax to be paid over total sales, not per transaction, each invoice increases the tax liability account by a little too little, if rounding is applied. What issues do we have with the current behavior? 1. Open items with sub-cent amounts due will never be completely closed 2. Because of (1), AR and AP summary accounts may accrue amounts to stay there forever 3. There is no way to entirely clear the AR/AP summary account nor the tax account, since the only way to enter sub-cent amounts into the books is by creating AR/AP transactions (GL transactions don't allow sub-cent values) 4. Due to number (3), there's no way to clear the tax liability account as part of the year-end books-closing procedure that both John and I seem to have. Now, to solve these issues, John suggested we should never record the tax liability with greater precision than what has to be paid to the tax authorities. In John's case (US), that would make sense, because every penny he calculates in sales tax, he has to submit back to the tax authority. However, in my case, it doesn't make sense, because I'm allowed to cut off the cents of my VAT before reporting to the tax authority (NL). In my case, it would mean that we'd never record more precision than 1EUR; with VAT rates of 21% and 6%, no tax would get recorded for sales below 4.76EUR and 16.67EUR respectively :-) Personally, I do see the benefit of getting a cumulatively correct tax calculation (ie. something roughly similar to what we do now). This feature would be especially important for shop sales with high transaction volumes and low average invoice amounts. It means that I can simply trust my books to give me the right tax liability figures and I don't have to redo them at the end of each quarter (apart from rounding). I do perceive the 4 mentioned issues as real issues though. Please provide your feedback as to whether you see other issues apart from the 4 ones mentioned above. Assuming the 4 issues above are the main issues to be solved, I would like to propose the following resolutions: 1. Only ever post rounded amounts on the AR/AP summary accounts, like they are printed on the invoices by using a separate account to post the rounding differences on; this allows the tax liability account to reflect the correct tax amount (when rounded) and accrue the right amount over time without the need for re-calculation. [this means the tax account will still be posted to with sub-cent amounts; AR/AP summary accounts won't] This solves the problem that the amounts can never be completely closed. 2. (1) solves the potential ever-increasing (or decreasing) amounts on the AR/AP summary accounts as well 3. Mark some accounts as acceptable sub-cent GL transaction entry; the rounding differences account would be such an account, as would the tax liability account This scheme makes it possible to clear any sub-cent amounts between the rounding account and the tax liability at whatever interval required. 4. (3) allows the year-end closing procedure to reset the tax liability account to be cleared against the amount actually paid out to the tax authority This scheme works for my own 1EUR - rounded - VAT reporting and from what I can see might work for John's 0.01USD (unrounded) sales tax reporting. One last remark: if the current approach (ie the one with the above mentioned issues) is a really wrong direction, it'd be good to have this discussion resolved before we release 1.4: if it's wrong, better to remove it from 1.4 from day 1. If it can be improved upon - and we can gradually roll out the improvements - there's no reason not to do that in a patch release. However, I'd like the patch releases to stay as close as possible to 1.4.0's configuration and workflows [element of the least surprise]. So, what are your opinions? Regards, Erik. -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to
Re: [Ledger-smb-devel] 1.3: Taxes, sub cent invoice amounts and non sub-cent payments
Hi, Just to clarify my position, I believe that the current behavior of storing sub-cent amounts in acc_trans is flat out wrong. We don't invoice the customer in sub-cent amounts -- we invoice and collect an amount rounded to the nearest cent. Anything more precise than that does not reflect the reality of our books. Rounding errors are going to occur, when in tax collection you round for each invoice, but on tax payment, you round based on the total. The question is, is this amount ever enough to cause you to want to know exactly how many pennies more you might need to send to the tax authority? The current state leads to confusing books, because they don't reflect the real transactions. Balancing out rounding errors is a common enough, and understandable thing for an accountant to handle (and I'm sure they have to do this with other accounting systems). While it may be nice to know the actual liability you've accrued for tax purposes, does this ever amount to enough to be worth our time? In my case it's never more than one or two cents, and just plain not worth any time spent on it whatsoever -- but the current case can lead to maddening state of the books. But I think we can't make a blanket precision for rounding. This is an easy question for USD, and many currencies. It sounds like for Erik/EUR, there are different rounding rules that might add up to more -- what's the worst-case amount for rounding to be a problem? And, as we start to delve into BTC, we need to allow far more precision there. Perhaps we need currency-specific, configurable rounding precisions? (by the way, there might be a large new user base if we support BTC out of the box...) I guess my interest is having my books match my bank statements and any customer invoices. I don't want phantom fractional transactions appearing -- they should reflect exactly the transaction that took place, and any other behavior is wrong, IMO. -- John Locke Principal, Freelock Web Sites That Make Your Organization Run Better http://www.freelock.com On 02/20/2014 12:01 PM, Erik Huelsmann wrote: Hi all, The other day, John and I were chatting on IRC, discussing the issue of sub-cent transaction amounts that may be calculated and posted by 1.3+ So, let me start to explain the issue: when LedgerSMB calculates taxes, it doesn't round the resulting tax amount. This means the tax liability is increased by sub-cent amounts in such cases. On the other hand, the AR or AP summary account is also posted with this sub-cent amount. The printed invoice doesn't show this accuracy, not is the customer expected to pay with sub-cent accuracy. By consequence, the AR account has a lot of sub-cent items which are to be considered closed. They will never be cleared beyond the level that they are. So, why does LedgerSMB work this way? Imagine owning a business with many small transactions. Let's assume they ask get rounded down with respect to the tax. Since the tax authorities calculate the total tax to be paid over total sales, not per transaction, each invoice increases the tax liability account by a little too little, if rounding is applied. What issues do we have with the current behavior? 1. Open items with sub-cent amounts due will never be completely closed 2. Because of (1), AR and AP summary accounts may accrue amounts to stay there forever 3. There is no way to entirely clear the AR/AP summary account nor the tax account, since the only way to enter sub-cent amounts into the books is by creating AR/AP transactions (GL transactions don't allow sub-cent values) 4. Due to number (3), there's no way to clear the tax liability account as part of the year-end books-closing procedure that both John and I seem to have. Now, to solve these issues, John suggested we should never record the tax liability with greater precision than what has to be paid to the tax authorities. In John's case (US), that would make sense, because every penny he calculates in sales tax, he has to submit back to the tax authority. However, in my case, it doesn't make sense, because I'm allowed to cut off the cents of my VAT before reporting to the tax authority (NL). In my case, it would mean that we'd never record more precision than 1EUR; with VAT rates of 21% and 6%, no tax would get recorded for sales below 4.76EUR and 16.67EUR respectively :-) Personally, I do see the benefit of getting a cumulatively correct tax calculation (ie. something roughly similar to what we do now). This feature would be especially important for shop sales with high transaction volumes and low average invoice amounts. It means that I can simply trust my books to give me the right tax liability figures and I don't have to redo them at the end of each quarter (apart from rounding). I do perceive the 4 mentioned issues as real issues though. Please provide your feedback as to whether you see other issues
Re: [Ledger-smb-devel] 1.3: Taxes, sub cent invoice amounts and non sub-cent payments
This is not an official position but the tax authorities do not seem to be as worried about sub cent tax amounts as in getting as much money as possible. Here in Canada it used to be that amounts of less than $1 were neither owed nor paid on personal tax forms. For quite a few years (at least 8 or 10) it is now $2. The government has also eliminated the penny and clarified the position on rounding. I would make sure that the tax boys get what they are owed with excellent mathematical rounding. Now if you are handling large enough numbers of sub cent transactions (hundreds of thousands per year (now you are talking a total amount that might reach $500 statistically)) I would be asking my tax authority for clarification. If not - - - - 'let sleeping dogs lie(). Darald On Thu, Feb 20, 2014 at 7:29 PM, Chris Travers chris.trav...@gmail.comwrote: On Thu, Feb 20, 2014 at 12:17 PM, John Locke m...@freelock.com wrote: Hi, Just to clarify my position, I believe that the current behavior of storing sub-cent amounts in acc_trans is flat out wrong. We don't invoice the customer in sub-cent amounts -- we invoice and collect an amount rounded to the nearest cent. Anything more precise than that does not reflect the reality of our books. There are plenty of cases where you want to be aware of subcent amounts. For example, we handle asset depreciation with subcent amounts (so that in aggregate things work out over time). There may be cases where interest accrues in subcent amounts where this is important. For example, Amazon Payments owes my business a fraction of a cent for this reason. The problem described I think is somewhat more specific than that, namely that summary lines representing the total for ar/ap need to match what is expected to be settled. Usually this is going to be no more precision than the currency allows for but there may be exceptions to this. Rounding errors are going to occur, when in tax collection you round for each invoice, but on tax payment, you round based on the total. The question is, is this amount ever enough to cause you to want to know exactly how many pennies more you might need to send to the tax authority? I would think that having confidence in an accounting system requires answering that question in the affirmative. There are also a large number of other cases where subcents become important, such as: 1. Suppose we want to add automatic handling of taxes on gross invoice amounts, like Washington State BO tax so that the liability of the year to date gets shown in the balance sheet. You can't do that safely without subcent tax handling. 2. Suppose someone is handling compounding interest. If you have, say, 3% apr interest compounded, say, monthly, you can't handle what happens if you start with $1.00, add $1.00 in six months, and withdraw $.50 two months later. This can't be done without handling fractional cents. So I don't think it is as simple as saying that fractional cents should never be recorded. I *do* think that invoices need to be recorded for ar/ap purposes for the exact amount that is intended to be settled. We can discuss how to handle simple interest as a late fee later. But I think we can't make a blanket precision for rounding. This is an easy question for USD, and many currencies. It sounds like for Erik/EUR, there are different rounding rules that might add up to more -- what's the worst-case amount for rounding to be a problem? The worst case is where you have industry-specific rules like compounding interest on customer deposits. And, as we start to delve into BTC, we need to allow far more precision there. Perhaps we need currency-specific, configurable rounding precisions? Certainly one needs this as well, but consider the questions of exchange rates (by the way, there might be a large new user base if we support BTC out of the box...) I guess my interest is having my books match my bank statements and any customer invoices. I don't want phantom fractional transactions appearing -- they should reflect exactly the transaction that took place, and any other behavior is wrong, IMO. Right. Here's what I have done for 1.4. I think we should look at unifying the solution a bit better in 1.5. I added a new rounding tax module, which allows you to round your taxes to your current money precision settings. This should solve your specific problem. However, when dealing with bitcoin you have some additional issues, namely the fact you have an exchangerate and a different precision. This would need to be handled somewhat differently. I.e. you want your USD balance for the transaction in your case to be rounded to $0.01 and you want your bitcoin amount to be displayed to a much higher precision (but that's a foreign exchange amount). I don't know if it is enabled by default on upgrades. If not that is a bug and I will fix it. In 1.5 I
