It is a Saturday in October. Nine birthday parties are on the books, two corporate groups come in at six, and the lobby is full of walk-ins who booked nothing. At close, your booking system says the day was worth one number and your POS says it was worth another, and neither of them is wrong.
This is the gap. It is not a bug in either product, and a better export will not fix it. Bookings and sales are different kinds of record, and most FEC stacks ask you to reconcile them by hand every night.
Operators of small multi-attraction venues name the booking system as their biggest bottleneck more often than the POS. Worth understanding why before you go shopping.
Why Do Bookings And Sales Never Tie Out?
Because they are not the same kind of thing, and matching them as if they were is what fails.
A booking is a claim on future capacity. It holds a resource — a lane, an arena, a party room — for a window of time that has not happened yet. It can move, shrink, grow or evaporate, and until the guests walk in it has produced no revenue at all.
A sale is a completed exchange. It happened at a moment, it is final, and it never changes shape.
Different lifecycles, different moments of truth. A booking system answers "what is available at two o'clock next Saturday." A POS answers "what did we sell today." Neither question contains the other, which is why no amount of exporting makes the totals agree.
The industry compounds this. Booking platforms handle parties and resource allocation well, and many integrate cleanly with the arcade card vendor. What almost none handle is walk-in and pass buyers in concert with party bookings — a different structure that still has to tie to the same floor, the same staff and the same day's revenue.
Where Does The Gap Actually Open?
In five places. Each is a reconciliation problem of its own, and knowing which you have tells you how big your project is.
The deposit. Money arrives weeks before the party — cash today, revenue on a date that has not arrived. The booking system records a payment; the POS records nothing, because nothing was sold. Both are correct, and your daily sales number is ambiguous until someone decides which system owns it.
The package. A party package is one line in the booking system and six things on the floor — arena time, pizza, drinks, arcade credit, a host, a goodie bag. Sold as one SKU, consumed as many. If it never breaks into components, your food cost, arcade usage and labour all sit inside one opaque line.
Walk-in against booked capacity. The same attraction is being sold twice, by two systems, to two kinds of buyer. Unless exactly one of them owns the capacity calendar, you will either oversell a lane or hold slots that nobody takes.
The change. Parties move dates, drop from twelve kids to eight, add a lane, or do not show up. A sale never does any of those things, and every change is a place two systems drift apart quietly.
The third system. The arcade or card vendor your booking system talks to and your POS does not, or the reverse. Whichever side lacks that link cannot answer anything about the full visit. The same tangle is covered in why FEC tech stacks end up with six systems.
What Does "It Integrates" Have To Mean?
Every vendor says the word. It is worth five specific questions, because "integrates" covers everything from a real-time two-way sync to a nightly CSV someone imports by hand.
- Which system owns capacity? Exactly one should. If both can book the same lane, you have not integrated anything, you have duplicated it.
- Where does a deposit land? It should sit as a liability until the party happens and move to revenue on the day it is consumed. If the answer is "it shows as a sale when we take it", your month-end will never be clean.
- Does a package break into its parts? At the point of consumption, one booked package should become the food, the play time and the credit it contained.
- What happens when a booking changes? Ask the vendor to walk you through a party that moves from Saturday to Sunday and drops four guests. Count how many places a human has to retype something.
- Can you get one day's total in one place? Booked and walk-in, food and attractions, without exporting two files and joining them in a spreadsheet.
That last one matters most for a small venue. Operators describe reporting where every number is technically present but extracting it implies hiring someone — a cost a lightly staffed FEC cannot carry. A manager dashboard that needs an analyst is not a dashboard.
Can You Close The Gap Without Replacing The Booking System?
Often, yes — and usually the right first move, because the booking system is frequently doing the most specialised work.
Start by naming the system of record for each number rather than making both agree. Which owns gross sales, which owns deferred revenue, which owns capacity. That decision costs nothing and ends most of the nightly argument; the method is in when your two sales reports disagree.
Then make the integration push rather than depend on staff. Any step where a host retypes a booking into the POS fails on your busiest Saturday, which is the day the numbers matter most.
Then explode packages at consumption, so the party's food lands in food and its play lands in play.
And accept a reconciliation line instead of chasing zero. Deposits taken, deposits consumed and bookings changed are legitimate reasons for two reports to differ. Written down, they stop being a monthly mystery.
Who Does This Operational Approach Fit Best?
Unifying bookings and POS pays off most in venues with a real party or event business alongside walk-in trade. If a meaningful share of revenue is committed before the guest arrives, you already have the gap, named or not.
It fits especially well in multi-attraction venues with a small back office, where nobody has the hours to assemble the day by hand and there is no analyst to hire. An entertainment commerce platform earns its place here by removing the join rather than by adding a report.
It fits poorly in pure walk-in venues, where there are no forward commitments and so no gap to close. And it is premature anywhere you cannot yet say which system owns capacity — a policy decision rather than a software one, and no integration will make it for you.
Want to see what one system covering bookings and sales would look like on your floor? Request a demo, or start with the complete FEC technology stack. It is also worth checking what a family entertainment center POS should already be doing before you scope an integration project around it.
FAQ
Why do my booking system and POS totals not match?
Usually because they count different things rather than counting the same thing wrongly. Deposits taken in advance, packages sold as one line and consumed as several, and bookings changed after the fact all produce legitimate differences. Identify which seams you have before assuming a defect.
Should party deposits appear as revenue when they are taken?
No. A deposit is a liability until the party happens, and recognising it as revenue on collection inflates the week you sell parties and deflates the week you deliver them. Deposits taken, deposits consumed and the outstanding balance belong in reporting as three separate figures.
Can a booking system and a POS share one capacity calendar?
They can, but only if exactly one owns it and the other reads from it. Two systems that can each independently commit the same lane will oversell on a peak day, and no reconciliation afterwards recovers a slot you sold twice.
What should an FEC ask a vendor about booking and POS integration?
Ask who owns capacity, where a deposit sits before the party happens, whether a package breaks into its parts at consumption, how many manual steps a changed booking creates, and whether a day's booked and walk-in revenue can be read in one place. Vague answers to those five are the answer.
