Nonprofit Reconciliation: Bridging the Gap Between Development and Finance
When I talk to both nonprofit financial managers and fundraising executives, one of the first topics that comes up is reconciliation. It’s a great word, and one that’s especially apropos to bridging the divide between Development and Finance.
‘Reconciliation’ means ensuring that numbers correspond, but it also means restoring friendly relations. Accounting and fundraising professionals have to work together for a number of reasons that could probably be the topic of an entirely separate essay. But, suffice it to say that ‘reconciliation’ is not just about the numbers tying out between systems.
Here’s a relevant story:
Prior to working for Omatic, I worked for thirteen years at Blackbaud architecting and implementing fundraising and financial management systems for nonprofits of all shapes and sizes. But hospital foundations were special to me because I had worked at one for seven years before coming to Blackbaud, first as Director of Annual Giving and then as Senior Director of Finance. So, I was working with a hospital foundation that had just gone live with Raiser’s Edge. Cynthia, the database lead, was confounded by not being able to reconcile the most recent gifts with Finance, even though the data conversion from her old system had been just about flawless.
Jean, the accounting manager, came over to where I was sitting and softly said:
“Please, stop pulling your hair out about data reconciliation. We’re starting a new fiscal year in a few weeks. Once we’re in the new year, all I really need is a posting file that I can look at in Excel, that I don’t need to manipulate, that I can easily import into a journal, and that is summarized to match my deposits. That’s all I need. If I can get a file every week that I don’t have to convert, that I don’t have to add columns to, and that I don’t have to rekey, the reconciliations will take care of themselves. I’ll be happier, and Cynthia will be happier. There’s really nothing that I want more in this relationship.”
Is Nonprofit Data Reconciliation a Tall Order?
What Jean wanted, and what most of her peers want and need, is relevant posting data to be transmitted from the Raiser’s Edge in a way that is easy to consume and to use. It goes without saying that the data have to be accurate, but precision has always been a requirement for both sides. What the Development team often does not understand (or has not tried to understand) is that posting file requirements for an accounting system often include structures that were affected due to broader institutional reporting and analysis needs.
Especially when fundraising is only one of the multiple organizational revenue sources, it’s safe to say that the accounting system was designed to support all of those sources, but also to support and control the entire expense side of the equation. It also supports areas such as asset management (think endowments), government and stakeholder reporting, and routine auditing.
The point here is that many organizations that use systems like RE for Development may need to provide fundraising data to Finance in a format that serves a number of Finance-related requirements, but may not be consistent with how RE needs to be set up for effective, productive fundraising.
If that resonates with you who are reading this, join the club.
But it’s not such a tall order as you might think. In the grand scheme of things, systems like RE contain a lot of financial data, data that will always be needed by the Finance team, and so it really just boils down to Finance understanding what Development can provide, and Development understanding how to generate the data that Finance needs. Then, you need to ensure data is transferred in the necessary format and managed without an unreasonable amount of effort.
No Need for Square Pegs in Round Holes with Data Reconciliation
I’ve worked with so many Development executives and RE database managers who feel that when they have to get fundraising financial data to accounting in the desired format, the only answer is to clutter up RE with unnecessary coding, manually rekey detail or summary transactional data into Excel, or do both.
The great fallacy here is the notion that fundraising data can’t meet the needs of both the Development team and the Finance team. RE should absolutely be configured in a way that is necessary and useful for its primary users: Development professionals and fundraisers. The trick is to be able to translate the RE setup to also provide what the nonprofit accounting team needs.
In my discussions with RE users and their Finance team counterparts, there are three main things that people like Jean and Cynthia, from my story earlier, are looking for to make them happier and their lives easier – reconciled both on paper and emotionally:
Let’s dig into each of these in a little more depth:
Flexibility Supports More Effective Nonprofit Reconciliation
It’s really pretty ‘black and white’: while the standard post file that is generated by RE is adequate for some percentage of nonprofits, it is simply not going to work for the majority, especially for those that use large, complex ERP accounting systems that serve the needs of many departments throughout the organization.
The RE GL Distributions grid on the Fund record is actually a brilliant design concept, but the standard file output is limited to being based on just a few input variables – fund, gift type, subtype – and if the transactional data for posting cannot be based on that combination of variables, you’re out of options. If you need your GL account data to be based on appeal, event, location, membership level, etc., the standard RE post file will not deliver what is needed without RE fund permutation, customization, manual effort, or all of those.
In addition, the standard RE output generates only a handful of fields – which may or may not have to be manipulated to make them importable into your GL’s electronic journals. Some of those standard output fields may be useful, others not needed, while other required fields are missing altogether, all depending on the import requirements established in your GL.
Finally, the GL may require the file of transactions for posting to be generated in a certain format, eg, XML or OFX; or it may require that credit transactions be entered with ‘negative’ amounts to support balancing; or, it may require certain column headers. One organization with which I worked preferred summary transactions from RE except for gifts of $1000 or more, in which case they wanted detailed transactions with the donor’s name in the reference field.
PostOmatic removes these limitations by allowing just about any nonprofit data element in RE to be the source for building the needed GL account numbers or any other field required for integration with your accounting system.
Plus, PostOmatic can provide flexibility on whether and when transactions are summarized (or not), how they are formatted, and how they are validated. But the most ‘beautiful’ aspect is that all of the necessary nonprofit accounting data that the GL needs from RE can be driven by how RE has been configured to best support the needs of the fundraising team.
Efficiency Allows for Expedited Reconciliation
The majority of RE users do not use the standard post-to-GL functionality; many for the reasons described above (ie, the output does not work for their GL system), others because they are locked into a report-based business process that may be effective but also labor-intensive and time-inefficient.
The typical scenarios look something like this:
- Batch commit control reports are printed and sent – or pdf’ed and emailed – to accounting, who rekeys the transaction details into journals. Or, accounting manually summarizes transactions so that they can hand-enter summary transactions into journals.
- If gift transactions are not marked as ‘Posted’ in RE, there’s a good chance that any later edits to gift records – amount, date, fund, subtype, etc. – will not be sent to accounting, which could cause a nonprofit reconciliation nightmare, and a lot of time spent trying to back-track and figure things out.
And even for those who are using the standard RE post to GL output, there’s this scenario:
- The csv post file of gift transactions by batch or for the day or week is generated in RE and then sent to accounting, who converts the file to Excel and then manipulates the Excel file to make it compatible with what’s needed for uploading into their system. This could include modifying or parsing or rekeying in GL account numbers, adding other necessary columns, reformatting financial data, as well as converting the file overall to whatever file format is required by the system.
And then there’s this:
- Once the financial data from RE are finally in the GL, a journal (paper or pdf) may be sent back to the RE team to validate and confirm what has been entered, but this now may need to be ‘unpacked’ – perhaps ‘un-summarized’ – so that what was posted to the GL can be reconciled against what was initially sent over by Development. The journal sent back over to the RE team may have GL account numbers or other coding that is meaningless to Development, further complicating the validation process.
By using PostOmatic, gift records are only entered once – into RE (which should always be the source of fundraising financial data). The posting process then locks down the gift records in RE so that they cannot be changed, which prevents nonprofit reconciliation challenges. The posting process also generates a data file that does not require any manipulation by the accounting team, and can be summarized as desired so that the GL is not cluttered with too much transactional detail.
Accounting can easily review the file as needed before importing into journals, and push it back to the RE team if anything amiss is detected before posting. Because the posting process locks down the gift transactions, any changes that do need to be made require an adjustment entry, which will generate its own proper GL entries so that there is a complete audit trail that can be followed when fundraising data need to be changed.
Accuracy Improves Nonprofit Reconciliation
We’ve talked about the additional time and effort spent when transactions need to be rekeyed, or summarized in Excel before creating journal entries, or when data or columns need to be added or removed from files that are sent over from Development to Finance. Not only can this be labor-intensive, but it also presents the additional opportunity for errors. Just as often, the accounting team may catch errors in what they received from the RE team, but if there is no posting process in place that ties RE to the GL, then accounting may not be able to trust that such errors will be remediated in RE.
In addition, RE’s standard post-to-GL functionality does not have a feature to validate that account numbers have been entered correctly on the Fund. If any account number was entered incorrectly, that incorrect account number will be sent over in the post file and will likely cause an error on the accounting side.
And, at the risk of repeating myself, there is a further opportunity for inaccuracy if RE gift records are not locked down after being sent to accounting, because it leaves them open to be changed without forcing an audit trail.
PostOmatic alleviates these situations by supporting gift data that only have to be entered once (in RE), and locking down records in RE after posting so that they cannot be changed. If later changes are required, PostOmatic forces those changes to be entered into RE (only once) leveraging the adjustment process which provides both an audit trail and GL journal entries to reflect any corrections or other gift record modifications. And, PostOmatic can include validation routines to ensure that account numbers and other required data are valid before generating the post file.
Bridging the Gap
MacMillan Dictionary defines ‘bridging the gap’ as ‘reducing the differences that separate two things or groups’ – I couldn’t have crafted a more appropriate definition for how PostOmatic works – exactly that way – to reduce any differences between financial information coming out of RE and transactional information that needs to come into the GL.
And PostOmatic does this without requiring either the Development team or the Finance team to change system structures, undertake unnecessary effort, or sacrifice business requirements. In other words, Development can use RE the way they need to use it to support the business of effective fundraising, and, with PostOmatic, Finance can get out of RE the reliable nonprofit financial and accounting data they need, in the format they need, and at the cadence they need.
The flexibility that PostOmatic provides, the efficiency that it supports, and the accuracy that it ensures are tactical benefits that any Development or Finance team would enjoy and would be grateful for. But the overriding strategic outcome goes back to that notion of nonprofit reconciliation that I started this discussion with.
PostOmatic ensures that RE numbers and reporting can always be reconciled to the numbers and reporting generated by the accounting system, and to the official statements prepared by Finance. But the solution also ensures another kind of nonprofit reconciliation: supporting a friendly relationship between Finance and Development departments and promoting ongoing collaboration that better enables the organization to deliver on its mission overall.
