Nonprofit Starter Pack and Money

At a recent gathering of nonprofit-focused Salesforce developers, we got into a deep discussion about how to best track money in Salesforce. Everyone agreed that the Opportunity object was key, but there were differing opinions about what else needed to be done and how. I realized that this group of people, who had years and years of consulting experience with nonprofits, did not have a shared understanding of the best practices of how nonprofits should track money. I include myself in this group–I’ve had nonprofit accounting explained to me countless times, and it’s been a little different each time.

This article is meant to lay out what I’ve learned about this subject from all the great finance people I’ve worked with over my career. But more importantly it will examine how it all relates to Salesforce.com and some changes Kevin Bromer is making to the Nonprofit Starter Pack.

First I’ll talk a bit about how the Nonprofit Starter Pack works today. Next I’ll get into the accounting of it all, with the full disclaimer that I am not an accountant. And then I’ll get into the new way we’re going to do things, and talk about why that’s better, all with the goal of us better understanding the business processes we support.

Salesforce.com isn’t an accounting system, but thousands of organizations use it to track money. Many organizations directly integrate with their accounting systems. Modeling money well in Salesforce.com makes that kind of integration easier. And even if you don’t integrate, the changes we’re making provide much better support for key nonprofit work like pledged gifts, and gifts with multiple payments.

I got a lot of help in writing this article from Debbi Lewang, Shalinee Thakur, Nick Bailey, Sam Dorman and of course Kevin Bromer–any insights should be attributed to them, any errors in logic or accounting are most definitely mine.

How the nonprofit starter pack works today

The Nonprofit Starter Pack is used by thousands of organizations on Salesforce.com to manage their organizations and their missions. These organizations are incredibly diverse, engaging in everything from class-room education to lobbying congress to providing health care to the homeless. But no matter what they do, they must track their organizational revenue stream, and many do in the form of gifts, grants, ticket sales, etc.

Salesforce.com has a database object called Opportunity that represents revenue and potential future revenue. It was created by the company to handle sales deals when Salesforce.com was limited to Sales and Marketing. Now that the platform is so much more flexible, the Opportunity object serves well as any kind of revenue–gifts, grants, memberships, ticket sales, etc.

The Nonprofit Starter Pack uses Opportunity to track revenue, and it works pretty well. We also have a Recurring Donations package that can be used to track gifts that are paid with more than one payment. It has a simple object and wizard for creating a schedule of Opportunities spaced out at intervals you select. It is a simple way to create multiple Opportunities that are related.

There are some limitations with the way the Nonprofit Starter Pack supports money today. The main problems have to do with a lack of support for cash in addition to revenue. In the next section I’ll talk about the accounting realities that we are planning to support.

Revenue and Cash: Nonprofit accounting

Revenue tracking and forecasting is critical to all nonprofits. Annual revenue must be reported to the IRS, and any business that doesn’t know its revenue picture can’t effectively plan for the future. This is easily done by reporting on Opportunities, and most nonprofits using Salesforce.com have already figured that out.

Nonprofit accounting (and accounting in general) is more complex than simply recording revenue, though. We need to support cash tracking in addition to revenue. This is because nonprofits can report revenue without receiving any money. When that happens from a donor or a grant maker, we often call it a pledge. The donor commits to giving to the organization, and may identify a payment schedule at that time. Let’s look at an example case to get into the specifics.

The nonprofit Friends of Tiny Creek (FOTC) wins a $1 million grant from a foundation. At the time of the award, they are promised a check for $250,000 and are told to expect 3 additional payments of $250,000 over the next 3 years. How should this be recorded on the financial statements?

FOTC records $1 million in revenue from the foundation. This is revenue in the fiscal year in which the grant was received. Because the cash isn’t received at the time the revenue is recorded, it can’t be spent yet. While the funder can put other restrictions on the gift, we will assume that this one hasn’t, and the money will be available when the cash payments are received.

So this $1 million commitment is recorded as a credit (increase) to revenue on the income statement and a debit to assets on the balance sheet.

One week later the $250,000 check comes in as promised. $250,000 is now cash that can be spent. On the balance sheet, cash is debited by $250,000 and assets receivable is credited by the same amount. The effect of this seemingly backwards transaction (there is a reason I’m not an accountant) is that $250,000 of the grant funds are now available for use and $750,000 is still to be received. [1]

The initial pledge and the resulting cash are related, but come in at very different times. And in this case you can see how the date the revenue is recorded is very different from when FOTC can actually spend the money to support it’s mission efforts. If FOTC isn’t paying attention to it’s cash picture, they’re going to have a hard time planning and delivering.

As the yearly payments come in, they are recorded and revenue is released accordingly. When all payments are made, the receivable goes to zero and the funds are available.

In this case, though, the foundation in question rescinded the last payment of $250,000. In this case, FOTC must record that amount as a write off against the receivable. That balances the sheet, and the change in revenue can be reported in their annual numbers.

The case of monthly giving

On the face of it monthly giving looks a lot like a pledge of multiple payments similar to our grant example above. A monthly giver commits to $20/month and then makes payments on a schedule. However, the monthly giver’s commitment isn’t an official pledge unless they tell you the end point of their giving. In many cases the monthly gift is started with no set end date. If you don’t know the end date, you don’t know the total revenue, so you can’t record it as pledged revenue on your income statement.

Because of this, each monthly gift should be considered a separate revenue entry, with it’s own matching cash entry when it is paid.

Better modeling cash in the Nonprofit Starter Pack

As stated earlier, the Opportunity object is great for tracking revenue. But what about cash related to that revenue? There isn’t a good way to model cash in the Nonprofit Starter Pack, but lots of Salesforce.com users have already solved this for themselves–that’s the beauty of a flexible platform. We’ve looked at those solutions can come up with something that we think works pretty well. When we release this functionality, you’ll be able to turn it on, or continue to use the Nonprofit Starter Pack as you are today.

The Nonprofit Starter Pack will get a new child object to Opportunity called Payments. Payments will be where cash is recorded. The Payment object will represent all the cash received by an organization. It will be helpful in a number of ways:

  • Payments will allow you to record received cash payments against promised revenue
  • Payments will allow you to record a payment schedule and make sure you don’t forget to collect them when they come due
  • Payments will allow you to write off rescinded payments
  • Tracking cash in Salesforce.com allows for much better analytics than most accounting systems

The Payment object will have rollup summary fields to the Opportunity that show you the number of payments per Opportunity, the amount of payments that have been made, and the remaining balance. Having this information on Opportunity makes it very easy to see which Opportunities aren’t fully paid yet.

Ok, back to our scenario for some illumination.

FOTC is a very stable organization. If we look at a dashboard of their revenue (Opportunities), we see that it’s uniform. They get about the same amount of revenue each month.

Most of those Opportunities were one-time payments–the cash came in the same time the revenue did. But about a third of them were paid in multiple payments. If we take a look at a chart of the cash, you’ll see that it’s much more irregular than the revenue chart. Note that the scale is different in these charts.

The same is true with forecasting–revenue in the future is expected to be pretty stable.

If we look at a cash forecast, it’s very lumpy, with peaks and valleys.

FOTC needs to see its revenue picture and also it’s cash picture, and it’s not clear from one what the other will look like.

Revenue where the cash is received immediately

At most nonprofits, most gifts aren’t pledged, they are just given. A typical scenario is a $100 check coming in the mail. Recording that check requires recording the revenue and the cash at the same time. Data entry is a time consuming task as it is. Having to do double entry–revenue and cash–for all gifts is an unacceptable burden, so we built automatic cash recording right in.

In the case of a gift where revenue and cash are simultaneous, the new payments functionality creates one payment for every Opportunity. It keeps this payment in sync with the Opportunity, unless you choose to set up a payment schedule. This solves the case of multi-payment gifts without causing extra work for all those gifts that don’t have multiple payments.

By creating automatic cash payments for each opp, the cash picture isn’t limited just to pledges with payment schedules, but includes all cash for all revenue. This allows for better reporting, like the charts shown above.

The case of monthly giving

For monthly giving, each gift should be considered it’s own revenue event because they aren’t connected to a known pledged amount. Therefore each gift should be an Opportunity, rather than Payments under one Opportunity. Each gift will, of course, have a payment, because all revenue does when you’re tracking revenue and cash.

The Recurring Donations functionality in the Nonprofit Starter Pack will handle this case better with the next release. You will be able to create a Recurring Donation Profile, detailing the recurring gift. The wizard will then create Opportunities according to your schedule. At present moment we’re thinking that the Recurring Donation functionality doesn’t need to know about payments at all–it will just interact with Opportunities. This may change, but it’s what we’re thinking now.

Currently Recurring Donations has the word “Pledges” in the object name. If you’ve read this far, you understand now that this is incorrect. Kevin is planning major upgrades to Recurring donations, and we will likely be renaming things to make more sense. He’s also planning on supporting the automatic creation of Opportunities for open-ended giving, and keeping the Recurring Donation Profile in sync with the Opportunities. We’ll likely give you the ability to keep a rolling year of potential gifts in the system. If you don’t want all those open gifts out there, we’ll likely give you a way to keep just one open gift for each recurring donation.

Conclusion

While Salesforce.com isn’t an accounting system, better modeling of nonprofit accounting practices is great functionality and we expect it to be popular. The coming upgrades to the Nonprofit Starter Pack will allow for cash reporting, write-offs of revenue, and facilitate collections of promised payments. Upcoming improvements to Recurring Donations will make it easier to handle recurring donations that are open ended.

If you have questions or comments on our implementation, or have feature requests, please comment on this post.

————-

1. Technically, multi-year grants are received as restricted assets. Each year the revenue is released from restricted net assets to operating net assets as it is needed (credit on the restricted side, debit on the unrestricted side). Another interesting point – multi-year pledges are worth less than cash received today.You have to discount to present value and adjust based on the outstanding amount of the pledge each year. Again, this is something you’ll likely want to handle in your accounting system.

JP Rangaswami on social objects

I’ve been really enjoying JP Ranagaswami’s latest series on social objects in the enterprise. His series so far is here, here, and here.

I’m finding his tale of the merging of internal systems of record with external systems of engagement, and the socialization and consumerization of these objects to be really compelling. The corporation is changing, and his take resonates with me. It’s worth a read.

Segmenting Campaigns

In the run up to the amazing Web of Change conference this year, I was asked to write a think-piece. I ended up writing about being scientific in the design, implementation, and analysis of our work. I called it We Must Be Scientists for Change, and it seemed to resonate with a number of the attendees.

In that article I talked about doing some simple A/B testing. A/B testing is best described as doing some effort while changing one variable in the hopes of learning something about how to affect the outcome of effort. It’s been perfected by the direct mail industry–mailings are run as experiments and each mailing adds to the base of knowledge of how to increase response rats.

As I was writing the article I became dismayed that what I was proposing wasn’t actually very easy to do in Salesforce.com, the system I champion on a daily basis. We use Campaigns for outreach efforts, and while Campaigns are incredibly powerful and easy to work with, randomly breaking them into segments for A/B testing wasn’t easy.

I say “wasn’t” because I have released a tool for A/B testing that is free to users of Salesforce.com, which is listed on the Appexchange under the name Campaign Segmentation Wizard.

Build your list of people to whom you want to reach out, then use the wizard to randomly break them into segments of the exact size you desire. Those segments are Campaigns of their own, and can be used in any way you see fit–mass email, phone banking, etc.

Here’s a short video showing how it works.

If you install it and use it, please rate the app on the Appexchange so others will get a sense if it’s helpful or not.

Load more