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