A customer story with almost nothing in it
Oracle put out a press release through PR Newswire on September 23, 2026 saying Manchester's Co-op Live arena has connected Oracle Simphony Cloud point of sale to NetSuite. That is close to the whole disclosure. No contract value, no go-live date, no performance figure, no start date.
Vendor reference stories run thin, and the reason to read this one sits in the operating profile rather than the news. Co-op Live seats 23,500 and hosts over 120 event nights a year on the Etihad Campus. Simphony covers ordering, payments and operational data across bars, concessions, premium spaces and self-service kiosks, while NetSuite handles financial reconciliation, budgeting and forecasting.
Guy Dunstan, Senior Vice President and General Manager of Co-op Live, is quoted in the release: "By connecting our venue and finance data, our teams have better visibility across the business, helping us make more informed decisions while delivering fast, efficient, and reliable service at every event." That is vendor copy.
The volume shape is the whole design problem
The defining constraint at a venue this size is distribution, not total volume. A building that opens its doors 120 times a year concentrates nearly all of its transactions into a few hours on event days and produces close to none in between.
An architect whose experience is steady retail or a monthly close has rarely had to design for that curve. Average throughput tells you almost nothing here. The numbers that matter are the busiest minute of the busiest night and how many of those minutes you can lose before a queue at the bar becomes revenue nobody records.
Sizing for the peak is half the work. The other half is deciding what runs during the trough, because quiet days are when batch posting, price changes and any reprocessing have room to run without competing with live sales.
What the bars do when the finance link is gone
Point of sale keeps taking money when everything behind it is unreachable. A till cannot wait for a finance system to acknowledge a round of drinks, so the hard problem sits downstream, in what the venue does with several hours of transactions when the integration is unavailable during a sold-out show.
The release answers none of that, and the questions are the useful part. Does Simphony buffer locally and replay on recovery, ordered and deduplicated? How deep does the buffer go before it drops or blocks? When the link returns at two in the morning carrying a full night of sales, does NetSuite record them against the trading day they belong to, or the day they arrived?
Each of those has a wrong answer that nobody spots until a variance turns up at month end. A retry that silently replays an entire shift does more damage than one that fails loudly, which is the argument in error handling that pages someone. Settle the replay semantics before the first sold-out night.
Several settlement paths have to agree by morning
A single concession stand produces several settlement paths that all have to agree by the next morning. Cash drawers count one way. Card takings settle through an acquirer on the acquirer's timetable, net of fees, often a day or more behind. Comped items, voids, staff discounts and suite accounts each post differently.
Finance has to tie that back to one event's revenue by outlet, by tender type and by trading day. Getting it wrong is never discovered on the night. It shows up days later when the deposit fails to match the sales report, by which time the shift staff have moved on. Anyone who has worked a payroll cutover reconciliation knows how that week goes.
The trading day boundary deserves its own conversation. An event running past midnight produces sales on two calendar dates that belong to one trading day. If the point of sale and the ledger disagree on where that line sits, every event-level margin number is quietly wrong.
Kiosks move the reconciliation problem rather than removing it
Self-service kiosks get sold partly on reducing the reconciliation burden, since no staff member is holding cash. They move the problem instead. A kiosk removes the drawer count and adds an unattended device that has to be monitored, reconciled against its own card terminal and matched to fulfilment at a collection point.
The failure modes change with it. A kiosk that takes payment and then fails to send the order downstream creates a paid transaction with no fulfilment, and the customer complains at a counter instead of surfacing in a report. Neither that nor a duplicate authorisation from a double prompt shows up in a till-against-bank comparison the way a short drawer does, so ask for the exception report before the kiosks go in.
One vendor stack, and the question to take away
Putting venue operations and finance on one vendor's stack is a defensible call at this scale. Simphony and NetSuite are both Oracle products, so the mapping between menu items, outlets and ledger accounts follows a supported path rather than a bespoke integration one contractor understands. A small finance team with no appetite for running integration platforms can reasonably take that trade.
The cost turns up at renewal and at the edges, since ticketing, sponsorship, hospitality and parking rarely sit in the same stack. Tottenham's consolidation of 35 systems shows the same shape from the fan-facing side, and our reading of NetSuite against Fusion covers the finance half.
What the release does not establish is the status of any of this. Oracle says the arena has connected Simphony to NetSuite. It does not say whether that happened this year or at the building's opening, and it does not say whether the announcement extends something already running.
Take one question into the next design review on any high-peak retail integration. Name the longest finance outage the operation can absorb during a sold-out event, then show where those transactions sit while it lasts and in what order they post once the link returns.
