Event Billing: Separate from Dues Billing

Last Update : August 2026

Event registration invoices and membership dues invoices are kept separate in MemberLeap. An event registration creates its own invoice with its own invoice number, payment history, and accounting record. A dues renewal creates a completely different invoice. The two never merge, even when the same person is involved.

This is an intentional design decision, not a configuration choice you can change. This article explains why MemberLeap works this way, what alternatives were considered, and what the separation means for you as an admin.

Why event billing is separate

The short answer: most organizations have non-members registering for events. Non-members aren't reliably in your member database, which means there's no member record to attach their event invoice to. If the system tried to roll event billing into member billing, every non-member registration would either need to create a stub member record (cluttering your database) or get treated as an orphan (defeating the point of integrated billing).

Keeping event registration on its own billing track sidesteps the problem entirely. Event invoices live in their own table, are tracked with their own invoice-number sequence, and are reported on through the event-reporting tools rather than the dues-reporting tools.

The alternatives, and why they don't work

Even if your organization only allowed members to register for events, the system would still need a reliable way to match each registration to a member record. There are two reasonable approaches, and both have practical problems.

Requiring login

The cleanest approach is forcing members to log in before they can register for an event. If they're logged in, you know exactly which member record to attach the invoice to.

The problem is that most members never remember their username and password. Requiring login at registration time becomes a major friction point — members try to register, can't log in, give up, and call or mail in their registration instead. That defeats the entire point of having online event registration in the first place.

This trade-off is why MemberLeap doesn't require login by default. The system supports requiring login when you want it (see the Members Only Registration option in the Access Restrictions card of Advanced Options), but it's opt-in per event rather than the default.

Email lookup

The next-best approach is matching by email address. The system can look up the email entered on the registration form, find the member record that uses that email, and attach the invoice there.

MemberLeap uses email lookup extensively for things like member-vs-non-member pricing — the registration form checks whether the entered email matches a member account and adjusts package visibility accordingly. But it's not 100% reliable for billing-level attribution:

• People change email addresses and don't always update their member record.
• Members frequently have multiple email addresses and don't remember which one is on file with your organization.
• Spouses, assistants, or family members sometimes register for a member using their own email address.
• Members occasionally register using a work email when their account is under a personal one (or vice versa).

For pricing decisions, an occasional mismatch is recoverable — an admin can step in and apply a discount. For billing attribution, an occasional mismatch means an invoice attached to the wrong member, which is much harder to undo cleanly and creates audit-trail issues.

How linking is handled instead

Event registrations can still be tied to member records — it just happens after the fact through an explicit matching step rather than as part of the registration flow.

The Member Match Tool, accessible from the per-event Reporting Dashboard under the Attendees tab, walks you through the unmatched attendees on an event and lets you confirm each match against a member record. Once matched, the registration's data shows up on the member's record in the member database — you can see their event history, their custom-field answers, their attendance status — without the invoice or payment moving into dues-side billing.

This gives you the best of both worlds. Event billing stays clean and standalone for accounting and reporting purposes, but member records still reflect everything their member has done with your events. Reports that span both systems (like the cross-event Attendance Report or Member vs Non-Member CSV) work off the matched data.

What this means for you

In day-to-day operations, the separation is mostly invisible. You manage event invoices and payments through the event-side tools (the Invoice Information page on each attendee). You manage dues invoices and payments through the dues-side tools. The two never need to interact directly.

A few practical implications worth knowing:

• Reports are split. Event-side reports cover event billing only. Dues-side reports cover dues billing only. There's no combined "total billed by member" report — if you need that view, you'd pull both reports and combine them manually (or in your accounting software).
• Payments don't cross over. A payment recorded against an event invoice doesn't credit a dues balance, and vice versa. If a member wants to apply a credit from one to the other, you'd handle that as a refund on one side and a payment on the other.
• There's one place they can intersect. The Allow Non-Members to Join as Part of Registration and Current Members to Pay Existing Renewal Invoices option in the global Event Registration configuration lets attendees pay outstanding dues during event checkout. Even then, the two invoices remain separate — the dues payment goes against the dues invoice, and the event payment goes against the event invoice. The attendee just gets to handle both in one checkout.
• Member records still get enriched. Matched attendees show their event history on the member info page in the member database, so you can see "this member came to these events" without pulling a separate report.