Handling standing orders

A standing order is a recurring bank transfer used in the UK. The same method goes by other names in other countries, like periodieke overschrijving in the Netherlands.

Where direct debits are set up by the creditor (you), standing orders are set up by the debtor (payer). The frequency, amount (always a fixed value), included description and duration of standing orders are controlled by the debtor, though some organizations help steer the process with standing order forms.

Standing orders can be canceled or changed by the debtor without any notification. These unpredictable changes, combined with potentially unstructured remittance information, can make standing orders hard to match and reconcile. However, once you have standing orders in your org, you can catch these changes and, for example, follow up on unpaid installments.

Standing orders and the data model

Standing orders are recurring, so they can be represented by a Recurring Payment or the equivalent source-specific objects, like Recurring Donation in NPSP.

Once you know you have a standing order, you can add the recurring payment record with installments for the duration and frequency the payer has indicated.

Setting up standing orders in FinDock

Follow these steps to create a simple setup in FinDock for handling standing orders. This is a recommended workflow only. You can customize and extend your own setup as needed. For clarity, we will use NPSP objects here, namely Recurring Donation and Opportunity. (FinDock standalone implementations would use Recurring Payment and Installment, for example.)

Step 1: Create a custom payment method

To track and report standing orders, you need to create a custom payment method. You can name the custom payment method however you like. Here we will assume it is called “Standing Order.” Once added, you need to activate and deploy the payment method to make it available in picklists.

Step 2: Create recurring donation and opportunities

For each standing order, create a recurring donation based on a standing order parameters. This procedure assumes you are working with a payment that has already been processed and you are now setting up a record for future payments.

1. Add contact if needed
2. Add recurring donation for the contact with the standing order parameters:
   • Amount = amount of each standing order payment
   • Payment Method = Standing Order
   • Open Ended Status = None if the standing order is for a fixed period
   • Next Donation Date = date of the next expected standing order payment
   • Installment Period = frequency of the standing order payments
   • Number of Planned Installments = total expected future payments
3. Add a reference for future matching purposes.
   • Custom Payment Reference = free text; add the description from the payer’s standing order; this value is in the Payment Reference field on the transaction record created by FinDock.

How to handle the creation of the recurring donation is dependent on the behavior of the donor. If they inform you upfront, you can make sure the recurring donation is present before they make their first payment so that you have all standing order payments related to the correct recurring donation.

However, it is common that donors don’t announce the standing order. In that case, we recommend creating a recurring donation after you have identified the standing order pattern in single donations. In this case, as described above, add the bank statement description to the custom payment reference on the recurring donation record to match future payments against the same recurring donation.

Step 3: Create Guided Matching rules for enrichment

For custom payment methods, you can create your own Guided Matching rules to enrich Salesforce data and expand default ProcessingHub matching.

Once you have matching logic in place, upload your bank statement file to process standing order payments. Keep in mind that there are open opportunities that share the same payment reference (see step 2 above) that is used for initial matching. You need to tell FinDock which open installment to match the next payment against using the Multiple Installment Handling setting.

With this setup, you can also identify missed payments and use your own workflows to follow up and, for instance, offer other payment methods through a personalized PayLink.