Re: 1.3: Taxes, sub cent invoice amounts and non sub-cent payments

[John Locke <..hidden..>]

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 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.

!DSPAM:53065f3033401444519702!