> 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 <<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 and For the Members: How much (in aggregate for all destinations) each member donated? (for Gift Aid purposes) 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 _______________________________________________ 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.
