Craig Bennett wrote:
>
>> If you want to take a particular system out to extra digits, it's
>> probably good to record the rounding error as a separate component of
>> the transaction (that is, if you want everything to balance out
>> perfectly).
>>
>>
> I think you have two different problems here. On the one hand you have
> rounding errors which are material when aggregated on the other hand
> most sales transactions (for example) will come to a dollar and cents
> figure. If you have two accounts with different precision then I think
> from an accounting perspective you need to say something like this
> when posting between the two:
>
> DR My 2 Decimal Precision Account 2.00
> DR Accumulated Rounding (4 Decimal) 0.0010
> CR Original 4 Decimal Account
> 2.0010
>
> Then at period end you can including your rounding account and
> everything will balance.
>
>
> Craig
Thats not the problem its the different tables having different
precision. We have a WIP tables that notes all the labor and
material consumed by all the jobs for an accounting period. So you have
some jobs all ways open crossing periods so you need to audit that WIP
process account which means going to the WIP tables and verifying that
the values in the WIP account equal to the jobs in the WIP tables. If
the detail differs even a a penny you have a problem you are not allowed
to simply call it rounding error. Pushing it into another account
called rounding error does not solve the problem. Values in the wip
tables need to equal the values in the General ledger tables
The problem occurs when the WIP tables store 6 and 8 decimals and the GL
tables have only 2. it creates all kinds of rounding problems and it
gets worst when you have thousands of transactions a day a penny
multiplied by 1000 becomes 10 bucks times 30 days in a accounting period
= 300 bucks. Thats getting pretty big for a rounding mistake and this
is only one account. Now take that and multiply that by 10 accounts
each going every which way.
