> On 26 Aug 2019, at 17:27, 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.
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 _______________________________________________ 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.
