Overview
When viewing responses for a form or event registration, Slate will display a default column labeled Payment Due. In an Advancement database, this column can sometimes appear confusing. It may show a balance due, overpaid amount, paid status, or blank value even when the actual payment and gift processed correctly.
The key distinction is that Payment Due is a balance calculation based on payment activities, not a direct display of the payment transaction or gift amount from that specific form submission.
A confusing value in the Payment Due column does not necessarily mean that a payment failed, a gift was not created, or money was not received.
Key Concepts
Payment Records
A payment record is the actual transaction. It represents the payment processed through Slate Payments.
Payment records indicate whether money was received, rejected, refunded, pending, or scheduled. The payment record is connected to the gift record.
Payment Activities
A payment activity is an activity on a person's record that represents an expected or received payment amount. Payment activities may indicate that an amount is due, received, waived, or refunded.
Payment activities are used to calculate the balance that appears in the Payment Due column.
Gift Records
A gift record stores the charitable contribution. A gift can be connected to a payment record even if there is no corresponding Payment Due activity.
This is why a gift can be correct even when the Payment Due column appears blank, overdue, or overpaid.
What the Payment Due Column Shows
The standard Payment Due column does not simply show the amount entered on the form. It shows the calculated balance of relevant payment activities on the person's record.
In general:
| Display | What it usually means |
|---|---|
| Blank | No Payment Due activity is linked to the form response |
| Paid | Payment due and payment received activities balance to zero |
| Due | More payment is expected based on the activity balance |
| Overpaid | More payment has been received than was marked as due |
This calculation can include payment activity beyond the individual form response. As a result, the column may reflect a broader activity balance on the person record rather than only what happened on the specific form submission.
Why This Balance Calculation Can Be Confusing
In many Advancement workflows, a donor gives through a form, the payment processes, and a gift is created. However, the donor may not have a corresponding Payment Due activity unless the form is configured to create one.
That means the form response list may show a blank value or an unexpected balance even though the payment and gift are correct.
This is especially common for giving forms because donors are not always “paying a balance due” in the same way someone might pay an application fee, registration fee, or other required charge.
Payment Due Activities on Payment Forms
Payment forms can be configured to create a Payment Due activity automatically with each submission. This is often helpful because it gives Slate a specific expected payment amount to balance against the payment received.
This setting is generally useful when each submission represents a clear financial obligation, such as:
- Event registrations
- Online donation forms
- One-time payments where the submitted amount should be tracked as due and received
However, even when this setting is used, the Payment Due column can still be affected by other payment activity on the person's record. For that reason, the column should be interpreted as a payment activity balance, not as the definitive status of the gift or payment transaction.
Recurring Payments
Recurring payments can add additional complexity when viewing the Payment Due column.
For example, a donor may submit a recurring gift of $100 per month. If the initial submission creates one Payment Due activity for $100, and each future monthly payment creates a Payment Received activity, the balance may eventually show as overpaid.
That does not mean the donor was charged incorrectly. It means the payment activity balance now includes more received activity than due activity.
In recurring gift scenarios, the gift and payment records are usually the better source for confirming what was actually processed.
Recommended Approach for Displaying Payment Details for Forms and Events
For Advancement forms, the most reliable way to understand what happened on a specific submission is to customize the registration list.
Rather than relying on the default Payment Due column, configure Custom List Fields to show the values that matter most to your office. This allows the list to display submission-specific giving and payment details instead of a broader payment activity balance.
Useful fields may include:
| Field | Why it helps |
|---|---|
| Donor first name | Identifies the respondent |
| Donor last name | Identifies the respondent |
| Form Submission date | Shows when the form was submitted |
| Gift amount | Shows the gift amount associated with the form submission |
| Gift fund | Shows the fund selected or assigned for the gift |
| Gift status | Helps confirm the gift's processing status |
| Payment amount | Shows the amount associated with the payment transaction |
| Payment status | Shows whether the payment was received, pending, rejected, refunded, or otherwise updated |
| Form registration status | Shows if the respondent has registered, attended, etc. |
Depending on what you want the registration list to show, there are two common approaches:
Show Gift Values from the Form
If the goal is to review the giving information captured through the form, add custom list fields that display gift-related values directly from the form submission. This is often the clearest option for Advancement users because it shows the fundraising details that matter most, such as gift amount, fund, or gift status.
Join to the Payment Record
If the goal is to review the actual payment transaction, use the Payment Received Activity join, then join from Payment Received Activity to the Payment base.
This allows the registration list to display payment-specific details from the payment record, such as payment amount, payment status, transaction ID, payment date, or other processor-related information.
This approach is useful when you want the registration list to answer questions like:
- Did the payment process successfully?
- What is the payment status?
- What transaction ID was returned?
- Was the payment pending, received, rejected, or refunded?
- What amount was processed?
To configure these fields, edit the form properties and use the Custom List Fields section. Once custom fields are added, they replace the default list columns with the columns you define.
Common Scenarios and What to Check
The Payment Due column is blank
A blank value usually means no Payment Due activity is linked to the form submission.
This does not mean the payment failed. The payment and gift may still have processed correctly. Review the payment record or gift record to confirm what actually happened.
For payment forms, institutions should generally enable the setting that creates a Payment Due activity with each submission. This allows the Payment Due activity to coincide with the Payment Received activity created when the payment processes.
The Payment Due column shows Paid
Paid usually means the Payment Due and Payment Received activities balance to zero.
This is the most intuitive result and is more likely when forms are configured to create a Payment Due activity for each submission.
The Payment Due column shows Due
A due amount means the payment activity balance indicates an outstanding amount.
This may mean the payment was not received, but it may also mean the balance is being affected by other payment activity on the person's record. Review the payment record, gift record, and payment activities before assuming that the transaction failed.
The Payment Due column shows Overpaid
Overpaid usually means Payment Received activity exceeds Payment Due activity.
This can happen with recurring gifts or scenarios where some gifts and payments were collected without a corresponding payment due activity being set.
For example, the initial submission may create one Payment Due activity, while each recurring payment creates an additional Payment Received activity. Over time, the balance can appear overpaid even though the recurring payments and gifts are processing correctly.
The amount does not match the form submission
The Payment Due column is not intended to show the amount entered on the form. It shows a balance based on payment activities.
To see submission-specific giving information, customize the registration list and add gift values directly from the form. To see transaction-specific information, join through the Payment Received Activity to the Payment base.
You need to confirm whether money was actually received
Use the payment record and gift record. The Payment Due column can provide helpful context, but it is not the source of truth for whether a transaction processed or whether a gift was created.
Summary
The Payment Due column on a registration list is best understood as a payment activity balance. It is not the same as the payment amount entered on the form, the payment transaction, or the gift record.
Institutions should generally create a Payment Due activity with each payment submission so that it corresponds with the Payment Received activity created when the payment processes. This makes the standard Payment Due column more intuitive, but it does not make the column the best source of truth for every giving scenario.
To understand what happened on a specific submission, review the gift and payment records. To make the registration list more useful for Advancement staff, customize the list fields to show the gift and payment values that matter most to your office.