For organizations which have integrated their accounting software with Salesforce, does your organization enter value added information such as:
- Date of check
- Date received
- Date closed
- Transaction ID
- Transaction ID type
- Via method (donation received via PayPal, Venmo, etc.)
- Source of donation (how or why the donor sent it, e.g., an appeal, event attendance, phone call to donor, website link...)
- Memo on checks
- Check number
If you do enter this, does the accounting department enter this info, or does the development department/database team? If your database/development team does, what is your workflow to organize your communications to be referenced for a transaction, syncing the transaction, notifying you that the transaction has been created, and entering the value added info from the aforementioned communications?
Also, what is your workflow for reconciling transactions so you have checks and balances to be sure all transactions are entered and entered correctly, thereby confirming that those synced from Stripe or other sources are syncing correctly and that cash and check donations are not missed?
Finally, which role is responsible for checking the contact information received on new donations against the record in the database and updating it if it has changed? What is the workflow for this?
To give some background on this question, we currently have data entered in QuickBooks by the accounting department and data entered in the CRM by the development department. The accounting department enters data by hand, capturing just:
- Amount
- Date closed
- Transaction ID
- Minimum note related to accounting concerns for the transaction (sometimes).
The development department enters data by hand, capturing:
- Amount
- Date closed
- Date of check
- Source of donation
- Transaction ID
- Memo on checks
- Check number
- Via method
- Notes written by the donor and included with the donation or those that explain the donation in some way.
*Our future goals are to capture even more info, including date received, transaction and ID type.
At the same time as the development department enters this data, they also check the contact info in the CRM against that provided in the donation, updating it as necessary, and they copy any corresponding communications to the account.
At the end of a given period (usually a week), both departments export that period's donation reports, and the development department reconciles the two, which usually results in catching cash, check or EFT donations that weren't entered at all or were entered incorrectly (wrong fund, wrong date, etc) by the accounting department (or by the development department). The development department notifies the respective department of the mismatches, and that department corrects the mismatches.
If the accounting data is simply synced to Salesforce, is this really more efficient or accurate in terms of capturing all the data both departments need and ensuring those donations which can't be synced in turn from some other source are entered and entered correctly? Erego my interest in workflows that either achieve this accuracy, efficiency, and comprehensiveness or which sacrifice something in order to integrate accounting systems with Salesforce, and how those workflows achieve these goals or what they sacrifice.
We enter almost all of the information that can be known from the check or envelope into Gift Entry in batches. We compromise on only two dates: day of close (check date unless there is a reason to accrue earlier, like postdate of envelope for something extremely late or falling across a book closing boundary, notification of grant or multi-payment donation sufficient to trigger accrual, etc) and date of deposit (payment date planned at bank). CRM batches go hand in hand with deposits of checks. If an offer code can be figured out from the source, we record it. We have a similar process for batches of other types of donations that come in regularly (Facebook). We batch entry of Payapl and STripe even though it comes in daily. We do keep track of the payment source (Paypal, which bank account, Venmo, Facebook, etc). We keep track of payment method (check, bank transfer, cash, gift card, Paypal -- since it's special). We currently trigger each Venmo donation to be transferred to the bank so that it get's handled that way. If a third party is involved in the donation from real people, we record that in a lookup field (e.g., Great Nonprofits, Benevity, United Way, etc.). There is some overlap in third party with payment source. Anyway... getting money is messy. Can't really fix that.
On the accounting side, each transaction is downloaded automatically. Currently we have one transaction per check deposit because we use mobile deposit. If we banked in person it would be a check batch. Currently accounting refers to a report in Salesforce to add names to each named transaction. It's unclear if there is value to this but it doesn't take long (150 transactions per month) and helps with reconciliation and audit.
After the fact, we often redistribute Benevity, United Way, etc in CRM. We do not match that breakdown in accounting. The information to do so comes much later than the payment. But our donors want us to know who gave what so we do it.
Once a month, we reconcile Salesforce as our source of truth (is the term "golden record" now?) for all income. We use the payment date of NPSP payments as the key date and the close amount as the amount. If there are fees taken out, accounting will notice that but we don't fix CRM since the donor thinks they gave the whole amount. (We could approximate the fee at CRM entry time but that's not always easy with bulk and batch fees that are increasingly common.) Accounting is the source of truth for income and expenses and reconciliation to external statements. They do the work each month of reconciling the salesforce report (broken down by payment type and account source) with accounting records. They generate a report that goes to CRM with things like: The following are in accounting but not in CRM: date, person (they can see check images online), amount. We investiage and fix. They also sometimes tell us we have a duplciate or something they can't find. Frequently they are right since they have the oldest and more mature data. They include a record of how much we are off for things like Benefity fees, Facebook fees (sigh... starting in October), Stripe, etc. Paypal actually downloads with fees and gross so that works great.
That's our flow and it's been working for about three years now with about 150 transactions monthly. It requires both a close date and payment date. It requires payment type and channel to sort out weird situations during reconciliation quickly. We're small... the accounting work for our books takes about the same amount of time as our twice weekly payroll administration.
Would it work at 250 transactions per month. PRobably. At 1000 transactions per month... doubtful. But at that scale, you probably would calculate the desired amounts by channel and payment type in the SF report and investigate only the big offset. At that scale it's also doubtful if we'd have one bank transaction per check. It would likely be several weekly deposit batches.
It's all about which you want to be your source of truth. We decided that CRM had to be accurate from the donor perspective and capture sufficient data to be reconciled precisely or by bins to the accounting data. We decided that accounting must reconcile to external financial statements and get sign-off for all differences from treasury. And it must reconcile monthly to CRM and get sign-off from Director or ACcounting and Development for differences (same person in this case). Annually they have to get sign-off from our auditor so the monthly paper trail is crucial, as is diligent corrective action. If it possible to duplciate all the CRM information in accounting (names, addresses, etc) But we didn't see utility to that. We generate our compliance and reporting data for donors and fundraising from CRM.
--Terry
