Event ticketing in Excel: a ticket sales and check-in spreadsheet that works, where it breaks, and what replaces it

Plenty of events are sold out of a spreadsheet. A ticket sales sheet fed by a form or a payment link, a guest list printed for the door, a running count of how many seats are left. For a single event with a few hundred tickets and one person handling the sales, it works — and it costs nothing, where a ticketing platform takes a fee on every ticket.

A ticket is not like stock on a shelf, though. It is admission to one night, and it is tested all at once, at the door, by a queue. The spreadsheet that was fine for three weeks of sales can fall apart in the twenty minutes before doors open, and it falls apart in the same five places every time.

This is the honest version: an event ticketing spreadsheet structure that is worth copying, exactly where each part of it fails, and what your options are when it does.

The ticket sales spreadsheet worth copying

Most free ticket sales templates are one sheet with one row per buyer: name, email, number of tickets, paid. That works until someone buys four tickets and their friends arrive separately, or asks for a refund on one of the four. Start from the ticket, not the buyer.

Sheet 1 — Events. One row per performance or date.

Sheet 2 — Ticket types. What you sell, at what price, and how many.

Sheet 3 — Orders. One row per purchase, with how it was paid and where.

Sheet 4 — Tickets. One row per ticket, each with its own code and state. This is the sheet that matters.

State is Valid, Used, Refunded or Void. A refund changes the ticket's state; it never deletes the row.

Sold and remaining are then derived, never typed:

Sold      = COUNTIFS(Tickets[Event], event, Tickets[Type], type, Tickets[State], "<>Refunded", Tickets[State], "<>Void")
Remaining = Quantity - Sold
Checked in = COUNTIFS(Tickets[Event], event, Tickets[State], "Used")

The one-row-per-ticket design is the whole point. It lets a group arrive separately, lets you refund one ticket out of four, and gives the door something specific to check: a code that is valid exactly once.

Where it breaks

1. Two channels sell the last seats

Online sales come in through a form or payment link, and someone sells tickets at the box office or on the door. Each one checks the remaining count, sees three seats left and sells them. Nothing reserves a ticket between being checked and being sold, and nothing makes two channels wait for each other. On a busy evening you oversell, and you find out at the door.

2. The door is a queue, not a spreadsheet

Checking people in by searching a spreadsheet on a phone takes twenty seconds a person. A queue of three hundred people at twenty seconds each is an hour and forty minutes. Worse, a screenshot of a ticket can be shown twice, by two people, at two different doors. Checking in has to mark a ticket used once, and the second attempt has to be refused, instantly, with a reason the person on the door can act on.

3. The venue Wi-Fi goes down at 18:55

Doors are exactly when the building's connection gives up, because everyone in the queue is on it. A shared spreadsheet that cannot load cannot check anyone in. So the door falls back to a printed list, and the printed list does not know which tickets were refunded this afternoon.

4. A refunded ticket still gets in

Someone asks for a refund on Thursday. You refund the payment and mean to update the sheet. The printed door list was made on Wednesday. On Saturday, the refunded ticket is scanned in, and on the Monday the buyer disputes a charge they have already been refunded for. Refunds, cancellations and postponements have to change the ticket itself, everywhere the ticket is checked.

5. Seats, not just tickets

The moment the venue is seated — rows, tables, sections — "how many are left" is the wrong question. The question is which seats are left, and a spreadsheet cannot stop two people being sold row F, seat 12. Reserved seating needs a seat map where each seat can be held while someone pays, sold exactly once, and released if the payment fails.

What a real one has that a spreadsheet doesn't

We keep a hand-counted inventory of what ticketing and box-office products actually ship, built from 100 products:

Two rows are worth reading closely. Check-in is near the top — 84 of 100 — because admission is the moment a ticket actually does its job; that is failures 2 and 4. And offline scanning is at the very bottom, at 7 of 100. Failure 3 happens at almost every busy venue, yet very few products say publicly how they handle it. If your doors lose signal, ask any product you are considering exactly what happens to a scan with no connection, and how it is reconciled afterwards.

Your three options, honestly

Keep the ticketing spreadsheet

Correct for a single event of a few hundred people with one sales channel and one person running it. Use the one-row-per-ticket structure above, freeze sales an hour before doors, and print the door list from the ticket sheet after the freeze, not before.

Stop when you sell through more than one channel at once, when you need reserved seats, or when the door queue is longer than your patience.

Buy software

Correct for most events. A ticketing platform handles the payment, sends each buyer their tickets, stops two channels overselling, and gives the door a scanner. The trade is the fee on every ticket, and on cheap tickets the fee is a large share. Compare the per-ticket cost at your actual price, and check who owns the attendee list — you or the platform. Free event ticketing software covers each kind of free and six tests to run before the doors open.

Build it

A coding agent can build a ticketing system in days. It will build the event page and the checkout first, because those look like any online shop. What makes ticketing different is everything after the sale: a ticket valid exactly once, admission that works with the Wi-Fi down, a refund that changes what the door sees, and seats that cannot be sold twice. When four AI models built the same ticketing spec, the board was scored on three of them: whether the last seat can be sold twice, whether a refunded ticket still gets in, and whether the door can tell a duplicate from a valid entry.

If you build it, build these first

1. One record per ticket, with a state — valid, used, refunded, void — so a refund or a scan changes the ticket itself.
2. Inventory that cannot be oversold, across every channel, with a hold while someone is paying.
3. Check-in that admits a ticket once, refuses a second scan with a clear reason, and is fast enough for a queue.
4. Scanning that keeps working offline, and reconciles cleanly when the connection comes back.
5. Refunds, cancellations and postponements that change the ticket, everywhere it is checked.

Reserved seating, season passes, presale codes and door sales are real scope, and worth adding once the admission path is right.

---

If you are building with a coding agent, the Event Ticketing planner is the spec we hand ours: the ticket lifecycle, admission and the refund path, written so an agent cannot quietly build a shop and call it a box office.