# Reconcile Circle community access with your paying subscribers

> Spot everyone who cancelled but can still get in, and everyone who paid but never got access, then fix each one with a click and a preview.

- Workflow type: app
- Services: Circle, Chargebee
- Categories: Operations, Finance
- Published: 2026-08-16

## What it does

- Loads your subscriber list from your billing system and your member list from Circle, then matches the two by email address.
- Sorts everyone into four groups you can work through: paying but locked out, cancelled but still has access, member with no subscription at all, and paid but never joined.
- Gives every person a one click fix, so you can grant access, take it away, invite someone in, or remove them from the community.
- Waits until a cancelled member's paid through date has actually passed before flagging them, so nobody gets cut off early.

## What you'll need

- A Circle community on a plan that allows admin access, and admin rights to it.
- A Chargebee account where your subscriptions are billed. The same audit works with whatever subscription billing tool your community uses.
- The name of the Circle access group your paying members belong to.
- Roughly matching email addresses between the two systems, since that is what the audit matches people on.

## Prompt

Build me a reconciliation console for my paid Circle community. It should show me every place my paid Circle access no longer matches who is actually paying in Chargebee, so I can work through the drift that failed payments, refunds, manual comps and mid-cycle cancellations leave behind. Event-driven automations never catch the ones that already slipped through, so this is the weekly or monthly audit I do by hand today.

Setup, saved between visits: let me choose which Circle access group represents paid access, using List Access Groups to populate the picker. Let me also set a grace period in days and choose which Chargebee subscription statuses count as paying. Default the paying statuses to active and non_renewing, and default the grace period to 3 days. Save these settings so I do not re-enter them every time I open the app.

The billing side of the screen loads from Chargebee using List Subscriptions filtered by status, covering both the paying statuses and the lapsed ones (cancelled, non_renewing, paused) so I can see drift in both directions. For each subscription, resolve the subscriber's email address with Retrieve Customer on the subscription's customer id. Cache resolved customers within a run so a customer with several subscriptions is only fetched once, and respect Chargebee's pagination and rate limits while loading. Show a progress indicator, because this side can take a while on a large community.

The community side loads from Circle: List Community Members for everyone in the community, List Access Groups for the groups themselves, and List Access Group Members for who currently holds the paid access group.

Match the two sides on email address, lowercased and trimmed, and sort everyone into four buckets I can work through as tabs or sections, each showing a count: (1) paying but missing the paid access group, (2) cancelled or lapsed but still holding paid access, (3) community member with no subscription at all, and (4) subscriber who paid but never joined the community.

Respect the grace period strictly. A cancelled or lapsed subscriber must never be flagged in bucket 2 until their paid-through date (the subscription's current term end, or its cancelled-at date) has actually passed, plus the configured grace days. Someone who cancelled but is paid through the end of the month is not a problem yet, so put them in a separate scheduled-to-lapse view showing the date their access should end, rather than in the actionable bucket.

Show the matched evidence on every row so I can trust the match before I act on it. On the billing side show the email that matched, the subscription id, its status, the plan or item price, and the paid-through date. On the community side show the member name, member id, join date, and which access groups they are currently in. Let me expand a row to see the full detail of both sides next to each other.

Every row carries its own fix. In bucket 1, grant access with Add Member to Access Group. In bucket 2, revoke it with Remove Member from Access Group. In bucket 3, let me either revoke paid access or remove the person entirely with Delete Community Member. In bucket 4, invite them with Create Community Member, or generate a shareable link with Create Invitation Link when I would rather send it myself. Every action sits behind a confirmation step that previews exactly what will change, naming the person, the action and the access group, before anything is written. Let me select several rows in a bucket and confirm them together, with the same preview listing every row in the batch.

Keep a visible log of what I changed in this session: timestamp, person, action taken, and whether it succeeded, with failures called out so I can retry them. Persist the log so it survives a reload, and let me re-run the comparison after acting to confirm the buckets actually shrank.

Nothing is ever written without my explicit confirmation, and no bucket is ever actioned wholesale on its own. The same pattern applies to whichever subscription billing tool a community uses, so keep the billing side of the code in one place that could be pointed at a different biller later.

## How to customize

- Change the grace period, so a cancelled member gets a few extra days before they show up as needing removal.
- Point it at more than one paid access group if you sell tiers, and audit each one separately.
- Decide which subscription statuses count as paying, for example whether someone in a failed payment retry window still keeps access.

## FAQ

### Will this remove anyone automatically?

No. Nothing is changed until you click, and every action shows you a preview of exactly what will happen and to whom before it is written. You can also select a few people and confirm them together, and the preview still lists every single one.

### What happens if someone pays with a different email than the one they use in the community?

They will show up twice, once as a subscriber who never joined and once as a member with no subscription. That is intentional, because those two rows sitting next to each other are usually how you spot a mismatched email, and you can leave both alone once you know.

### Does this work with Stripe or another billing tool?

The example is built on Chargebee because it can both list subscriptions and look up each subscriber's email address. The same audit works with any subscription billing tool that can do those two things, so you can point it at whatever you use.

### Why not just set up an automatic sync instead?

Automatic syncs only catch things going forward, and they quietly miss cases like failed payments, refunds, manual comps and mid cycle cancellations. This is for catching the drift that has already built up, which is exactly what an event based automation cannot see.

### How often should I run this?

Most paid community owners do this weekly or monthly. Run it more often around a launch or a big renewal date, when more people are moving in and out at once.

Use this prompt in General Input: https://www.generalinput.com/prompts/reconcile-circle-community-access-with-your-paying-subscribers