The cost of processing sign-ups in one system and payments in another (even if they are processed online) is reconciliation some days or weeks later in a spreadsheet.
Note down where these new gaps are going to fall and work from there on how you can design one process to cover them. Also, work out what you will be measuring to see the result of it having been implemented.
Where the administrative cost accumulates
The visible cost of processing payment separately from processing event registrations is the cost of reconciliation of the names on the registrations with the corresponding transactions. There are, however, many additional costs that are not so apparent, such as chasing up attendees whose payments are late, processing of late payments, queries from attendees as to status of payments, dealing with exceptional cases (such as cancellation), manual postings to the General Ledger account.
The four common leak points
- Registrations with no matching payment, which require chasing and often a second invoice.
- Payments with no matching registration, usually a bank transfer with a reference that means nothing to the finance team.
- Partial payments and group bookings where one payer covers several attendees under one name.
- Refunds and cancellations processed outside the registration record, so the attendee list and the ledger disagree.
Tracking individual events is relatively inexpensive but once you start to aggregate across many events then it becomes expensive. Even though most events will be ‘perfect’ it is more cost effective to track all of them rather than only the defective ones. For a midsize conference with 200-500 registrants there can be 100+ exceptions to the rule.
Designing a single transaction instead of two
When processing payment within a registration process, authorization for payment should occur prior to the creation of the registration record (e.g. Payment authorization information captured prior to the creation of the registration record). This ensures that an unpaid registration record is not created in error.
However, for card payments and wallets like PayPal, Apple Pay etc, you’ll need to process these immediately online. This can be done online via a form for payment by invoice too. Most organizations will need two models of payment at registration, online capture of immediate online payment and payment by invoice (slower, via manual processing by the organization).
What to require at the point of registration
- A payment method or a purchase order reference. No exceptions, including for internal staff.
- Attendee-level detail for every seat in a group booking, even if one payer covers them all.
- A tax status or billing entity, captured once rather than reconstructed later from email threads.
- An explicit acceptance of the cancellation terms, timestamped against the record.
Choosing a collection model that fits your event mix
The key issue here is what model to use for a particular situation and this will depend on the ticket price, buyer type and how far in advance people book. A free community event and a multi-day training program with corporate purchasing behind it for example would require very different approaches to payment at registration. If your team is running several formats side by side, it is worth using a single tool that lets you plan and collect event payments in the same place, so the sign-up list and the ledger never drift apart.
| Model | Best suited to | Main advantage | Main trade-off |
| Card at checkout | Consumer and small business audiences, ticket values under a few hundred | Zero reconciliation, instant confirmation | Processing fees, unsuitable for procurement-led buyers |
| Automated invoicing | Corporate and public sector bookings | Fits existing purchase order workflows | Settlement lag, requires structured chasing |
| Deposit plus balance | High-value programs booked months ahead | Secures commitment, spreads cash flow | Two collection points to manage per attendee |
| Direct debit or installments | Membership-linked or recurring series | Predictable revenue, low failure rate | Mandate setup adds friction at sign-up |
Do not offer all four
More payment options equal more reconciliation headaches. For the majority of scenarios, 2 models will be sufficient. 3 scenarios will most likely introduce the same issues you’re trying to avoid with processing payments online in the first place.
Automating reconciliation rather than accelerating it
Reconciliation between payments and pending registrations is only going to be faster than manual matching if the payments (online card payments or bank transfers) contain sufficient information to automatically tie the payments to the pending registrations. This means that the payment must contain the same identifier as the registration records created online in the Event Registration Platform, and this identifier must flow unaltered through the ERP and into the Accounting Package – typically provided by the online event registration platform.
So test out all the various edge cases for payment integration, i.e. A group booking that only gets to have part of their payment refunded; payments by invoice which have been paid for by 2 x bank transfers; a booking which has been transferred to another attendee after payment has been processed for them.
Measuring whether it worked
Note the 4 measures you can use to track the process for the next 3 events, The % of sign-ups that pay up immediately. The average number of days from sign-up to cleared funds. The # of manual reconciliation errors per hundred sign-ups. The # of hours staff & volunteers spend to track down payment in the last 2 weeks of the event.
What good looks like
Card led events will have the majority of tickets paying for tickets online via credit cards, with only odd occasions needing to be manually updated for every 100+ tickets. Manual updating of paid invoices for invoice paid events will need to settle within your standard payment terms, with automated chasing of late payment if required.
