Financial Integrations

Introduction

The automated integration of data between Customer Engagement (Fundraising, CRM, Donor Management, Grant Management) and ERP applications can provide a range of benefits to any NfP:

• Significantly reduces double-entry, resulting in less overhead and reduced potential for error
• Facilitates cross-application reporting (with potential for drill-thru), thereby providing a base for 360° reporting across donors/beneficiaries, income/expenses
• Can greatly streamline key operations such as Bank Reconciliation
• Provides potential for enhanced auditing/tracking of data movements throughout an NfP

m-hance would offer a number of observations in relation to our experiences in undertaking such integrations.

Coding of Income/Expenditure

A key reason for an NfP to undertake integrations between their Customer Engagement (CE) application(s) and their ERP system is likely to be to keep account of income and expenditure. As such, it is important to ensure that any entry of income/expenditure in the CE application is recorded against appropriate codes that will mean something within your finance system.

This can of course be achieved by incorporating your hierarchy of nominal accounts within your CE application. In our experience, this isn’t necessarily the best approach. An alternative is to configure your CE application to use whatever range of Income Types, Payment Methods etc. are most appropriate for your needs and then to facilitate some form of mapping of these values to suitable nominal accounts within your ERP’s Chart of Accounts.

Your integrations could then read the mapping table using any combination of source values on your CE application (e.g. Income Type) and retrieve the appropriate nominal code against which to post to your ERP.

Reference/Static Data

Every application utilises what we would call Reference Data. Typically, this data is fairly static in nature – changing relatively infrequently. Whilst much of this data will be local to the individual application, some will apply across your organisation and so should be consistent across applications.

For certain classes of data that change very infrequently, such as your Funds, Cost Centres or Bank details, we often decide not to undertake what can be reasonably complex integrations and to recommend some business processes to ensure that data remains consistent in each application.

For other data that will change more frequently, such as Appeals, Campaigns and Events, we would typically see the CE application designated as master, with automated integrations ensuring that updated or newly created records are replicated to the ERP system. In some cases, such items may be implemented as Dimensions in order to facilitate analysis of income/expenditure within the ERP.

Transactional Postings

The likely complexity and varied nature of the processes within your CE application would present a challenge to any suite of integrations:

• You would potentially require a significant number of distinct integrations to cover each type of operation/business process (for example, within Fundraising alone, you might have such things as Direct Debit runs, daily file imports from 3rd Party Payment Providers, Standing Order transactions, Bank Lodgements etc.)
• Each one may require retrieval of differing information from different locations within your CE application(s). This not only places a burden of knowledge upon your integrations but also increases their vulnerability to changes within your application(s).

A modified approach would see transactions from all areas of the application being made available to the suite of integrations via a transactional export table/entity. Such an approach would also facilitate the simple export of transactional data for manual transfer.

Funds

NfPs are required to support apportionment of revenues across a range of Funds (Restricted and Unrestricted). Excluding specific cases where a donor may specifically designate an apportionment, most allocations of revenues across funds may follow standard patterns; in such cases, the allocation could be implemented during the generation of records on the outgoing transactional posting table.

In this way, the records for integration are already pre-allocated and can therefore simply be picked up and attributed to matching funds within your ERP application.

Donors / Debtors

In our experience, most donor records will exist only on an NfP’s CE/Donor Management/ Fundraising application – they would not typically be recorded as debtors within the NfP’s finance system.

There will however be exceptions to this, such as institutional/corporate donors or perhaps government grants. Often the criteria as to whether to record a donor as a debtor is simply whether or not they require to be invoiced (typically in advance of the donation).

In such cases, details of the donor organisation will need to be integrated to the ERP system as a Debtor account. This will typically involve automated derivation of a range of ERP-specific fields (such as Payment Terms, Default VAT Group, Default Posting Group etc.) which are not likely to exist on a donor management solution. For reporting purposes, a unique identifier should be maintained across both systems for each such Debtor/Donor.

Unlike entities such as Campaign and Event, where your front-of-house CE application will likely be the designated master (for these record types), debtors/donors will likely encounter updates in either/both applications (as different personnel will likely be using them). As such, care should be taken in terms of the synchronization of common fields such as Address, Phone No. etc.

Bank Statement Reconciliation

As mentioned previously, many different types of income transactions are likely to be supported within your Customer Engagement application(s). A key differentiator between such transaction types is how each impacts your Bank Statement. Consider these examples of transaction that could take place on any given day:

• You receive a number of cheques in the post direct to your office – these are batched, recorded on your CE application and then lodged to the bank as a single lodgement.
• You run a direct debit payment run for 10,000 direct debits, resulting in a single, aggregated transaction hitting your bank statement.
•  You receive 200 standing order payments to your bank account, each one showing up separately on your bank statement.

A key objective of any integration of income to your ERP application should be to ensure that your bank reconciliation can be as streamlined/automated as possible. This can be greatly facilitated by aggregating your income transactions at an appropriate level – e.g. one set of aggregated transactions for all income on a given DD run, but individual sets of transactions for each distinct standing order.

Debtor-related transactions can result in additional complexity, as such transactions may require isolation in order to be matched against associated invoices within your ERP.

Summary

In this article we have highlighted some potential considerations from a Data Management perspective (based on our experiences to date in the Not-for-Profit sector) in relation to integrating data from an NfP’s front-of-house Customer Engagement Application (CRM, Donor Management or Fundraising Solution) to their Finance/ERP System.

Authored by Ger Dayman