by james dungate
It’s a well worn charity cliché: “Every penny raised goes straight to the cause!” We can have the debate about whether or not this is desirable another time; today I want to dig into why it’s so hard to know exactly how many pennies a charity has raised, given we look after them all so carefully. Why do the CRM and Finance systems often show different amounts raised? Why is reconciliation so hard?
George Bernard Shaw (or was it Oscar Wilde?) said, “The UK and USA are two nations divided by a common language”. A lot of reconciliation challenges are caused by fundraising and finance colleagues being divided by a common language. Let’s look at some of the common challenges:
Gift amount - To a fundraiser and the CRM, this figure will be the amount that the supporter has given. But to Finance, this is the amount that the organisation received. These may be the same, but digital transactions will usually have a processing fee deducted before receipt. So that £10 donated will be slightly less in the finance system. Added up over hundreds or thousands of donations, that becomes a big difference.
Gift date - A similar dynamic is at play here. To a fundraiser, the gift date is the date the donor gives, but to Finance this is the date received in the bank. This gap can be days or even weeks – Just Giving, for example, will have a transaction for an average of about two weeks before paying it to a charity. If this gap bridges the finance department’s month end date, then the transaction will be in one month/period (delete according to whether you work in finance or fundraising!) for the CRM, but the following one for Finance. Which means month on month reconciliation will not batch.
Coding - Are you sure that every code created in the CRM is pushed through to the finance system and vice versa? You need to have a robust, unambiguous mapping of product, team and restriction codes between the two departments. Each code needs an exact counterpart in the opposite system or an agreement the code isn’t needed.
Transaction groupings - Finance systems are often dealing with multiple transactions in one – think about the pile of cheques at the end of a day’s income processing, all paid into the bank as one. This means the individual CRM transactions need to be unambiguously grouped to show a single bank deposit amount.
Exceptions - Sometimes, individual transactions get rejected at the point of paying into a bank. Think of an unsigned cheque or similar which may already be on the CRM. This is deducted from the total paid in, meaning that the CRM batch won’t align with the bank deposit, until adjusted.
Quality control - Finance and data teams are both busy service departments with multiple pressures on their time. It is important to make time to systematically verify tasks have been correctly executed. Mistakes *will* happen – it is best to proactively catch and correct them than be caught out further down the line.
So… how does this get resolved?
You have to speak the same language, not be divided by it! If you are a CRM lead, capture the information that your finance department needs, as well as the info you need. For example, have multiple gift date fields – a “transaction date” and a “banked on” date. Have gross and net transaction values. Make sure your process for creating financial coding requires sign off from finance or, even better, configure your CRM so new financial codes can only be created as a result of their being created in the finance system.
The most important thing is to understand that reconciliation is really achievable, once you’re speaking the same language. You can do this! If you’d like to discuss your reconciliation challenges, drop us a line – we love data improvement projects!