Running registration to attendance reconciliation as a numbered ledger every year

Somebody on the board asked a show director why 38,200 people registered and 26,500 came, and whether the missing 11,700 were a marketing problem or a data problem.

He did not know. Neither did anyone in the room. The registration total came from one system, the attendance total came from another, and the difference had never been decomposed into anything, because nobody had ever been asked to.

The honest answer, which took three weeks to assemble and should have taken twenty minutes, was that about a third of the gap was not people failing to turn up at all.

What shape should a registration to attendance reconciliation take?

Finance solved this problem a long time ago and the solution is a shape rather than a technique.

A bank reconciliation opens with the balance per the statement, applies a numbered list of adjustments each with its own evidence, and closes on the balance per the books. Nobody argues about whether the two balances should match, because the reconciliation is the argument, written down, line by line.

Registration to attendance has exactly that structure. Open with registrations created in the registration system. Apply the adjustments. Close on the reported attendance figure. Every line is a population with a sign in front of it, and the total is not allowed to be a plug. Each of those populations needs the same four slots as any other metric definition: population, filters, time window, source system.

The discipline this imposes is that the closing figure stops being a separate measurement that happens to differ from the opening one. It becomes a derived number with a visible path behind it, which is the only form in which anybody can challenge a single component instead of the whole thing.

Eight lines and a running balance

Here is the ledger for the show above.

1. Registrations created, all registrant types: 38,200.
2. Less cancellations and withdrawals recorded before show open: 1,900, leaving 36,300.
3. Less duplicate registrations collapsed into an existing person: 1,150, leaving 35,150.
4. Less registrations that never produced a badge, being incomplete, unpaid or rejected at vetting: 940, leaving 34,210.
5. Less no shows, meaning a badge was issued and produced no scan of any kind: 12,400, leaving 21,810.
6. Plus registrations created on site during show days: 2,600, giving 24,410.
7. Plus complimentary and guest badges issued on site: 1,180, giving 25,590.
8. Plus exhibitor-supplied guest passes redeemed at the door: 910, giving 26,500.

The closing figure is the reported attendance, 26,500, and it is now a number with a derivation instead of a number from a different system.

Read the composition off the ledger. Pre-registered attendees are 21,810 of 26,500, which is 82.3 per cent. On-site registrations are 2,600, which is 9.8 per cent. Complimentary and guest badges are 1,180, or 4.5 per cent. Exhibitor guest passes are 910, or 3.4 per cent. Those four sum to 26,500, and the percentages sum to 100.

The no-show line is the one that gets misread

Line 5 is where the board's question was really pointed, and it needs a denominator stated with it.

12,400 no shows against the 34,210 people who actually held a badge is 36.2 per cent. Quoting it against the 38,200 opening figure would give 32.5 per cent, which is a different and softer number describing a population that includes people who cancelled and people who never completed registration.

For a sense of scale, PheedLoop's Event Data Lab Report #06, published in May 2026, analysed more than 860 events holding both registration and check-in data and found median no-show rates running from roughly 17 per cent to 29 per cent depending on the registration completion band, and among paid events found the rate essentially flat at 16 to 19 per cent whatever the completion rate. Its conclusion is that registration friction does not independently predict attendance, and that whether the event charges is what explains most of the apparent relationship.

At 36.2 per cent this show sits above those bands, which is a finding rather than an embarrassment. A free-to-attend trade show with a long registration window will run higher than a paid conference, and knowing by how much is what makes the next conversation useful. Sizing the effect on your own file also stops somebody trying to fix the no-show rate by adding friction to the form, which that report suggests will change the registration count and leave attendance where it was.

Every line needs a source system and an owner

A ledger with eight numbers and no attribution is a slide. A ledger with eight numbers, eight source systems and eight named owners is a control.

Lines 1 to 4 come from the registration platform and belong to whoever runs registration. Line 5 comes from the access control feed joined to the badge table and belongs to operations, because operations is the team that can tell you a reader was down for forty minutes on day two. Line 6 comes from the on-site registration terminals, which are often a different product from the pre-registration platform even when the supplier is the same, and that difference is where a reconciliation usually breaks. Lines 7 and 8 come from the badge production log and the exhibitor portal respectively, and both are usually owned by nobody, which is why they are the two lines most often missing entirely.

Write the owner's name, not the team's. A team cannot be asked why line 7 moved. Named owners also hand you the rows for a definition diff the next time two teams arrive with two attendance figures.

The other benefit of naming owners is that it exposes the lines you cannot currently produce. Most organisers running this for the first time discover that they cannot separate line 3 from line 5, because duplicate registrations and no shows look identical in the data: both are records with no scan. Splitting them needs deduplication before the ledger runs, which turns on the key you count distinct on, and until you can do it your no-show line is overstated by however many duplicates you have.

What do you do when the ledger does not balance?

The first time you run this, it will not balance. Expect a residual of a few hundred and resist the two things everybody does with it.

Do not add a line called other. An adjustments line absorbs the residual, the ledger balances, and you have converted an unanswered question into a permanent feature of the report. Next edition it will be bigger, because nothing was ever fixed, and by the third edition somebody will be defending a line nobody can explain.

Do not force the closing figure either. If the ledger lands on 26,340 and the access control system says 26,500, publishing 26,500 with the ledger arriving somewhere else means the ledger is decorative.

Instead, carry the residual as a named unreconciled line with its own value and a note saying what you think is in it. 160 rows, suspected on-site terminal records that failed to upload. That line is a work item with a number attached, and it will usually shrink to zero within two editions because somebody now owns it.

The sign convention matters too. Every line is either a subtraction from the pre-registered population or an addition of a population that was never pre-registered. A line that could plausibly go either way, exhibitor guest passes issued in advance and redeemed on site being the common one, has to be assigned to a side and kept there, or the ledger will double count it the year a different person builds it.

Run it identically every year, or do not bother

The ledger's value compounds. One edition tells you the composition of your gate. Five editions tell you which line is moving, and that series is worth more to your attendee analytics than the headline it produces.

That only works if the line list is fixed. Adding a line, merging two, or changing what counts as a cancellation makes the series incomparable, and the fix is the same one D2 sets out for the report as a whole: a numbered line list that belongs to the series, with a changelog entry and a restated prior figure whenever a line changes.

The CEIR Index, published through IAEE, tracks professional attendance as one of its four components, alongside net square feet of exhibit space sold, number of exhibiting companies, and gross revenue. In CEIR's second quarter 2025 results, attendees sat 3.7 per cent below their Q2 2019 level while real revenues sat 15.6 per cent below. A single attendance number placed against a benchmark like that tells you where you stand. Only the ledger tells you which line moved to put you there, and whether the movement was in the pre-registered population, the walk-up population, or the comp list.

I have seen a show hold its headline attendance flat for three editions while pre-registered attendance fell 8 per cent and comps rose to cover it. Nothing in the headline showed it. The ledger showed it on line 7 immediately.

Where this stops

The ledger reconciles counts. It cannot tell you whether the counts are complete.

Line 5 assumes that no scan means no attendance, and that is only true where scan coverage is close to total. If a side entrance has no reader, everybody who used it lands in your no-show line and your attendance figure is low by that population. The reconciliation will still balance perfectly, because both sides of the error sit inside line 5. Balance is not accuracy, and this is the specific way a ledger can be internally consistent and wrong. Tagging each counted person with the evidence behind them is the check that catches it.

The second limit is that the ledger only ties out at a moment in time. Registration data keeps settling for weeks after a show closes: late cancellations get processed, on-site terminal data gets uploaded, exhibitor guest pass records arrive. A ledger run on day three and a ledger run on day thirty will produce different totals, and neither is wrong. Pick a freeze date, run it once, and publish that version, which is the argument a post show data freeze date makes properly.

Build the eight lines for your last edition using whatever data you can get in a day, and leave the lines you cannot produce as blanks with a name against them. The blanks are the useful output. They are the list of things your reporting cannot currently see, and every one of them is currently sitting inside your no-show number.