Members or contributions missing from a payment run

In this article, you will learn how to fix issues with payment runs that do not include all members or contributions:

Contents

• Quick Guide
• Check Why Members Were Excluded
• Assign Members to the Correct Payment Run Group
• Check the Payment Method in the Member Account
• Check the Stops in the "Account balance" Widget
• Verify the Payment Run Configuration
• Contact Customer Support
• Related Articles

Quick Guide

1. Open Finance / Payment runs and select the payment run you want to check.
2. Open the "Non-involved members" tab and read the reason listed for each missing member.
3. Open the "Considered debt claim types" tab to see which types of receivables the run collected.
4. Fix the cause in the member account, for example the payment method, the SEPA mandate, the address or an active collection stop.
5. Check the option you selected in the field "Payment run group" when the run was created. "All members" collects without any restriction, "Members without payment run group" collects only members and contracts that have no group at all, and a group listed by its name collects only that group.
6. Check the configuration if contributions are missing: the payment run group, the types of receivables and the collection of future receivables.
7. Start a new payment run and contact customer support if the issue persists.

Check Why Members Were Excluded

The payment run itself documents why a member was left out. Open Finance / Payment runs and select the run. The detail view is divided into the tabs "Detailed evaluation", "Members", "Non-involved members", "Failed payments" and "Considered debt claim types".

The "Non-involved members" tab lists every member that was excluded from this run, with the columns "Member no.", "First name", "Last name", "Reason", "Origin" and "Original claim sum". The "Reason" column is the fastest way to find the cause. The "Origin" column shows whether the reason was raised by the software itself or by the factoring service that purchases the claims. You can export the list from the tab if you want to work through it outside the software.

These are the reasons the software can show and what to check for each of them:

A member that does not appear in the "Non-involved members" tab at all either was not selected for this run or had no receivable that matched the configuration of the run. Both cases are covered in the following sections.

Assign Members to the Correct Payment Run Group

Payment run groups let you split your members into separate collection groups. You manage them in Settings / Finance / Payment run groups. A group only decides which members and receivables a run picks up, so a wrong assignment leaves a member out of the run even when the payment data of that member is complete and valid.

Which members and receivables a run reaches is decided when the run is created, in the field "Payment run group". That field always carries a value, and it offers three kinds of option:

Which group counts is decided on the contract: if the contract or its main contract carries a payment run group, that group decides and the group on the member is ignored. The group on the member counts only when neither the contract nor its main contract carries one.

Important: two selections in this field leave members uncollected. First, "Members without payment run group" sits next to "All members" in the same list and can be read as "everyone else", although it collects the opposite: only the members and contracts that have no group. Select it while you mean "All members" and every member who is assigned to a group is left out of the run. Second, a run for a single group collects that group only. If your members are spread over several payment run groups, each group needs its own run, otherwise the members of a forgotten group are not collected in that period. So check the selected option and your list of groups before you start a run.

You can check this in the run itself. A member that the group selection keeps out of a run appears in the "Non-involved members" tab with the reason "Open claims meanwhile balanced", because the selection removes the receivables from the run and the open amount that remains is zero. That reason does not describe what happened, since nothing was settled. Whenever a run worked with a payment run group, do not take that reason at face value: compare the payment run group of the members concerned with the option that was selected for the run before you conclude that the claims were already paid.

Check the following three points:

• Selection in the payment run. A member assigned to a group other than the one the run was started for stays open until you start a run for that group.
• Member and contract can differ. A payment run group can be set on the member and on the contract. If the two differ, the contract wins. The software points this out with the message "The payment run group of the member and those of the contracts are configured differently. The configuration on the contract has priority." The field on the contract is labelled "Payment run group of contract". On the member, the group is the field "Payment run group" in the "Account balance" widget on the tab Management / Overview, and you change it with the action "Edit payment run group" in the "…" menu of that widget. Editing it requires the permission Settings / Resources / Roles / Manage payment run group.
• Release per facility. The payment run group has to be released for the facility of the member. You control this in the group itself with the action "Edit sharing settings", which opens the panel "Facilities with permission" and sets each facility to "Write", "Read" or "No permission". If the facility of the member is not released, the software shows the message "The customer uses the payment run group ... but it is not whitelisted in the customer studio. Please check the whitelisting of the payment run group to avoid problems with payment runs."

The form for a payment run group contains the fields "Name", "Description" and "Collection account", the checkbox "Set payment run group at contract conclusion also at member level" and the action "Edit sharing settings". Editing the payment run groups themselves requires the permission Settings / Resources / Roles / Manage payment run groups.

Check the Payment Method in the Member Account

Open the member in Members and go to the tab Management / Overview. The payment data of the member sits in the "Account balance" widget on that tab: the fields "Payment method" and "Payment run group", the four stops described in the next section, the consumption credit and the open debt claims. Use the action "Change payment method" in the "…" menu of the widget to correct the payment method.

The tab Finance / Account in the member account is the list of bookings of the member, with the columns "Due date", "Type", "Description", "Amount", "VAT", "Payment date", "PF" and "Open". It does not contain the payment method, so do not look for the payment method there. The "Account balance" widget and the "Account" tab are two different places, and only the widget holds the payment data.

Check that a means of payment suitable for collection is stored, that the bank details are complete and valid, and that the SEPA mandate is confirmed. Members that fail one of these checks appear in the "Non-involved members" tab with the reason "Invalid bank details", "Invalid SEPA mandate", "No means of payment available" or "Credit card expired".

The Account balance card holds the payment method and the payment run group, not the Account tab.

Check the Stops in the "Account balance" Widget

The software has no separate screen for payment blocks. The stops that hold back a single member sit in the "Account balance" widget on the tab Management / Overview of the member. The widget carries four different stops, and only one of them removes the member from a payment run.

The four stops of a member. Only Collection stop (manual) keeps a member out of a payment run.

If a member is missing from a payment run, the relevant stop is therefore "Collection stop (manual)", not the debt collection stop. The two are easy to mix up because the exclusion reason in the run is called "Collection stop".

You operate all four stops from the "…" menu of the "Account balance" widget. Each item is named after the action it performs, so it begins with "Activate" while the stop is inactive and with "Deactivate" once the stop is active, for example "Activate Collection stop (manual)" and "Activate debt collection stop". The same menu also holds the actions "Change payment method", "Edit payment run group", "Edit dunning level" and "Transfer to collection". Each of the other three stops acts on one process only and never on the collection itself. The "Invoice stop" suppresses the creation of invoices and receipts while the charge is still collected. The "Dunning stop" suppresses the dunning escalation and the reminder letters. The "Debt collection stop" prevents the handover of open claims to the debt collection agency. When you activate the invoice stop, the option "Create invoices retroactively after the end of the invoice stop" decides whether the claims of that period are invoiced once the stop ends. If you leave that option unticked, those claims stay uninvoiced permanently.

If a member should stay excluded from the collection, leave the "Collection stop (manual)" in place and expect the member in the "Non-involved members" tab on every following run.

Verify the Payment Run Configuration

If members are collected but individual contributions or fees are missing, the cause is usually the configuration of the receivable types or of the due dates. There is no separate configuration screen below the payment runs. The settings sit in two places:

• The payment run. Open Settings / Finance / Payment runs and select the payment run. Its detail page contains the setting "Debt claim types", which defines the receivables this run collects, and the setting "Collection of debt claims in the future", which defines whether receivables with a future due date are collected. Receivables can be collected up to 30 days in advance. A contribution that is due later than the configuration allows stays open and is collected in a later run.
• The payment run group. A payment run group can restrict the receivable types on its own, through the action "Edit types of receivables" in Settings / Finance / Payment run groups. If a group carries its own setting, the software points this out with the message "A specific setting for booking entries has been configured for this payment run group. Please check the payment run group in order to verify the to-be-collected booking entries."

To see what a run actually used, open the run in Finance / Payment runs and check the "Considered debt claim types" tab. Compare that list with the receivables you expected. If a type is missing there, adjust the payment run or the payment run group and start a new run.

Contact Customer Support

If the problem persists after these checks, contact customer support. Include the payment run, the collection date and the member number, and state the reason shown in the "Non-involved members" tab. With these details support can trace the run and help you faster.

Related Articles

• How to do a payment run
• Configuration of payment runs
• Configuration of payment run groups
• What is the difference in claim type configuration between payment runs and payment run groups?
• Configuration of the collection of future receivables
• Invalid SEPA mandates during payment run