A PRACTICAL GUIDE FOR MEMBERSHIP TEAMS

Prepare a membership import without losing the meaning of your records.

Agree identities, reconcile totals and review exceptions before committing a member import. A clean CSV is only one part of a reliable migration.

Written by VeritableRoll. Reviewed . Examples are fictional; apply your organisation's own rules.

Start with a stable source identity

List the systems that own member identity, branch membership and payment facts. Pick an export cutoff and record it with the file. A membership number may be unique only within a branch; an email address may be shared, changed or missing. Neither is a safe universal match on its own.

Preserve external member numbers as text. For example, 000042 must not become 42 when a spreadsheet opens the file. Keep the source-system name and source record reference alongside the number. If one person has several memberships, agree how the person and each membership are identified separately.

Resolve ambiguous matches before attaching evidence or updating an existing member. Do not guess that two records are the same person because their names or email addresses match.

Agree what each column means

Prepare a mapping sheet with the source column, destination field, format and owner of any unresolved decision. Grade and branch labels need explicit mappings: “Fellow” in one source is not automatically the same grade or scope in another.

  • Dates: distinguish joining date, current-term start, renewal due date and expiry. State whether an end date is inclusive or exclusive.
  • Amounts: record the currency and units. £125.00 is 12,500 pence; a balance is not evidence that a payment happened.
  • Status: distinguish active membership, a future term, suspension and a pending renewal.
  • Evidence: preserve the source reference and relevant dates. A document reference is not an approval.

Preview a representative sample

Include ordinary members and the cases most likely to fail: leading-zero numbers, duplicate source references, multiple branches, blank emails, future terms and outstanding balances. Use fictional records while evaluating a public demonstration. Transfer customer records only through an agreed private process.

Review each rejected row and each proposed update. Decide which conflicts need a corrected export and which need a documented mapping decision. Keep the original export unchanged so a reviewer can understand how the prepared file was produced.

Reconcile the import and plan the handover

Agree the expected totals before import: people, memberships by branch and grade, terms, outstanding balances by currency, and evidence references. Compare the completion receipt with those totals and review the exception list. A row count alone will not reveal a shifted renewal date or an incorrect currency.

For a staged migration, define which system remains authoritative and how changes made after the export cutoff will be reconciled. Pause automated reminders or charges until the relevant data and provider setup have been accepted. Agree who can approve the import and who signs off the handover.

Keep a record of the source file, mapping version, approval, import result and unresolved actions under the agreed retention policy. Check the recovery procedure before relying on a bulk change.

How VeritableRoll handles this

The private application implements mapped CSV imports with preview, explicit approval, durable processing and completion receipts. Source identifiers remain text; exact repeat files do not create duplicate records. Conflicts are held for review rather than silently merged by email.

The current operational format can carry one source term, one positive opening balance and evidence references per membership. It does not reconstruct a complete historic invoice ledger, import evidence files or transfer payment mandates.

Customer onboarding is still being prepared. The public renewal demo uses fictional records and accepts no CSV uploads. Use it to explore what happens after records are available; it is not an import trial.