For Part 4 of our blog series on transforming grant-making using Salesforce, the topic is Finance Management.

There are a number of elements to discuss here so they are grouped under the following headings 1) Payment management, 2) Fund tracking and 3) Integration with accounts.

1. Payment management

Each payment is recorded as a separate data record related to the funding request record (we use the term funding request rather than ‘grant’ to accommodate other funding types such as social investments) to track the amount, status and scheduled / paid dates. This means that either single or multiple payments associated with a single grant application can be created and edited throughout its lifecycle.

As with any process, some payment management requirements are more complex than others. However, the following are the most common Salesforce features that we use to ensure the necessary control:

• User profile permissions to restrict the types of users that can create and edit payments
• Criteria-based approval processes to assign tasks to specific internal contacts required to approve payments depending on the value or programme
• Automated process to create payment records when the funding request status is Approved
• Field tracking applied to the payment status field to retain the history of the edit value, date and user
• Validation rules to ensure that total payments scheduled do not exceed awarded amount
• Roll-up summary fields on the funding request to calculate how many payments have been paid, returned/cancelled against the original amount awarded and the balance outstanding
• Picklist field values to control the status of the payment – including Returned/Cancelled where negative amounts can be entered to credit balance calculations

If bank details are captured in Salesforce (some organisations prefer to keep these offline), processes can be set up to manage these including:

• Permission sets to control access to bank details fields (this is a feature that we built into our grant-making solution grantFlex)
• Verification checks to assign a task to relevant user/s to validate entries against supplied bank statements
• Automatic deletion routines (typically require custom coding) to delete bank details based on specified criteria (depending on the GDPR compliance policies)
• Automatic transfer of payment instructions via an authorised BACS bureau (this will incur an initial set up charge and ongoing volume-based transaction fee from the chosen provider).

2. Fund tracking

This is less relevant for organisations that manage a single unrestricted fund from which all grant payments are made. However, in our experience, most grant-makers have separate budgets/funds associated with multiple funding programmes.

Our recommendation is that Fund details should be stored on a separate record. This allows information related to the fund to be captured including free text or picklist fields to enter type, description etc. In our grantFlex product, we use the standard Salesforce General Accounting Unit object that comes within the Salesforce non-profit success pack, primarily because for grant-makers who also receive donations, this provides a way to track both the ins and the outs.

For simple processes, this may be enough – the funding request (grant) record can be linked directly to the fund it is paid out from and reports can be run to group / filter all approved grants and related payments by fund.

To provide a higher level of flexibility, our approach is to create a custom data object (which in grantFlex we call Fund allocation) to link the funding request to the fund and to:

• Record the total funding ‘commitment’ ie the full awarded amount separately from the payments made over time
• Fund a single project from multiple funds if required
• Record fund adjustments – for example debits for management fee or credits for bank interest amounts
• Process inter-fund transfers where amounts are moved between funds when they are closed or merged
• Track fund balances on roll-up summaries on the Fund record to reflect commitment, adjustment, returned amounts and calculate balance based on annual budgets or opening balance

Of course, on top of the basic solution infrastructure, further sophisticated processes can be developed. Some of our larger grant-making customers produce fund statements for fund holders using merge document templates. Salesforce Community cloud can be configured to provide direct access to fund holders to view transactions in real time.

3.  Integration with accounts

There are many and varied accounts solutions used by grant-makers and the level of integration will depend largely on the transaction volumes, regularity of processing and the budget available for implementation.

Export report data

The simplest way to export financial transaction data from Salesforce is to run a report filtered by record status (e.g. Approved for payment) in Excel format. This can be provided to finance team members for entry into accounts. Once posted, a standard editable list view can be used to filter and mass update the status of payment records.

Batch export file

To avoid double data entry (and human error that can be associated with manual data entry), one of the most common solutions that we have set up is to generate a formatted export file that is ready for import into accounts.  To do this, we set up processes to group all payments with a specific status onto a Batch record where they can be checked, the file generated and the status automatically updated.

Full bi-directional integration

This approach involves the transfer of data between Salesforce and accounts with no human intervention (apart from validating records of course). Depending on the accounts system, there may already be middleware available to avoid custom development (these typically incur a licence cost). Alternatively, if an API (Application Programming Interface) is available, a developer can programme the code required to manage the data transfer routine – this option will incur a higher set up cost but avoid any ongoing costs (and any changes would require development skills).

We have experience setting up each of the above for organisations using Xero, Sage, AccessDimensions and many other accounts systems. Irrespective of the approach taken, we do advise that any accounts/nominal codes required for accounts are auto-populated on Salesforce before the record is transferred (using the in-build process builder tool). It is often the case that a Salesforce implementation provides the ideal opportunity to review the structure and volume of accounts codes – mainly due to the enhanced reporting now available to the grant managers.

Hyphen8 has years of experience implementing grant-making solutions on Salesforce. If you would like more information get in touch.

In the next blog, part 5 of this series, the focus is on grant Monitoring – the processes to manage grant reporting and outcomes evaluation.

Read previous blogs in this series on the how to manage the grant-making lifecycle on Salesforce:

Part 1 – Application

Part 2 – Assessment

Part 3 – Decision