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