Several account-wide settings control how memberships renew, lapse, and become active again. They also decide which membership takes precedence when a contact has two memberships, and whether group membership applications are available. This article explains those settings. For details about the shared Membership settings record and how saving works, see Membership Settings: How Saving and Setup Work.
What This Controls
- Whether a lapsed member can be reinstated, how long they have, and whether they pay the renewal price or the join price.
- Whether members can see and use join processes during their reinstatement period.
- Whether a membership’s expiration date advances from the order date or the payment date.
- Which membership controls benefits when a contact has both a personal membership and one through their organization.
- The default grace period after a membership expires.
- Whether group membership applications are available, so one person can apply for several members at once.
- Whether membership invoices default to Due Upon Receipt or a specific payment term, along with checkout defaults such as donation prompts, credit card processing fees, split payments, saved cards for installments and auto-renewal, and billing a contact’s organization or parent organization.
Where to Find It
Go to Setup › Other Settings.
The Settings
| Setting | Card | Options | Default | Effect |
|---|---|---|---|---|
| Reinstatement (switch) | Reinstatement | On, off | Uses the stored value; on a new record, the form shows this switch as off, although the underlying record’s default is on | Turns lapsed-member reinstatement on or off for your Rhythm account |
| Reinstatement Period (days) | Reinstatement | A number | Empty | Sets how many days after a member is dropped they have to reinstate before they must use a join process. Rhythm counts from either the termination date or the expiration date, based on the setting below. Blank or 0 does not limit the period here; some accounts use a very large number, such as over 3,000, to keep expired memberships eligible for renewal-style access indefinitely instead of moving them through a drop |
| Give renewal pricing during the reinstatement period | Reinstatement | On, off | Off | When this is on, a member who reinstates within the period pays the renewal price instead of the join price |
| Do not show join processes during the reinstatement period | Reinstatement | On, off | Off | When this is on, a member inside the reinstatement window sees reinstatement processes only, not join processes |
| Which membership date should we use for reinstate period calculation? | Reinstatement | Termination date, Expiration date | Termination date | Sets whether the reinstatement window starts when the membership was terminated or when it expired |
| Enable group membership applications | Other Options | On, off | Off | Turns on group applications, so one person can apply for several members at once. This appears only when the feature is available for your account |
| When a membership payment is received, advance membership expiration date using the date of payment, NOT the date of the order | Other Options | On, off | Off | On: a membership’s expiration advances from the date payment is received. Off, which is the default: the expiration advances from the date the order was created, even if payment arrives later |
| When a contact with a personal membership has a conflicting membership from their organization, which one should take precedence? | Other Options | The individual's personal membership, The organizational membership | The individual's personal membership | Sets which membership controls benefits, pricing, and the membership's chapter and section values when a contact qualifies both ways |
| Default Grace Period: | Other Options | A number | Empty | Stores a number, although the page does not state a unit. The billing run that drops expired memberships reads this value to decide whether an expired membership is old enough to include in that drop. During the grace period, the member can still access the renewal process. This setting does not affect reinstatement eligibility or rejoin behavior, and it does not change a membership's status by itself. Check with Support before relying on the exact number if you need to confirm how it is interpreted |
| Invoice Payment Terms | Finance Settings | Use default payment terms, or a specific payment term | Use default payment terms | When you leave this on the default, invoices generated from membership applications use Due Upon Receipt. This setting does not automatically use the only active payment term configured elsewhere in Finance & Billing; choose a specific term here if you want membership invoices to use something else |
| Save cards for payments | Other Payment Options | On, off | Off | When this is on, a payment method saved on a membership, including one saved through a payment link, is kept and reused for installment plans and membership auto-renewal |
| Allow members to bill their organization / their organization's parent organization | Other Payment Options | On, off (two separate checkboxes) | Off | Lets a contact charge a membership invoice to their organization, or to their organization's parent organization, instead of paying it themselves |
A few related checkout settings appear in the same area under Setup › Other Settings. Prompt for Donations at Checkout adds a donation prompt to every membership application’s checkout. An individual application process can use its own Override Checkout Settings to turn that prompt on or off for that process instead of following the account default.
The same area sets your account’s default credit card processing fee behavior for membership orders, and a process can override that default for itself. Another setting controls whether someone completing a membership order, or paying a membership invoice, can split the charge across two payment methods in the Console and the Portal. When that setting is off, the two-payment-method option does not appear.
When members pay a membership invoice in the Portal, they can see an auto-renewal opt-in during payment. A separate setting controls whether that offer is preselected or left for the member to choose. Offering auto-renewal on an application’s checkout also requires secure payment method saving on that checkout. If a process does not offer card saving, members can still turn on auto-renewal later from their membership overview page in the Portal. If only some members should see auto-renewal at checkout, use a separate process for them instead of changing the setting for everyone. When a member unchecks Renew Automatically and continues to the next step of a renewal, Rhythm keeps that choice and does not re-check it as they move forward. For an organization membership, unchecking Renew Automatically during the organization's own join or renewal process sets that field to No on the membership and removes the stored card, just as it does for an individual membership.
Members update the payment method used for auto-renewal from their own Portal payment settings page. That page lists every saved payment method on the account, not only the one currently used for auto-renewal. Saving changes there updates only the payment method designated for membership auto-renewal, and that designation is supported for memberships only. A stored payment method tied to an active auto-renewal subscription cannot be deleted directly. Cancel auto-renewal first, then delete the stored payment method. If the member still wants auto-renewal on, set it up again afterward with a different method.
Changing a member's own membership, such as moving them to a different type or package, is expected to turn off Renew Automatically as part of that change. That said, this has been observed not to clear the flag on its own in every case. As an interim workaround while that is investigated, run the membership process for that member and clear Renew Automatically there yourself.
Reinstatement, Renewal, and Expiration Behavior
By default, a new membership starts in the month you place the order, even if payment arrives later. When a member renews, including after the membership has been expired for some time, Rhythm advances the new expiration date from the membership’s previous expiration date. It does not start a fresh term from the order date or payment date.
The amount of time added comes from the membership package’s configured term, not from how long the membership has been lapsed. A member who is years past expiration and renews still moves forward only by that package’s term, such as one year. The renewal does not move the member all the way to a current-cycle date. If you need the member to land on a current-cycle expiration date, drop the old membership through a billing run and process the person as a new membership instead of renewing the old one forward year by year.
Turning on When a membership payment is received, advance membership expiration date using the date of payment, NOT the date of the order changes the timing basis for every membership order it touches: new joins, renewals, and reinstatements. There is no separate setting that uses payment-date timing only for new memberships while keeping renewals on order-date timing. There is also no way to give joins or reinstatements one expiration-date rule and renewals a different one; this is one account-wide choice.
The setting does not change the previous-expiration-date starting point for a renewal. It affects only memberships created or paid after you turn it on, and it does not apply retroactively to applications or orders that already existed. In one delayed-activation case, a join created with an earlier order date, then paid and activated later, still expired based on that earlier order date even with the payment-date setting on. That outcome was confirmed as expected, so do not assume the payment-date setting always overrides an order date recorded before the membership was completed.
If a membership’s termination date is blank, renewal advances by the package’s term length from the expiration date stored on the record at the time of purchase. If a payment does not move the membership forward as far as you expected, check that stored expiration date before assuming the payment failed.
Passing the expiration date does not, by itself, change a membership’s status or remove benefits. A membership stays Active past its expiration date, through the grace period and beyond, until it is terminated. Staff can terminate it manually by setting it inactive and entering a termination date, or a billing run can drop it automatically. Only termination removes benefits; expiration alone does not move a membership to Active Without Benefits or to any inactive status.
Rhythm also has no way to schedule an automatic bulk status change at a set time. If you need memberships moved to inactive on a schedule, plan a billing run’s drop step instead of expecting expiration to do it. If a drop leaves memberships active that you expected to lapse, you can find and clean them up by hand. Query for active memberships whose expiration date falls in the range you're checking, then narrow the results to the membership category you meant to affect before making those records inactive. Even after termination, the person is not automatically a non-member. Rhythm keeps the inactive membership record until you delete it, and deleting the membership entirely is what returns someone to non-member status.
A downstream system that reads current-member status, such as Higher Logic, follows the same timing. It can treat an expired-but-not-yet-dropped test contact as a current member, so update a test membership to Active before you rely on results tied to its status.
Because a membership stays Active until it is terminated, an expired member can often still see and use Renew, not Join or Reinstate, until a drop happens. Once a membership is terminated and has a termination date, renewal is no longer the offered path. The member moves into reinstatement if they are inside the reinstatement period, or into a join or rejoin path once that period passes.
If you drop a membership and members can no longer renew it, that is expected. Dropping intentionally moves the membership out of the renewal path and into reinstatement or join territory, so avoid the drop step if you want a lapsed member to keep renewing normally.
Rhythm offers reinstatement and renewal only when the person already has membership history in Rhythm. Someone who belonged to your organization before you tracked memberships here, with no membership record in Rhythm, is treated as new and offered a join path instead. If a lapsed member completes a new join process instead of reinstating, Rhythm updates the expiration date for the new term but leaves their original join date unchanged. A successful payment on a rejoin order for a terminated or lapsed member is generally expected to reactivate the membership and refresh its status and expiration together.
Purchase eligibility criteria and special pricing rules can control whether a product is available, or adjust its price, when a condition is met. They cannot weigh several conditions together to choose next year’s membership type and product for you, consistently across both self-service renewals and billing runs. They also cannot compare a stored date to “today” in a way that keeps evaluating correctly over time.
For example, there is no way to configure eligibility around “termination date within the last 365 days” that keeps working every day without being rebuilt. If you need Rhythm to automatically select a member’s next product by evaluating several attributes together, treat that as a process your staff run manually, or discuss custom development with your account team. Purchase and package eligibility can also stop at a membership’s expiration date while the record still displays Active pending a later drop. In that case, a member can lose access to member pricing or an eligibility-gated package before their record’s status visibly changes.
Tip
If you want a group of lapsed members to go through your join process instead of reinstating, set Reinstatement Period (days) to a very short window, such as one day. Members outside that window are offered only join processes. Be careful in the other direction: a very long reinstatement period keeps lapsed members eligible to reinstate for a long time, so they can keep returning to their old membership record and its original package choice instead of moving into a membership aligned with your current cycle.
To make it easy for lapsed members to come back on their own without offering full reinstatement, consider building a dedicated join or rejoin process for them. Use a form without approval or supporting-document requirements, and restrict it with eligibility criteria to contacts whose membership status is Inactive or whose termination date is populated. With that setup, an existing join process can act like a simplified renewal for people who have already dropped off, rather than sending them through your full new-member application. It also creates a new membership transaction in the person’s history instead of reusing the old record.
If Reinstatement is on but you have not configured a reinstatement process, expired members inside the reinstatement window can end up with no self-service option at all: neither reinstatement nor join. Whenever Reinstatement is on, confirm that a reinstatement process actually exists.
If you would rather not use reinstatement at all, you have two configuration paths for letting a lapsed member come back after expiration. Keep the reinstatement period and configure a reinstatement process, or turn the account-wide Reinstatement switch off so lapsed members go through the standard join process again instead.
The email a member receives after completing a reinstatement is not set on this page. It is configured on the reinstatement process itself, under Setup › Applications › Processes, in that process’s Membership Activation Confirmation Email.
Whether the reinstatement window counts from the termination date or the expiration date changes who still qualifies. Counting from the termination date can let someone reinstate long after their original term ended, because the clock starts only once they are actually dropped. Counting from the expiration date closes the window sooner after the original due date, sending members who miss it to a join process instead.
Choose the basis that matches your rule. For example, if your organization considers a member reinstated as long as they return within 365 days, confirm that this setting and your reinstatement process’s own timing both match that 365-day rule. This setting alone does not guarantee the outcome you intend.
A membership package can also have its own reinstatement settings that override these account-wide defaults for memberships sold with that package. When a package does this, the expiration date produced during reinstatement can reflect the package’s own configuration, not only the lapsed membership’s prior end date. Check the package before assuming these account-wide settings are the whole story.
A lapsed membership that already has a termination date can follow different expiration-date logic depending on whether it goes through reinstatement or ordinary renewal, and depending on whether a reinstatement process is configured. If no reinstatement process exists, that path may not follow the normal expiration-date rules at all. In practice, the expiration date after a late reinstatement depends on the lapse date, the reinstatement period length, the package term, and the package’s own renewal-timing settings together. Test your configuration and verify the actual date it produces, rather than assuming it will only restore the original lapsed term or only advance through the following one.
Because reinstatement continues the previous term instead of starting fresh, it also preserves details that a fresh join would not. A member who was on a calendar-year expiration before lapsing keeps that calendar-year expiration through reinstatement, even if they choose an anniversary-based package while reinstating. To move someone from calendar-year to anniversary timing, they must complete a join process, which is offered only after termination and after the reinstatement period has passed.
Reinstating into an old, dropped period can also affect your revenue reporting. Deferred revenue for that membership follows the original term it is reinstating into, so catching up a long-lapsed member can post a block of deferred revenue into a single current accounting period instead of spreading it out. The member can also appear in reports built around expected benefit periods in a way that looks unusual for a “recent” reactivation.
When you need to correct a membership or its charges after a mistake, the correction method you choose has its own side effects. Recreating an order can advance the membership’s expiration date, which may require you to move the member back to the correct term. Creating a separate order just for a missed charge, such as chapter dues, keeps that correction from changing membership dates, but splits the charges across separate invoices. Reversing and rebuilding the original invoice keeps related charges together on one invoice, without the expiration-date side effect of a brand-new order. Choose the method based on which trade-off matters more for the record you are fixing.
Tip
If you need to move someone from a calendar-year expiration to an anniversary-based one, or otherwise need a one-off correction, you can edit that member's expiration date by hand rather than waiting for a process to produce it. Before changing your account's term or renewal rules more broadly — for example, switching your whole membership base from calendar-year to anniversary — test the change in your sandbox first, so you can see its effect on your existing members before you commit to it in your live account.
Renewal Window and Access After Expiration
Access to these processes follows a sequence: a renewal window before expiration, a grace period after expiration, termination if a billing run drops the membership, a reinstatement period after termination, and finally a join or rejoin process once that period passes. A typical setup keeps the reinstatement period noticeably shorter than the renewal window, often somewhere between 30 days and 6 months. That timing guides lapsed members toward rejoining within a reasonable period instead of reinstating into a very old term.
The renewal window is configured on the renewal application process, not in these account-wide settings. Go to Setup › Applications › Processes, open your Renew Membership process, and change Renewal Window under Renewal Options. The window sets how many days before a membership’s expiration date the member becomes eligible to renew, and the Renew option does not appear until the member falls inside it. For example, a 30-day window on a membership expiring July 5, 2025 opens renewal on June 5, 2025. Setting it to 0 allows renewal at any time, regardless of expiration date. If you want to require the member to be close to expiration, use a small positive number such as 1 instead of 0. Enter a plain count of days here, not a date or a percentage. A large value such as 800 does not, by itself, mean a record falls inside the window, so confirm the member's own expiration date against the window instead of assuming the number alone settles eligibility.
A renewal-window message can also appear for a member who is already expired. That points at the window setting even when the real cause is something else, such as missing reinstatement configuration or package eligibility criteria that the record does not meet. If the window looks wide enough and the member is still blocked, check the reinstatement setup and the target package's own eligibility criteria before assuming the window itself is misconfigured.
Once a member is inside the window, renewal stays available until the membership is actually dropped. It does not disappear again just because more days pass than the window allows. A member who has already renewed through the end of the current term becomes eligible to renew again for the next term once their new expiration date falls back inside the configured window. That works the same as it does for anyone else approaching expiration. If a member’s own individual renewal option seems to be missing, the renewal process window is usually the reason, not the reinstatement settings on this page.
If you need to stop all renewals for a while, such as between terms, set the renewal process itself to Inactive instead of changing the window. This blocks every renewal until you reopen the process for the next cycle. For the reverse situation, where one person needs to renew before the window normally allows it, either temporarily widen the process’s Renewal Window, or temporarily change that member’s expiration date. Then complete the renewal order and restore the original expiration date afterward if needed.
Tip
Saved Membership queries are the practical way to find and correct existing records after one of these settings changes. Build a query to find memberships with a legacy auto-renewal value, or ones still carrying an old renewal currency after you change your default. Then use it with a bulk update to correct the auto-renewal flag or the renewal currency across every record it finds. The same kind of query can help you find members with a stored payment method on file: the renewal card's expiration date is visible in a Membership › Membership All query only for records that have a saved payment method and auto-renewal set to Yes, so it works as a stand-in for a direct "has a card on file" filter.
Dependencies and Precedence
- Turning Reinstatement off disables the whole card. The period, renewal pricing, and join-process visibility settings stay saved, but they do not affect anything until you turn Reinstatement back on.
- Do not show join processes during the reinstatement period matters only when Reinstatement is on and the member is inside the window. Outside the window, join processes are offered normally.
- Enable group membership applications affects only the Setup menu and the settings on this page. Group applications appear on a Portal page for your members only when that Portal feature is also installed there. Group membership applications are also a separate, administrator-driven way to manage memberships for several people at once. An administrator creates the group, adds each person, and completes one purchase for the whole group. This is different from your standard organization membership flow, and it is mainly intended for building new group memberships going forward rather than repairing or backdating existing ones.
- A membership with a recorded termination date needs an actual reinstatement process configured for it, even when Reinstatement is on. Without one, the member can see a renewal-window error instead of a working application. If Reinstatement itself is off, a configured reinstatement application does not appear for anyone until you turn it back on.
Change Impact and How to Revert
- Changing the reinstatement period, pricing, or join-process visibility affects members who reinstate after the change. It does not change memberships that were already reinstated under the old settings.
- Changing the expiration-date basis, from order date to payment date or from payment date to order date, affects membership orders paid after the change. It does not apply retroactively to applications or orders that already existed before you changed it, even if they are paid afterward.
- If you change a membership’s term dates by hand for a deferred payment, timing matters. Changing the term before payment is processed causes Rhythm to use the updated date. To keep the original timing for a deferred item, make the change after payment is processed but before the batch is posted.
- To revert any of these settings, choose the previous option and save again. There is no separate history for individual settings beyond your account’s audit history.
- If a membership was changed the wrong way, for example through an unsupported cancellation method, Rhythm has no automatic revert. Check your account’s audit history for the record’s previous values, or use a prior export or import file if the audit history does not go back far enough. For an anniversary-based membership, capture the original term dates before running a billing action you might need to undo, since they can otherwise be hard to reconstruct afterward.
Permissions
Changing these settings requires access to Setup › Other Settings, which is available to a Membership Administrator.
Validation and Errors
| Message or symptom | Cause | What to do |
|---|---|---|
| A lapsed member cannot reinstate at all | Reinstatement is off, or the member is outside the Reinstatement Period (days) window | Turn Reinstatement on, or confirm that the member is still inside the period |
| A member expects the reinstatement window to start from their expiration date, but it is measured differently | Which membership date should we use for reinstate period calculation? is set to the other option | Choose Termination date or Expiration date to match the rule you want |
| A member's new expiration date is not what was expected after a late payment | Expiration normally advances from the order date and from the previous expiration date, not from the payment date. If you expected payment-date timing, check whether advance membership expiration date using the date of payment is on | Turn the payment-date setting on if you want expiration to follow the payment date instead of the order date |
| Unable to save settings | The account's business unit or merchant account requirement was not met, or another field failed validation | See Membership Settings: How Saving and Setup Work |
| A renewal is not available, even though the member looks otherwise eligible | The membership's expiration date has been cleared | Restore the expiration date on the record, then use the renewal process again |
| An individual record can't be renewed even though the membership looks eligible | The record's own Date Status, in Advanced Options on the membership, is not set to Updated | Change the membership's Date Status in Advanced Options to Updated |
| An expiration date you typed lands on the day before you expected | You edited the date from a computer set to a different time zone than the one you had in mind; Rhythm generally uses the time zone of the machine making the edit | Enter dates from a machine in your intended time zone, and confirm the saved date after you save. Viewing an already-saved expiration date is consistent across users in different time zones; only manual entry is affected |
| A member's term looks shorter than expected after a pay-later application | The order was created, paid on a later date, and approved or activated later still; expiration calculated from the original order date rather than the later payment date | Confirm which date basis your account uses (see Reinstatement, Renewal, and Expiration Behavior above), and check the order, payment, and approval or activation dates against it |
| A membership expiration date entered in eligibility criteria, such as on a package's purchase eligibility or special pricing, is not accepted | The field expects a plain-text date in YYYY-MM-DD format, unlike the MM/DD/YY or long-date formats shown elsewhere on a membership record | Enter the date as YYYY-MM-DD; the field shows placeholder text in that format as a reminder |
| A finance batch fails to post, and a membership's expiration date is unusually far in the future | An unrealistic expiration year can make the revenue-recognition data for that membership too large for batch posting to process | Correct the membership's expiration date to a realistic value, then post the batch again |
| A member you temporarily terminated for a suspension does not come back on their own once the suspension period ends | Using termination or inactive status for a temporary suspension does not reactivate the membership automatically when the period passes | Manually reactivate or re-add the member once the suspension period ends |
| An expiration date looks wrong for a membership that went through a cloned application process | This has been reported with a process copied from another type, but was not confirmed as a reproducible expiration-date defect on review | Before assuming the calculation is wrong, verify the cloned process's actual type (join, renewal, or reinstatement) and check it against your account's global reinstatement-window settings |
Tip
Rhythm's Academy offers courses on using and configuring Membership, and on membership billing specifically. The knowledge base also has articles on Membership configuration and management if you want more detail before your first renewal season.
Related
- Membership Settings: How Saving and Setup Work
- Dues Proration and Renewal Pricing Overrides
- Reinstate a Membership at the Renewal Price
- Schedule, Run, and Monitor a Billing Run
- Group Application Processes
- How Rhythm Decides Which Application Paths You Can Start