Consolidation
Operator page
Some fixes here change what members are charged or which newsletters they receive. Every fix shows a preview first. Read it.
Every role can run a check, cancel a running one, and use Printable report and Export CSV. Previews, fixes and Email report are for owners. Membership managers see only three checks and can run the Mailchimp fixes in them (see What membership managers see). Finance can press the money buttons in section 8. Support can queue outreach and mark it contacted or resolved.
FMS keeps its own copy of every membership and treats it as the truth for access, dashboards and newsletter tags. Stripe's notifications and FMS's own updates keep that copy current, but the outside world still drifts: a notification from Stripe goes missing, somebody edits a subscription in the Stripe dashboard, an import brings in history FMS never saw, or a tag is changed by hand in Mailchimp.
Consolidation measures that drift and helps you repair it. Nothing is fetched until you ask, and nothing is changed until you press a fix button after seeing its preview.
The words on this screen
Update Mailchimp sets one member's Mailchimp tags to match their memberships; Update all drifting does it for everyone the last check found. A failed update is one FMS stopped retrying: a developer or an owner replays it from Dead letters. When a check or a fix fails, the page says so in a sentence; the server's own message is folded under Details for a developer.
What membership managers see
A membership manager sees only the three checks that compare FMS with Stripe and Mailchimp:
| # | Check | What they can do there |
|---|---|---|
| 7 | FMS ↔ Stripe | Read it. The fixes are an owner's; each row says what the fix would do and links to the member. |
| 10 | FMS ↔ Mailchimp | Update Mailchimp, Update all drifting and Add to the audience. |
| 11 | Mailchimp → FMS | Strip all…, and add a person as a member first if they should be one. |
The strip of checks, Collapse all and the list under New to consolidation? show the same three. The line under the title says so: an owner runs the rest of consolidation. Owners, developers, finance, support and viewers see all twelve, as before. This only trims the page; Printable report and Export CSV still cover every check.
Every issue says what to do next
Each row a check finds carries a Next step: one sentence saying what fixes it and where, then up to two links.
- Open member goes to the member's page. When the row knows only an address (a subscription FMS has no record of, a Mailchimp contact, a team buyer, a payment), the link is Find in Members instead: it searches Members for that address and may list more than one person.
- Fix it in … jumps to the check on this page that owns the repair.
- Guide links open the matching page of this guide in a new tab. They show only when the guide's address is set. Every check's header has one too, beside What this does & side effects.
- A link to a screen your role cannot use is left out. The sentence says who does it instead, for example An owner applies the fix.
On a wide screen the next step is its own column. On a narrow one, and in the three widest tables (FMS ↔ Stripe, Money ↔ Stripe, Payment health), it sits under the issue. On a phone it sits under the member.
Finding your way down the page
The twelve checks are long, so the page helps you move between them.
- The strip of checks stays at the top as you scroll. Each chip shows a check's name and what its last result found. A dash means it has not been run yet. Amber means there is something to look at, green means clean, and a tick means the backfill ran. Press a chip to jump to that check.
- The arrow beside each title folds the check to one line: its title, a badge with the count, and Checked 14 min ago. Press it again, or the title, to open it. Collapse all and Expand all at the end of the strip do every check at once. The page remembers which are folded.
- Running a folded check opens it, and so does a chip or a Fix it in link that lands on it.
- Every list shows ten rows a page. Use the arrows and page numbers under it, or Rows per page for 25, 50 or 100. The choice is shared by every list on this page. The Duplicates check pages its member cards the same way.
Bulk fixes cover every page
Fix all drifting, Update all drifting and Strip all… act on everything the check found, not only the page you are looking at. The line under the list says so when there is more than one page.
How every check works
- Press Run check. This reads. It changes nothing anywhere.
- Read what it found. A check with nothing to report is finished.
- Where a fix exists, press Preview. You get the exact list of what would change.
- If the list is right, apply it. Then press Re-check to confirm the rows cleared.
Checks that run in the background
Six checks read every member from Stripe or Mailchimp, so they take minutes with a full member list. They run in the background: Payment health, Invoice history backfill, Stripe ↔ Mailchimp, FMS ↔ Stripe, FMS ↔ Mailchimp and Mailchimp → FMS. The three report buttons do too.
| You see | What it means |
|---|---|
| A progress line, such as 8,400 of 21,312 | The check is working. You can leave the page and come back. |
| Cancel | Stops the check. Its result is not kept. A backfill keeps the rows it already added. |
| Checked 14 min ago | The last finished result, kept until you run the check again. |
| Another check is running | Only one runs at a time. Wait for it, or cancel it, then start yours. |
| FMS restarted while this check was running | The check stopped. Press Run check again. It starts from the top. |
Read the age before you act
A fix button works from the last result shown. Check how old it is. Run the check again if a lot has happened since.
Fix buttons are refused on live accounts
Anything that would write to a live Stripe account is refused until the system has been armed for it. Mailchimp fixes are refused on the live console the same way, except during the cutover clean-up. The badges under the page title say which is armed. Local fixes still work. Ask Thomas before arming anything.
"Check incomplete — do not read this as clean"
A red box with these words means the check could not read everything. An account's key may be unreadable, or Stripe or Mailchimp failed partway. Mailchimp may have refused to return a few members, twice each. Those members count as neither right nor wrong. What it did find is still listed. Fix the connection, then run the check again. An incomplete check never shows the green in sync box, and the emailed and downloaded reports say INCOMPLETE too.
Run them top to bottom
The order matters because fixing one thing can clear findings in a later check. The screen carries the same list under New to consolidation? at the top (membership managers see their three).
| # | Check | Why it comes here |
|---|---|---|
| 1 | Outreach queue | Members whose renewal already failed. People first. |
| 2 | Payment health | Renewals about to fail. Catch them before they do. |
| 3 | Duplicate subscriptions | Someone paying twice. |
| 4 | Team subscriptions without a team | Team plans with no roster to manage. |
| 5 | Invoice history backfill | Fill the member invoice history from Stripe. |
| 6 | Stripe ↔ Mailchimp | Per-member overview. Read-only. Points at 3, 10 and Connections. |
| 7 | FMS ↔ Stripe | Local status against live Stripe, both directions. |
| 8 | Money ↔ Stripe | Amounts, refunds and disputes against what Stripe recorded. |
| 9 | Plan prices ↔ Stripe | A local price that disagrees with the mapped Stripe price, and price edits still on their way. |
| 10 | FMS ↔ Mailchimp | Entitled tags against actual tags. |
| 11 | Mailchimp → FMS | Paid tags on people who are not members. |
| 12 | Mailchimp tag check | Tag names that do not exist in the audience. |
1. Outreach queue
Finds members who need a human. Their renewal already failed because their card's brand is not supported by the account that billed them, and no backup account had a saved card to take over silently. FMS gave them a grace window, so access has not lapsed yet. Members queued from Payment health appear here too.
The fix is you. Copy the checkout link, which points at an account that does take their card, and email it to the member. Then press Mark contacted and later Resolve to track where each conversation stands. Open member under each address goes to the member's page.
Touches: nothing in Stripe or Mailchimp. The buttons update FMS's own outreach status only. The member's new checkout is what actually repairs their billing.
A member who already pays on the other account
FMS checks the other account first. If the member already pays for the same plan there, FMS links their record to that payment and emails staff "linked, nothing to do". They do not appear in this queue. Rows from before 2 October may still say already on backup; those need linking by hand. Ask Thomas.
2. Payment health
Finds renewing subscriptions whose next charge is already doomed. Every renewing Stripe subscription is asked which card it would charge, and that card is judged against its own account's supported brands. No saved card means the invoice can never be paid. Brand not supported means the account will refuse the card even though it looks fine today, for example American Express on Thailand.
The fix is the member's. A card cannot be moved between Stripe accounts, so there is no automatic repair. Queue outreach puts the row into the Outreach queue above, and a rescue guide appears with the results.
Next step: Queue outreach, then send the checkout link from the Outreach queue. Once queued, the row links to the Outreach queue instead.
Touches: the check runs in the background and does one card lookup per subscription. It writes nothing. Queuing writes one local outreach row. Rows marked unknown could not be read this run and are retried next time. They never count as at-risk.
3. Duplicate subscriptions
Finds members with two or more active subscriptions, usually one per Stripe account after a migration or a re-signup. Double-billed means at least two of them actually charge money.
Fix: cancel the extra row by row, or use the one-click resolution on a double-billed member. It keeps a team's subscription, otherwise the oldest, and cancels the rest. You choose which one survives. Nothing is cancelled without your click. Each member's card repeats the rule as its Next step, with a link to Cancel or refund.
Touches: cancelling writes to Stripe, stopping the charge and its reminder emails, on test-mode accounts only. On a live account only the local row is marked cancelled and the message tells you so. A Mailchimp tag update is queued so the member's newsletters follow.
Moves money
Cancelling the wrong one stops a legitimate subscription. Read both rows before you choose.
4. Team subscriptions without a team
Finds team-plan subscriptions with no team record. The buyer is paying for seats but has no roster to manage. Happens with purchases from before automatic team creation, or imports.
Fix: one click creates a team shell for every listed subscription with the buyer as admin. The table you see is the complete list of what will be created. Each row's Next step says so and links to the buyer with Find in Members; a provisioned row links to its team.
Touches: FMS only. No Stripe, no Mailchimp, no emails. Safe on live accounts, safe to re-run. Teams that already exist are skipped.
5. Invoice history backfill
Finds invoice history that exists in Stripe but not in the local cache that the member-facing invoice page reads. It pages through every account's invoice list, matching customers to members by mapping first, then by email.
Fix: Preview (no writes) shows what would be pulled in and which customers match nobody. Run backfill writes the missing rows. Both run in the background, with progress. If it stops, run it again. Re-running only adds what is still missing.
Touches: reads Stripe, never writes to it. Locally it adds invoice rows and member-to-customer mappings for email matches. Unmatched customers are listed for you, not guessed.
6. Stripe ↔ Mailchimp
Shows each member's whole pipeline in one row: which Stripe accounts they are active on, whether that entitles them to members-only tags, and whether the tags they actually carry match. Under-tagged paying members, still-tagged ex-members and duplicates all show up here.
No fix here, on purpose. Each flagged row's Next step says where it is repaired, and every row links to the member:
| Row says | Next step |
|---|---|
| Active but under-tagged, Tagged after canceling, Wrong PMPro level, Tags don't match | Update Mailchimp in FMS ↔ Mailchimp pushes the right tags, with Fix it in FMS ↔ Mailchimp. |
| No PMPro level for this plan | Map the Stripe price to a plan on its connection page (developer or owner). They get Open Connections. |
| Not in the Mailchimp audience | Add to the audience only if they agreed to newsletters; otherwise leave it. |
| Mailchimp refuses this address | Correct the address on the member's page, then re-check. |
| Duplicate subscriptions | Cancel the extra one in Duplicate subscriptions: keep the team's, otherwise the oldest. |
Touches: nothing. It reads local state and Mailchimp, one member at a time, in the background.
7. FMS ↔ Stripe
Finds drift in both directions. Forward: the status, plan and seat count FMS holds for every subscription, compared against live Stripe. A missed Stripe notification or a dashboard edit shows up here. Reverse: every account swept for live subscriptions FMS has no record of. It also confirms each account still notifies FMS (its webhook) of every kind of event FMS handles.
The address it looks for is this environment's own. A sandbox's ends ?env= and its name. A red note Stripe has no address to notify this environment names the account. A developer or an owner presses Create webhook endpoint on its Connections page (the note links there for them; everyone else reads who fixes it). An amber note says an Omise account points at another environment. That is fine when the other one should get its events.
Fixes, each with a preview:
| Button | What it does |
|---|---|
| Pull | Updates the local cache to match Stripe. |
| Mark canceled | Records locally that Stripe no longer has the subscription. |
| Adopt | Attaches an unknown live subscription to a member, matched or created by email, and starts tracking it. |
Each row's Next step:
| Row says | Next step | Link |
|---|---|---|
| Status mismatch, Plan/seats mismatch | Fix updates FMS to match Stripe; Stripe is not changed. | Open member |
| Missing in Stripe | Fix marks it ended in FMS. If they should keep access, grant it on their page. | Open member |
| Missing in FMS | Fix attaches it to the member with this email, or creates one. | Find in Members |
| Billed twice | Cancel the extra subscription in Stripe (refund it if it charged), then re-check. | Open member, Cancel or refund |
Only owners have the Fix button. Everyone else reads An owner applies the fix with what it would do, and can check the member meanwhile.
Moves money — Billed twice
A red Billed twice row means Stripe charges one member for two memberships at once. Usually one account's cancel never happened. There is no button for this. Open both subscriptions in Stripe, cancel the extra one, refund it if it charged, then press Re-check. Fix all drifting never touches these rows.
The check runs in the background. It reads each tracked subscription from Stripe one by one.
Touches: never Stripe. Only FMS's local cache. Mailchimp tag updates are queued so tags follow the corrected status. A pull to cancelled removes members-only tags. On a read-only account the fix reports blocked instead of applying.
8. Money ↔ Stripe
Finds money that FMS recorded differently from Stripe, in the last 90 days (or the window you pick). It reads every paid invoice, refund and dispute on each connected account. The totals table shows Stripe's paid invoices beside what FMS recorded for the same invoices.
| Row says | What it means | What to do |
|---|---|---|
| Invoice missing | Stripe was paid; FMS has no invoice for it. | Run Invoice history backfill (section 5). |
| Amount differs | FMS recorded a different amount or currency. | Run Invoice history backfill. |
| Paid on one side only | Paid in Stripe, not in FMS, or the reverse. | Run Invoice history backfill. |
| Renewal off price | A renewal charged something other than its own price × seats, before tax, or its price belongs to another plan. A member on a discount code or an older imported price is fine and is not listed. | Look at the invoice in Stripe first. Change a price only if the member really is on the wrong plan. |
| Refund not recorded | Stripe refunded more than the ledger knows. Reports show too much. | Press Re-read refunds. |
| Lost dispute not recorded | The money was taken back; Reports still count it. | Press Mark disputed. |
| Won dispute still marked | The dispute was won; Reports still leave it out. | Press Mark settled. |
Open disputes are listed underneath. Answer them in the Stripe dashboard.
Each row's Next step repeats the What to do column, with Find in Members when the payment has an address. Open disputes read Answer it in the Stripe dashboard.
Touches: reads Stripe. Re-read refunds queues another Stripe read. The mark buttons ask Stripe again first, then change one ledger row, which moves that payment in or out of Reports. Finance and owners can press them. This check is not on a membership manager's page.
9. Plan prices ↔ Stripe
Finds plans whose local price differs from the Stripe price actually mapped for an account. A mismatch means checkout shows one amount and Stripe charges another.
Since 16 October 2026 a price edit reaches Stripe through the background queue, so a plan drifts for a few seconds after it is saved. The check says so:
- Propagating to Stripe: N — price edits still on their way. Run the check again in a moment.
- Refused by Stripe (failed updates): N — Stripe refused the new price, usually because the live write brake is on or the connection is read-only. A developer or an owner fixes that, then replays it in Health → Dead letters.
Older drift has no button. Map the intended price on Connections, or change the plan's price on the plan page, which creates a new Stripe price at the new amount. For team plans, rebuild team pricing. Each row's Next step says so; owners get Open Plans, and everyone gets the Changing a price guide link.
Touches: nothing. Entirely local, no Stripe call.
10. FMS ↔ Mailchimp
Finds, for every member, the members-only tags their subscriptions entitle them to, compared with the tags on their Mailchimp record. Drift means a paying member missing access tags, or an ex-member still receiving members-only sends.
The check runs in the background. It reads every member from Mailchimp, so it takes minutes with a full member list.
Fix: Update Mailchimp previews the exact tags that would be added and removed for one member, then queues the change. FMS sends it in the background, so re-check a moment later to confirm the rows cleared. Membership managers and owners can press it.
Update all drifting works from the last finished check. Its preview counts the members it will update, those not in the audience, and those Mailchimp refuses. It does not read Mailchimp again. Applying is one press: every update is queued at once and sent in the background. Run the check again a few minutes later.
Run the check again until it is complete
An incomplete check leaves out the members it could not read. Update all drifting only updates the members the check saw.
Adding members who are not in the audience
An update only changes contacts Mailchimp already has. A paying member Mailchimp has no record of shows Not in audience, and an update leaves them out. Since 16 October 2026 you can add them.
- One member: press Update Mailchimp on their row. The panel says they are not in the audience. Press Add to the audience.
- Everyone: press Add absent members to the audience above the table. It shows only when the check found such members. It works from the last finished check, like Update all drifting. The preview says how many it will add and how many it leaves out. Press Add N members to queue them.
Each member is added as a subscribed contact, with the newsletters they get now. This is what a signup does. Add only members who agreed to get your newsletters. Your name goes in the activity trail.
It leaves out, and counts:
| Left out | Why |
|---|---|
| Mailchimp refused the address | Mailchimp rejected it for good. Correct the member's address first. |
| PMPro still manages them | They have not been handed over yet. Hand them over on Settings → Migration first. |
| They get no newsletter now | They opted out of every newsletter, or their membership ended since the check. |
The same brake as every Mailchimp fix applies. On the live console it is off except during the cutover clean-up.
Each row's Next step, with Open member:
| Row says | What it means | Next step |
|---|---|---|
| Tags to add or remove | The member's tags drifted. | Update Mailchimp pushes the right tags. |
| Not in audience | A paying member Mailchimp has no record of. An update never adds a contact. | Add to the audience (under Update Mailchimp) only if they agreed to newsletters; otherwise leave it. Their Newsletters card says whether they did. |
| Mailchimp refuses this address | Mailchimp rejected the address itself: compliance state, forgotten, or fake. FMS stops trying for 30 days. | Correct the address on the member's page, then re-check, with the Change the address guide link. |
Roles without the Mailchimp fixes read A membership manager or an owner presses Update Mailchimp.
Touches: Mailchimp. Adds and removes tags through the same queue normal membership changes use. On the live console it is off except during the cutover clean-up (the badge says Mailchimp fixes off for the live audience). Never changes subscriptions or access, never touches Stripe. Only Add to the audience subscribes anyone new, and only the members you add.
11. Mailchimp → FMS
Finds people in the Mailchimp audience who hold members-only tags while no FMS member gets newsletters at that address. They are mostly left over from PMPro, tagged by hand, or an address a member moved their newsletters away from. Addresses that do belong to members are counted and left to section 10.
The check runs in the background. It reads the whole audience, a thousand contacts at a time.
Fix: Strip all… works from the last finished check, so run the check first. It checks each address against FMS again, shows how many addresses it will change, and asks you to confirm. It turns their paid tags off. Free newsletters they chose themselves, Frontier Fridays and Website, stay on. The contact stays in the audience. Membership managers and owners can press it.
Next step on each address: Strip all removes members-only tags from people who are not members. If this person should be a member, add them first. Find in Members searches for the address; New member (support, membership managers and owners) opens the new-member form.
Touches: Mailchimp tags, through the queue. Never adds a contact, never touches a member's address. Off on the live console except during the cutover clean-up, like section 10.
12. Mailchimp tag check
Finds tag names your plans reference that do not exist in the audience, and the reverse, audience tags your catalog does not know. A referenced-but-missing tag silently applies to nobody, so a typo here means a whole tier gets no newsletters.
Fix: Import into catalog creates local catalog rows for the audience tags FMS did not know, guessing the category from a (Premium) suffix. Review the imported rows afterwards, since that guess is only a convention.
Touches: FMS catalog rows only. Never Mailchimp, never existing rows, never a member.
Sharing what you found
The header has Email report, Printable report and Export CSV. Each first builds a full report covering every check, in the background. That takes minutes with a full member list.
- Printable report and Export CSV download the report once it is built. The printable one opens in a new tab and saves as a PDF.
- Email report sends the summary to the admin address when the report finishes.
- A report that could not read everything says INCOMPLETE at the top. Do not read it as clean. Run it again later.
Check it worked
- Every check re-run after its fix reports nothing, or only rows you chose to leave
- No new failed updates a few minutes later (the Dashboard's Needs attention says so; developers and owners see them in Dead letters)
- Members you touched have a note explaining why