trial balance - how to find mismatch question

[David Carlson]

I am not a custodian but neither do I trust my custodians to remain 100%
invulnerable to hacking, so I continue to monitor their reports and check
them for accuracy.  If all the numbers in GnuCash are correct, the GnuCash
reports can line up next to the trustees reports and usually agree to the
penny.  That makes checking a pleasant, if quixotic activity.  :-)

David C

On Tue, Mar 6, 2018 at 11:15 AM, David T. <sunfish62 at yahoo.com> wrote:

> BTW, quixotic, while based on the famous Don Quixote, is a non-proper
> (improper?) adjective, and thus does not need capitalization. Whether you
> pronounce it “key-hotic” or “quick-sotic” depends on your personal
> predilection, as I undetstand it.
>
> David
>
>
> On Mar 6, 2018, at 7:57 AM, David Carlson <david.carlson.417 at gmail.com>
> wrote:
>
> 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
> experienced.
>
> David C
>
> 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>
>> wrote:
>> >
>> > 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
>> transactions.
>>
>> >
>> > 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
>> the
>> > F:Q module is sometimes unable to acquire some prices on the first
>> pass, it
>> > 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
>> currently
>> > active developers have too many other things on their plates.
>> >
>> > David C
>> >
>>
>>
>
>