The Membership Query Center lets you query memberships, past membership snapshots, add-ons, applications, application groups, and billing run actions. You can list all memberships, only memberships held directly, or only memberships people received through an organization. Each query type returns records from your Rhythm account only. You cannot run one query across more than one Rhythm account, so run the same query in each account and compare the results manually when you need to compare accounts. For help building conditions, choosing output fields, running a query, and downloading results, see Design and Run a Query.
Prerequisites
- Your role must be allowed to run the query type you want. If you cannot run that type, it does not appear in the picker.
- To download results, your role must also be allowed to download results for that type.
Open the Membership Query Center
- Go to Membership & Committees › Queries.
- Choose New Query, then pick a category and query type as described below.
Tip
Queries is the closest thing Membership has to a report builder. If you are used to a separate "Reports" area from another system, or from older Membership training, build your list here instead. Membership application reporting used to include a dedicated report option, but that option is no longer part of the application. If older documentation or training tells you to run a "report" on applications, build that same list here as a query.
If you need to update membership-related values for many records at once, start with membership data here instead of CRM organization records. This applies to batch corrections, newly added fields, and records you need to reassign to a different type or package. Membership fields such as type, package, chapter, and status live on the membership record, not on the contact or organization record, so a CRM bulk update cannot change them. See Update Many Memberships at Once below.
List Memberships: All, Principal, or Downstream
Three query types cover memberships:
| Query type | Rows returned |
|---|---|
| Memberships - All | Every membership, whether the member holds it directly or received it through an organization |
| Memberships - Principal | Only memberships whose origin is exactly Principal — the memberships a person or organization bought or applied for themselves |
| Memberships - Downstream | Only memberships whose origin is anything other than Principal — memberships people hold because their organization gave them access |
Memberships - Principal is the type your dashboard tiles use. It brings together the contact, the contact's login profile, the membership's organization, the contact's organization, the primary chapter, and the order. In all three query types, each membership appears as one row, so someone with both a direct membership and a membership through their organization appears once for each membership. If a dashboard tile drill-down does not show the fields you need, save a custom query on the same type with the fields you want instead of using the tile's fixed drill-down output.
Because Memberships - All includes memberships owned by organizations and individual people, its row count can be higher than the number of active member organizations. To return only individual members, add a condition where Owner Type equals Contact. To return only organization-owned memberships, set the same condition to Organization. If you only want memberships people hold because of their employer, use Memberships - Downstream instead of relying on an owner-type filter.
The Is New field on a membership record marks a record with no prior membership history, so you can use it to separate first-time members from renewals in your results.
Tip
Memberships - Downstream includes memberships that flowed down automatically through an organization tier and memberships an administrator assigned by hand. Both count as downstream, so add another condition or use another source if you need to tell them apart. Add the Origin field to your output to see whether a downstream row is Principal, an automatic flowdown, or a manually assigned membership. Check this field when you need to confirm the exact membership type before correcting it. Reviewing the organization's own system audit log alongside the query can help confirm when and how a flowdown or assigned membership was created.
A single contact can appear more than once in these query types, and in a broader contact query that includes membership fields, without being a duplicate contact. Each row represents one membership, not one person. For example, a contact who has an individual membership and is also connected to an organization's membership as the billing or primary contact can appear on more than one row, sometimes with different membership statuses. Add Membership ID, Owner Type, or Contact Number to your output fields to see whether extra rows share the same contact. To narrow a contact-oriented query to one row per person, filter by Membership Origin or set Owner Type equals Contact. If you want to avoid the extra rows an organization's billing or primary-contact relationship can add in Memberships - All, run the same fields and criteria on Memberships - Downstream for a flowdown member, or filter by Owner Type.
An organization's own application can also show its applicant or primary contact as part of the membership record. That contact is not a separate member. The contact appears because the application process links them to the organization's membership, not because the query returned a duplicate.
Tip
Some administrators compare a membership's Owner with its related Organization in a Memberships - All query to spot flowdown assignments that need review. For example, a person's flowdown membership might no longer match their current organization. Treat a mismatch as something to review and correct, not as a query error.
If you are checking active-versus-inactive membership status and a contact-oriented query does not match what you expect, run the same question as a Membership query. A Membership query starts from the membership record, while a contact record can include status information from more than one membership. When you need to confirm memberships that are still active within a certain expiration window, a narrower or contact-oriented query can miss active records that Memberships - All would find. Use the broader query type when you are validating completeness.
Tip
Contact status and Membership status answer different questions. A contact can be active as a person while having no active membership, so filtering Contacts by active status and filtering Memberships by active status returns different counts. Use Contact Active status when you are counting active individual accounts, and Membership Active status when you are counting active memberships.
To find active members who are not currently certified, start with an active-membership query. Then exclude the contacts or organizations returned by a certification query for the population you want to leave out. This is more reliable than using a blank certification-status condition, which can miss records that were never evaluated.
You can filter any of these query types by fields stored on the membership, such as type, package, or expiration date. For example, use a configurable date condition to compile current memberships that expire by a chosen date. You can also filter by fields on the related contact when the information you need, such as profession or specialty, is stored there.
Field Meanings Worth Knowing
A few output fields on these query types have more specific meanings than their labels suggest:
| Field | What it actually shows |
|---|---|
| Is New | Whether the membership has no prior membership history. Use it to distinguish a genuinely new member from someone whose membership record was recreated |
| Membership Origin | Only exists on membership records. Filtering by Origin, such as Principal or a downstream value, leaves out anyone with no membership because a non-member has no Origin value to match |
| Join Date vs. Membership Join Date | Join Date is the application-level join date preserved from the original membership application. Membership Join Date is the join date stored on the membership record. These usually match, but they can differ when a prior member returns after termination and receives a new membership record with its own join date |
| Order Date, Last Bill Date, Renewal Date, Join or Last Renewal Date | Order Date is when the order or invoice was created. Last Bill Date is when the member was last billed. Renewal Date is the start date of the new term. Join or Last Renewal Date is the most recent date the member joined or successfully renewed. These fields can share the same value in some scenarios, even though each one represents a different event |
| Renew Automatically | A status field, not a timestamp. It is blank when the member has not opted into auto-renew, and it shows Yes when they have. It does not show when the member made that choice |
| Name, on a membership's own record | Can show the name recorded when the membership was purchased or the application was submitted, rather than a later name change on the related CRM contact or organization record. If the related record is renamed afterward, this field can continue showing the earlier name. Results can stay inconsistent even after you update the name on the membership application itself. If you need the current CRM name, add Organization Name (Contact) or Name (Organization) as an output field instead; those fields reflect the organization's current CRM record |
| Package, on an older membership | Can keep showing the membership type that applied when it was purchased, even after that package is later moved to a different membership type. Purchases made after the change use the new type |
Package, Total, and Coupon Fields
Package and Total tell you which package was bought and what was paid, but Total does not isolate the membership charge by itself. If an add-on or advocacy donation was processed in the same transaction, it is included in the same Total. Filtering by package, including a prior year's or specific year's packages, works well for grouping records. It does not show full billed-and-paid order detail because the query includes only the amount paid on the order or on the membership itself.
You can report coupon codes used on a membership order from Memberships - All by using the Order group of fields, specifically Order › Coupon Code ID(s). A separate coupon-related field on Memberships - Principal has been reported to return blank even when the coupon had recorded usages. If that happens, use the Order fields on Memberships - All instead.
Warning
On memberships purchased with a recently created package, Memberships - All can show the package's ID while leaving the Package name blank. Older packages generally display their name normally. If you see this, use the package ID to distinguish records temporarily while you confirm the package name separately.
Setting a membership package inactive also removes it from the choices available as query criteria. If a package you expect to filter by is missing from the picker, check whether it was made inactive before assuming the field itself is broken.
Application Group membership is not available as a filter or output field in Memberships - All, Memberships - Principal, or Memberships - Downstream. Use the separate Application Groups query type described below when you need that information.
Warning
Custom address types you created can be visible in your address-type setup before they are available as output fields in a Membership query. If an address type exists in setup but is missing from the field list, contact Support. Rhythm may need to make a change before the fields appear.
A CRM custom field you created and populated through a mass update does not automatically appear with values in a Membership query's matching output field. If a custom-field column returns empty cells after a mass update, check whether the query reads from the field you updated. A similarly named field can exist on more than one record type.
Reporting on activity across your whole Rhythm account against a connected external system, such as validating a member list an integration maintains, usually means recreating that system's population logic as a Membership query. Then compare the two lists side by side.
If you need non-membership invoices tied to people who just joined, run two queries. First, run a Memberships query filtered by the join date you need. Then use the resulting contact IDs in an Invoices query in Finance & Billing, filtering Billing Contact ID to that list of IDs and excluding membership-type orders.
Retention and Renewal Reporting
To report on renewals for a target period, filter Memberships on Renewal Date together with Billed status. Billed equals Yes returns members who have been billed but have not yet paid, and that value automatically changes to No once payment succeeds. Use Memberships - Principal when you specifically want a list of organizations that have a chapter relationship, rather than a chapter-roster query type that returns individual chapter members.
Warning
If a membership's active count dropped unexpectedly right after a renewal billing run, check the recently renewed records before assuming the query is wrong. In some cases, the renewal order changed the membership's chapter or association assignment, expiration date, or status. Correcting those fields on the affected records restores them to the active count.
Build Accurate Query Criteria
A membership query returns only records that satisfy every condition you add, including conditions that are implied rather than obvious. Keep these behaviors in mind before you rely on date- or balance-based criteria:
- A date condition only matches populated dates. A condition such as Membership Join Date greater than a specific date returns only records where Membership Join Date has a later value. A membership with a blank Join Date is excluded, even if another date field, such as a renewal date, is filled in. If results look shorter than expected, check for blank Membership Join Date values. Missing or changed join dates are sometimes caused by an earlier staff edit or a change made by the member, so check the record's own history if a date-based result looks unusual.
- A membership's term start date affects new-membership queries. If a member's stored term start date falls outside the window you intended, they do not appear in a query built to catch new memberships for that window, even if you expected them to.
- An order-date condition can look only at the most recent order. If a membership has more than one order, and the order inside your requested date range is not the latest order, the record can be excluded even though it had qualifying activity in range.
- To find members who paid but whose term did not advance, you usually need more than one condition. Use an order-date range plus a condition that allows a balance, because a record with a no-balance condition does not appear if it still carries a balance.
- None of these query types default to active-only. If you want only active memberships, add a Membership Status equals Active condition. Without it, memberships in every status are included.
- A saved query returns only what its saved criteria allow. If a saved query includes a condition equivalent to order balance due equals zero, memberships that still carry a balance are excluded, even if they match everything else you need.
- For monthly renewal campaigns aimed at one exact day — such as separate 30-, 60-, and 90-day-out lists you run every month — use an exact date match for that run's target date. Do not use a "greater than or equal to" condition, because that accumulates everyone past the threshold instead of returning only that day's group.
- Open-balance conditions depend on the membership's own stored balance-due value. If that value has not been populated on the membership record for an order, the related contact or membership can be missing from a balance-based query even though the order itself has a balance.
- A workaround for finding likely-incorrect reinstatements, when you cannot compare two fields directly in a query, is to combine two date conditions instead. Use an expiration date before one cutoff, together with a reinstatement or order date on or after another cutoff. Combining thresholds this way can approximate a comparison the query designer cannot do directly.
- Fixing one field does not guarantee a related record is fixed too. If you correct a bad value on one record type, such as applications, and rerun a query for that same type, you may see no more matching rows. The same bad value can still exist on a related record type, such as memberships, which a different query would need to check separately.
If the Package (Membership) criterion does not show a place to enter a value after you choose contains text or does not contain text, try the equals operator instead, or contact Support.
For the full rules on how each operator treats blanks, letter case, and dates, see Query Criteria and Filter Operators.
Update Many Memberships at Once
You can change many membership records at once instead of editing them one by one. Build a Membership query that returns the records you want to change, then use Bulk Changes › Mass Update beside the results. You can also go directly to System & Security › Mass Updates. See Update Records in Bulk for the full steps to preview, commit, and read the results. This section covers what is specific to memberships.
Choosing Between the Two
If every selected membership should receive the same new value, isolate those records in a query and use Bulk Changes › Mass Update. If different records need different values, such as different expiration dates, use System & Security › Mass Updates with a file so each row supplies its own new values.
Common membership bulk changes include:
- Reassigning memberships to a different type and package during a consolidation. Query the affected memberships, then use Bulk Changes to update the type and package fields.
- Setting membership status in bulk, including setting it to Active, after you isolate the affected records in a query.
- Adding or updating section assignments. Build a membership query that returns the target members, then run a mass update from that query using Section ID. A section added this way does not create a charge, even when the section normally has an associated cost. Use this for retroactive assignment, not for billing a section.
- Setting Do Not Renew in bulk. Add the Do Not Renew field to a query to find affected memberships. Then mass-update that field to
Yes/Trueto exclude them from renewal billing, or toNoto bring memberships back into renewal billing. - Correcting Origin from Assigned to Principal. Query for memberships where Origin equals Assigned, include Origin and Membership ID in the output, export the results, edit the Origin values, and upload the file to Mass Update, mapping ID and Origin.
- Auditing and clearing overridden fields. Query for memberships with an Overridden Fields value and include Membership ID in the output. For example, filter Overridden Fields contains
add_onson Memberships - Downstream to find flowdown memberships with an overridden add-on. Export the results, decide which override values to clear, and use Mass Update to remove them in bulk so flowdown can apply again. - Mass-updating add-ons. Use the add-on's ID-based field, not its name field. If you supply a name where an ID is expected, the update returns an error instead of changing the record.
Prerequisites
- A mass update import for memberships needs the membership record's own identifier, which is the field labeled ID (Membership). Do not use a CRM contact ID, organization ID, or the visible membership number. The membership number is not the same as the internal membership ID that mass update needs.
- If you need a membership package ID for an import file, you can get it from a Membership query's Package fields.
- If you plan to exclude certain members from a bulk billing action and Group Membership is not configured for them, identify those members by another reliable, queryable marker before you build the exclusion. Use a membership ID, membership number, or another distinguishing field.
Warning
Removing many section associations from many members at once is not fully self-service. If one combined query-and-mass-update attempt does not remove every section link you expect, work through one section at a time with its own query and mass update instead of combining several sections in one pass.
A Bulk Changes update from a query can succeed at the preview step but apply to only some of the matching records after you commit, even when Membership ID is included in the output. If that happens, check the results file for records marked as errors or unchanged, and contact Support if the cause is not clear from those results.
Warning
Filtering a yes/no field such as Renews Automatically with "equals No" can return fewer records than you expect because it excludes records where the field is blank rather than set to No. If you need every record that is not set to Yes, including blank records, use "does not equal Yes" instead.
Tip
For an organization-owned membership, the generic contact name and email output fields may not return the organization's primary contact. Choose the organization-scoped fields instead, such as (Organization) Primary Contact - Name and (Organization) Primary Contact - Email Address. To build a reusable list of contact names and email addresses for active member organizations, set the query to include contacts only and exclude organization records. Otherwise, organization rows without their own email address can throw off your totals.
Tip
To find contact-owned memberships that may be missing an expiration date, use a Memberships - All query with Owner Type = Contact, Membership Status = Active, and Membership Expiration Date is blank. Review the results to decide what needs correction.
Tip
A flowdown membership does not carry its own copy of the parent organization's balance or amount due. To find unpaid memberships that might include flowdown records, add a condition that checks the parent membership's balance field in addition to the membership's own. For example, use a balance-due condition on either the membership or its parent membership.
Warning
If you inactivate a membership package, you can no longer use it as criteria when filtering a Membership query. Keep a package active while you still need to query for it.
These query types include some finance-related fields, such as Amount Paid, Total, and Payment Method, and they can approximate a full order-level view but do not replace one. They will not cleanly identify a member who paid after a certain date but still shows an old expiration date, because that comparison needs payment data the Membership query area does not expose. The Total field also includes any add-on or advocacy-donation amount charged in the same transaction, so it does not isolate what was paid for the package alone. The Order Number and Balance Due shown for a membership come from the membership record itself. If that record falls out of step with its linked order, these fields can show a stale order number or a balance due that does not match the order until someone corrects the membership record. A saved query also returns only what matches its own criteria: if it includes a condition such as order balance due equals zero, it leaves out members who still owe money, even if they otherwise match what you are looking for.
See What a Membership Looked Like in a Past Month
Historical Membership Snapshots compares a membership's current stored details with how it looked in an earlier month, so you can confirm whether a status, date, or other detail changed. The month list shows the last sixty months, whether or not a snapshot exists for each month. If you choose a month with no snapshot, the query returns no results instead of an error. That is different from a query that fails or times out. If a query for a month you expect to have data errors out instead of returning no results, report that separate problem to Support.
Snapshots update on the first of each month. If you want a saved copy of this query delivered right after the newest snapshot appears, open the saved query's row menu, choose Schedule, and set the delivery for first thing in the morning on the 1st. See Query Delivery Schedules for how a schedule works.
The snapshot date controls which point in time you see. Add other conditions, such as membership status, membership type, or organization, based on the list you want to produce. The Snapshot Date condition itself only supports the equals operator, matching one month at a time, so other comparison operators are not built for this use.
You can use the Renew Automatically output field with the snapshot date to see when a record changed from not auto-renewing to auto-renewing. This narrows the change to the month it happened, not an exact date or time.
Tip
To see how many members with a prior membership type renewed, run a snapshot query for the earlier date and include Membership ID in the output. Export the results, then run a new snapshot query for the later date with a Membership ID is in list condition using those exported ids, so you can see how those same memberships look on the later date.
If a historical snapshot query does not return the renewal analysis you expect, some administrators instead filter Memberships - All by Membership > Application Process and select the renewal process values they need.
Warning
The month list is built once and can be a month behind when your account has not been visited in a while, so the newest month may occasionally be missing. If you do not see the month you expect, check back after your Membership area has been visited again, or ask Support.
Monthly snapshots depend on a background job that must run successfully for that month's data to exist. If that job fails or is delayed for a month, the month can still appear in the picker but return no rows. That looks the same as a month that genuinely has no snapshot yet. If a specific membership you know was active during a chosen month does not appear in that month's results, contact Support so it can be checked. Do not assume the membership was inactive.
Each month's data is a separate snapshot row, not one consolidated view of a membership's full history. To track how a membership changed over time, such as its package, type, or status across several months, review a separate row for each relevant month. Current membership records show only where things stand right now. After something on a membership changes, or the record is deleted, the earlier version is not available from the live record. Monthly snapshots are the only way to see a past state, which makes them the right source for trend, retention, cohort, and year-over-year analysis. Do not rely on current membership records for that type of reporting. This is also a point-in-time source. There is no built-in way to pull everyone who held a membership at any point across an entire membership year into one consolidated report. If monthly point-in-time snapshots do not answer your question, contact Support about your reporting goal.
The membership record's own History tab can show historical chapter or section affiliations and other past-membership details, including information imported during setup. That History tab data is not available as query fields, and there is no alternate report for it. If you need historical detail for reporting, use Historical Membership Snapshots or a query on the record types you need, not the History tab.
Tip
The Snapshot Date criterion supports only the equals operator with an exact month. Other comparison operators, such as less than or greater than, are not meant to work for this field. Snapshot Date is the main control for a historical question. Add membership status, membership type, or organization and contact conditions on top of it based on the list you need, just as you would in any other membership query. For example, to get a list of memberships as they stood at year end, set Snapshot Date to the relevant month, add any status or type conditions you need, choose your output fields, and export.
To track how many members of a prior type or package renewed, include Membership ID in the output of an earlier snapshot and export those IDs. Then run a later snapshot filtered by Membership ID is in list using that exported list, so you can see how those same memberships look on a later snapshot date.
If Historical Membership Snapshots does not answer a renewal question, such as identifying members who renewed for two consecutive years, filtering Memberships - All by Membership › Application Process and selecting the relevant renewal process values is a useful alternative.
A snapshot dated for a given month is taken shortly after that month begins and represents the state at the end of the prior month, not that day's activity. A snapshot labeled for the month after a change is expected and does not mean a run was missed. Auto-renewal changes can only be tracked at this same monthly level through this query type. There is no exact timestamp for when a membership's Renew Automatically value changed, only what each monthly snapshot shows.
You can schedule a saved Historical Membership Snapshots query to run and deliver automatically each month. This is useful for routine reporting and as insurance if a particular month's snapshot generation is delayed.
List Membership Add-Ons
Add Ons lists every add-on attached to a membership, with one row per add-on and the order line that sold it. If an add-on was bought on a later order and its add-on entry was recorded without its own order reference, this query type shows the membership's original order instead of the order that actually sold the add-on. To find memberships with add-ons through the membership query types, use the Add On Names field as a criterion or output field on Memberships - All. A member's add-ons also appear on the membership overview page in the Portal.
List Applications and Application Groups
Applications lists membership applications with details for the applicant, their organization, the chapter, and the order. This query type returns the full application history, including renewals and repeated application series for the same person, unless you filter it by date. Its raw row count is not the same as a count of current individual members. Denied and cancelled application submissions remain in this query type with every other status, so filter by Application Status if you want to find or exclude them.
Application Groups lists group applications with their administrator, organization, and order, with one row per group. It does not list the individual applications inside a group, so use the Applications query type if you need those.
Tip
On the Applications query type, an organization's own application shows no organization in the Organization group of columns when no individual contact is attached. That happens because the Organization columns follow the applicant contact, not the application's owner directly.
Tip
A referral-member field on an application can occasionally show an internal identifier code instead of the referring member's name in query output. This has been seen as a suspected bug rather than intended behavior. If you see a code where a name should be, report it instead of working around it.
Warning
The Applications query type does not include membership record fields such as membership status, membership type, or expiration date directly. It covers only the application itself. If you need to compare application data with the resulting membership's details, run the Applications query first. For example, to find applications where a chapter was selected but the resulting membership record has no chapter, filter Applications to a non-blank chapter and export Application ID. Then run a Memberships - All query filtered to that list of Application IDs where the chapter is blank. Cross-reference the two result sets manually; there is no single query that joins both directly.
Payment, Order, and Renewal Fields Have Limits in Membership Queries
Membership query types can include some finance-related fields, such as Amount Paid, Total, and Payment Method. These fields can help approximate payment reporting alongside membership data, but they do not provide full financial detail. Know these limits before you build a report that depends on them:
- No Paid Date. Membership queries do not currently offer a Paid Date field for orders or renewals. This matters when your organization bills first and collects payment later. When you need the actual payment date, use the payment query in Finance & Billing, not Membership.
- No special pricing detail. Special Pricing Logic Criteria names and prices cannot be returned in a Membership query. As a partial substitute, use Membership › Package together with Membership › Total or Order › Amount Paid to infer which pricing tier likely applied, based on the amount charged.
- No stored payment-card detail. Membership queries do not expose card details such as the last four digits, and you cannot filter specifically by which payment processor a saved method uses.
- No dedicated stored-payment-method query. There is no query built specifically to find who has a stored payment method. As an approximate proxy, a Membership query filtered on Renew Automatically equals Yes identifies people likely to have a saved method for recurring billing, because auto-renewal generally depends on one. This is imperfect because a member can have auto-renew turned on without an actual saved payment method.
- Payment Method reflects the order's original state, not a later payment. The Payment Method field in query results reflects what was selected when the order was created. If an order was created without payment and a payment such as a check was applied afterward, the query still shows None instead of the later method. This is especially noticeable in invoice-first workflows, where an invoice or order is created before payment is recorded.
- No payment line-item detail for renewal analysis. Membership queries cannot return detailed payment line items. When you need to filter renewals by the date they were actually paid, the closest available date is a join or renewal date, not a true paid date.
- Invoice status lives in Finance, not Membership. For the most accurate open-invoice counts, use Finance & Billing's Invoices query type because invoice status is stored there. Membership queries can show fields such as expiration date, package, and chapter that Finance invoice queries do not include, but Membership queries do not expose invoice status directly. A question that needs both memberships and invoice status usually requires two queries, cross-referenced manually.
- Finance/subledger queries do not carry membership-specific fields, such as whether a membership is new or a renewal. If you need that distinction, build the search in the Membership Query Center instead of trying to extend a finance-side query.
- Use Membership queries, not Invoice queries, to find members with open membership invoices before a billing run. Invoice queries have field limits that make this approach unreliable; build the query on the membership side instead.
- No single query surfaces every affected transaction in an unpaid-fulfillment review. Some reconciliation work, such as confirming which memberships were fulfilled without matching payment, requires you to manually cross-reference candidate records against payment data. This is usually harder to review for anniversary-based membership models than for calendar-year-based ones.
- Cross-year reporting has a structural limit. No single query returns prior-year active membership status together with billed and paid amounts across more than one membership year, because the order tied to a membership changes each membership year.
- Voiding an invoice and manually adjusting a membership's expiration does not create a payment record. If you void an invoice and then extend a membership's expiration by hand, query-based payment history reporting still shows no payment for that change. It depends on an actual recorded financial transaction, not a manually adjusted date.
- There is no query that previews a future auto-renewal charge per member. To see what has already been charged, including add-ons, use Finance & Billing's Invoices query type, which includes invoice line items with their product detail.
- Reporting on who actually renewed in a given month may need a payment-based query. A Membership-only query, including a historical snapshot, may not fully answer "who renewed in [month]." A payment-oriented query in Finance & Billing can be the more reliable source for that specific question.
- Combining membership and finance data for one renewal question generally means running two queries and cross-checking them by hand — for example, to confirm that a renewal updated the membership correctly and had a matching successful payment. There is no single built-in query that joins both sides of that question.
- Bucketing renewals into day ranges after expiration — for example, before-expiration versus 15-, 30-, 60-, and 90-day-late buckets — is not something the standard query tools do automatically. You can filter by renewal date and expiration date, but you must group results into those buckets after export.
- Identifying members who did not renew is usually more reliable with Renewal Date or Billing Run–related conditions than with invoice-oriented criteria, which can undercount unexpectedly.
- A billing contact query built on open membership balances can miss expected records if a Contacts-based query is the only one you try. If your usual query for billing contacts with open invoices misses people, build the equivalent query from your Contacts records instead. Filter on the organization's membership order balance, the contact's own membership status, and the contact's billing role to surface records the other approach missed.
- There may be no reliable self-service way to find every membership with an incorrect open-order banner. A broad query can miss affected active members or incorrectly flag memberships that have a legitimate open order. If a targeted query does not cleanly separate the two, ask Support to review a specific list of affected records instead of running a blanket cleanup yourself.
Warning
The Applications query type does not include membership fields such as status, type, or expiration date. To compare an application against the member's current membership, run a Memberships query type separately and cross-reference the results using the contact or application identifier.
Review or Hand Off Billing Run Actions
Billing Run Actions lists one row for each member action a billing run planned or performed, across all billing runs or narrowed to one run. This query type does not bring in other records, so member contact details are not available directly. If you need to identify the people involved, add a condition on the run or membership identifier and cross-reference elsewhere. For example, to find failed auto-renewal payments, filter this query type by the relevant action or status and cross-reference the resulting membership or contact identifiers with the member's own record.
If a set of renewal orders from an affected billing run cannot be reverted, use a saved query filtered to order status Awaiting Payment. That lets you monitor those records so you can manually drop or remove the ones that remain unpaid after your deadline.
Warning
When you use this query type to download one run's actions, be careful with a download condition that names only one "any of" test. A single "any of" condition behaves the same as an "all of" condition, so it will not narrow the results the way an "any of" test with more than one condition would.
Result
Each query type opens in the query designer with its own default columns and sort order. From there, you can add conditions, choose output fields, and run it like any other Membership query type.
If Query Results Look Wrong or Out of Date
A membership, application, or related record can sometimes show data in a query that does not match what you now see on the record itself. Before you escalate, try these checks:
- Re-save the record. Make a small edit to the affected membership or contact record and save it. In some cases, this has been enough to make a query result line up with the record's current values again, such as an old name, old email address, or outdated renewal or expiration date. This is a workaround, not a guaranteed fix, but it is worth trying before you escalate.
- Check for genuinely deleted or orphaned records. If a query shows membership-related values for a contact or organization that no longer has a membership record, or a membership record seems deleted but still returns errors like "not found" when you try to update or remove it from a list, you usually cannot clear it from the query side. Contact Support so the underlying record can be reviewed and, if necessary, removed by engineering. This is especially likely when the related contact was merged into another record and no longer exists as its own accessible record elsewhere.
- Watch for raw criteria values on an older saved query. Occasionally, an older saved Membership query can display an unreadable internal value in its criteria instead of the readable option you originally chose. This usually happens after a behind-the-scenes change to how queries are built. Edit the affected condition back to a normal value and re-save the query; that has resolved the issue for the saved query going forward.
- Ask Support about a stale expiration date on a specific record, if re-saving does not resolve it. In some cases, the fix requires a broader look at the query rather than the record.
- Ask Support about backfilling missing values if a query's contact or name column is blank for records you know should have a value. Support may be able to populate the missing value from another source while any underlying defect is investigated.
- Compare an order or balance field against the actual order, not just against the membership. Order-related output fields on a membership query, such as order number and balance due, reflect the values stored on the membership record rather than the current order in real time. If the two fall out of step, for example after a manual correction to the linked order, update the membership record's own Order ID and balance fields so the query output matches the real order again.
- Check the record's and package's own audit log when a renewal result looks wrong. The audit log can show whether a join date was removed by staff or a member, whether a membership package was marked inactive shortly before renewal, or whether recent edits to a membership or its package explain why a renewal behaved differently than expected.
Related
For chapters, sections, and committees instead, see Query Chapters, Sections, and Committees. To review or refresh what a billing run itself is about to do, rather than querying its finished actions, see the billing run planning task listed with this page. To change many membership records at once beyond what a query's Bulk Changes menu offers, see Update Records in Bulk. For membership revenue and invoice-level financial reporting, see See and Trace Membership Revenue and Ask and Export Questions in the Finance & Billing Query Center.