Paypal transaction split confusion

[Wm]

In article <1461116779779-4684361.post at n4.nabble.com>
trythis <grahamlane at gmail.com> wrote:
>
> This was a very useful post, thanks for the insight.  I want to clarify that
> my invoicing is not functioning on a real pledging function.  I wasnt using
> the right word because we dont get pledges, just cash donations or
> fundraising income.

MikeN is a good commentator on this.  As an aside, note that the 
legal status of pledges differ widely around the world and 
different states within the USA have different rules.  It is a mess 
in the sense that you can't presume that when someone says "pledge" 
it means the same thing anywhere else or to anyone else even in 
conversation.

> Some of our income results in tickets to our functions,
> other times it goes to restricted project expenses.

Heh, "income ... goes to restricted project expenses", non-trivial 
accounting, see [1] below.

>  The only way I can keep
> up with all the donations from people in one set of books is through
> invoicing. I am only invoicing after the donation is made so theoretically,
> as an instant invoice, its generated the instant the donor decides to let go
> of the cash and it gets posted and paid the moment the money hits the table.

Restricted stuff (something a minority of people here understand) 
must be kept seperate or at least accounted for seperately.  I 
think you probably know that, I'm just saying I am aware of it and 
it is something that most businesses or individuals don't encounter 
and tend to be a bit puzzled about.

[1] I have a model non-profit GnuCash book including transaction 
templates for review if anyone is interested, one of my GnuCash 
projects that I got done to my satisfaction so never finished in 
public because I'd answered my own questions about possibilty and 
practicality.

> I suppose a person could have an series of accounts that keep track of
> donors, but the invoice system works great for reports on customers (donors)
> and ties in very well with reports on actual activities ppr programs.

If the majority of the "invoices" are actually effectively 
"receipts" (essentially what you'd get if you bought something at a 
shop) then the model will probably fit with how GnuCash's business 
stuff works.

If the majority of "invoices" sent out speculatively (i.e. you 
haven't received the money, but they promised to pay and are 
*expecting* a reminder, no conflict about willingness to pay, 
ability to pay, etc) are paid then GnuCash's business stuff works.

It falls apart when it is used as an outbound marketing / pledge 
system becuase the resultant mess (what do I do with all these 
invoices that aren't actually valid demands for payment?) becomes 
an administrative problem.  GnuCash does not play nice with 
invoices that aren't actually invoices, i.e. speculative ProFormas, 
sales orders presented as demands for payment, etc.

> Instead of programming a "pledging system" I guess I would have to develop a
> "contribution receipt" or just change invoicing ling to Statement for the
> non-profit wing of gnucash.  Since I am not a programmer I will just have to
> dream.

Depending on which of the invoice forms you are using there is 
actually quite a lot of flexibility wrt the wording.  I think the 
issue is defining in your head what is actually owed to your org.

Be clear: if, in your jurisdiction, Mary Smith, having consumed a 
glass of cider pledges her life savings to your org, should you 
send her an invoice or not?

In some USA states the pledge machine says "get every penny", it 
isn't like that everywhere.

Some of us like people to give willingly and after consideration, 
that way we can approach them year after year and ask again, 
nicely, explaining what we have done over the last year, how we 
have given benefit, etc.

Non-profit is very competitive in its own way these days, there is 
a limit to funds and most people should be spending them well.

-- 
Wm