Class accounting?

[Jeff Wiegley]

Well, I was composing a nice long response to Daniel's message
but in the end found that his small quips to me added up to
probably as much as he found my postings insulting. Sorry
Daniel.

So I guess since I'm insulting everybody with my discussion
I'll just deleted that response for fear of ticking everybody off
even more. I'll just summarize for posterity in case some other
poor Joe needs project accounting like I do and he can google my
thoughts in the mailing list archives in the future and save
himself the embarrassment of also being offending. Then I'll
leave you all alone. Current members need neither read this
nor reply; I guess it's just a record of my conclusions.

here's the summary: I need project accounting.

My original question was basically: "In gnucash, how do I account
for transactions related to a project so that I can attribute costs
and profit to a project."

Suggestions given:

Use split transactions. This is not an answer as it solves an
   entirely different, and useful, problem. (That is it aggregates
   the debit/credits from several other accounts under a single
   credit/debit in a target account.) Extremely handy for many things
   including ATM deposits containing multiple checks, Purchases
   for multiple items on a single invoice. Salary deductions and
   Loan payments. I have used split transactions for years in
   Quicken. None of this satisfactorily accounts for project details.
   Conclusion: off topic for project cost accounting.

Self suggestion: Use Quicken instead. It also doesn't do project
   cost accounting. I'll grant it doesn't even do vendor accounting
   properly since it sort of maxes out with "categories" and
   categories which are really nothing more than glorified
   description fields. Quicken small business does start to
   provide proper vendor support but is hiding the fact that
   vendors are accounts and that double-entry is taking place
   behind the scenes. Ok, use Quickbooks. That's where I'm tending to
   now. I'm a fan of open source. I've made a career based on it.
   I would like to switch to gnucash to avoid feeding corporate greed
   and having to deal with a Windows platform for the sole purpose of
   tracking accounting information. I would rather be delighted if
   gnucash could meet my needs. Even if that's done in an unorthodox,
   yet complete and accurate manner.

Make every project an account. summarize all vendor expenses or
   purchases under that catchall account. This is not acceptable
   because it produces gnucash account registers which do not
   correlate to financial statements. Your bank statement will say:
   "Paid $X to V" Where X is a dollar amount and V is a vendor.
   Gnucash will show "Paid $X to P" where P is a project. It is now
   a manual, doable yet error prone, process to cross-reference
   account and statement line items. Gnucash has also lost all vendor
   information with this scheme. Conclusion: unsatisfactory due to A)
   loss of information and B) discrepancy between account and
   statement.

Augmentation: Do the previous suggestion but also record the
   vendor's name in the transaction description. Conclusion: better.
   solves loss of information. Same discrepancy problem; statement
   says A->V while gnucash says A->P. Also error prone. Descriptions
   are arbitrary and prone to error. Were the other entries Ralphs,
   ralphs, Ralph's or Ralph's groceries? Vendors and/or projects
   should be one time creation items and then picked from a discrete
   list for each transaction to prevent errors such as typos.

Better augmentation: Make accounts for Vendors, place project names
   in the descriptions. This is an improvement. Statements and
   gnucash both indicate A->V. Only problem now is that projects
   can also be mistyped in the description field yielding the same
   report integrity problems when making queries about project costs.
   Was it doomsday or Doomsday, I forget. similar problem to previous.
   But this is the most accurate, complete method that I currently
   understand gnucash being able to support.

Use subaccounts. make every project an account and then under each
   project make subaccounts for each vendor. No loss of information
   little possibility of typos since accounts are one time creation
   items. Conclusion: problem exists with reporting integrity and
   and accuracy. Also suffers lack of conceptual cohesion by having
   single vendor account accounted for in multiple independent
   locations. Reports can be inaccurate by failing to mark all
   appropriate accounts for inclusion or by having the same types
   of typos in names.
     Expenses:Doomsday:McMaster
     Expenses:Gardening:Mcmaster-Carr  (oops)
   Possibly on par for accuracy and completeness as previous
   solution. Better due to discrete nature of Projects preventing
   some typos, poorer due to increased complexity of account levels
   while not adding additional capability or integrity. I'm tied
   for acceptability between this suggestion and the previous if
   I move forward with gnucash.

reverse you subaccounts:
   Expenses:McMaster:Doomsday
   Expenses:Mcmaster:Gardening
   Same problem, Doomsday might be entered "Doom's day" under a
   different vendor. Single items should be implemented in a single
   manner and should not rely upon tricks of nomenclature to suggest
   meaning. Imagine if mathematics texts did this: Let X be the
   square of the hypotenuse of a right triangle, let Y be the square
   of one the legs and let a different X be the square of the remaining
   leg.
   Then:
       X = Y + X
   therefore, through algebraic manipulation, one might incorrectly
   assume that:
       0 = Y
   (although in this the same name is representing independent
    variables versus the account being specified in independent
    locations. it no less presents an example of the type of problem
    you can get in to with tricks of nomenclature.) Labels are
    arbitrary, the underlying objects should accurately and closely
    implement the concept instances they represent. Nomenclature
    should not be relied upon to enforce behavior.
   Also suffers from A->V versus A->P problem.

I also want to put forth this observation:
Projects should not be accounts. Accounts have assets of measurable
financial value. Projects do not; they are virtual. Project
accounting is primarily intended to serve the internal analytical
needs of a company. Accounts serve external account reporting
needs as well as internal. (please don't nit pick my summary, I'm
fully aware that many organizations need to report project
activities and success to external agencies as well as for internal
use. I'm just trying to lay the groundwork for my conclusions.)
As I think about it, transactions happen between accounts while
Projects are more the cause of the transaction, not the source or
destination of the transaction. I'll spend a lot of time next
week with a CPA of forty+ years of accounting and financial
management experience and see if I can't get a better understanding
of this. Maybe I'm wrong and hopefully I'll figure that out next
week. But I'm willing to stack up the accuracy and completeness of
my personal and business accounting records to those of anybody
else. I'm pretty sure I've got an excellent grasp of accounting
principles already.

I apologize if I missed anybody's suggestions; I think I covered
all the methods suggested. I also want to point out that I know
some of the negative analysis points are manageable given small
numbers of projects or vendors. If you have three projects, it is
relatively easy to manually verify the spelling of accounts or
descriptions and to verify account inclusion in reports. But for
larger numbers of projects or vendors and given that the system
may need to be operated by a variety of employees who may not
understand database concepts like normal forms and such these
analysis points are valid. gnucash should address them if it is
intended to compete with the likes of QuickBooks or Peachtree. If
the gnucash goal does not include robust enterprise accounting
features then, of course, I am out of line and this is all moot.

I close with an implementation suggestion.
   GnuCash should support an editable list of "classes" or "causes",
   to provide a name for projects ("projects" seems too specific
   and there may be activities or reasons one wants to attribute
   transactions to that would not fit the definition of a project.
   For instance process management policies and practices might
   cause/incur monetary transactions and would nearly be the
   antithesis of a project.)

   Each transaction should have a field allowing it to be associated
   to a single specific class and a direction (whether the direction
   of value flow should be counted as a credit due to the project or
   a debit. The association would not affect any information about
   the accounts the transaction actually took place between.

   The class could then be viewed as a pseudo-account. whereby the
   "view" would simply locate and present all transactions tagged by
   the class and list the transaction as a debit or credit to this
   pseudo-account based on the bias of the direction assigned to the
   association.  No method should be provided for the editing of
   the virtual transactions presented in the pseudo-account view of
   a class. (You couldn't add, delete or modify line items in the
   pseudo-class view.

Though I may have to give this some more thought as it is not
entirely clear to me yet whether one to one associations between
classes and transactions are sufficient to properly represent
enterprise business accounting practices and I have a few tugs of
doubt about the existence of other unrecognized insufficiencies.
For instance: subclasses I quickly think might be useful. I
have advanced project needs but I certainly wouldn't call them
enterprise class so I could be missing something useful to those
fish larger than myself. But I think any change to gnucash like
this should be designed cleanly and well enough to ultimately
support an enterprise environment.

Thanks for your help,

- Jeff

Daniel wrote:
> Jeff Wiegley wrote:
>>> No, you create accounts for each *project*.  You can create
>>> sub-accounts for vendor.
>>
>> That does not work.
>>
>> A single vendor can support multiple projects. Which project
>> should you stash that vendor under? Whatever you select is wrong.
> 
> 
> Expenses:Projects:Doomsday Weapon:Ralphs
> Expenses:Projects:Gardening Robot:Ralphs
> 
> 
>> Each invoice or receipt (or even portion of a receipt) should
>> be attributable to any project account
> 
> Split transactions.
> 
> 
>>>> The problem is that this doesn't extend to projects.
>>
>> see?
> 
> Actually, I don't. I don't understand what you mean by extend.
> 
>>>> But I can't put the McMaster account under "doomsday weapon"
>>>> because then all purchases for the gardening project also
>>>> get accounted for under the doomsday project. I can't put
>>>> McMaster under the gardening project for the symmetric
>>>> argument.
>>
>> And there is my example of why you can't have projects as
>> accounts and vendors as subaccounts. Unless I guess you are able
>> tp create two different subaccounts under their respective projects
>> accounts with the same name.
> 
> Yes.
> 
> Expenses:Doomsday Weapon:McMaster
> Expenses:Gardening Robot:McMaster
> 
> 
>> But that is also asking for trouble
>> which I am not going to get into here unless you want me to. The
>> problem with two different accounts with the same name should be
>> obvious.
> 
> It is not obvious to me. What's the problem? Some times I have accounts 
> with the same name under different parent accounts.
> 
> 
>> Splits are simply the aggregation of multiple, individual transactions,
>> to produce a single credit or debit amount that matches some statement,
>> or invoice record.
> 
> No they are not. For example, consider the following split:
> 
> Assets:Banks      -> - $300
> Expenses:Interest -> + $130
> Liabilities:Loan  -> - $170

I'm sorry, I cannot resist challenging this one item. It is so much
two separate transactions aggregated into one line that the two
transactions are attributable to entirely different tax schedules
(at least if we are talking about a home loan in the US). One
transaction is the bank charging you for $130 which you agreed to pay
them for the use of their money. The second is an amount of
$170 to pay off a portion of the outstanding principle which you agreed
to in order to maintain their trust in you. The bank was just nice
enough to let you write a single check to cover both charges. Two
different chunks of value moved between different account pairs.

I'm ok if you want to consider it a single "transaction". It is
in a sense a thing that only requires you go through the motions of
a single gnucash transaction entry. Kind of a Poh-tato vs Pah-tata
argument I could admit. But it still doesn't solve any project cost
accounting needs.

> 
> This is a single transaction that affects three accounts, not two 
> transactions. I did not make two loan payments, I made one. Part of it 
> went toward the principal and part was interest. You _could_ whack it 
> into two transactions, but that would be _wrong_ not just because it 
> doesn't match the bank statement but simply because that is not what 
> really happened. I did not make two payments, I made one payment that 
> had an expense component and a liability component.
> 
> 
>> For instance if I deposit three checks drawn from
>> three accounts as debit into a savings account then really three
>> transactions took place. But the bank statement for the savings
>> account shows a single credit.
> 
> In this case I would make three transactions in GnuCash. What you 
> described is not what split transactions are for. They are not for 
> matching bank statements. They are for matching single transactions that 
> touch 3 or more accounts.
> 
>> Anyways, in doing it as project accounts with vendor subaccounts
>> (with or without splits) you can never track back who you paid an
>> amount to. All you can see is that in the bank account there are 
>> transactions, paid to "doomsday" or to "gardening".
> 
> No, you would see a transaction that says "Doomsday:McMaster".
> 
>> But if you wanted to purchase the same component again who would
>> you buy it from?  If you had a problem with the charge, like say
>> it was discovered to be the incorrect amount, who would you call?
> 
> If the transaction says "Expenses:Doomsday:McMaster" I suggest you talk 
> to McMaster.
> 
> 
>> Oh... visually and manually cross-reference the bank statement you
>> say? Forget that.
> 
> What the heck are you talking about? Who in the world suggested that you 
> check statements manually? We are showing you how to use GnuCash and 
> answering your questions in our spare time. Show some appreciation.
> 
>> You also can't make intelligent use of your data because you have
>> lost all vendor information.
> 
> Are you sure you understand the concept of sub-accounts?
> 
> Expenses:Doomsday:McMaster
> 
> How exactly did you lose all the vendor information?
> 
>> You can say "How much did I spend on the
>> doomsday product" but you can't determine "How much did dealing with
>> McMaster-Carr cost me last year?" which can be equally important
>> to a business as there are other suppliers.
> 
> You'd have to add up the totals for each McMaster sub-account. Mildly 
> annoying, but perfectly doable. Or you could make an income-expense 
> report and under 'Options' select only the McMaster sub-accounts.
> 
>>>> So it doesn't fit the food model. (Even the Food model
>>>> doesn't work because I might want to account for food I
>>>> bought for myself versus food I bought for guests as gifts
>>>> under projects and such. I.E. not everything I buy at
>>>> Ralph's is consumed ultimately paid for by me but rather my
>>>> roommate.)
>>> This is again done with a split.
>>
>> No, it isn't. IANACPABMFI (I am not a CPA but my father is) I have
>> discussed this at length with him and this is not done with splits
>> or subaccounts.
> 
> Expenses:Doomsday:Gifts
> 
> Who says you have to put everything that is edible in the Food account? 
> I have an account for groceries and another for leisure which includes 
> restaurants.
> 
> Much of the rest of your email was bordering on insult and I'd rather 
> not reply to it.
> 
> Best,
> Daniel.

-- 
Jeff Wiegley, PhD
Cyte.Com, LLC