trial balance - how to find mismatch question
david.carlson.417 at gmail.com
Mon Mar 5 21:57:27 EST 2018
David T, I guess you do not have any IRA's or 401-K's as the IRS requires
every custodian to file either a "Fair Market Value" form or a form 5498
which includes the fair market value for each account. The "as of" time is
calendar year end.
When you turn 70-1/2 you get to take a "Required Minimum Distribution" each
year based on a formula outlined in Publication 590-B which uses the Fair
Market Value and an actuarial table. If you do not take the RMD, you pay a
fine and take it anyway.
While I would not depend on GnuCash to make an accurate report without
checking on every part of the data that it used to make the calculation and
check it in an external spreadsheet where I can actually see every number,
I like to try to verify that my custodians used the method I think they
should use to calculate realized gains long and short where needed and to
accurately report FMV so that my RMD is correct.
I did not intend to be unwitting about the problems with getting an
accurate balance report out of GnuCash, you are correct to call it
Quixotic, and I would capitalize that adjective, if it is one. In fact, I
was trying to underline some of the issues that I have personally
On Mon, Mar 5, 2018 at 8:08 PM, David T. <sunfish62 at yahoo.com> wrote:
> David Carlson,
> > On Mar 6, 2018, at 4:27 AM, David Carlson <david.carlson.417 at gmail.com>
> > Adrien, I think that you summarized the problem with "nearest in time"
> > nicely. Wm, no doubt, had tongue in cheek when he was assigning a high
> > value to future prices. You clarify that reports are often run "as of"
> > historical dates (and often need to match accounting reports submitted to
> > government agencies) thus could be exposed to erroneous values assigned
> > after the "as of" date by the "nearest in time" criterion.
> Can you clarify the reports that you submit to governmental agencies that
> use market value? My government (the US) doesn’t require any reporting of
> asset market value that I am aware of. As far as I know, the only reporting
> that is required is actual, realized, gains—and not book value of holdings.
> And as far as I understand, GnuCash doesn’t use price db entries to track
> this information; the preferred methods (as outlined in various sources) is
> to enter the gains literally, based on the price entered and stored in the
> > Your final note that ideally the prices would always be downloaded on the
> > date they are needed for the report is true, but as a practical matter it
> > is sometimes difficult to do, as the prices are often posted on the
> > internet several hours after the respective closing bell, and now that
> > F:Q module is sometimes unable to acquire some prices on the first pass,
> > is sometimes problematic whether it has even succeeded in getting all the
> > needed prices. If it is done by a chron job, the job would need very
> > intelligent error handling capability to be confident about success.
> Here, I think you unwittingly point to a significant problem inherent in
> trying to track market value of even a moderate portfolio: there is no
> means of determining the effective valuation date. If, as Adrien points
> out, you retrieve prices monthly, then the values can be almost a month out
> of date. If, as you point out, some prices fail to update, then some may be
> from last week, while others from today. So, obtaining an accurate
> valuation is a significant challenge. Perhaps this suggests that the entire
> portfolio valuation proposal is quixotic in its goal of Absolute Valuation,
> and should be considered only as a rough guide at best?
> David T.
> > If a developer wanted to expand the scope of the price download module to
> > allow downloading "as of" prices for arbitrary historical dates, I think
> > many of us would buy him a beer. Alas, right now I fear that the
> > active developers have too many other things on their plates.
> > David C
More information about the gnucash-devel