Re: [GNC] Bookkeeping for a club's charity account - use business features?

[Michael Hendry]

After looking at various ways of recording members’ individual contributions 
(using multiple children of Income: accounts), and examined the scope for 
simplifying data entry from using the Business Features, I’ve decided the 
answer to my question is “No”!

It’s much simpler to use a spreadsheet for recording the individual 
contributions which occur frequently during the year and enter only the totals 
for each destination in GnuCash. If I stick to that sequence (spreadsheet 
first, then totals to GnuCash) the two records should remain in step, and the 
annual report for Gift Aid can be derived from the spreadsheet.

I had hoped to be able to keep all of the records in one place (a single 
GnuCash file), but it didn’t work out.

In the meantime, I have learned a little about the use of Import and Export as 
a way of bulk-entering regular but variable transactions, and was puzzled to 
find that GnuCash sometimes can't Import a file it’s recently Exported. I’d 
used the Export to CSV to determine the columns titles used, but apparently 
these aren’t the same as the columns required for Import.

Above all, I’ve benefited from the generous support and advice of members of 
the GnuCash community - many thanks to all!

Regards,

Michael

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Bookkeeping for a club's charity account - use business features?

[Michael Hendry]

> On 27 Aug 2019, at 22:29, elvis  wrote:
> 
>>> 
>>> Hi Michael,
>>> 
>>> This is how I would do it. I'm assuming you have around 30 people to 
>>> account for.
>>> 
>>> Make up all your accounts and sub accounts and sub sub accounts and cross 
>>> accounts.
>>> 
>>> Have a transaction in each person's account with all the splits possible.
>>> 
>>> Each dinner copy the last transaction and alter the amounts. Maybe 20 
>>> seconds each so you are looking at about 15 minutes to update the whole.
>>> 
>>> 
>>> I'm assuming your primary document is some kind of piece of paper your 
>>> members fill out. If you have a spreadsheet on entry you would just massage 
>>> it and import it.
>>> 
>>> By the time you much around with business features you might as well just 
>>> copy transactions.
>>> 
>>> 
>>> Lawrence
>> Thanks, Lawrence.
>> 
>> The difficulty this suggestion doesn’t solve is in generating a report 
>> listing Gift-Aid-eligible totals for each member - the identity of the 
>> contributing member in each income account tree is at the twig level:
>> 
>> Income:Destination1:MemberA
>> Income:Destination2:MemberA
>> Income:Destination3:MemberA
>> etc
>> fo
> 
> You would do a joint income account that goes to separate member balances 
> that can be split up as to purpose.

If I understand what you mean, doesn’t this just do the multiplication in a 
different order?

Income:MemberA:Destination1
Income:MemberA:Destination2
...
Income:MemberB:Destination1
Income:MemberB:Destination2

etc., which just shifts the awkward report from all contributions by MemberX to 
all receipts for Destination99.

> 
> The Gnucash reports are very flexible, the balance sheet should do that, it 
> isn't really income it is a member balance which is an asset. I do the same 
> thing for my super fund and it works a treat. I have used Gnucash for 12 
> years and I don't use the business features except for our big invoices, 
> maybe 5 a month. Everything else I use something else and just post totals. 
> Once you have clickey clacked 30 times to enter every invoice you will feel 
> like punching the screen .

Exactly! This is why I’m attracted to the idea of importing invoice 
transactions from a CSV file, which would be edited on a spreadsheet to deal 
with minor variations in attendance at each meeting.

Michael
 
> 
> 
> 
>> all need to be picked up and added together for each destination and each 
>> member.
>> 
>> The Customer-based model would ease that aspect.
>> 
>> Unfortunately, there doesn’t seem to be a way of creating regularly repeated 
>> invoices as Scheduled Transactions, but I’m currently thinking along the 
>> lines of creating an invoice for each member for the default amounts at the 
>> beginning of the year, and then duplicating these invoices, one for each 
>> member for each meeting. After each meeting, I would edit each invoice if 
>> necessary (to deal with absences and variations in contributions) then post 
>> and pay them.
>> 
>> This way the Destination accounts don’t need children and the annual Gift 
>> Aid Report can be populated from Customer Reports.
>> 
>> I’ll do some experiments…
>> 
>> Michael
>> 
 Thanks,
 
 Michael
 
 ___
 gnucash-user mailing list
 gnucash-user@gnucash.org
 To update your subscription preferences or to unsubscribe:
 https://lists.gnucash.org/mailman/listinfo/gnucash-user
 If you are using Nabble or Gmane, please see 
 https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
 -
 Please remember to CC this list on all your replies.
 You can do this by using Reply-To-List or Reply-All.



___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Bookkeeping for a club's charity account - use business features?

[Michael Hendry]

> On 27 Aug 2019, at 16:10, Adrien Monteleone  
> wrote:
> 
> You can also import invoices. So if you find the duplication-post workflow 
> tedious, you could set up a spreadsheet with the invoice data ready to 
> import. Then each dinner, edit the amounts, export from spreadsheet to CSV, 
> import the CSV into GnuCash. For the next dinner, bring up the spreadsheet 
> again, edit the amounts, rinse-repeat.

Having a quick look at this option, exported some invoices, edited them (to 
change Customer’s name, which had appeared in the Description column) and tried 
to import, but nothing came up in the Preview apart from the headers.

I think this may be something to do with the UTF-8 problem I’ve recently come 
across with imports of names with acute accents in them. This time it’s the 
pound sign (“£”) that is the cause of trouble - if I change it to a dollar-sign 
the preview comes up OK but the import still fails, on the basis that there is 
no such customer.

Documentation on the export/import procedure for invoices is scant and hard to 
find.

Nonetheless, his sounds like a promising approach to what would be a tedious 
process if done by hand.

Thanks, Adrien, you’ve been a great help!

Michael

> 
> If the amount(s) that need to be edited are the same for each member, you 
> could either have a master sheet where you chance just those numbers and they 
> get pulled to the ‘invoice’ sheet, or else just do a Find/Replace if it is 
> that simple.
> 
> Regards,
> Adrien
> 
>> On Aug 27, 2019 w35d239, at 5:30 AM, Michael Hendry 
>>  wrote:
>> 
>> Unfortunately, there doesn’t seem to be a way of creating regularly repeated 
>> invoices as Scheduled Transactions, but I’m currently thinking along the 
>> lines of creating an invoice for each member for the default amounts at the 
>> beginning of the year, and then duplicating these invoices, one for each 
>> member for each meeting. After each meeting, I would edit each invoice if 
>> necessary (to deal with absences and variations in contributions) then post 
>> and pay them.
>> 
>> This way the Destination accounts don’t need children and the annual Gift 
>> Aid Report can be populated from Customer Reports.
>> 
>> I’ll do some experiments…
>> 
>> Michael
> 
> ___
> gnucash-user mailing list
> gnucash-user@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see 
> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.



___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Bookkeeping for a club's charity account - use business features?

[Adrien Monteleone]

You can also import invoices. So if you find the duplication-post workflow 
tedious, you could set up a spreadsheet with the invoice data ready to import. 
Then each dinner, edit the amounts, export from spreadsheet to CSV, import the 
CSV into GnuCash. For the next dinner, bring up the spreadsheet again, edit the 
amounts, rinse-repeat.

If the amount(s) that need to be edited are the same for each member, you could 
either have a master sheet where you chance just those numbers and they get 
pulled to the ‘invoice’ sheet, or else just do a Find/Replace if it is that 
simple.

Regards,
Adrien

> On Aug 27, 2019 w35d239, at 5:30 AM, Michael Hendry 
>  wrote:
> 
> Unfortunately, there doesn’t seem to be a way of creating regularly repeated 
> invoices as Scheduled Transactions, but I’m currently thinking along the 
> lines of creating an invoice for each member for the default amounts at the 
> beginning of the year, and then duplicating these invoices, one for each 
> member for each meeting. After each meeting, I would edit each invoice if 
> necessary (to deal with absences and variations in contributions) then post 
> and pay them.
> 
> This way the Destination accounts don’t need children and the annual Gift Aid 
> Report can be populated from Customer Reports.
> 
> I’ll do some experiments…
> 
> Michael

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Bookkeeping for a club's charity account - use business features?

[Adrien Monteleone]

> \On Aug 27, 2019 w35d239, at 7:36 AM, Michael Hendry 
>  wrote:
> 
> 
> I was thinking Mike meant that there was something intrinsically incompatible 
> with cash-based accounting which happened when Business Features were added. 
> But you’re saying that it’s only if there are posted and unpaid invoices 
> outstanding at year-end that this is a problem.

Even more precisely, it is only a problem if you include the affected accounts 
in your reports. Having posted and outstanding invoices is fine because there 
will be a separate mechanism to ‘realize’ income on a cash basis. (and a 
separate account for that which *will* get included in reports)

Here’s a little detail:

Invoice Posted
--

Dr. A/R $50
Cr. Income:Pledges  $50

Accrual method, ‘Income’ = $50
Cash method, ‘Income’ = 0

This is because in accrual accounting, you ‘realize’ income when it is 
‘earned’. Posting an invoice, means you’ve already ‘earned’ it. If you were to 
include all income accounts in the income statement, it would show you an 
income of $50, which is incorrect on a cash basis. Creating a separate 
cash-basis income account solves this.


Invoice Paid


Dr. Cash$50
Cr. A/R $50
Dr. Income:Pledges  $50
Cr. Income:Receipts $50

Accrual method, ‘Income’ = 0
Cash method, ‘Income’ = $50

(note, you have to do the second part of the above manually or via SX, the 
first Dr./Cr. pair is done with the ‘process payment’ business feature.)

Now, you’ve moved the ‘accrued’ income to a ‘cash’ income account, when you run 
the Income Statement report, *only* include the cash account - all will be well 
even if the ‘accrued’ account is not zero yet - that is, has outstanding 
invoices. This is also why you don’t have to ‘clear up’ outstanding invoices at 
year end. (unless unpaid pledges reset to ‘zero’ at that time.)

Your Income Statement would show an income of $50 which *is* correct now, 
because you’ve received the money. Since you are only reporting on the 
Income:Receipts account, it doesn’t matter that the Income:Pledges account 
might reflect some unpaid invoices - it won’t factor into the report.


> 
> I presume that an unposted invoice can be deleted, so it would be possible to 
> prepare invoices when (for example) a member opted in to the Foundation 
> Dinners, and to review unposted invoices periodically - especially in the 
> closing weeks of the year.

You wouldn’t necessarily have unposted invoices. But regardless of posted or 
unposted, you can’t delete them. You can however assign them to a ‘placeholder’ 
customer, and/or zero out all the info. The usual recommendation is to change 
the invoice number to something like “use next” so you can spot it easy in an 
invoice ‘find’, edit the invoice, and re-use it later.

Regards,
Adrien
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Bookkeeping for a club's charity account - use business features?

[Michael Hendry]

> On 27 Aug 2019, at 13:24, Mike or Penny Novack  
> wrote:
> 
> On 8/27/2019 2:40 AM, Michael Hendry wrote:
> 
>> I had understood from a recent response from Mike Novack that using an 
>> accrual-basis system for cash-basis organisation would be wrong.
> "Wrong" is the wrong term. I did not say that. I said that adjustments might 
> have to be made (the books kept on accrual basis but the reports had to 
> reflect cash basis). That calls for more than a little bookkeeping experience 
> to do correctly.

Apologies for misquoting you. I’ve extracted part of the exchange (between 
asterisks):

***
> On 25 Aug 2019, at 15:55, Mike or Penny Novack  
> wrote:
> 
> On 8/25/2019 3:25 AM, Michael Hendry wrote:
> 
> First (and an important question)
>   Is your organization om the cash or accrual basis? You should always state 
> that.

Cash.

> The business features of gnucash only work for accrual.
***

…which I mistakenly took to mean I could only use the business features if I 
were accounting on an accrual basis.


> 
> Back to the suggestion of not posting invoices immediately, that would be 
> correct for memberships/dues (which are not legally receivable) but you could 
> post pledges (which are --once a pledge is made the person owes that amount 
> to the organization). Not that I only know this true for the US.
> 
> The other thing mentioned, RESTRICTED donations (the donor has earmarked for 
> a set purpose) introduces the need for more record keeping. The treasurer has 
> to track when the organization has "earned" that donation << the restriction 
> removed because that amount has been spent for the designated purpose >>

Yes, we’d already discussed this a couple of years ago in another context, and 
you had suggested using a Liabilities account to keep track of such restricted 
funds. The accountant who examined those accounts prior to their submission to 
OSCR advised that this wasn’t the proper way to handle restricted funds in a UK 
context, and that the administrator would have to keep an eye on (e.g.) 
bursaries awarded through donations restricted for this purpose.

> 
> Michael D Novack

Regards,

Michael

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Bookkeeping for a club's charity account - use business features?

[Michael Hendry]

> On 27 Aug 2019, at 09:41, Adrien Monteleone  
> wrote:
> 
> 
> 
>> On Aug 27, 2019 w35d239, at 1:40 AM, Michael Hendry 
>>  wrote:
>> 
>> 
>> OK, so provided I’m careful to clean up any outstanding invoices before the 
>> end of the financial year, I can use the Business Features for a cash-basis 
>> organisation.
> 
> Not necessary to clean up any outstanding invoices. Since you aren’t 
> including the ‘Income:Pledges’ account in the Income Statement, any that 
> aren’t paid in full won’t affect your Income. Only actual receipts will - aka 
> - Cash Basis.


But my OCD tendencies would force me to do so…

> 
> Also, you wouldn’t include A/R in your Balance Sheet report since technically 
> it isn’t supposed to exist in a Cash system.
> 
> 
>> 
>> I had understood from a recent response from Mike Novack that using an 
>> accrual-basis system for cash-basis organisation would be wrong.
> 
> That is true. What you are doing is using the invoice system (which is 
> accrual based) to track some stuff you need for special purposes, but you 
> aren’t reporting on those affected accounts. You’re using cash-basis accounts 
> containing only cash-basis transactions for your formal reports.

I was thinking Mike meant that there was something intrinsically incompatible 
with cash-based accounting which happened when Business Features were added. 
But you’re saying that it’s only if there are posted and unpaid invoices 
outstanding at year-end that this is a problem.

> 
>> 
>>> 
>>> 
 
> 
> But you can easily have a second set of books to keep and report on "by 
> member" stuff, and if using the business features, can invoice.
 
 That’s a method I hadn’t thought of, and will look into. There’s the 
 obvious risk of these two sets of books getting out of step.
>> 
>> Working this way would avoid creating the Income:Pledges and Income:Receipts 
>> workaround suggested above.
>> 
>> All income received from members could then be simultaneously invoiced and 
>> paid, with Accounts Receivable persistently zero.
> 
> You can do that, and it would be the standard advice on how to use GnuCash 
> for a cash-basis book, but then lose the ability to see who hasn’t ‘paid up’.
> 
> (at least not without lots of individual member accounts, or a separate 
> spreadsheet to keep track)
> 
> I’m also not sure how yet how that would affect your ability to track the 
> gift amount per member.

I presume that an unposted invoice can be deleted, so it would be possible to 
prepare invoices when (for example) a member opted in to the Foundation 
Dinners, and to review unposted invoices periodically - especially in the 
closing weeks of the year.

>>> 1) Do you need to know how much each member donated for each destination?
>>> 
>>> or
>>> 
>>> 2)
>>> 
>>> For the Club:
>>> 
>>>  Do you just want to track how much was received (in aggregate for all 
>>> members) for each destination
>> 
>> Yes
> 
> Then you shouldn’t need individual member sub-accounts for each destination.

Exactly.

>> 
>>> 
>>> and
>>> 
>>> For the Members:
>>> 
>>>  How much (in aggregate for all destinations) each member donated? (for 
>>> Gift Aid purposes)
>> 
>> Yes, but some destinations aren’t Gift-Aid-eligible
> 
> Here’s where I’m investigating using ‘expense vouchers’ for those 
> destinations that are eligible. I didn’t get a chance to do a trial with it 
> yet. Hopefully later today.
> 
> Another option might be the upcoming ‘owner report’ that might get included 
> in the 3.7 release. It will allow you to match up payments to invoices 
> easily. This might also allow you to run a report of gift amounts for only 
> those invoices that match the eligible destinations.

Sounds useful!

Regards,

Michael

> 
> Regards,
> Adrien
> ___
> gnucash-user mailing list
> gnucash-user@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see 
> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.



___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Bookkeeping for a club's charity account - use business features?

[Mike or Penny Novack]

On 8/27/2019 2:40 AM, Michael Hendry wrote:


I had understood from a recent response from Mike Novack that using an 
accrual-basis system for cash-basis organisation would be wrong.
"Wrong" is the wrong term. I did not say that. I said that adjustments 
might have to be made (the books kept on accrual basis but the reports 
had to reflect cash basis). That calls for more than a little 
bookkeeping experience to do correctly.


Back to the suggestion of not posting invoices immediately, that would 
be correct for memberships/dues (which are not legally receivable) but 
you could post pledges (which are --once a pledge is made the person 
owes that amount to the organization). Not that I only know this true 
for the US.


The other thing mentioned, RESTRICTED donations (the donor has earmarked 
for a set purpose) introduces the need for more record keeping. The 
treasurer has to track when the organization has "earned" that donation 
<< the restriction removed because that amount has been spent for the 
designated purpose >>


Michael D Novack
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Bookkeeping for a club's charity account - use business features?

[elvis]

If #1 one, that is quite messy, yes, and you’ll need lots of manual 
transactions and some sort of searchable/filterable tag system as I described 
previously. (to avoid hundreds or thousands of accounts and sub-accounts)

But if #2, then the business features can handle that easily with invoice line 
items posted to Income accounts for each destination and assigning those 
invoices to  individual customer accounts. No need for the individual member 
account(s) in the Income tree at all. GnuCash will track each customer's 
pledged (invoiced) amounts as well as payments. The gift portion *might* be a 
little trickier, but I think it can be achieved by the expense vouchers 
feature. (since they operate as sort of a ‘chargeback’) I’ll have to 
investigate.

Regards,
Adrien


Hi Michael,

This is how I would do it. I'm assuming you have around 30 people to 
account for.


Make up all your accounts and sub accounts and sub sub accounts and 
cross accounts.


Have a transaction in each person's account with all the splits possible.

Each dinner copy the last transaction and alter the amounts. Maybe 20 
seconds each so you are looking at about 15 minutes to update the whole.



I'm assuming your primary document is some kind of piece of paper your 
members fill out. If you have a spreadsheet on entry you would just 
massage it and import it.


By the time you much around with business features you might as well 
just copy transactions.



Lawrence


Thanks,

Michael

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


--
The harder I work the luckier I get.

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Bookkeeping for a club's charity account - use business features?

[Michael Hendry]

> On 27 Aug 2019, at 08:20, elvis  wrote:
> 
> 
>>> If #1 one, that is quite messy, yes, and you’ll need lots of manual 
>>> transactions and some sort of searchable/filterable tag system as I 
>>> described previously. (to avoid hundreds or thousands of accounts and 
>>> sub-accounts)
>>> 
>>> But if #2, then the business features can handle that easily with invoice 
>>> line items posted to Income accounts for each destination and assigning 
>>> those invoices to  individual customer accounts. No need for the individual 
>>> member account(s) in the Income tree at all. GnuCash will track each 
>>> customer's pledged (invoiced) amounts as well as payments. The gift portion 
>>> *might* be a little trickier, but I think it can be achieved by the expense 
>>> vouchers feature. (since they operate as sort of a ‘chargeback’) I’ll have 
>>> to investigate.
>>> 
>>> Regards,
>>> Adrien
>>> 
> Hi Michael,
> 
> This is how I would do it. I'm assuming you have around 30 people to account 
> for.
> 
> Make up all your accounts and sub accounts and sub sub accounts and cross 
> accounts.
> 
> Have a transaction in each person's account with all the splits possible.
> 
> Each dinner copy the last transaction and alter the amounts. Maybe 20 seconds 
> each so you are looking at about 15 minutes to update the whole.
> 
> 
> I'm assuming your primary document is some kind of piece of paper your 
> members fill out. If you have a spreadsheet on entry you would just massage 
> it and import it.
> 
> By the time you much around with business features you might as well just 
> copy transactions.
> 
> 
> Lawrence

Thanks, Lawrence.

The difficulty this suggestion doesn’t solve is in generating a report listing 
Gift-Aid-eligible totals for each member - the identity of the contributing 
member in each income account tree is at the twig level:

Income:Destination1:MemberA
Income:Destination2:MemberA
Income:Destination3:MemberA
etc

all need to be picked up and added together for each destination and each 
member.

The Customer-based model would ease that aspect.

Unfortunately, there doesn’t seem to be a way of creating regularly repeated 
invoices as Scheduled Transactions, but I’m currently thinking along the lines 
of creating an invoice for each member for the default amounts at the beginning 
of the year, and then duplicating these invoices, one for each member for each 
meeting. After each meeting, I would edit each invoice if necessary (to deal 
with absences and variations in contributions) then post and pay them.

This way the Destination accounts don’t need children and the annual Gift Aid 
Report can be populated from Customer Reports.

I’ll do some experiments…

Michael

> 
>> Thanks,
>> 
>> Michael
>> 
>> ___
>> gnucash-user mailing list
>> gnucash-user@gnucash.org
>> To update your subscription preferences or to unsubscribe:
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> If you are using Nabble or Gmane, please see 
>> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
>> -
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.



___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Bookkeeping for a club's charity account - use business features?

[Adrien Monteleone]

> On Aug 27, 2019 w35d239, at 1:40 AM, Michael Hendry 
>  wrote:
> 
> 
> OK, so provided I’m careful to clean up any outstanding invoices before the 
> end of the financial year, I can use the Business Features for a cash-basis 
> organisation.

Not necessary to clean up any outstanding invoices. Since you aren’t including 
the ‘Income:Pledges’ account in the Income Statement, any that aren’t paid in 
full won’t affect your Income. Only actual receipts will - aka - Cash Basis.

Also, you wouldn’t include A/R in your Balance Sheet report since technically 
it isn’t supposed to exist in a Cash system.


> 
> I had understood from a recent response from Mike Novack that using an 
> accrual-basis system for cash-basis organisation would be wrong.

That is true. What you are doing is using the invoice system (which is accrual 
based) to track some stuff you need for special purposes, but you aren’t 
reporting on those affected accounts. You’re using cash-basis accounts 
containing only cash-basis transactions for your formal reports.

> 
>> 
>> 
>>> 
 
 But you can easily have a second set of books to keep and report on "by 
 member" stuff, and if using the business features, can invoice.
>>> 
>>> That’s a method I hadn’t thought of, and will look into. There’s the 
>>> obvious risk of these two sets of books getting out of step.
> 
> Working this way would avoid creating the Income:Pledges and Income:Receipts 
> workaround suggested above.
> 
> All income received from members could then be simultaneously invoiced and 
> paid, with Accounts Receivable persistently zero.

You can do that, and it would be the standard advice on how to use GnuCash for 
a cash-basis book, but then lose the ability to see who hasn’t ‘paid up’.

(at least not without lots of individual member accounts, or a separate 
spreadsheet to keep track)

I’m also not sure how yet how that would affect your ability to track the gift 
amount per member.
>> 1) Do you need to know how much each member donated for each destination?
>> 
>> or
>> 
>> 2)
>> 
>> For the Club:
>> 
>>   Do you just want to track how much was received (in aggregate for all 
>> members) for each destination
> 
> Yes

Then you shouldn’t need individual member sub-accounts for each destination.
> 
>> 
>> and
>> 
>> For the Members:
>> 
>>   How much (in aggregate for all destinations) each member donated? (for 
>> Gift Aid purposes)
> 
> Yes, but some destinations aren’t Gift-Aid-eligible

Here’s where I’m investigating using ‘expense vouchers’ for those destinations 
that are eligible. I didn’t get a chance to do a trial with it yet. Hopefully 
later today.

Another option might be the upcoming ‘owner report’ that might get included in 
the 3.7 release. It will allow you to match up payments to invoices easily. 
This might also allow you to run a report of gift amounts for only those 
invoices that match the eligible destinations.

Regards,
Adrien
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Bookkeeping for a club's charity account - use business features?

[Michael Hendry]

> On 26 Aug 2019, at 17:27, Adrien Monteleone  
> wrote:
> 
>> 
>> On Aug 26, 2019 w35d238, at 3:43 AM, Michael Hendry 
>>  wrote:
>> 
>> 
>>> And I see that your organization does pledges. Here in the US, pledges ARE 
>>> receivable,but only according to the terms of the pledge << thus if a 
>>> person pledged X a year for five years, only the X for the current year due 
>>> NOW >> So pledge accounting will require extra work unless all your pledges 
>>> are simple, immediate pledges.
>> 
>> Volunteering to be a paying guest at a “Foundation Dinner” is the only 
>> undertaking that fits into the definition of a pledge, but I can see that 
>> setting up an invoice for it would make it “receivable”, and have a lifetime 
>> that went beyond the financial year’s end.
>> 
>> But if I avoided setting up invoices for this particular fundraising 
>> activity, could I use the Business Features to record income from a each 
>> member (“Customer”) as it arises?
> 
> To answer that question first, yes, you can take a payment without a 
> corresponding invoice already having been posted, it is considered a 
> ‘pre-payment’. But you won’t get any comparison against pledged amounts 
> because that is what the invoice is for and those wouldn’t have been posted 
> (or created) yet. You’ll just get to see that MemberX paid a certain amount. 
> (and since there is no pledge amount to balance it, it won’t calculate your 
> ‘gift’ portion.)
> 
> However,
> 
> The issue with invoices on a cash basis in GnuCash is you can’t post them 
> till payment is received otherwise it hits the ‘Income’ account too early. 
> But that negates the ability to see what was ‘pledged’ vs. what was paid.
> 
> You can get around this limitation by creating two accounts, something like 
> this:
> 
> Income:Pledges
> Income:Receipts
> 
> 1) Post the invoices to the Pledges account.
> 2) Take payments as normal.
> 
> You can now track what money is promised vs. what was paid via Customer 
> Reports.
> 
> 3) When payments are made, make an additional transaction that transfers the 
> same amount of funds from the Pledges account to the Receipts account.
> 
> 4) When you run your Income Statement, include the Receipts account, but not 
> the Pledges account.
> 
> You now have a cash-basis Income Statement, _and_ you get to take advantage 
> of the A/R features.

OK, so provided I’m careful to clean up any outstanding invoices before the end 
of the financial year, I can use the Business Features for a cash-basis 
organisation.

I had understood from a recent response from Mike Novack that using an 
accrual-basis system for cash-basis organisation would be wrong.

> 
> 
>> 
>>> 
>>> But you can easily have a second set of books to keep and report on "by 
>>> member" stuff, and if using the business features, can invoice.
>> 
>> That’s a method I hadn’t thought of, and will look into. There’s the obvious 
>> risk of these two sets of books getting out of step.

Working this way would avoid creating the Income:Pledges and Income:Receipts 
workaround suggested above.

All income received from members could then be simultaneously invoiced and 
paid, with Accounts Receivable persistently zero.

>> 
>>> Note though that  at least in the US "membership dies" are not really 
>>> receivables <>> organization at any time -- organizational rules about "demits", etc. apply 
>>> only if you want to rejoin>> However many organizations even cash basis 
>>> [prefer being able to send out "statements" (invoices to members)
>>> 
>>> Notice that I misunderstood.What I was suggesting was if you had to supply 
>>> to the government the CORRECT member name for the donations, not just that 
>>> it had to be SOME member's name. The latter is of course far simpler in 
>>> terms of record keeping << I was picturing the former because possibly 
>>> there were by person limits >>
>> 
>> From the point of view of the annual report to OSCR (the charity regulator) 
>> there is no need for detailed reporting of income - see 
>> https://www.oscr.org.uk/media/1800/2015-01-27-example-accounts-scio.pdf - 
>> but the annual claim for Gift Aid requires the total contributed per annum 
>> by each individual member. The 25% boost that Gift Aid covers is the reason 
>> why most Rotary Clubs in the UK set up charities which operate “at 
>> arms-length” from the clubs themselves but whose trustees are club officers. 
>> 
>>> 
>>> Michael
>>> 
>>> PS: I do NOT attempt to get gnucash to produce reports in their final form. 
>>> Easier to export full reports and then copy into a document that gets 
>>> edited to remove extraneous detail, insert annotations, etc.
>>> 
>> 
>> The way I’ve set up the accounts may need review, as I’m going to require a 
>> lot of individual searches to isolate contributions from individual members.
>> 
>> I think I need to remove a tier and identify the intended destination of the 
>> income using a tag in a searchable field.
>> 
>> Income:Destination1:MemberA … 

Re: [GNC] Bookkeeping for a club's charity account - use business features?

[Michael Hendry]

> On 27 Aug 2019, at 03:36, doncram  wrote:
> 
> In your case, Michael Hendry, are there other persons who need or work with
> some of the information?  

No, I’m playing in a one-man-band - which is (mostly) a good thing!

> Surely then there are communication / information
> sharing needs, which cannot be addressed easily with your single-access
> semi-complicated GnuCash system.
> 
> I, too, am new treasurer of a nonprofit, a botanical garden society which
> is set up as a charitable nonprofit, and I have puzzled over similar issues
> for tracking, but also for sharing info.  A big issue is that select other
> board members or volunteers work with some of the same information.  The
> treasurer job is too big already, and others are better about handling some
> tasks like tracking membership renewals (i.e. contributions at "pledge"
> amount) and sending out reminders, and following up with thank you notes in
> writing for larger donations, and email notes for smaller ones.  One
> volunteer, call her the membership director,  has a big spreadsheet of most
> of the members/contributors and dollar amounts and so on.  The board
> secretary is really good at writing nice thank you notes for the bigger
> donations. I hate the fact that I, as treasurer, if I follow the past
> practice, am essentially duplicating a whole lot of info, when I enter each
> donation or membership payment, putting member name into a description/note
> field.  "We" already have that information!  Couldn't it be shared?  And
> what about cross-checking the spreadsheet information vs. my accounting
> entries I know there are at least a few discrepancies, which need to be
> identified and followed up upon, else a donor gets no acknowledgment or
> gets "billed" twice or whatever.
> 
> So, I have started use of a combined-access spreadsheet, by uploading the
> membership director's spreadsheet to a Google Docs spreadsheet, and I
> talked her through using it online.  Happily it is perfectly easy for her
> to do her job in the now-shared spreadsheet.  And I will add columns as
> necessary to record deposit dates and whatnot.  I am hoping to do my data
> entry about specific individuals there, i.e. by just recording treasurer
> stuff in "my" columns, adding to already-existing rows for all members.  I
> am hoping to stop my very detailed accounting, and making occasional
> accounting entries that are summary, tying out to the info in my columns.
> E.g. I can record the donation/membership check amounts in a column for
> income from August 2019, say, and make just one summary entry into the
> accounting system.

I think you’re very brave, allowing read-write access to your spreadsheet(s). 
But of course, you wouldn’t be reaping the benefits of data-sharing if you 
didn’t allow others to write to them.

> 
> I cannot imagine myself producing all the necessary reports to serve others
> and all purposes if I was handling all the info myself.  And I can't
> imagine collaborating with others in any way other than a shared
> spreadsheet.  Any comments/suggestions?
> 
> Thank you Michael Hendry for the question and thank all the participants so
> far!
> 
> sincerely, Donald Cram
> 

My questions arise from my own ignorance, and I depend for answers on the ready 
support of this forum.

Regards, 

Michael
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Bookkeeping for a club's charity account - use business features?

[Adrien Monteleone]

To make your life even easier, consider creating another Google Sheet that 
pulls info from the shared one, does the summary math you want, and results in 
an arrangement that can be imported directly into GnuCash. Then you don’t have 
to type anything twice and eliminate occasions for math mistakes.

Regards,
Adrien

> On Aug 26, 2019 w35d238, at 9:36 PM, doncram  wrote:
> 
> In your case, Michael Hendry, are there other persons who need or work with 
> some of the information?  Surely then there are communication / information 
> sharing needs, which cannot be addressed easily with your single-access 
> semi-complicated GnuCash system.   
>  
> I, too, am new treasurer of a nonprofit, a botanical garden society which is 
> set up as a charitable nonprofit, and I have puzzled over similar issues for 
> tracking, but also for sharing info.  A big issue is that select other board 
> members or volunteers work with some of the same information.  The treasurer 
> job is too big already, and others are better about handling some tasks like 
> tracking membership renewals (i.e. contributions at "pledge" amount) and 
> sending out reminders, and following up with thank you notes in writing for 
> larger donations, and email notes for smaller ones.  One volunteer, call her 
> the membership director,  has a big spreadsheet of most of the 
> members/contributors and dollar amounts and so on.  The board secretary is 
> really good at writing nice thank you notes for the bigger donations. I hate 
> the fact that I, as treasurer, if I follow the past practice, am essentially 
> duplicating a whole lot of info, when I enter each donation or membership 
> payment, putting member name into a description/note field.  "We" already 
> have that information!  Couldn't it be shared?  And what about cross-checking 
> the spreadsheet information vs. my accounting entries I know there are at 
> least a few discrepancies, which need to be identified and followed up upon, 
> else a donor gets no acknowledgment or gets "billed" twice or whatever.
> 
> So, I have started use of a combined-access spreadsheet, by uploading the 
> membership director's spreadsheet to a Google Docs spreadsheet, and I talked 
> her through using it online.  Happily it is perfectly easy for her to do her 
> job in the now-shared spreadsheet.  And I will add columns as necessary to 
> record deposit dates and whatnot.  I am hoping to do my data entry about 
> specific individuals there, i.e. by just recording treasurer stuff in "my" 
> columns, adding to already-existing rows for all members.  I am hoping to 
> stop my very detailed accounting, and making occasional accounting entries 
> that are summary, tying out to the info in my columns.  E.g. I can record the 
> donation/membership check amounts in a column for income from August 2019, 
> say, and make just one summary entry into the accounting system.
> 
> I cannot imagine myself producing all the necessary reports to serve others 
> and all purposes if I was handling all the info myself.  And I can't imagine 
> collaborating with others in any way other than a shared spreadsheet.  Any 
> comments/suggestions?
> 
> Thank you Michael Hendry for the question and thank all the participants so 
> far!
> 
> sincerely, Donald Cram
> 

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Bookkeeping for a club's charity account - use business features?

[doncram]

Oh, another complication for my botanical garden society, is that some of
the donations create obligations that need to be tracked.  Similar to how
Michael Hendry needs to track the multiple purposes for each individual's
payments.  Contributions might be earmarked for one of our subgarden areas,
to fund a tree or bench, or might "earn" placement of a memorial brick in
one of our patios.  The donor might want the brick done, or might not.  I
think the previous treasurer kept all this in her head somehow, or in some
separate file she might have kept, and she arranged for the bricks to be
done periodically, with text chosen by donor.  I cannot do any of that,
because I am limited and also the organization has been growing.  But the
info needs to go to the right other people.

Oh, by the way, for a shared spreadsheet or even for any non-shared
spreadsheet, one absolutely has to have an "original sort order" column, to
bring the spreadsheet back to regular format, when anyone sorts it
differently for some purpose, and those with access need to understand that
and not mess up that column, which is okay by everyone else in my case.
Again, I cannot imagine myself generating reports or whatever, I do not
have the time.  No way can I run multiple accounting systems for pledges or
whatever, either.  I can only imagine sharing the info in a joint-access
spreadsheet so others can add whatever they need to, and sort it however
they like and get what they need.  How else could this possibly be done?

Donald Cram


Virus-free.
www.avast.com

<#m_-1710799610467280712_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Mon, Aug 26, 2019 at 8:36 PM doncram  wrote:

> In your case, Michael Hendry, are there other persons who need or work
> with some of the information?  Surely then there are communication /
> information sharing needs, which cannot be addressed easily with your
> single-access semi-complicated GnuCash system.
>
> I, too, am new treasurer of a nonprofit, a botanical garden society which
> is set up as a charitable nonprofit, and I have puzzled over similar issues
> for tracking, but also for sharing info.  A big issue is that select other
> board members or volunteers work with some of the same information.  The
> treasurer job is too big already, and others are better about handling some
> tasks like tracking membership renewals (i.e. contributions at "pledge"
> amount) and sending out reminders, and following up with thank you notes in
> writing for larger donations, and email notes for smaller ones.  One
> volunteer, call her the membership director,  has a big spreadsheet of most
> of the members/contributors and dollar amounts and so on.  The board
> secretary is really good at writing nice thank you notes for the bigger
> donations. I hate the fact that I, as treasurer, if I follow the past
> practice, am essentially duplicating a whole lot of info, when I enter each
> donation or membership payment, putting member name into a description/note
> field.  "We" already have that information!  Couldn't it be shared?  And
> what about cross-checking the spreadsheet information vs. my accounting
> entries I know there are at least a few discrepancies, which need to be
> identified and followed up upon, else a donor gets no acknowledgment or
> gets "billed" twice or whatever.
>
> So, I have started use of a combined-access spreadsheet, by uploading the
> membership director's spreadsheet to a Google Docs spreadsheet, and I
> talked her through using it online.  Happily it is perfectly easy for her
> to do her job in the now-shared spreadsheet.  And I will add columns as
> necessary to record deposit dates and whatnot.  I am hoping to do my data
> entry about specific individuals there, i.e. by just recording treasurer
> stuff in "my" columns, adding to already-existing rows for all members.  I
> am hoping to stop my very detailed accounting, and making occasional
> accounting entries that are summary, tying out to the info in my columns.
> E.g. I can record the donation/membership check amounts in a column for
> income from August 2019, say, and make just one summary entry into the
> accounting system.
>
> I cannot imagine myself producing all the necessary reports to serve
> others and all purposes if I was handling all the info myself.  And I can't
> imagine collaborating with others in any way other than a shared
> spreadsheet.  Any comments/suggestions?
>
> Thank you Michael Hendry for the question and thank all the participants
> so far!
>
> sincerely, Donald Cram
>
>
>
>
> 
>  Virus-free.
> www.avast.com
> 

Re: [GNC] Bookkeeping for a club's charity account - use business features?

[Christopher Lam]

This "pledged income" tracking looks eerily similar to the budgeting aka
"virtual transactions" that I was floating about some time ago...

On Tue., 27 Aug. 2019, 00:29 Adrien Monteleone, <
adrien.montele...@lusfiber.net> wrote:

>
> > On Aug 26, 2019 w35d238, at 3:43 AM, Michael Hendry <
> hendry.mich...@gmail.com> wrote:
> >
> >
> >> And I see that your organization does pledges. Here in the US, pledges
> ARE receivable,but only according to the terms of the pledge << thus if a
> person pledged X a year for five years, only the X for the current year due
> NOW >> So pledge accounting will require extra work unless all your pledges
> are simple, immediate pledges.
> >
> > Volunteering to be a paying guest at a “Foundation Dinner” is the only
> undertaking that fits into the definition of a pledge, but I can see that
> setting up an invoice for it would make it “receivable”, and have a
> lifetime that went beyond the financial year’s end.
> >
> > But if I avoided setting up invoices for this particular fundraising
> activity, could I use the Business Features to record income from a each
> member (“Customer”) as it arises?
>
> To answer that question first, yes, you can take a payment without a
> corresponding invoice already having been posted, it is considered a
> ‘pre-payment’. But you won’t get any comparison against pledged amounts
> because that is what the invoice is for and those wouldn’t have been posted
> (or created) yet. You’ll just get to see that MemberX paid a certain
> amount. (and since there is no pledge amount to balance it, it won’t
> calculate your ‘gift’ portion.)
>
> However,
>
> The issue with invoices on a cash basis in GnuCash is you can’t post them
> till payment is received otherwise it hits the ‘Income’ account too early.
> But that negates the ability to see what was ‘pledged’ vs. what was paid.
>
> You can get around this limitation by creating two accounts, something
> like this:
>
> Income:Pledges
> Income:Receipts
>
> 1) Post the invoices to the Pledges account.
> 2) Take payments as normal.
>
> You can now track what money is promised vs. what was paid via Customer
> Reports.
>
> 3) When payments are made, make an additional transaction that transfers
> the same amount of funds from the Pledges account to the Receipts account.
>
> 4) When you run your Income Statement, include the Receipts account, but
> not the Pledges account.
>
> You now have a cash-basis Income Statement, _and_ you get to take
> advantage of the A/R features.
>
>
> >
> >>
> >> But you can easily have a second set of books to keep and report on "by
> member" stuff, and if using the business features, can invoice.
> >
> > That’s a method I hadn’t thought of, and will look into. There’s the
> obvious risk of these two sets of books getting out of step.
> >
> >> Note though that  at least in the US "membership dies" are not really
> receivables < organization at any time -- organizational rules about "demits", etc. apply
> only if you want to rejoin>> However many organizations even cash basis
> [prefer being able to send out "statements" (invoices to members)
> >>
> >> Notice that I misunderstood.What I was suggesting was if you had to
> supply to the government the CORRECT member name for the donations, not
> just that it had to be SOME member's name. The latter is of course far
> simpler in terms of record keeping << I was picturing the former because
> possibly there were by person limits >>
> >
> > From the point of view of the annual report to OSCR (the charity
> regulator) there is no need for detailed reporting of income - see
> https://www.oscr.org.uk/media/1800/2015-01-27-example-accounts-scio.pdf -
> but the annual claim for Gift Aid requires the total contributed per annum
> by each individual member. The 25% boost that Gift Aid covers is the reason
> why most Rotary Clubs in the UK set up charities which operate “at
> arms-length” from the clubs themselves but whose trustees are club
> officers.
> >
> >>
> >> Michael
> >>
> >> PS: I do NOT attempt to get gnucash to produce reports in their final
> form. Easier to export full reports and then copy into a document that gets
> edited to remove extraneous detail, insert annotations, etc.
> >>
> >
> > The way I’ve set up the accounts may need review, as I’m going to
> require a lot of individual searches to isolate contributions from
> individual members.
> >
> > I think I need to remove a tier and identify the intended destination of
> the income using a tag in a searchable field.
> >
> > Income:Destination1:MemberA … MemberN
> > Income:Destination2:MemberA … MemberN
> > …
> > Income:DestinationX:MemberA … MemberN
> >
> > - a total of X * N accounts.
>
> >
> >
> > Becomes
> >
> > Income:Donations:MemberA … MemberN, with Destinations 1…X recorded in
> the Description field of each transaction.
> >
> > - a total of N accounts.
> >
> > Thanks for your continued interest and support,
> >
> > Michael
>
> 1) Do you need to know how much each member 

Re: [GNC] Bookkeeping for a club's charity account - use business features?

[Mike or Penny Novack]

On 8/26/2019 6:49 AM, Greg Feneis wrote:

Michael, I use GnuCash for my cash business and don't have any trouble with
it.  I think the only trouble you may have is with report generation.

Kind regards, Greg Feneis
(Pixel 3)

Well yes, it is precisely that, adjustments necessary to convert 
"accrual" to "cash" for reports. Not THAT hard to do for those 
experienced in bookkeeping (the old way) and if doesn't need to be done 
all that often. If quarterly of annually only, I might do it that way.


But a business is different than a club/church/charity  and it is only 
for the latter sort of org that I am willing to help in this way. The 
reason I am suggesting "a second set of books" JUST to send invoices 
(member statements) is that in my experience possibly the majority of 
collections will be "not as billed".


Take a church/synagogue as am example. The "membership dues" might be 
set as X, and perhaps half the congregation sends in that amount. The 
other half, people contact the treasurer (or an abatement committee) and 
say "sorry,we just can't afford that much" and they get an "abatement" 
<< an arrangement to pay what they can >> In other words, the total of 
"receivables" is NEVER going to be close to what comes in.


Would you, as a business, be so casual about "not had to adjust: is HALF 
of you invoices involved adjustment to "bad debt"? << in the 
organizational case, "abated" >>


The point is, the second set of books I am talking about is JUST for 
sending out "statements". You don't necessarily have to record there 
when payments come in unless you want to be able to send out follow-up 
statements. There is an argument for NOT doing it. If "abated amount" is 
put in and statement sent out again (for the lesser amount) that is ALL 
you would get. And of course might not even get that. But if the person 
is told by the treasurer or abatement committee ,"look, pay half you 
can" you MIGHT end up getting more. Usually the board wants to know how 
many (what percentage of our congregation is abated) and how much 
collected from all who are abated (for predicting total membership dues 
for budgeting) but NOT "who is abated and by how much" << that is 
private, confidential >> Note that is you are recording these incoming 
payments into the (real/main) books on cash basis and that is the 
information needed just have to have "membership dues" and under it two 
child accounts "full membership dues" and "abated membership dues".


Michael D Novack
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Bookkeeping for a club's charity account - use business features?

[Greg Feneis]

Michael, I use GnuCash for my cash business and don't have any trouble with
it.  I think the only trouble you may have is with report generation.

Kind regards, Greg Feneis
(Pixel 3)


On Mon, Aug 26, 2019, 01:46 Michael Hendry  wrote:

> > On 25 Aug 2019, at 15:55, Mike or Penny Novack <
> stepbystepf...@comcast.net> wrote:
> >
> > On 8/25/2019 3:25 AM, Michael Hendry wrote:
> >
> > First (and an important question)
> >Is your organization om the cash or accrual basis? You should always
> state that.
>
> Cash.
>
> > The business features of gnucash only work for accrual.
>
> In that case, my question in the subject line is answered, in the
> negative!
>
> > And I see that your organization does pledges. Here in the US, pledges
> ARE receivable,but only according to the terms of the pledge << thus if a
> person pledged X a year for five years, only the X for the current year due
> NOW >> So pledge accounting will require extra work unless all your pledges
> are simple, immediate pledges.
>
> Volunteering to be a paying guest at a “Foundation Dinner” is the only
> undertaking that fits into the definition of a pledge, but I can see that
> setting up an invoice for it would make it “receivable”, and have a
> lifetime that went beyond the financial year’s end.
>
> But if I avoided setting up invoices for this particular fundraising
> activity, could I use the Business Features to record income from a each
> member (“Customer”) as it arises?
>
> >
> > But you can easily have a second set of books to keep and report on "by
> member" stuff, and if using the business features, can invoice.
>
> That’s a method I hadn’t thought of, and will look into. There’s the
> obvious risk of these two sets of books getting out of step.
>
> > Note though that  at least in the US "membership dies" are not really
> receivables < organization at any time -- organizational rules about "demits", etc. apply
> only if you want to rejoin>> However many organizations even cash basis
> [prefer being able to send out "statements" (invoices to members)
> >
> > Notice that I misunderstood.What I was suggesting was if you had to
> supply to the government the CORRECT member name for the donations, not
> just that it had to be SOME member's name. The latter is of course far
> simpler in terms of record keeping << I was picturing the former because
> possibly there were by person limits >>
>
> From the point of view of the annual report to OSCR (the charity
> regulator) there is no need for detailed reporting of income - see
> https://www.oscr.org.uk/media/1800/2015-01-27-example-accounts-scio.pdf -
> but the annual claim for Gift Aid requires the total contributed per annum
> by each individual member. The 25% boost that Gift Aid covers is the reason
> why most Rotary Clubs in the UK set up charities which operate “at
> arms-length” from the clubs themselves but whose trustees are club
> officers.
>
> >
> > Michael
> >
> > PS: I do NOT attempt to get gnucash to produce reports in their final
> form. Easier to export full reports and then copy into a document that gets
> edited to remove extraneous detail, insert annotations, etc.
> >
>
> The way I’ve set up the accounts may need review, as I’m going to require
> a lot of individual searches to isolate contributions from individual
> members.
>
> I think I need to remove a tier and identify the intended destination of
> the income using a tag in a searchable field.
>
> Income:Destination1:MemberA … MemberN
> Income:Destination2:MemberA … MemberN
> …
> Income:DestinationX:MemberA … MemberN
>
>  - a total of X * N accounts.
>
>
> Becomes
>
> Income:Donations:MemberA … MemberN, with Destinations 1…X recorded in the
> Description field of each transaction.
>
>  - a total of N accounts.
>
> Thanks for your continued interest and support,
>
> Michael
>
>
> ___
> gnucash-user mailing list
> gnucash-user@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see
> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> -
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Bookkeeping for a club's charity account - use business features?

[Michael Hendry]

> On 25 Aug 2019, at 15:55, Mike or Penny Novack  
> wrote:
> 
> On 8/25/2019 3:25 AM, Michael Hendry wrote:
> 
> First (and an important question)
>Is your organization om the cash or accrual basis? You should always state 
> that.

Cash.

> The business features of gnucash only work for accrual.

In that case, my question in the subject line is answered, in the negative! 

> And I see that your organization does pledges. Here in the US, pledges ARE 
> receivable,but only according to the terms of the pledge << thus if a person 
> pledged X a year for five years, only the X for the current year due NOW >> 
> So pledge accounting will require extra work unless all your pledges are 
> simple, immediate pledges.

Volunteering to be a paying guest at a “Foundation Dinner” is the only 
undertaking that fits into the definition of a pledge, but I can see that 
setting up an invoice for it would make it “receivable”, and have a lifetime 
that went beyond the financial year’s end.

But if I avoided setting up invoices for this particular fundraising activity, 
could I use the Business Features to record income from a each member 
(“Customer”) as it arises?

> 
> But you can easily have a second set of books to keep and report on "by 
> member" stuff, and if using the business features, can invoice.

That’s a method I hadn’t thought of, and will look into. There’s the obvious 
risk of these two sets of books getting out of step.

> Note though that  at least in the US "membership dies" are not really 
> receivables < at any time -- organizational rules about "demits", etc. apply only if you 
> want to rejoin>> However many organizations even cash basis [prefer being 
> able to send out "statements" (invoices to members)
> 
> Notice that I misunderstood.What I was suggesting was if you had to supply to 
> the government the CORRECT member name for the donations, not just that it 
> had to be SOME member's name. The latter is of course far simpler in terms of 
> record keeping << I was picturing the former because possibly there were by 
> person limits >>

From the point of view of the annual report to OSCR (the charity regulator) 
there is no need for detailed reporting of income - see 
https://www.oscr.org.uk/media/1800/2015-01-27-example-accounts-scio.pdf - but 
the annual claim for Gift Aid requires the total contributed per annum by each 
individual member. The 25% boost that Gift Aid covers is the reason why most 
Rotary Clubs in the UK set up charities which operate “at arms-length” from the 
clubs themselves but whose trustees are club officers. 

> 
> Michael
> 
> PS: I do NOT attempt to get gnucash to produce reports in their final form. 
> Easier to export full reports and then copy into a document that gets edited 
> to remove extraneous detail, insert annotations, etc.
> 

The way I’ve set up the accounts may need review, as I’m going to require a lot 
of individual searches to isolate contributions from individual members.

I think I need to remove a tier and identify the intended destination of the 
income using a tag in a searchable field.

Income:Destination1:MemberA … MemberN
Income:Destination2:MemberA … MemberN
…
Income:DestinationX:MemberA … MemberN

 - a total of X * N accounts.


Becomes

Income:Donations:MemberA … MemberN, with Destinations 1…X recorded in the 
Description field of each transaction.

 - a total of N accounts.

Thanks for your continued interest and support,

Michael


___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Bookkeeping for a club's charity account - use business features?

[Mike or Penny Novack]

On 8/25/2019 3:25 AM, Michael Hendry wrote:

First (and an important question)
Is your organization om the cash or accrual basis? You should 
always state that. The business features of gnucash only work for 
accrual. And I see that your organization does pledges. Here in the US, 
pledges ARE receivable,but only according to the terms of the pledge << 
thus if a person pledged X a year for five years, only the X for the 
current year due NOW >> So pledge accounting will require extra work 
unless all your pledges are simple, immediate pledges.


But you can easily have a second set of books to keep and report on "by 
member" stuff, and if using the business features, can invoice. Note 
though that  at least in the US "membership dies" are not really 
receivables > However many organizations even cash 
basis [prefer being able to send out "statements" (invoices to members)


Notice that I misunderstood.What I was suggesting was if you had to 
supply to the government the CORRECT member name for the donations, not 
just that it had to be SOME member's name. The latter is of course far 
simpler in terms of record keeping << I was picturing the former because 
possibly there were by person limits >>


Michael

PS: I do NOT attempt to get gnucash to produce reports in their final 
form. Easier to export full reports and then copy into a document that 
gets edited to remove extraneous detail, insert annotations, etc.




On 24 Aug 2019, at 23:03, Mike or Penny Novack  
wrote:

On 8/24/2019 5:39 PM, Michael Hendry wrote:


This is for the Gift Aid claim. We have to put in an annual claim to the 
taxman, identifying each contributor and his/her total amount donated during 
the year. Many UK charities use this method to boost their income - for 
example, when you pay the National Trust for Scotland the admission fee for one 
of their properties, they’ll ask you if you’re willing for them to make a Gift 
Aid claim and take down enough details to make that claim. You have to have 
enough income to be taxed at the basic rate, and the charity can claim tax back 
at a rate 25% of the admission fee.

I have to account for the income as it is received, and I’d prefer to record 
sufficient detail in GC at that point, rather than run a parallel record on a 
spreadsheet or whatever.

Regards,

Michael


OK, I think I understand now. And it seems straight forward to implement in 
gnucash, though you will an easy way to suppress the detail on most reports.

When your organization has money come in for any purpose, that is a debit to 
cash (or some bank account) and a credit to some income account. Could be a 
split to multiple income accounts. Follow so far?

So in your income tree, one item is "donations". Under that you have an account for each donor. A FULL "statement of 
revenues and expenses" << gnucash name Income Statement but I gave it the usual title a non-profit uses; a for profit 
says "profit and loss" >> shows the detail (total for each donor. But usually you would probably want to suppress 
that. You could try a dummy placeholder (say named "donors") in between donations and the individual donor accounts and 
try hiding that subtree when producing the report for the governing board who might want to know the total of all donations but not 
how much from each whom.

Michael

PS: So a typical transaction for an event where person A "rounds up" as a 
donation.
 debit
 cash   X
 credit
 dinner share   X - Y
  donor A  Y


It’s actually a little simpler than that, because a nominated cashier collects 
X from each member at the door but only has to pay X - Y to the venue after the 
meal, passing Y to the Charities Account.

We have chosen to label this income “Charity Choice” - two members are selected 
at the end of the year to nominate their favourite charities to receive the 
proceeds.

Thus I have:

Income:Charity Choice:MemberA
Income:Charity Choice:MemberB
etc.

Visiting members from other Rotary Clubs are charged in the same way, and (so 
far) I’ve recorded this income in the parent account (Income:Charity Choice), 
but there might be an argument for accumulating this income in a generic 
non-member child account (Income:Charity Choice:NonMember). We don’t claim Gift 
Aid on the latter.

My difficulty is that we have several other buckets in which we accumulate 
income from members during the year, so I need:

Income:Bucket1:MemberA … MemberN
Income:Bucket2:MemberA … MemberN
etc.

 From time to time during the year I need to report on the total contents of 
each bucket, and once a year I have to report each individual member’s total 
contributions to all buckets. I think that using the Business Features might 
ease these two reporting requirements in that the Income buckets wouldn’t need 
all these child accounts and each member would have all bucket contributions 

Re: [GNC] Bookkeeping for a club's charity account - use business features?

[Michael Hendry]

> On 24 Aug 2019, at 23:03, Mike or Penny Novack  
> wrote:
> 
> On 8/24/2019 5:39 PM, Michael Hendry wrote:
> 
>> This is for the Gift Aid claim. We have to put in an annual claim to the 
>> taxman, identifying each contributor and his/her total amount donated during 
>> the year. Many UK charities use this method to boost their income - for 
>> example, when you pay the National Trust for Scotland the admission fee for 
>> one of their properties, they’ll ask you if you’re willing for them to make 
>> a Gift Aid claim and take down enough details to make that claim. You have 
>> to have enough income to be taxed at the basic rate, and the charity can 
>> claim tax back at a rate 25% of the admission fee.
>> 
>> I have to account for the income as it is received, and I’d prefer to record 
>> sufficient detail in GC at that point, rather than run a parallel record on 
>> a spreadsheet or whatever.
>> 
>> Regards,
>> 
>> Michael
>> 
> OK, I think I understand now. And it seems straight forward to implement in 
> gnucash, though you will an easy way to suppress the detail on most reports.
> 
> When your organization has money come in for any purpose, that is a debit to 
> cash (or some bank account) and a credit to some income account. Could be a 
> split to multiple income accounts. Follow so far?
> 
> So in your income tree, one item is "donations". Under that you have an 
> account for each donor. A FULL "statement of revenues and expenses" << 
> gnucash name Income Statement but I gave it the usual title a non-profit 
> uses; a for profit says "profit and loss" >> shows the detail (total for each 
> donor. But usually you would probably want to suppress that. You could try a 
> dummy placeholder (say named "donors") in between donations and the 
> individual donor accounts and try hiding that subtree when producing the 
> report for the governing board who might want to know the total of all 
> donations but not how much from each whom.
> 
> Michael
> 
> PS: So a typical transaction for an event where person A "rounds up" as a 
> donation.
> debit
> cash   X
> credit
> dinner share   X - Y
>  donor A  Y
> 

It’s actually a little simpler than that, because a nominated cashier collects 
X from each member at the door but only has to pay X - Y to the venue after the 
meal, passing Y to the Charities Account. 

We have chosen to label this income “Charity Choice” - two members are selected 
at the end of the year to nominate their favourite charities to receive the 
proceeds.

Thus I have:

Income:Charity Choice:MemberA
Income:Charity Choice:MemberB
etc.

Visiting members from other Rotary Clubs are charged in the same way, and (so 
far) I’ve recorded this income in the parent account (Income:Charity Choice), 
but there might be an argument for accumulating this income in a generic 
non-member child account (Income:Charity Choice:NonMember). We don’t claim Gift 
Aid on the latter.

My difficulty is that we have several other buckets in which we accumulate 
income from members during the year, so I need:

Income:Bucket1:MemberA … MemberN
Income:Bucket2:MemberA … MemberN
etc.

From time to time during the year I need to report on the total contents of 
each bucket, and once a year I have to report each individual member’s total 
contributions to all buckets. I think that using the Business Features might 
ease these two reporting requirements in that the Income buckets wouldn’t need 
all these child accounts and each member would have all bucket contributions 
recorded in his own customer record. This would also allow me to record 
commitments to contribute to any particular bucket at some point in the future 
and report on these via Accounts Receivable.

Having no experience of the Business Features, I may not be seeing the elephant 
trap concealed in my path!

Regards,

Michael



___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Bookkeeping for a club's charity account - use business features?

[Mike or Penny Novack]

On 8/24/2019 5:39 PM, Michael Hendry wrote:


This is for the Gift Aid claim. We have to put in an annual claim to the 
taxman, identifying each contributor and his/her total amount donated during 
the year. Many UK charities use this method to boost their income - for 
example, when you pay the National Trust for Scotland the admission fee for one 
of their properties, they’ll ask you if you’re willing for them to make a Gift 
Aid claim and take down enough details to make that claim. You have to have 
enough income to be taxed at the basic rate, and the charity can claim tax back 
at a rate 25% of the admission fee.

I have to account for the income as it is received, and I’d prefer to record 
sufficient detail in GC at that point, rather than run a parallel record on a 
spreadsheet or whatever.

Regards,

Michael

OK, I think I understand now. And it seems straight forward to implement 
in gnucash, though you will an easy way to suppress the detail on most 
reports.


When your organization has money come in for any purpose, that is a 
debit to cash (or some bank account) and a credit to some income 
account. Could be a split to multiple income accounts. Follow so far?


So in your income tree, one item is "donations". Under that you have an 
account for each donor. A FULL "statement of revenues and expenses" << 
gnucash name Income Statement but I gave it the usual title a non-profit 
uses; a for profit says "profit and loss" >> shows the detail (total for 
each donor. But usually you would probably want to suppress that. You 
could try a dummy placeholder (say named "donors") in between donations 
and the individual donor accounts and try hiding that subtree when 
producing the report for the governing board who might want to know the 
total of all donations but not how much from each whom.


Michael

PS: So a typical transaction for an event where person A "rounds up" as 
a donation.

 debit
 cash   X
 credit
 dinner share   X - Y
  donor A  Y

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Bookkeeping for a club's charity account - use business features?

[Michael Hendry]

> On 24 Aug 2019, at 21:58, Mike or Penny Novack  
> wrote:
> 
> On 8/24/2019 11:57 AM, Michael Hendry wrote:
> 
>> Thanks, Mike.
>> 
>> The club itself keeps its own financial records for running expenses etc. 
>> Any income arising from charitable activities is passed to a trust which is 
>> registered as a charity with OSCR (the relevant regulatory authority in 
>> Scotland). Any donation to this charity from a member (or indeed from any 
>> member of the public) is eligible for Gift Aid. The treasurer for the last 
>> five years is a retired banker, and his accounts were all certified by a 
>> chartered account before being passed on to OSCR so I think the principles 
>> have been established. What I am trying to do is find the best way of using 
>> GC to record and report the necessary information.
> OK, like I said, I've done stiff like this but don't know YOUR regs and seems 
> different so I want clarification.
> 
> In addition to knowing the amounts (these extras that are designated as 
> charitable donations) you have to report to the government "from whom"? Here 
> we would not -- thus at an event, might be stated "event cost $X per person, 
> pay at least that much. If people pay more, the extra will be given to 
> charity A. The organization would report the amount, but how much from each 
> person who did donate extra. Like when at a meeting of an organization a 
> motion is raised to donate to some charity by passing around a hat.
> 
> If it is similar where you are, what is the tracking by member for?

This is for the Gift Aid claim. We have to put in an annual claim to the 
taxman, identifying each contributor and his/her total amount donated during 
the year. Many UK charities use this method to boost their income - for 
example, when you pay the National Trust for Scotland the admission fee for one 
of their properties, they’ll ask you if you’re willing for them to make a Gift 
Aid claim and take down enough details to make that claim. You have to have 
enough income to be taxed at the basic rate, and the charity can claim tax back 
at a rate 25% of the admission fee.

I have to account for the income as it is received, and I’d prefer to record 
sufficient detail in GC at that point, rather than run a parallel record on a 
spreadsheet or whatever.

Regards,

Michael

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Bookkeeping for a club's charity account - use business features?

[Mike or Penny Novack]

On 8/24/2019 11:57 AM, Michael Hendry wrote:


Thanks, Mike.

The club itself keeps its own financial records for running expenses etc. Any 
income arising from charitable activities is passed to a trust which is 
registered as a charity with OSCR (the relevant regulatory authority in 
Scotland). Any donation to this charity from a member (or indeed from any 
member of the public) is eligible for Gift Aid. The treasurer for the last five 
years is a retired banker, and his accounts were all certified by a chartered 
account before being passed on to OSCR so I think the principles have been 
established. What I am trying to do is find the best way of using GC to record 
and report the necessary information.
OK, like I said, I've done stiff like this but don't know YOUR regs and 
seems different so I want clarification.


In addition to knowing the amounts (these extras that are designated as 
charitable donations) you have to report to the government "from whom"? 
Here we would not -- thus at an event, might be stated "event cost $X 
per person, pay at least that much. If people pay more, the extra will 
be given to charity A. The organization would report the amount, but how 
much from each person who did donate extra. Like when at a meeting of an 
organization a motion is raised to donate to some charity by passing 
around a hat.


If it is similar where you are, what is the tracking by member for?

Michael
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Bookkeeping for a club's charity account - use business features?

[Michael Hendry]

> On 24 Aug 2019, at 15:41, Mike or Penny Novack  
> wrote:
> 
> On 8/23/2019 10:59 AM, Wm via gnucash-user wrote:
>> 
>>> For example, the price of the meals at meetings is rounded up to the 
>>> nearest pound, and the remainder is earmarked for “Charity Choice”. Not all 
>>> members attend every meeting, and some members skip the meal and make a 
>>> token payment to Charity Choice. There are several such income headings to 
>>> deal with.
>> 
>> Sounds like crap to me.
>> 
>> Think about this: I went to dinner with my mates, said it cost more than it 
>> did and said the difference was for charity.  Would you believe me?
>> 
>>> The difficulty is that it must be possible to document each individual 
>>> member’s contributions over the year in order to make a Gift Aid claim to 
>>> Her Majesty’s Revenue and Customs (HMRC), which tops up the members’ 
>>> contributions by 25%.
>> 
>> OK, it sounds to me like you're being asked to cheat HMRC.  Are you prepared 
>> to do that? 
> 
> You know all that much, both about the charitable components (tax deductible, 
> need to be reported separately) of organizations that while non-profit (tax 
> exempt) are not "deductible" << for example, a "fraternal" society -- what 
> this is >> and specifically what is required in the UK?
> 
> What was asked for here seemed perfectly above board to me. Besides being 
> treasurer of 501(c)3's I also belong to organizations that are not deductible 
> BUT do sometimes make charitable donations. In some cases, that is a lot of 
> what these organizations do beyond their social functions << Lions, Shriners, 
> etc. >>  I do not know how they report even here in the US let alone in the 
> UK.

Thanks, Mike.

The club itself keeps its own financial records for running expenses etc. Any 
income arising from charitable activities is passed to a trust which is 
registered as a charity with OSCR (the relevant regulatory authority in 
Scotland). Any donation to this charity from a member (or indeed from any 
member of the public) is eligible for Gift Aid. The treasurer for the last five 
years is a retired banker, and his accounts were all certified by a chartered 
account before being passed on to OSCR so I think the principles have been 
established. What I am trying to do is find the best way of using GC to record 
and report the necessary information.

My predecessor has passed on unpopulated spreadsheets for this club year, and I 
plan to run both methods until I can decide which is better.

Regards,

Michael

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Bookkeeping for a club's charity account - use business features?

[Mike or Penny Novack]

On 8/23/2019 10:59 AM, Wm via gnucash-user wrote:


For example, the price of the meals at meetings is rounded up to the 
nearest pound, and the remainder is earmarked for “Charity Choice”. 
Not all members attend every meeting, and some members skip the meal 
and make a token payment to Charity Choice. There are several such 
income headings to deal with.


Sounds like crap to me.

Think about this: I went to dinner with my mates, said it cost more 
than it did and said the difference was for charity.  Would you 
believe me?


The difficulty is that it must be possible to document each 
individual member’s contributions over the year in order to make a 
Gift Aid claim to Her Majesty’s Revenue and Customs (HMRC), which 
tops up the members’ contributions by 25%.


OK, it sounds to me like you're being asked to cheat HMRC.  Are you 
prepared to do that? 


You know all that much, both about the charitable components (tax 
deductible, need to be reported separately) of organizations that while 
non-profit (tax exempt) are not "deductible" << for example, a 
"fraternal" society -- what this is >> and specifically what is required 
in the UK?


What was asked for here seemed perfectly above board to me. Besides 
being treasurer of 501(c)3's I also belong to organizations that are not 
deductible BUT do sometimes make charitable donations. In some cases, 
that is a lot of what these organizations do beyond their social 
functions << Lions, Shriners, etc. >>  I do not know how they report 
even here in the US let alone in the UK.


Michael D Novack



___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Bookkeeping for a club's charity account - use business features?

[Wm via gnucash-user]

On 23/08/2019 09:24, Michael Hendry wrote:

First, Adrien makes some very valid points which I think you should 
consider.



As previously mentioned on the list, I’ve just become Treasurer of our local 
Rotary Club, which has two sets of books, one relating to the business of 
running the club (annual subs, insurance, secretarial support, etc) and the 
other to the club’s charitable activities.

The club part is straightforward, and has no need for the business features.

The charity accounts are different in that although the bulk of the income 
comes from the general public, some of it is extracted from members with 
particular charitable destinations in mind.


Charitable organisations have some quite specific accounting 
requirements in the UK and most countries.  Don't let the other people 
fool you about where the money is going to and from.



For example, the price of the meals at meetings is rounded up to the nearest 
pound, and the remainder is earmarked for “Charity Choice”. Not all members 
attend every meeting, and some members skip the meal and make a token payment 
to Charity Choice. There are several such income headings to deal with.


Sounds like crap to me.

Think about this: I went to dinner with my mates, said it cost more than 
it did and said the difference was for charity.  Would you believe me?



The difficulty is that it must be possible to document each individual member’s 
contributions over the year in order to make a Gift Aid claim to Her Majesty’s 
Revenue and Customs (HMRC), which tops up the members’ contributions by 25%.


OK, it sounds to me like you're being asked to cheat HMRC.  Are you 
prepared to do that?



I have set up a series of accounts of the form:

Income:Destination1:member1 … Income:Destination1:memberN

…

Income:DestinationX:member1 … Income:DestinationX:memberN


don't do it like that, think of income as a source not a person, "where 
are we getting our income from?", "who are we paying our expenses too?", 
"are we washing money?"



which allows me to report on the total income for each destination easily, but 
makes it harder to pick out individual members’ contributions.

Changing the hierarchy to Income:memberN:DestinationnX would make it easy to 
pick out the Gift Aid detail per member, but harder to report on the total 
raised for each destination.


gnc is unusually flexible in that you can change the hierarchy on the 
fly and report on that (you should also look at the buglist if you find 
altering, editing or creating accounts turns out to be a problem).



It occurs to me that it might be easier to treat members as customers, who 
would “purchase” Gift-Aid-Claimable (as well as non-claimable) items. In the 
case of “Foundation Dinners”, members commit in advance to pay for a meal at 
another member’s home - this commitment would be equivalent to an order payable 
on delivery of the goods. I wouldn’t anticipate issuing invoices, but a monthly 
list of defaulters would allow me to issue gentle reminders.


This is a classic charitable issue.  Our american friends have their 
answers but they only work in some states and not others.


I think you'll find your Rotary Club might have been breaking the 
charitable reporting rules for a while.



It might well be easier to deal with some of these reporting tasks using 
spreadsheets, but I’d much prefer to have a single point of entry for each 
transaction.


The problem isn't a gnc one, start here

https://www.gov.uk/government/organisations/charity-commission

depending on how much money you are processing you may or may not need 
to report some stuff.



It’s been the usual practice for Treasurers to serve for five years, so 
slow-but-sure is preferable to fast-and-dirty.

I’d appreciate the advice of the list - especially from anyone with practical 
experience of my situation.


This isn't about gnc, this is about understanding the rules about 
charities.  Having a dinner with friends and declaring it a charitable 
contribution is a bit last century.


Hitting a women is also regarded as wrong.

Voting a stupid man president or a buffoon prime minister is, however, 
allowed in some countries.


HTH

Wm

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Bookkeeping for a club's charity account - use business features?

[david whiting]

I'm also experimenting with ways of using gnucash for a member
organisation, in my case a local football club with 27 teams across
different age groups. We have around 450 current members each year, with a
fair amount of churn (about 100 members leave and 100 new members join each
year as players switch between clubs in the area, or stop playing and new
players start). Each member pays monthly subs so I have a lot of
transactions to deal with.

At the moment I have members as assets accounts, e.g. assets:members:david
and transactions to income:subs. When members pay, ideally directly into
the club current (checking) account, I have the transaction go from the
bank account to the appropriate member account, e.g. assets:current
assets:current account -> assets:members:david. This way the asset:member
accounts show me the transactions for a given member and the income:subs
account shows me how much I (should) have received in subs. If members have
not paid-up then there will be a balance owed in their asset account. You
could have separate income accounts for each destination. So, with the
following accounts:

Assets:members:member1
Assets:members:member2
Assets:members:memberN

Income:destination1
Income:destination2
Income:destinationN

And the following transactions:

Assets:members:member1 -> Income:destination2  $10
Assets:current assets:checking account -> Assets:members:member1 $10

Assets:members:member1 -> Income:destination3  $20

you would be able to see how much each member has contributed (or at least
committed to contributing) to each destination and easily see how much each
member owes. I've created a demo gnucash file to demonstrate this and
uploaded it here:
https://www.dropbox.com/s/ccf3ugufp79miht/membership%20example.gnucash?dl=0
In this example you can see that member 1 has committed to contributing £10
to destination 1 and £20 to destination 2, but has only paid £10 so far, so
owes £20. If you look at income:destinations:destination 1 you can see that
£25 has been committed in total, and so on.

I have no accounting training whatsoever (this is the careful application
of brute force and ignorance) so this could be really bad practice, but it
does seem to me to be transparent and allows me to easily track where the
money is and who I need to chase for subs payments (a significant part of
my life now!).

David





On Fri, 23 Aug 2019 at 18:39, Michael Hendry 
wrote:

> > On 23 Aug 2019, at 14:48, Adrien Monteleone <
> adrien.montele...@lusfiber.net> wrote:
> >
> > The business features certainly offer some perks with respect to
> reporting, reminders and info lookups.
> >
> > I’d probably take that approach in some fashion if I had to tackle the
> problem myself.
> >
> > However, if the only reason you are considering using them is simply to
> handle multi-dimensional reporting, consider this:
> >
> > The Transaction Report (as well as some other reports) can be filtered
> (with regular expressions, not just with other accounts) and that report in
> particular can have 2 sorting dimensions with sub-totals. One could also
> apply a view filter to an account or run a search and then run an ‘Account
> Report’ from the result.
> >
> > For multi-dimensional issues, I’d solve those by using the ‘Description’
> field as one dimension, and the ’Notes’ and/or ‘Memo’ fields as additional
> dimensions. (the Action fields might also be useful here) This would be in
> addition to the regular ‘Account’ field as the primary dimension.
> >
> > You might even be able to keep all donations in a single account or a
> small handful of accounts, greatly simplifying your CoA and other
> organization reports.
> >
> > Consider booking the donations using the member name as the Description
> and putting the destination in the Notes or other fields. You could also
> track the sources such as ‘Foundation Dinners’ if you’ll have more than
> one, and the need to do so, in any other unused fields.
> >
> > As long as you are consistent in where the information appears, a
> semi-custom filtered report could be achieved.
> >
> > The drawback to regular transactions would be issuing reminders, but
> that could be accomplished by employing a ‘receivables’ type account that
> would be filled with scheduled transactions for each member, and then the
> actual payments would reduce those balances as transfers to some other
> account to accumulate donations YTD. (this would be a second layer of
> transaction info, not the tracking of actual funds moving around) You could
> then run a report based on such accounts.
> >
> > The only drawback to this approach would be if you also needed GnuCash
> to double as a member ‘database’ with address, contact info, etc. In that
> case, making all members ‘customers’ might be the better route because such
> information already has a place to be stored without having to shoe-horn it
> into individual transactions. (but even that would be possible, and
> auto-fill will greatly assist with 

Re: [GNC] Bookkeeping for a club's charity account - use business features?

[Michael Hendry]

> On 23 Aug 2019, at 14:48, Adrien Monteleone  
> wrote:
> 
> The business features certainly offer some perks with respect to reporting, 
> reminders and info lookups.
> 
> I’d probably take that approach in some fashion if I had to tackle the 
> problem myself.
> 
> However, if the only reason you are considering using them is simply to 
> handle multi-dimensional reporting, consider this:
> 
> The Transaction Report (as well as some other reports) can be filtered (with 
> regular expressions, not just with other accounts) and that report in 
> particular can have 2 sorting dimensions with sub-totals. One could also 
> apply a view filter to an account or run a search and then run an ‘Account 
> Report’ from the result.
> 
> For multi-dimensional issues, I’d solve those by using the ‘Description’ 
> field as one dimension, and the ’Notes’ and/or ‘Memo’ fields as additional 
> dimensions. (the Action fields might also be useful here) This would be in 
> addition to the regular ‘Account’ field as the primary dimension.
> 
> You might even be able to keep all donations in a single account or a small 
> handful of accounts, greatly simplifying your CoA and other organization 
> reports.
> 
> Consider booking the donations using the member name as the Description and 
> putting the destination in the Notes or other fields. You could also track 
> the sources such as ‘Foundation Dinners’ if you’ll have more than one, and 
> the need to do so, in any other unused fields.
> 
> As long as you are consistent in where the information appears, a semi-custom 
> filtered report could be achieved.
> 
> The drawback to regular transactions would be issuing reminders, but that 
> could be accomplished by employing a ‘receivables’ type account that would be 
> filled with scheduled transactions for each member, and then the actual 
> payments would reduce those balances as transfers to some other account to 
> accumulate donations YTD. (this would be a second layer of transaction info, 
> not the tracking of actual funds moving around) You could then run a report 
> based on such accounts.
> 
> The only drawback to this approach would be if you also needed GnuCash to 
> double as a member ‘database’ with address, contact info, etc. In that case, 
> making all members ‘customers’ might be the better route because such 
> information already has a place to be stored without having to shoe-horn it 
> into individual transactions. (but even that would be possible, and auto-fill 
> will greatly assist with data entry)
> 
> 
> Regards,
> Adrien

Thanks, Adrien.

Plenty of food for thought there!

I’m not desperately keen on using free text in the Description and Notes fields 
because minor variations in spelling might well cause a transaction to be 
missed, but I can see that this would greatly speed up data entry.

I’ve already set up an Asset account called “Members’ Commitments”, which will 
be populated (e.g.) as members commit to being paying guests at a Foundation 
Dinner, and then reduced to zero once a suitable date has been negotiated, the 
meal eaten and payment received.

I can foresee a lot of revisions going on until I settle down on a workable 
method.

Regards,

Michael

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Bookkeeping for a club's charity account - use business features?

[Adrien Monteleone]

The business features certainly offer some perks with respect to reporting, 
reminders and info lookups.

I’d probably take that approach in some fashion if I had to tackle the problem 
myself.

However, if the only reason you are considering using them is simply to handle 
multi-dimensional reporting, consider this:

The Transaction Report (as well as some other reports) can be filtered (with 
regular expressions, not just with other accounts) and that report in 
particular can have 2 sorting dimensions with sub-totals. One could also apply 
a view filter to an account or run a search and then run an ‘Account Report’ 
from the result.

For multi-dimensional issues, I’d solve those by using the ‘Description’ field 
as one dimension, and the ’Notes’ and/or ‘Memo’ fields as additional 
dimensions. (the Action fields might also be useful here) This would be in 
addition to the regular ‘Account’ field as the primary dimension.

You might even be able to keep all donations in a single account or a small 
handful of accounts, greatly simplifying your CoA and other organization 
reports.

Consider booking the donations using the member name as the Description and 
putting the destination in the Notes or other fields. You could also track the 
sources such as ‘Foundation Dinners’ if you’ll have more than one, and the need 
to do so, in any other unused fields.

As long as you are consistent in where the information appears, a semi-custom 
filtered report could be achieved.

The drawback to regular transactions would be issuing reminders, but that could 
be accomplished by employing a ‘receivables’ type account that would be filled 
with scheduled transactions for each member, and then the actual payments would 
reduce those balances as transfers to some other account to accumulate 
donations YTD. (this would be a second layer of transaction info, not the 
tracking of actual funds moving around) You could then run a report based on 
such accounts.

The only drawback to this approach would be if you also needed GnuCash to 
double as a member ‘database’ with address, contact info, etc. In that case, 
making all members ‘customers’ might be the better route because such 
information already has a place to be stored without having to shoe-horn it 
into individual transactions. (but even that would be possible, and auto-fill 
will greatly assist with data entry)


Regards,
Adrien


> On Aug 23, 2019 w34d235, at 3:24 AM, Michael Hendry 
>  wrote:
> 
> As previously mentioned on the list, I’ve just become Treasurer of our local 
> Rotary Club, which has two sets of books, one relating to the business of 
> running the club (annual subs, insurance, secretarial support, etc) and the 
> other to the club’s charitable activities.
> 
> The club part is straightforward, and has no need for the business features.
> 
> The charity accounts are different in that although the bulk of the income 
> comes from the general public, some of it is extracted from members with 
> particular charitable destinations in mind.
> 
> For example, the price of the meals at meetings is rounded up to the nearest 
> pound, and the remainder is earmarked for “Charity Choice”. Not all members 
> attend every meeting, and some members skip the meal and make a token payment 
> to Charity Choice. There are several such income headings to deal with.
> 
> The difficulty is that it must be possible to document each individual 
> member’s contributions over the year in order to make a Gift Aid claim to Her 
> Majesty’s Revenue and Customs (HMRC), which tops up the members’ 
> contributions by 25%.
> 
> I have set up a series of accounts of the form:
> 
> Income:Destination1:member1 … Income:Destination1:memberN
> 
> …
> 
> Income:DestinationX:member1 … Income:DestinationX:memberN
> 
> which allows me to report on the total income for each destination easily, 
> but makes it harder to pick out individual members’ contributions.
> 
> Changing the hierarchy to Income:memberN:DestinationnX would make it easy to 
> pick out the Gift Aid detail per member, but harder to report on the total 
> raised for each destination.
> 
> It occurs to me that it might be easier to treat members as customers, who 
> would “purchase” Gift-Aid-Claimable (as well as non-claimable) items. In the 
> case of “Foundation Dinners”, members commit in advance to pay for a meal at 
> another member’s home - this commitment would be equivalent to an order 
> payable on delivery of the goods. I wouldn’t anticipate issuing invoices, but 
> a monthly list of defaulters would allow me to issue gentle reminders.
> 
> It might well be easier to deal with some of these reporting tasks using 
> spreadsheets, but I’d much prefer to have a single point of entry for each 
> transaction.
> 
> It’s been the usual practice for Treasurers to serve for five years, so 
> slow-but-sure is preferable to fast-and-dirty.
> 
> I’d appreciate the advice of the list - especially from anyone with practical 
> 

[GNC] Bookkeeping for a club's charity account - use business features?

[Michael Hendry]

As previously mentioned on the list, I’ve just become Treasurer of our local 
Rotary Club, which has two sets of books, one relating to the business of 
running the club (annual subs, insurance, secretarial support, etc) and the 
other to the club’s charitable activities.

The club part is straightforward, and has no need for the business features.

The charity accounts are different in that although the bulk of the income 
comes from the general public, some of it is extracted from members with 
particular charitable destinations in mind.

For example, the price of the meals at meetings is rounded up to the nearest 
pound, and the remainder is earmarked for “Charity Choice”. Not all members 
attend every meeting, and some members skip the meal and make a token payment 
to Charity Choice. There are several such income headings to deal with.

The difficulty is that it must be possible to document each individual member’s 
contributions over the year in order to make a Gift Aid claim to Her Majesty’s 
Revenue and Customs (HMRC), which tops up the members’ contributions by 25%.

I have set up a series of accounts of the form:

Income:Destination1:member1 … Income:Destination1:memberN

…

Income:DestinationX:member1 … Income:DestinationX:memberN

which allows me to report on the total income for each destination easily, but 
makes it harder to pick out individual members’ contributions.

Changing the hierarchy to Income:memberN:DestinationnX would make it easy to 
pick out the Gift Aid detail per member, but harder to report on the total 
raised for each destination.

It occurs to me that it might be easier to treat members as customers, who 
would “purchase” Gift-Aid-Claimable (as well as non-claimable) items. In the 
case of “Foundation Dinners”, members commit in advance to pay for a meal at 
another member’s home - this commitment would be equivalent to an order payable 
on delivery of the goods. I wouldn’t anticipate issuing invoices, but a monthly 
list of defaulters would allow me to issue gentle reminders.

It might well be easier to deal with some of these reporting tasks using 
spreadsheets, but I’d much prefer to have a single point of entry for each 
transaction.

It’s been the usual practice for Treasurers to serve for five years, so 
slow-but-sure is preferable to fast-and-dirty.

I’d appreciate the advice of the list - especially from anyone with practical 
experience of my situation.

Regards,

Michael

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.