Three records for one member, and nobody sure which pays
A delegate books your annual conference at the member rate. Their email domain matches a member firm, so the events team lets it through. A week later finance notices the booking came from a sister company in the same group, one that has never paid a subscription. Is that company covered or not? The membership manager thinks the group joined as a whole. The renewal invoice says otherwise: it names one limited company and one registered address.
Then the group is acquired. The parent changes its name, two subsidiaries merge, and a trading brand you have listed as a separate member turns out to be the same legal entity as another record. Your database now holds three rows for what is really one member, each with its own contacts, its own survey history and its own notes. Nobody wants to delete any of them, because each holds something useful.
This is ordinary life for an association whose sector has consolidated. The larger members are rarely a single company in a single building.
Why a flat company list keeps breaking
Most membership databases and CRMs start with one table of organisations. That works while members are independent firms. It stops working when the thing you need to answer is 'who is covered by this subscription', because the answer depends on group structure, and the database has nowhere to put it.
- Subsidiaries, trading names and branches are entered as separate organisations with no link between them.
- The billing entity and the member entity are assumed to be the same, when a group finance team often pays for several companies.
- Benefit rules (who gets member rates, who can use the helpline, who appears in the directory) live in staff heads, not in the record.
- Mergers and renames are handled by editing names in place, which erases the history of who the member used to be.
- Companies House numbers are missing or mistyped, so there is no reliable key to match against.
The structure question is a membership policy decision for your board. The data problem is that your system cannot record whatever the answer is.
What the muddle costs the association
Money leaks both ways. Unpaid sister companies take member rates at events and exhibitions, and at the same time a group that pays a large subscription gets chased for a second one because a subsidiary appears unpaid. Neither is a good conversation to have with an important member.
Survey returns get attributed to the wrong entity, which matters when your statistics are split by firm size or region. The public directory lists firms that are not members and misses some that are. Staff spend time untangling records every renewal season, and the untangling is lost the next time someone edits a name.
A member record that understands groups
We rebuild the member record around the structure your sector actually has, inside your existing CRM where it can hold it, or as a small membership service beside it where it cannot.
- Every organisation gets a Companies House number or overseas equivalent where one exists, checked against the Companies House API so names and status stay current.
- Organisations link to a parent, so a group appears once at the top with its subsidiaries, brands and sites beneath it.
- Each membership is a separate record that names the member entity, the billing entity and the tier, so a group can pay for several members, or one subscription can cover a whole group, whichever your rules say.
- Benefit coverage is a field, not a guess: which linked entities inherit member rates, directory listing and helpline access.
- Renames, mergers and acquisitions are recorded as events with dates, so the old name still finds the member and past survey returns stay attached.
- Membership status and billing entity sync to Xero, Sage or your finance system through its API, so the invoice and the record agree.
| Situation | How the record handles it | Who decides the rule |
|---|---|---|
| Group joins as a whole | One membership on the parent, coverage flag on each subsidiary | Your membership policy |
| Only one subsidiary joins | Membership on that entity, siblings shown as non-members | Your membership policy |
| Trading name of a member | Linked as an alias, not a separate company | Membership team |
| Member acquired by a non-member | Acquisition event logged, renewal flagged for review | Membership manager |
| Group finance pays for several members | One billing entity linked to several memberships | Finance |
Event booking forms and the member portal then check coverage against the record, so an events coordinator no longer has to judge an email domain by eye.
What renewal season looks like afterwards
The membership manager opens a group and sees every company in it, which are covered, who pays and what each has used this year. When the group's procurement team asks what they are paying for, you can send a list rather than an estimate. A sister company that tries to book at the member rate gets a polite prompt to talk to your team, not an automatic yes.
When two members merge, someone records the event once. Survey history and contacts follow, and the board report on membership numbers counts groups and companies the way your board has chosen to count them.
Is your member list flatter than your sector?
- The same member appears under two or three names in your database.
- Events staff decide member rates by looking at email domains.
- You cannot say which companies a group subscription covers without asking someone.
- Mergers in your sector leave orphaned records every year.
- The invoice and the member record name different companies.