On Thu, 10 Feb 2000 16:08:23 +0100, the world broke into rejoicing as
Herbert Thoma <[EMAIL PROTECTED]>  said:
> Jan Schrage wrote:
> > 
> > On Thu, Feb 10, 2000 at 10:00:35PM +1100, Robert Graham Merkel wrote:
> > > <snip>
> > >  > > For profit and loss statements, however, the situation is a little
> > >  > > different.  To figure out the overall profit for an accounting perio
d,
> > >  > > you need to count only that income and the expenses for that period.
> > >  > >
> > >  > > Am I missing anything here?
> > >  >
> > >  > How do you consider stock price changes? If you enter a 'price' split 
in
> > >  > a stock register there's no transaction from/to an income/expense
> > >  > account
> > >  > associated with it, nevertheless you make a profit or loss.
> > >
> > > Correct.  However, I don't know how one accounts for such things.
> > > Can somebody provide some guidance here?
> > >
> > For tax purposes this is, I think, usually  not counted as profit. You
> > only make a profit upon sale. Since tax calculations are one of the more
> > important reasons for using an accounting program I suggest we use that
> > as a guideline.
> 
> Now how do you enter stock purchase or sale? I think as a transfer
> from a bank account to a stock account or vice versa. Again no
> income/expense account involved... (Exept for transaction fees ;-))

This is an ambiguous situation, as there are multiple *valid*
perspectives:

---> From the perspective of taxation, a gain on a stock that has not
     been "actualized" by sale at the higher price is *not* a
     gain/profit for tax purposes.

---> From my perspective as someone tracking the state of my
     portfolio, I don't care that the government doesn't think I've
     got a gain; I'm concerned about whether my portfolio is gaining
     in value, and I'm glad to see the gain.

> A solution to this problem is probably the account balance tracker
> report:
> Apply it to all accounts exept income/expense and it will yield a total
> net gain/loss.
> 
> I do not use Quicken or M$ Money. Does anyone known how these
> programmes deal with this problem?

Quicken provides reports that indicate portfolio value.  I'll ought to
look closer at what they may offer in terms of reporting that is
oriented towards tax reporting.

I'm not sure that they're offering that much in that regard.

And I'm not sure that this is something that we ought to be a whole
lot worried about either.  Consider:

a) Taxation of transactions can get far more peculiar than many of you
have likely seen.  When Odd Things Happen, and a tax professional gets
into the game, their analysis of the critical transactions is far more
important than the way things are recorded on the books.

b) We have no formal tax professionals involved with this project, and
thus have no place expecting to handle this with too much greater
precision than anyone else does.

c) It is entirely normal for the accounting records to be an
approximation, providing a summary of transactions that is the
*starting* point for computing taxes.

I've had some contact with both Canadian and US reporting; just with
regards to capital depreciation, the policies differ quite a lot:
 - In the US, it appears that there is a mandate to use, for public
   reporting, the same sorts of depreciation policies as are used for
   tax purposes.
 - In Canada, the financial reporting side commonly mandates using
   depreciation schedules that bear no resemblance to the Capital Cost
   Allowance system that defines depreciation for tax purposes.  As a
   result, you do up the accounts one way, and then, at tax time,
   reverse out depreciation and then put in CCA instead for the tax
   returns. 

That's a longwinded way of saying that the accounting software merely
provides a "draft" form of the financial results, and those results
will be modified to conform with taxation (and public reporting)
requirements.

There's no point in making *heroic* efforts to follow all the
peculiarities of tax law if the statements are going to get adjusted
anyways.

I'd be more concerned, on the other hand, by the operational matter of
handling things like sales taxes.  If you charge the wrong amount at a
cash register, there's going to be great grief.  If you charge too
little, you *can't* go back and charge them more if you don't have a
name and address.  (Leave aside the official embarrassment involved if
you call up a customer and tell them, "I'm sorry, but we're going to
have to bill you more for what you bought.")
--
Who's afraid of ARPA?
[EMAIL PROTECTED] - <http://www.hex.net/~cbbrowne/lsf.html>

--
Gnucash Developer's List 
To unsubscribe send empty email to: [EMAIL PROTECTED]

Reply via email to