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!
------------------------------------------------------------------------------
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=121054471&iu=/4140/ostg.clktrk
_______________________________________________
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel