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

[Michael Hendry]

> On 26 Aug 2019, at 17:27, Adrien Monteleone <adrien.monteleone at lusfiber.net> wrote:
> 
>> 
>> On Aug 26, 2019 w35d238, at 3:43 AM, Michael Hendry <hendry.michael at 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.

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 <<you are legally allowed to drop out of a voluntary 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 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

> 
>  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

> 
> 
> 
> 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
> 

Thanks,

Michael