Conference registration payment reconciliation becomes urgent when three reports appear to tell three different stories. The registration export shows $100,000 in paid orders. The payment processor shows $93,420 in payouts. The September bank statement shows only $84,000 received. That does not automatically mean $16,000 has vanished.
Those figures may cover different parts of the payment journey and different dates. A registration report records what attendees bought. A processor report explains what it collected, refunded, deducted and grouped into payouts. A bank statement records when funds actually arrived. Reconciliation connects those records and gives every difference a documented reason.
This guide follows one fictional conference through that process. The figures are illustrative, but the questions and controls are practical: which orders count, which payments reached the processor, what changed the payout, when did the bank post it and who approved any unresolved item?
Three totals can all be correct
Imagine that a conference closes its September books with these figures:
| Record | Amount | What the amount represents |
|---|---|---|
| Registration report | $100,000 | Paid attendee orders, including $4,000 collected by bank transfer |
| Processor gross | $96,000 | Online card payments handled by the processor |
| Processor payouts | $93,420 | Online payments after $1,200 in refunds and $1,380 in fees |
| September bank receipts | $84,000 | The $4,000 offline transfer plus an $80,000 processor payout posted by September 30 |
The remaining $13,420 processor payout reaches the bank on October 2. The September difference is therefore a cutoff item, not a missing payment. The team should carry it forward with the payout reference and expected date, then clear it against the October bank entry.
This example also shows why “paid” and “settled” should not be used as synonyms. A paid order tells the registration team that an attendee completed an accepted payment method. A payout is the processor’s net transfer of one or more transactions. A bank posting confirms when that transfer reached the organisation’s account. Each status answers a different question.
Follow the evidence from registration to the bank
Do not begin with two grand totals and try to force them to agree. Start with the records that created those totals. Each record proves one stage of the journey.
| Record | What it proves | Useful reference |
|---|---|---|
| Registration order | What the attendee bought and the order’s current status | Event ID and order ID |
| Invoice or receipt | What the attendee was charged, including tax and discount treatment | Invoice or receipt number |
| Payment transaction | What the processor attempted, authorised, captured or declined | Processor transaction ID |
| Refund or adjustment | Why the original amount changed later | Refund or adjustment ID |
| Payout | Which transactions and deductions formed a net transfer | Payout ID and expected arrival date |
| Bank entry | What the bank received or withdrew and when it posted | Bank reference and posting date |
| Accounting entry | How finance classified and approved the activity | Journal or ledger reference |
Processor exports do not all use the same labels. For example, Eventbrite’s official guidance explains how to export an itemised payout report and which order, adjustment and payout fields it contains. Use the fields your provider actually supplies rather than assuming that every gateway follows the same format.
Build the identifier chain before comparing totals
A reliable reconciliation needs a traceable chain:
Event ID → Order ID → Invoice or receipt → Transaction ID → Refund or adjustment ID → Payout ID → Bank reference → Accounting entry
The chain is rarely one-to-one. One order may have a failed attempt followed by a successful payment. A partial payment may create more than one transaction. One payout usually contains many transactions, refunds and fees. A bank may combine or shorten the payout reference. The person reconciling the period must know which relationships are one-to-one and which are one-to-many.
Keep the transaction date, refund date, payout creation date, expected arrival date and bank posting date in separate fields. Replacing them with one generic “payment date” makes genuine timing differences look like errors.
Offline payments need their own route through the chain. If an attendee pays $4,000 by wire, record the order and the bank reference, but do not expect that amount to appear in the card processor report. For events that take payments across countries or currencies, the international payment workflow may also require settlement-currency and conversion references.
Run conference registration payment reconciliation in two passes
Pass 1: Match orders to payment transactions
First, confirm whether each registration order has the right financial status. Match the order amount and currency to the payment transaction, then separate the results into useful groups:
- Paid online orders with a successful transaction.
- Paid offline orders with bank or cash evidence.
- Pending or partially paid orders.
- Failed attempts that did not create revenue.
- Waived or complimentary registrations with no payment expected.
- Cancelled orders and any related refund.
A paid status without supporting evidence deserves review. It may be a valid manual status for a wire transfer, or it may be an accidental change. A transaction without a corresponding order may point to a duplicate, a deleted order or an integration delay. Do not correct either record until the evidence explains the difference.
Pass 2: Match transactions to payouts and the bank
Next, group successful online transactions by payout ID. Add the deductions and adjustments shown by the processor, calculate the expected payout, and match that payout to the bank reference. Stripe, for example, exposes events for payout status changes; its event documentation illustrates why teams should record status and timing instead of relying only on a static total.
In the fictional example, Pass 1 accounts for $96,000 in online payments and $4,000 offline. Pass 2 explains how $96,000 became $93,420 and then confirms that the payout arrived in two bank postings. The method locates the difference without treating every mismatch as a loss.
Explain the gross-to-net bridge
The bridge should begin with amounts that use the same basis. If the registration report already shows the amount paid after a promotional discount, do not subtract that discount again. If it includes offline payments, remove them before comparing the report with the processor. Treat taxes according to the actual order and processor reports, including who collects and remits them.
For the illustrative conference, the bridge is:
| Step | Amount | Evidence |
|---|---|---|
| Paid registration orders | $100,000 | Registration order export |
| Less offline wire payments | ($4,000) | Payment-method field and bank reference |
| Expected processor gross | $96,000 | Successful online transactions |
| Less refunds | ($1,200) | Refund report and order references |
| Less processor fees | ($1,380) | Payout itemisation |
| Expected processor payouts | $93,420 | Payout A plus Payout B |
Every line needs a source. Eventbrite’s explanation of event payout amounts, for example, shows how ticket sales, fees, refunds, charges and credits can affect the transfer. Your own processor agreement and reports determine the exact bridge.
| Component | Evidence source | Common mistake |
|---|---|---|
| Gross online sales | Successful transaction report | Including failed, unpaid or offline orders |
| Refunds | Refund report | Comparing a later refund with the original sales period |
| Fees | Payout itemisation | Comparing a net payout directly with gross sales |
| Taxes | Order and processor reports | Confusing organiser-remitted tax with processor-remitted tax |
| Reserve | Payout summary and provider notice | Treating a temporary holdback as a permanent expense |
| Offline payment | Registration system and bank evidence | Expecting it to appear in the processor payout |
Keep cutoff and timing differences visible
A payout does not need to arrive before registration closes, and processors do not all follow one timetable. Payout timing depends on the provider, account settings, region, banking days, risk review and any hold or reserve. Use the provider’s stated expected arrival date and the bank’s actual posting date.
At September close in the example, the team can document the position in three lines:
- Cleared: $4,000 offline wire and $80,000 Payout A appear in the September bank statement.
- In transit: $13,420 Payout B has a valid processor reference and an expected arrival date of October 2.
- Unexplained: $0 remains after the evidence and cutoff are applied.
When October 2 arrives, the team matches Payout B to the bank and closes the carried item. If it does not arrive, the status changes from a normal timing difference to an exception that the payment owner must investigate.
Classify exceptions before investigating them
Clear categories keep the team from solving the same problem repeatedly. They also make recurring process failures visible.
| Exception | First check | Evidence that can close it |
|---|---|---|
| Order marked paid, no successful transaction | Manual status change or offline payment | Bank reference, receipt or approved correction |
| Successful transaction, no order | Duplicate, deleted or delayed order | Processor record linked to the restored or corrected order |
| Amount mismatch | Discount, tax, currency or partial payment | Invoice, transaction and adjustment trail |
| Duplicate payment | Repeated successful attempts or duplicate order | Refund record or documented decision |
| Refund missing from payout | Refund status and posting period | Payout line or processor case reference |
| Payout missing from bank | Expected date, bank reference or failed transfer | Bank posting or processor resolution |
| Currency mismatch | Transaction and settlement currencies | Conversion record and any FX fee |
| Offline payment in processor comparison | Payment method on the order | Removal from processor expectation and separate bank match |
Do not hide a difference in a balancing adjustment simply to finish the close. Give each exception an ID, amount, currency, owner, due date, evidence links and final resolution. If an item remains open, record who approved the carry-forward and when the team will review it again. Refund and dispute decisions should follow the event’s documented policy; this refunds, cancellations and chargebacks guide covers that separate control area.
Handle currency, reserves and negative payouts carefully
Multi-currency events need at least three distinct fields: the attendee’s transaction currency, the processor’s settlement currency and the organisation’s accounting currency. Store the original amount, converted amount, rate or conversion reference and any FX fee. Never treat a currency conversion difference as an unexplained shortage.
A processor may also hold a reserve for possible refunds or disputes, or offset a new payout with a negative balance from an earlier period. Record those items using the processor’s own descriptions and supporting notices. A reserve is not automatically a permanent expense, and a negative payout is not automatically connected to the event currently being closed.
If the event accepts several payment methods, separate card, wire, cheque and cash evidence before combining the final accounting view. The practical controls in Dryfta’s guide to digital payments for research conferences can help teams design the payment workflow before registrations open.
Assign the work and close the period
One person may perform several roles in a small conference team, but the responsibilities should still be clear.
| Role | Responsibility |
|---|---|
| Registration owner | Confirms order, attendee and payment-method status |
| Payment owner | Supplies processor transactions, refunds and payouts |
| Reconciliation preparer | Performs the matches and records exceptions |
| Finance reviewer | Checks the evidence, accounting treatment and open items |
| Authorised approver | Signs off the period and any approved carry-forward |
A complete close package usually contains the source exports, gross-to-net bridge, payout-to-bank match, exception register, relevant bank evidence and approval. Save the report dates and filters so another reviewer can reproduce the result. Keep unresolved items visible until the evidence closes them.
Limit the data in the package to what the review requires. Do not store full card numbers or unnecessary attendee details. The PCI Security Standards Council explains that sensitive authentication data must not be stored after authorisation, even when encrypted, in its official guidance. Follow the organisation’s accounting, tax, audit, privacy and retention policies, and ask qualified advisers about requirements specific to its jurisdiction.
Where Dryfta fits in the evidence chain
Dryfta helps conference teams organise the registration side of the evidence chain: attendee orders, ticket selections, payment status and the records used to manage registration activity. That gives the registration and finance teams a clearer starting point when they review paid, pending, waived, cancelled and offline orders.
The processor, bank and accounting system still supply their own evidence. Dryfta does not replace the payout report or bank statement; it helps the team connect those records to the registrations that created them. Organisers evaluating the workflow can review Dryfta’s event registration and ticketing tools. Teams that are still selecting a payment setup can also read this guide to accepting event payments.
Questions conference teams ask
Why does registration revenue not match the processor payout?
The registration total may include offline payments, while the processor total does not. Refunds, fees, taxes, reserves, disputes and adjustments can also reduce or delay the payout. Compare amounts on the same basis and use the payout itemisation to explain each difference.
What is the difference between a payment and a payout?
A payment is an attendee transaction linked to an order. A payout is a net transfer from the processor to the organiser that may contain many payments, refunds, fees and adjustments. The payout schedule depends on the provider and account; it does not necessarily wait until registration closes.
How often should a conference reconcile registration payments?
Choose a cadence that matches the event’s volume and risk. A team may review exceptions weekly during normal sales, more often near high-volume deadlines, and again at month-end and after the event. The important control is that each period has a named preparer, reviewer and follow-up date.
How should offline payments be handled?
Mark the payment method clearly on the registration order and retain the appropriate receipt or bank reference. Remove offline amounts from the expected processor gross, then reconcile them directly to their own bank or cash evidence.
Who should approve an unresolved difference?
The organisation should assign an authorised finance owner or approver in advance. That person should review the amount, evidence, proposed treatment, owner and due date. Approval does not erase the item; the exception remains open until a later payout, bank entry or documented correction closes it.
When the numbers do not match, ask five questions
- Are the registration, processor and bank reports covering the same dates and currencies?
- Did the registration total include offline, pending, failed, waived or cancelled orders?
- Which refunds, fees, taxes, reserves or adjustments changed the processor payout?
- Which payouts had reached the bank at the reporting cutoff, and which were still in transit?
- Does every unresolved amount have an owner, evidence trail, due date and approver?
These questions turn a vague shortfall into a traceable set of records. The goal is not to make three different reports show the same gross number. It is to explain, with evidence, how the value moved from registration to payment, payout, bank and accounting.
Request a Dryfta demo to see how the platform can keep the registration side of that evidence organised for your conference team.
