By: Stu Manewith, Nonprofit Advocacy Director at Omatic Software

Nonprofit Finance professionals are often mystified by how their Development colleagues ‘do it’ – the strategies, action plans, and tactics that raise lots of money. The mailings, phone calls, luncheons, events, pledge reminders, follow-ups, and volunteer coaching sessions.

That said, those same Finance pros are thrilled with successful fundraising outcomes – because it means being able to fund the activities and plans budgeted out by the organization’s program leaders. But there’s often a cloud buried not-too-deeply within that shiny silver fundraising goal: getting the right data from the Development team over to the Finance team, without errors, without undue effort, and without drama.

Some nonprofit accounting basics

It might be best to start with some nonprofit accounting basics – really, some accounting basics that apply regardless of sector. (And, anyone who is a nonprofit Finance pro or an accountant can probably skip this section.)

The Finance team’s comprehensive system of record for financial data is called the General Ledger, often abbreviated as ‘the GL’. The GL is made up of accounts that track both the organization’s day-to-day financial activity and overall financial position.

Conventional, day-to-day financial activity seen by organizations includes revenue that comes into the organization and expenses that are paid out for program support, administrative, and operational purposes. Fundraising is a standard type of revenue – for some nonprofits, it’s the only revenue stream; for others, fundraising may be one of several revenue streams that the Finance team has to record and track.

For better or worse, and by any other name, the fundraising data system serves as what accountants might call a ‘subsidiary ledger’ to the GL. That doesn’t mean the fundraising system is inferior or subordinate. What this means is that the fundraising system stores a lot of detail, and only the most germane fundraising-financial data needs to be sent over to the Finance team, to be added to the GL.

Debits and credits

A well-known accounting professor would tell his students on the first day of class ‘this is all you need to remember: debits go on the left and credits go on the right’. Double-entry accounting – meaning that for each transaction there are both debit and credit entries in the GL that are ultimately required to balance – is more than 500 years old and has become the platinum standard for accounting practice and reporting worldwide.

There are two key concepts involving debits and credits that will inform how fundraising financial data are conveyed to Finance:

The finance team will need data from fundraising furnished to them in terms of debits and credits. Ideally, it will be provided that way, but if it’s not, the finance team will put in that format, and, in that latter case, they may need to make some assumptions along the way.
For fundraising, which is generally a primary revenue source, the following is typical for gift transactions; ie, when a donation is made, promised, paid off, etc.:
- Debit rows typically identify the asset component of the gift – cash, pledge, securities, etc.
- Credit rows typically identify the revenue category of the gift – however, revenue is classified by the organization – eg, donations from individuals vs. corporations, restricted gifts vs. unrestricted, gifts vs. grants, or any permutation of these categories.

There’s a little more about debits and credit below, but the main point is that fundraising financial information ultimately needs to be in that specific format for it to be usable by Finance, but it’s not the ‘natural’ state in the fundraising system. It’s important to determine who’s going to translate the data and ensure that translation can support ongoing reconciliation between systems.

What is the Finance team responsible for?

At the end of the day – really, at the end of the fiscal year or any fiscal period – the finance team is responsible for financial reporting that complies with generally accepted accounting principles (‘GAAP’), and that meets the objectives and requirements of:

organizational leadership
federal and provincial government agencies that monitor tax statuses and other nonprofit financial compliance
external and internal auditors

Further, this reporting has to be able to be ‘unpacked’, ie, auditable, so that any figures presented can be investigated at the transactional level, if necessary, and followed back to the source.

As a rule, financial reporting data are pulled from the General Ledger. In order for the Finance team to be able to effectively deliver financial reporting that meets the criteria above, the GL must contain all of the data that is required from all revenue and expense sources, which includes fundraising. The financial data from the subsidiary ledgers must not only be accurate, but must get reported in the GL in a timely fashion, so that financial reports provide a full and true financial snapshot.

And, most importantly – think about that ‘unpacking’ statement – the data in the GL must ‘tie back’ to – be easily reconcilable to – the corresponding figures coming from the sources, and certainly including the fundraising system.

What fundraising data does the Finance team need?

What the Finance team needs will depend on how the GL is set up, and the GL is very often set up to support financial reporting that meets the requirements discussed above. For example, as stated above, fundraising revenue may be classified in the GL so that reporting can present it in different groupings; eg, separate lines for donations from individuals, corporations, and foundations; etc.

In addition, practicality – as well as GAAP – dictate that gifts of cash be recorded in separate GL: accounts from gifts of other assets. Pledges – another type of asset – must be recorded in separate GL accounts as well. Pledge payments – whether cash or non-cash – cannot be counted as revenue if the pledge they’re paying has already been counted as revenue. And one further complexity: temporarily or permanently restricted donations must also be tagged in the GL so that they can be reported on separately from unrestricted contributions if needs-be.

Furthermore, depending on the accounting system used, there may be other data that the system – not necessarily the finance team – requires. This could be a batch number, a transaction reference, or fund code.

While that’s a lot to absorb, the bright side is this: after reviewing the most common accounting systems used by nonprofits, most systems only require a finite set of data elements for each gift transaction; ie, only a handful of columns for each row. Here are the main ones:

Date of transaction – easy.
Amount of transaction – easy.
Whether the transaction is a debit transaction or a credit transaction. Each gift will generally require one of each, but sometimes there will be exceptions. In addition, some Finance teams will prefer all transactions for a particular date summarized to reduce clutter in the GL. More on that below.
GL account number or account string – this is where the rubber hits the road in properly classifying the fundraising transactions. Each transaction’s account string will not only tell finance if it’s a debit or a credit, but also key additional information about the revenue category, any gift restrictions, if it’s a pledge or payment against a pledge, etc. Restricted contributions are typically coded somewhere in the account string so that they can be segregated in reporting when necessary.
A number of systems require an additional fund, project, or purpose code or designator which indicates the purpose of the donation.

Some Finance systems require that the different segments of an account string to be pulled into or parsed into separate columns; others required the debit amounts and the credit amounts in separate columns, or credit amounts to be stated as negative numbers (an old-school method of balancing – all debits and credits when added together should equal 0).

Some Finance teams prefer that transactional data sent over from Development for a particular date or deposit be summarized by account number, so that there are fewer entries that have to be added to the GL. That’s a common and effective way to keep the GL uncluttered, as long as the summarized numbers in the GL can be easily tied back to the detail in the fundraising system at any given time.

When you look at it closely, the Finance team does not need that much. But whatever is required has to be accurate, valid, and consistent, and cannot be changed after it’s been provided, unless a proper adjustment procedure is used.

How to translate fundraising financial data into accounting financial data

By this time, it may start becoming obvious that none of this happens in a vacuum. Assuming the Development and Finance systems are already in place and have not been designed together to support the easy transfer of data, the most important first step is focused and collaborative communication. Start with a discussion – with the right stakeholders, decision-makers, and amount of time – that explores the following questions:

What is the preferred cadence for sending data from fundraising to Finance? Best-practice is daily or by-deposit (for easy reconciliation), but that’s just a starting point.
What file format does the accounting system require for uploading or importing, and exactly what fields or columns are needed.
Does Finance prefer fundraising data summarized or furnished in detail for each gift transaction?
While gift date and gift amount are standard, where in the fundraising system is best to store data elements like the account string (or the parsed fields that comprise it)? Do the fund code or gift code or other standard data elements lend themselves to being used to hold data values that Finance needs? Would an additional fundraising app or integration help expand your current system to fill these needs?
If not, does there need to be some type of ‘crosswalk’ built so that data coming out of the fundraising system can be transformed to what finance needs?
In what ways does a data file furnished by Development have to be manipulated, either before sending it to Finance or by the Finance team after they receive it?
What methods need to be put into place to ensure that the two systems can be reconciled on-demand?

Once these conversations have been started and these issues discussed and addressed, there will likely be one or more reasonable paths forward.

Teams can effectively integrate data from their fundraising to their accounting systems by using technology solutions – such as implementing an automated crosswalk software – which can ensure that nobody on either team is required to manipulate transactions, add or delete rows or columns, or convert files to a different format – saving effort and ensuring accuracy.

Such solutions that integrate fundraising data with general ledgers can typically be configured to generate required files without ‘upending’ the fundraising system or forcing its users to use unfamiliar (or ‘unnatural’) structures, coding, and distributions. They are often worth their weight in gold, especially for organizations that have a high volume of gifts and/or that are required to post daily.

No mystery

Whether the Finance professionals are mystified by the workings of the Development team or not, what matters most is properly accounting for all of that money that they are raising. And proper accounting has to be the responsibility of both the Finance team and the fundraisers. Finance needs to be straightforward, but collaborative and reasonably flexible about exactly what they need, when they need it, and in what format. The Development team has to be equally flexible and collaborative, and understand that what the Finance team needs is often bigger than both teams and beyond either team’s control.

Perhaps the most startling outcome – completely unexpected by some – will be accurate fundraising data that efficiently flows from Development to Finance – without mystery.

About the Author

Stu Manewith joined Omatic Software almost five years ago as Director of Professional Services. In that role, he provided leadership to Omatic’s consulting, implementation, training, and custom-development teams. Prior to that, Stu worked for 13 years at Blackbaud, also in Professional Services, working with the Raiser’s Edge, Financial Edge, and Blackbaud CRM implementation and consulting teams as a consultant, solution architect, and practice manager.

Previously, Stu spent the first half of his career as a nonprofit executive, fundraiser, and finance director, working in both the healthcare and arts/cultural arenas of the nonprofit sector. He holds business degrees from Washington University and the University of Wisconsin, and he earned his CFRE credential in 1999.

Currently, Stu serves as Omatic’s Nonprofit Advocacy Director. In that role, he is Omatic’s nonprofit sector domain specialist and subject-matter expert, and is responsible for actively promoting and demonstrating Omatic’s position as the nonprofit industry authority on data health and integration.