# Sales and Attendees (/docs/live-events/sales-and-attendees) Every published event keeps a running picture of two things: how the inventory is moving (sold, held, still available, per ticket type) and how much money the event has actually taken. Alongside that sits the attendee list, one row per issued ticket, which is what you print or hand to the door. All of it is scoped to your own organization. An event belonging to another organizer returns nothing. Per Ticket Type [#per-ticket-type] Each [ticket type](/docs/live-events/tickets-and-add-ons) on the event reports its own numbers, in the order the types are arranged on the event: | Number | What it counts | | ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | **Price** | The type's current list price. | | **Total** | The capacity you set for that type. | | **Sold** | Tickets sold out of that capacity. This is the authoritative inventory count. | | **Held** | Seats currently reserved by shoppers who are mid-checkout. Only live holds count: expired holds and abandoned carts are excluded automatically. | | **Available** | What a buyer can still purchase right now, calculated as total minus sold minus held. It never goes below zero. | | **Gross revenue** | The type's list price multiplied by the number sold. | The per-type gross is a list-price figure, useful for comparing tiers against each other. It is not the money that reached your account: it does not account for refunds, service fees, or taxes. For the real money, use the event totals below. **Held is temporary.** A tier can read as unavailable simply because a few shoppers are in checkout. Those seats return to available on their own when the holds expire, so do not treat a temporary zero as a sellout. Add-ons report a shorter set: name, price, how many were sold, and the capacity if the add-on has one. Add-ons with unlimited stock have no total. Event Totals [#event-totals] | Total | What it means | | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Total capacity** | The sum of every ticket type's capacity. | | **Total sold** | The sum of every ticket type's sold count. | | **Gross revenue** | Everything buyers were charged, across paid, partially refunded, and fully refunded orders. It is the full order amount, so it includes service fees and taxes. | | **Refunded amount** | The sum of all refunds that actually completed on this event's orders. | | **Net revenue** | Gross revenue minus the refunded amount. This is what the event took, after giving money back. | | **Platform fees** | The Resytech platform fee charged on those same orders. See [Fees and Payouts](/docs/live-events/fees-and-payouts). | | **Paid orders** | The count of orders that were charged and not fully refunded. Partially refunded orders are included here. | | **Refunded orders** | The count of orders with any refund against them. Partially refunded orders are included here too. | Two things follow from those definitions, and both surprise people: * **A partially refunded order is counted in both order counts.** It is still a paid order (you kept part of the money) and it is also a refunded order (you gave part of it back). Adding the two counts together will overstate your order volume. * **Orders still in checkout are counted nowhere.** An order that has not completed payment contributes nothing to revenue and nothing to either order count. It may briefly hold seats, which shows up in the per-tier held number instead. The event's current status (draft, published, cancelled, and so on) is reported alongside these totals, so a report always says which state the numbers are from. Refunded Seats Stay Sold [#refunded-seats-stay-sold] This is the most important nuance in the whole picture: **refunding an order does not return its seats to the pool.** A refunded ticket is marked refunded and stops working at the door, but the sold count for its ticket type does not go down and the seat does not become available for a new buyer. Sold plus available therefore never exceeds capacity, and the numbers never wobble because of refund activity. What that means in practice: * **Sold** is best read as "seats issued", not "seats that will walk through the door". If you refunded ten of a hundred sold, expect ninety attendees. * **A refund does not reopen a sold-out event.** If you want those seats back on sale, raise the ticket type's capacity by the number you refunded. * Money and inventory move independently. The refunded amount and net revenue reflect the refund immediately, while the sold count does not move at all. The attendee list is where you see the difference: a refunded ticket is still in the list, flagged with a refunded status. The Attendee List [#the-attendee-list] The attendee list is one row per issued ticket, in the order the tickets were created. Each row contains: | Field | Notes | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Attendee name** | The name captured for that specific ticket. When per-attendee details were not collected at checkout, this falls back to the buyer's name, so every row always has a name. | | **Attendee email** | Same rule: the ticket's own email, falling back to the buyer's email. | | **Ticket type** | The tier the ticket was bought on. | | **Status** | Valid, checked in, refunded, or voided. | | **Checked in at** | When the ticket was admitted at the door, or empty if it has not been used. On a multi-day event this is the first admission, not the most recent re-entry. See [Door Check-In](/docs/live-events/check-in). | | **Buyer name and email** | Who paid, along with the order the ticket came from. | Because of the buyer fallback, a four-ticket order bought by one person with no attendee details shows four rows with that buyer's name on each. That is expected: the rows are admissions, not distinct people you have identified. The list contains no QR codes. Admission codes exist only in the buyer's confirmation email and are deliberately kept out of every organizer-facing view. What You Can See in the Dashboard Today [#what-you-can-see-in-the-dashboard-today] The event page shows part of this picture: * The event header shows **sold out of total capacity** for the whole event. * The **Tickets** tab shows each ticket type's sold count against its capacity, and each add-on's sold count against its capacity. * The **Orders** tab lists the event's orders with buyer, status, total, and ticket count, and opening an order shows its line items and each ticket's type, attendee name, and status. The full sales summary (gross, refunded, net, platform fees, order counts, held and available per tier) and the complete attendee list are produced by the server and available through the Resytech API, but they do **not** yet have their own screens in the dashboard. Until they do, use the Tickets tab for inventory, the Orders tab for money and attendee names, and the API for anything you need to export. Both are read-only and require the `events` permission. Related [#related] * [Orders and Refunds](/docs/live-events/orders-and-refunds) * [Door Check-In](/docs/live-events/check-in) * [Ticket Types and Add-Ons](/docs/live-events/tickets-and-add-ons) * [Fees and Payouts](/docs/live-events/fees-and-payouts) * [Live Events overview](/docs/live-events)