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, customer or donor). The frequency, amount, 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 the fact there is 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, if you are using NPSP, a Recurring Donation record. Each payment is represented by a single installment (opportunity in NPSP).
Once you know you have a standing order, you can add the recurring payment record with installments (or NPSP recurring donation with opportunities) 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.
- Add contact if needed
- 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
- 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: Process future payments
Once you have a recurring donation with open opportunities, you can upload your bank statement file to match the next incoming payment. ProcessingHub processes the file and matches payments based on the custom payment reference.
Since there are open opportunities that share the same payment reference, you need to tell FinDock which open installment to match the next payment against. This is determined by the Multiple Installment Handling setting under the ProcessingHub general settings.
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.