Skip to Content
RhythmHelp Center
/

Available Documentation

  • Platform
  • CRM
  • Portals
  • Security & Settings
  • Accreditation
  • Membership
  • Finance & Billing
  • Orders & Inventory
  • Events
  • Certifications
  • Awards
  • Careers
  • Fundraising
  • Integrations
  • Sponsorships
  • Submissions

Coming Later

  • DocumentsComing Soon
Membership
  • Overview

Subjects

  • Concepts
    • Overview
    • How a Billing Run Bills and Charges Members
    • How a Billing Run Plans and Refreshes Its Actions
    • How a Billing Run Sends Notices and Drops Members
    • How an Application's Order Is Priced
    • How an Organization's Membership Reaches Its People
    • How Buying or Renewing a Membership Package Updates Your Record
    • How Membership Applications Are Held for Approval
    • How Rhythm Decides Which Application Paths You Can Start
    • View All Articles
  • Tasks
  • Portal
  • Configure
  • Reference
  1. Home
  2. Membership
  3. Concepts

How a Billing Run Plans and Refreshes Its Actions

billing run plan ‧ member missing from billing run ‧ why is a member not in billing run ‧ refresh billing run ‧ excluded member came back ‧ one reminder per member ‧ assigned seat not billed ‧ expiration date range ‧ deceased contact still billed

On This Page
  • Each Task Chooses Its Own Candidates
  • Membership Settings That Keep a Member Off the Plan
  • What Never Qualifies
  • Refreshing a Plan
  • Finding a Missing or Unexpected Member
  • Related

When you pre-process a billing run, Rhythm builds a plan with one row for each member a task will touch. This article explains how the run decides who belongs on that plan, why an expected membership may be missing, and what changes when you refresh the plan later.

Each Task Chooses Its Own Candidates ​

A billing run can handle several tasks in one pass, including renewal orders, renewal reminders, auto-renewal card charges, auto-renewal reminders, expiring-card warnings, and expired-member drops. Each task has its own switch and settings, and each task selects its candidates separately.

If a task's switch is off or its settings are incomplete, that task selects no one. Rhythm does not show an error; the task's row in the run's statistics is simply empty.

Tip

Members who pay invoices and members on automatic renewal usually need different timing. Invoiced members are often billed several months before expiration so they have time to pay, while auto-renewal members are usually billed closer to expiration so their saved card is not charged too early. Plan separate renewal-order or renewal-notice tasks for members who are not on auto-renewal, and separate auto-renewal reminder and card-charge tasks for members who are.

For renewal orders and renewal notices, Rhythm starts with members whose expiration dates fall within the range you set. It then leaves out anyone who renews automatically, is already billed for the cycle, or is marked Do Not Renew. Renewal orders and renewal notices use the same rule, so auto-renewal members are left out of both tasks automatically. You do not need a separate setting to exclude them, and you cannot configure a renewal notice to include them. Rhythm then narrows the remaining members by any membership types, packages, or sub-status reasons you selected for the run. If you leave a type or package filter off, Rhythm does not limit the task to a specific type or package. It does not filter on that field at all. If the renewal order and renewal notice date ranges overlap, the same member can be selected for both tasks, and one of those two actions fails.

For the auto-renewal card charge task, Rhythm selects only auto-renewal members who have a stored payment method. If a member opted into auto-renewal but has no card on file, or the saved card information is incomplete, Rhythm leaves them out without an error or separate notice. Rhythm does not invoice that membership instead, so the member must renew manually and save a payment method before a future run can find them. Turning on auto-renewal is not enough by itself; a billing run must also exist and run before anyone is charged. A stored card with no auto-renewal run configured to process it will never be charged. A saved bank account works the same way as a saved card for this task, although Rhythm does not offer a query field that shows which type of payment method a member has stored. If you need to estimate who is ready to be charged automatically, filter by whether a payment method exists instead of using the Renew Automatically flag alone, because a member can have auto-renewal turned on without saving a card. A query for expiring auto-renewal members with valid payment details can still return more members than an auto-renewal billing run selects, because a member can also be marked not to be included in renewal billing. A query does not always check that on its own. The stored method also must be the tokenized card or bank account Rhythm keeps for recurring charges, not a one-time payment method. If that token is replaced with a one-time method, Rhythm treats the member as having no stored payment method even though auto-renewal is still on.

Auto-renewal always renews a member into their previous package. It never chooses a different package for them, even if they would now qualify for more than one. If a member wants a different package at renewal, they need to choose it through the portal instead of relying on auto-renewal to decide for them.

If your organization's memberships mostly expire at the end of the calendar year, use that same year-end date for an annual renewal-order or renewal-notice run. That date range reliably captures the members who expire then.

Warning

Updating a payment method through the portal's renewal setup flow has, in some cases, replaced the membership's stored renewal payment token with a one-time method instead of a new recurring one. When that happens, the member drops out of the auto-renewal card-charge task even though auto-renewal is still on and they believe they saved a new card. If a member's auto-renewal charge stops working right after they update payment details in the portal, check whether their record still shows a stored recurring payment method before assuming the update failed for another reason.

Planning and refresh both read the membership record at the moment they run, so a card added after the plan was built is not picked up until you refresh the plan. Before a billing run can charge anyone automatically, your membership application also needs to offer members the Renew Automatically option, and you need a billing template and a recurring run set up to process those charges.

The auto-renewal card-charge task does not check a member's card-expiration date. Only the separate expiring-card warning task checks that date, and it needs a recorded expiration date to select a member. A missing or incomplete card-expiration value in a query or report does not stop the renewal charge from being planned. Use the expiring-card warning task each renewal season to find auto-renewal members whose card will expire before their next charge, so staff can reach out before Rhythm attempts the charge.

For the drop task, Rhythm selects members whose expiration dates fall within the drop range you set, and leaves out any membership marked Do Not Drop. Rhythm does not compare the drop range with today's date, so a range that includes current or future dates can select members who are not expired. The drop task does not have a direct option to filter by state or target one member by contact number. If you need to drop one record, find it on the Actions tab of a run whose range covers it.

Warning

When you set the drop-expired-members range on a billing run, make sure it covers only dates before today. Nothing stops you from setting a range that includes current or future expiration dates, and a run built that way would select and drop members who have not actually lapsed.

Tip

To change many non-renewed members from active to another status at once, use a billing run's drop task with a date range that covers them instead of editing each membership individually. If you need to keep a specific group out of a drop run temporarily, query for that group, add Do Not Drop to the results, mass-update the field to true, run the drop, then mass-update it back to false afterward if you want those memberships eligible for a future drop.

If a member should never renew, setting a future termination or drop date and using a drop billing run is an alternative to relying only on a renewal-billing exclusion setting.

Renewal and auto-renewal reminders use numbered date ranges, such as reminder 1, reminder 2, and so on. Those ranges control reminder timing; Rhythm does not offer a separate, standalone reminder schedule outside a billing run or its template. If a member's expiration date falls inside two reminder ranges for the same task, Rhythm plans only one reminder for that member. It collapses the overlap instead of sending both. Because a run plans only one reminder per member for a given task, one run cannot send the same member more than one renewal reminder. To remind members at several points as they approach expiration, such as 30, 15, and 5 days out, use a recurring run that fires repeatedly or a separate run for each interval. That gives each interval its own opportunity to select the member. Reminders do not check whether a member is marked do-not-renew, so a member in that state can still receive a reminder.

Warning

A renewal reminder range that overlaps a reminder already processed by a different billing run can fail with a duplicate-record error instead of collapsing the way overlapping ranges inside the same run do. If a reminder task fails this way, check whether another run or template already covers part of the same date range, then adjust the ranges or remove the conflicting reminder.

The Default Grace Period you set in Membership Setup does not change which members the drop task selects. The drop task depends only on the drop range itself. The grace period affects your account's membership statistics, not who is eligible to be dropped in a billing run.

Segmenting the drop task, or any other task, by sub-status reason only works when the reason you choose matches what is actually stored on the members you expect to see. If you filter for one reason while your members carry another one, such as filtering for "Inactive" when the members are marked "Dropped," Rhythm returns no records instead of showing an error.

A billing run counts a membership once per task, no matter what else is happening at the same time. Rhythm plans exactly one action per member, per task, per run.

Membership Settings That Keep a Member Off the Plan ​

Beyond each task's own selection rule, a few membership-level settings and states keep a member off a plan entirely, or off one task in particular:

If a membership has this... Effect on the plan 
Do Not Renew selected Rhythm leaves the membership out of renewal orders, renewal notices, and auto-renewal card charges. Reminders still go out, and the member can still renew through the portal if your renewal rules allow it, so Do Not Renew does not block every renewal path. 
Do Not Drop selected Rhythm leaves the membership out of the drop task, no matter how far past its expiration date it is. 
Already billed for the current cycle Rhythm leaves the membership out of renewal orders, renewal notices, and auto-renewal charges until the flag resets at the next cycle. See How a Billing Run Bills and Charges Members for when Rhythm sets this flag. 
No stored payment method, or an incomplete one Rhythm leaves the membership out of the auto-renewal card-charge task, and does not invoice the member instead. 
A pending order or invoice from an earlier run that has not been resolved Rhythm leaves the membership out of later runs until the membership's Date Status is updated. A blue banner on the membership tells you when this exclusion applies. 
A status reason that does not match the run's selected sub-status reason, including one set during an import Rhythm leaves the membership out of any task that filters by sub-status reason. 

Do Not Renew and Renew Automatically are separate controls with different effects. A membership can have Renew Automatically off and still be excluded from billing because Do Not Renew is set. A membership can also have Renew Automatically on while Do Not Renew keeps it out of every renewal task. If a query of expiring members with valid payment details returns more records than a renewal-order or auto-renewal run's plan, check whether some records are marked Do Not Renew or already billed for the cycle. A run always leaves those records out, even when a broader query includes them.

If a membership was left out of a run because it already had a pending renewal order that will not be completed, create the renewal order by hand. Do not wait for a future run to pick it up, because the same pending record can keep excluding it from later runs.

What Never Qualifies ​

Assigned seats, flow-down memberships, and terminated memberships are left out of every task's selection. A billing run treats only a person's or organization's own membership as a candidate. An assigned seat can still appear in an organization's billing notice as one of the people the notice is about, but the seat is never billed, reminded, or dropped as its own candidate. A terminated membership should not show up in a renewal billing run's selection either.

Planning and refresh both use each membership's own record at the moment they run. If a membership changed only moments before, that change might not appear in the plan right away. The same timing works in the other direction: if a member turns off auto-renewal, or otherwise stops qualifying, only after a run has already selected them, that later change does not remove them from the existing plan. Only a refresh, or the run's own execution-time checks, can catch it.

Warning

A contact marked deceased is not automatically excluded from selection. An inactive membership within your date range can still be pulled into a Generate Renewal Orders action even when the linked contact is deceased, so do not rely on deceased status alone to keep a record out of a run. Add your own exclusion, such as a sub-status reason or a manual exclusion on the plan, if you need one.

Refreshing a Plan ​

A billing run's plan is not fixed after pre-processing finishes. From the run's page (Billing › Search › the run's name in the results), Refresh checks every task again against the run's saved settings and current membership data. Rhythm then merges the results into the existing plan instead of starting over:

  • Members who now qualify, and did not qualify before, are added to the plan.
  • Members who no longer qualify are marked no longer eligible instead of being removed. They stay visible on the Actions tab so you can see that the run once intended to include them, but Rhythm skips them when the run executes.
  • Members you excluded by hand are checked again. If they are still eligible, the refresh returns their action to pending, which undoes your exclusion.

Tip

If you excluded a member from a run and then refreshed the plan, check the Actions tab again before you execute. Refresh puts a still-eligible excluded member back to pending, so an exclusion you made earlier does not necessarily survive a refresh.

If you need to prevent one specific membership from being charged or billed in this run and cannot change its underlying settings in time, exclude its action by hand on the Actions tab. That takes effect immediately, while a setting change might not be picked up until the next refresh.

Refresh only re-checks the plan's pending and excluded actions; it does not retry an action that already executed and failed. If a member's renewal order or charge failed at execution because they were not eligible, and you later correct the eligibility problem, create a new billing run to pick them up instead of refreshing or rerunning the run that already executed.

Once planning or refresh finishes successfully, the run's status moves to ready for review. Rhythm also emails the run's notification address to say the plan is ready, if you set one.

Finding a Missing or Unexpected Member ​

If a member you expected is missing from a plan, first confirm which task and run you are reviewing. Renewal orders, renewal notices, auto-renewal charges, reminders, and drops each choose candidates by their own rule. A member can belong on one task's plan and not another's, and starting a run from a template instead of from scratch does not change the underlying rules. If you are comparing a saved query of expiring members with a billing run's results, make sure you are comparing it with the right task before treating the difference as a data problem.

When members who started in the same membership type need to renew into different outcomes based on other details, such as expected graduation date or field of study, build a separate query for each outcome. Review the members each query returns and make any needed corrections before you finalize the billing run, rather than relying on the run itself to sort them.

Tip

If a single member's expected action is missing and you cannot see why, try the same billing run with just that one membership. If the single-member test behaves differently than the full run, the difference is more likely something specific to that member's record than a problem with how the run works.

If an auto-renewal action you expected is missing, check these items in order: the membership's audit history for prior billed and auto-renewal status, whether its renewal payment method was saved before this run was planned, its current expiration date, and whether a pending-order banner is excluding it, as described above.

Related ​

For what happens once a planned renewal order or auto-renewal charge actually runs, see How a Billing Run Bills and Charges Members. For who receives a planned notice or reminder and what it contains, see How a Billing Run Sends Notices and Drops Members.

Continue in This Subject

PreviousHow a Billing Run Bills and Charges MembersNext How a Billing Run Sends Notices and Drops Members

Related Articles

  • How a Billing Run Bills and Charges Members

    How a billing run marks a member billed for the cycle, builds and processes their renewal order, and records a successful or declined charge.

  • How a Billing Run Sends Notices and Drops Members

    Who actually receives a billing run's renewal notice, reminder, or card-expiration warning, what each contains, and what changes to membership, billing, and committee or certification records when a run drops a member.

  • How a Billing Run's Status and Reports Work

    What a billing run's status and action statistics mean while it works and after it finishes, what its emailed report says, and why a run can show an error even though its actions finished in the background.

  • Review and Refresh a Billing Run's Plan

    See exactly which members a billing run is about to act on before it runs, leave individual members out or put them back, download the plan, and refresh it to pick up recent changes.

On This Page

  • Each Task Chooses Its Own Candidates
  • Membership Settings That Keep a Member Off the Plan
  • What Never Qualifies
  • Refreshing a Plan
  • Finding a Missing or Unexpected Member
  • Related
Rhythm Help Center© Rhythm Software

Search article titles, settings, tasks, and troubleshooting topics. Press Enter to see results.

Browse Platform Documentation