Event Registration Reports: Track Registrations, Revenue, and Check-Ins Without the Spreadsheet
Most event registration reports start as a CSV export and end as a spreadsheet nobody trusts. Here is how a report center with built-in reports and a custom report builder answers the questions your team actually asks, before, during, and after the event.
Most event registration reports begin the same way: someone exports a CSV, opens it in a spreadsheet, adds a filter, builds a pivot table, and emails a screenshot to the board. Two days later the numbers are stale, nobody remembers which filter was applied, and the finance lead is asking why the revenue figure does not match the bank deposit. The problem is not that your team lacks data. The problem is that the data is trapped inside a registration tool that only knows how to export it. This post walks through what a proper report center looks like inside your event registration software, what the built-in reports should answer out of the box, and when you should build a custom report instead.
Why event registration reports usually fail
Registration data has three audiences with three different questions, and a single export rarely serves any of them well.
Your operations team wants to know who is coming, which ticket they bought, which group they belong to, and whether they have checked in. Your finance team wants to know what was charged, what the processor took, what you refunded, and what you actually keep. Your leadership or board wants to know how this event compares to the last one, and whether registrations are tracking ahead of or behind plan.
When all three questions are answered from the same spreadsheet, you get a familiar set of failures:
Failure | What it looks like | Why it happens |
|---|---|---|
Stale numbers | The board deck says 412 registrations, the platform says 438 | The export was pulled on Tuesday, the deck was presented on Friday |
Mismatched revenue | Finance's total does not match what landed in the bank | Gross charges, processor fees, service fees, and refunds are all mixed into one column or missing entirely |
Lost context | Nobody can reproduce last month's report | The filters and column choices lived in someone's head, not in the tool |
Duplicate effort | Three people build three versions of the same roster | There is no shared, saved report the whole team can open |
Hidden data | Custom question answers never make it into the report | The export only includes standard fields, so T-shirt sizes and dietary needs get re-collected by email |
None of these are spreadsheet problems. They are symptoms of reporting living outside the system of record. The fix is to move reporting inside the registration platform, where the data is live, the filters are saved, and everyone on the team opens the same report.
What a report center should include out of the box
A report center is the single place in your event registration software where every report lives, both the ones the platform provides and the ones your team builds. In Sunfish Events, the Report Center is available at the organization level and inside each event.
The built-in reports cover the questions nearly every planner asks, grouped by the job they do:
Registration reports show everyone who started or finished registering, with their status, group, ticket, and payment. This also includes a view of people who started registering and left without finishing, with whatever information they typed before they left.
Attendance reports show who has checked in, when and where, and who has not shown up yet.
Finance reports cover the order ledger (every paid and refunded order, including later changes to a registration like an add-on being added or removed), revenue broken down by ticket, add-on, and session package after waivers, credits, discounts, and refunds, and discount code usage showing how often each code was used, on how many orders, and how much it took off.
Overview reports put every event side by side with registrations, net revenue, and check-ins.
You do not turn these on. They are there for every organization and every event from day one. The set will grow over time, so treat the list above as a starting point rather than a ceiling.
Every built-in report shares the same working surface, which matters more than the report list itself:
Control | What it does |
|---|---|
Search | Find a person, order number, event, or buyer by typing part of it |
Filters | Narrow by status, date range, payment status, event, and other fields relevant to that report |
Summary tiles | Headline numbers at the top that change with the report type (people, complete, and cancelled on a roster; orders, charged, processor fees, service fees, and refunds on a ledger; units, list price, item net, and waivers on a revenue report) |
Chart by | Turn the filtered rows into a chart by a dimension such as group, ticket, event, payment status, or placed date by week or month, with an optional second dimension to split each bar |
Columns | Show, hide, and reorder columns, with a one-click reset to the default layout |
Save view | Save your current filters and columns under a name so it appears on your organization's Reports page for the whole team |
Export | Download the current rows as a CSV, with the row count shown on the button before you click |
The data behind all of this is live. There is no refresh schedule and no overnight sync. If a registration completes while you are looking at the roster, the next time you load the page it is there.
Org-level versus event-level reporting
The same reports exist in both places. The difference is scope.
At the organization level, every report spans all of your events, and you choose which events to include. You can select one event, several, or leave the filter open to see everything. This is where the overview report lives, and it is the right place for questions like "how did our spring conference compare to our fall summit" or "which discount codes have we used across the whole year."
Inside an event, the Report Center shows the same reports already filtered to that event, with the event selector hidden because it would be redundant. This is where your on-site team works during the event: the attendance report for check-in status, the roster for a quick lookup, the ledger for a refund question at the registration desk.
Here is how the two levels split the common jobs:
Question | Where to answer it |
|---|---|
Who has not checked in yet for today's workshop? | Event level, attendance report |
What did this event net after fees and refunds? | Event level, order ledger |
How many registrations did each of our chapters' events draw this quarter? | Org level, overview report filtered to those events |
Which ticket types sell best across all our conferences? | Org level, revenue by item, charted by event and ticket |
Who registered for both the annual meeting and the regional summit? | Org level, roster filtered to both events |
How much revenue did the "EARLYBIRD" code remove across the year? | Org level, discount code usage |
Saved views work the same way. A report you save at the organization level shows up on the organization's Reports page for everyone on your team. Saving a filtered built-in report does not change the original. The built-in report stays as it was and your saved version sits beside it.
When to build a custom report instead
Built-in reports answer the common questions. Custom reports answer yours.
The custom report builder in Sunfish Events starts with one decision: what does each row represent? You pick a source, and that choice determines every field available to you.
Source | One row per | Best for |
|---|---|---|
Attendees | Registration, started or finished | Rosters, badge lists, check-in sheets, anything about people |
Orders | Paid or refunded order | Reconciliation, refund audits, what each buyer was charged |
Order lines | Item on an order, with its units and money after waivers, credits, discounts, and refunds | Revenue by product, add-on performance, session package uptake |
Discount uses | Time a code was applied to a confirmed order | Promo attribution, partner code tracking |
Once you have a source, the builder shows every available field grouped by where it comes from: attendee details, ticket, group, buyer, payment, and your own registration questions. You check the columns you want, drag them into the order you want, and the preview table updates as you go.
If you do not want to start from a blank slate, you can copy a built-in report instead. The copy opens in the builder with the original's columns and filters already in place, and the original stays untouched.
Filters in the builder work the way you would expect from a modern data tool. Text fields support "contains." Single-choice fields such as status or payment status let you check multiple values at once, so you can show paid and partially refunded orders together and leave fully refunded ones out. Question fields support "is," "has a value," and "has no value," which is how you find everyone who skipped the dietary question before the catering deadline.
A few examples of reports that are easy to build and hard to get from a generic export:
Badge print list for one session track. Source: Attendees. Columns: first name, last name, company (from your registration question), ticket. Filter: status is Complete, ticket is one of the three tickets that include that track. Save it, and the on-site team reopens it the morning of the event.
Catering count by meal choice. Source: Attendees. Chart by your "meal preference" question. The summary tile gives you the headcount, the chart gives you the breakdown by option, and you never touch a pivot table.
Sponsor-code attribution. Source: Discount uses. Columns: code, order, event, amount taken off. Filter: code contains your sponsor's prefix. Export the CSV and send it to the sponsor as proof of value.
Add-on revenue after refunds. Source: Order lines. Filter to your workshop add-ons. The item net tile shows what you kept after waivers and refunds, not the gross number that overstates reality.
Every custom report can be reopened and edited. When you make changes, you choose whether to save them to the existing report or save them as a new one, so a shared report does not get silently rewritten under someone else.
Your custom registration questions are real columns
This is the part that usually separates a registration tool's reporting from a real report center. Every question you ask during registration, whether it is a job title, a T-shirt size, a session preference, a waiver acknowledgment, or a free-text "anything else we should know," is available as a column and as a filter in the custom report builder.
That means the question you added to the form on Tuesday is reportable on Wednesday without anyone mapping fields or rebuilding an export template. It also means the data you collected to make the event better actually gets used to make the event better, rather than sitting in an export nobody opens.
A practical pattern for associations and chapter-based organizations: build one attendee report per operational need (catering, badging, accessibility, CE credit eligibility), each filtered on the relevant question, and save them at the organization level. Then every event inherits the same reports, already scoped to that event, and the chapter coordinator who has never logged into the platform before can open "Catering counts" and get a number.
Finance reports that reconcile with your bank
Finance teams distrust event revenue numbers for a reason. A "total sales" figure that ignores fees and refunds is not a number anyone can reconcile.
The order ledger in Sunfish Events shows every paid and refunded order with the amount charged, the processor fees, the service fees, the refunds, and what you keep, each as its own column and its own summary tile. Processor fees and service fees are shown separately rather than rolled into one line, so your controller can match the processor statement without reverse-engineering a blended number.
The ledger also records later changes to a registration as their own rows. If an attendee adds a workshop after their initial purchase, or removes one, that shows up as a change against the original order rather than disappearing into an adjusted total. Chart the ledger by placed date or paid date, by week or by month, and you have a cash timing view without building one.
Revenue by item does the same job one level down. Each ticket, add-on, and session package is shown with its units, list price, and item net after waivers, credits, discounts, and refunds. The gap between list price and item net is the number that tells you whether your discount strategy is working or just expensive. If you want to go deeper on that question, the post on using discount codes to drive event registrations covers how to structure codes so that the gap is intentional.
Building the post event report from live data
The post event report is where most teams feel the spreadsheet pain hardest, because it needs numbers from every part of the event at once: registrations, attendance, revenue, and comparison to the last event.
With a report center, the post event report is mostly assembly rather than analysis:
Registrations. Open the roster at the event level. The summary tiles give you total people, completed registrations, and cancellations. Chart by ticket to show the mix.
Attendance. Open the attendance report. You get who checked in and who did not, which is your show rate without a calculator.
Revenue. Open the order ledger for the net figure, then revenue by item for the breakdown by product. Both already account for fees and refunds.
Incomplete registrations. The abandoned carts view shows how many people started and did not finish, and what information they left behind. If that number is higher than you expected, the post on the abandoned cart email most organizers forget to send is a good next read.
Comparison. Go up to the organization level and open the overview report with this event and the previous one selected. Registrations, net revenue, and check-ins sit side by side.
Each of those steps is a saved view if you want it to be. Save them once, name them clearly, and the next post event report is five clicks.
If your reporting needs to leave the platform, the CSV export covers the hand-off, and the Zapier integration covers sending registration data to the tools your team already uses as registrations happen rather than after the fact.
FAQ
Can everyone on my team see saved reports, or only the person who created them?
Everyone in the organization can see saved reports. A view saved from a built-in report or a report built in the custom builder appears on the organization's Reports page for the whole team. There is no per-user hiding.
Is the data in reports real-time?
Yes. Reports read live data. There is no sync schedule or overnight refresh, so the numbers you see reflect what is in the platform when you load the page.
What format can I export?
CSV. The export button shows the number of rows it will include based on your current filters before you click it. Charts are on-screen only and are not included in the export.
Key takeaways and next step
Event registration reports fail when they live in a spreadsheet instead of in the system of record. A report center fixes that in three ways: built-in reports that answer the common operations, finance, and overview questions without setup; a custom report builder that starts from a clear row definition and treats your registration questions as first-class columns; and the same reports at the organization and event level so your central team and your on-site team are looking at the same numbers.
If your current platform's answer to "can I see that broken down by ticket type" is "export it and pivot," that is a sign reporting was bolted on rather than built in. Sunfish Events includes the Report Center for every organization on simple, transaction-based pricing with no multi-year contract. You can set up an event and open your first report in an afternoon. If you would rather see it with your own data first, book a short demo and bring the spreadsheet you are trying to retire.
Share
