How to Build a World Cup Q2C Engine: Ticketing, Hospitality, and Licensing Revenue at Scale

The 2026 FIFA World Cup is running across the United States, Canada, and Mexico: 16 host cities, 48 teams, 64 matches, and an estimated $6.4 billion in total revenue flowing through multiple legal entities, currencies, and revenue streams over an 18-month operating period.

From a quote-to-cash perspective, the World Cup is one of the most operationally complex billing events on the planet. Not because the math is hard, but because the revenue architecture spans:

• Consumer ticketing: individual fans buying in USD, EUR, GBP, BRL, MXN, and 30+ other currencies
• Corporate hospitality packages: B2B sales ranging from $15,000 to $600,000 per package, billed to global companies
• Sponsorship agreements: multi-year, multi-milestone contracts worth $30M to $200M each
• Broadcasting rights: country-by-country deals split across linear, streaming, and digital
• Licensing revenue: merchandise, naming rights, and official supplier contracts

Each stream has its own billing model, its own payment timeline, its own revenue recognition treatment, and its own downstream cash flow pattern.

Most companies will never run the World Cup's billing operation. But the challenges it surfaces - multi-entity structures, multi-currency collections, event-based revenue recognition, high-volume contract management, and concurrent AR streams - appear in scaled-up form in any complex B2B or media business.

This post breaks down how you would architect a Q2C engine for this kind of operation, and what every company building complex revenue infrastructure can take from it.

The Revenue Architecture

Before building any Q2C engine, you need to map the revenue streams. The World Cup has five, each with a distinct Q2C model.

1. Consumer Ticketing

CPQ complexity here is low. Fixed price list, volume pricing only for supporters clubs. The challenge is payment collection across 40 countries and managing the refund window if a match is cancelled or rescheduled.

Q2C flow: Selection - Booking - Payment confirmation - Ticket delivery - Match day - Revenue recognized.

2. Corporate Hospitality

CPQ complexity is high. Packages are configured per venue, match set (group stage vs. knockout), catering tier, and add-ons such as airport transfer, hotel, and exclusive events. Quoting requires a product catalog with match schedule dependency - a "Group Stage Pack" has a different lineup depending on when groups are drawn.

Q2C flow: Inquiry - Scoping call - Proposal (CPQ) - Contract - Deposit invoice - Group draw resolves match schedule - Balance invoice - Payment - Fulfillment - Revenue recognized at each match date.

The critical Q2C challenge: the contract is signed before the match schedule is confirmed. That means the quote cannot specify which teams the package covers. The order needs to be held partially open until the group draw - typically 12 to 18 months before the tournament - and then the invoice description updated to match the final schedule.

3. Sponsorship

Contract complexity is extreme. Every contract has custom payment schedules, custom activation deliverables, performance bonus clauses, and IP licensing sub-agreements.

The critical challenge: multi-element arrangements. A single $150M sponsorship contract may contain 12 distinct performance obligations - stadium branding, digital rights, hospitality entitlements, data rights, official supplier status, and player appearances. Each has its own standalone selling price (SSP) and recognition pattern. Getting this right requires close collaboration between finance, legal, and the revenue recognition team before the contract is signed.

4. Broadcasting Rights

The Q2C challenge here is rights delivery as a performance obligation. Revenue cannot be recognized until the broadcast signal is delivered to the rights holder for each match. For a rights holder covering 64 matches, revenue recognition needs to be automated against a match completion trigger - not done as a manual month-end entry.

5. Licensing

The Q2C challenge: variable consideration. You estimate total royalties at contract inception and true up at period end. Under ASC 606, royalty estimates must be constrained to what you are highly confident of - which means conservative recognition upfront and potentially significant catch-up adjustments at period end.

Building the Q2C Engine: Layer by Layer

Layer 1: CPQ

For the World Cup hospitality operation, the CPQ system needs to handle three things that most CPQ tools handle poorly:

Product catalog with time-bound bundles. A "Group Stage 4-person suite" at MetLife Stadium is a different product than the same suite at AT&T Stadium. The catalog must be structured by venue, then match tier, then suite configuration. This is a three-level hierarchy with ~200 base products across 16 venues.

Match schedule dependency resolution. Quotes are generated before the group draw. The system holds a "TBD" placeholder for team matchups. When the draw happens, the system auto-populates the match descriptions against open orders and triggers a contract amendment notification to the client. This needs to be a system-driven event, not a manual update task.

Multi-currency quoting with FX lock-in. The same package is quotable in USD, EUR, GBP, or MXN, with an FX lock-in rate captured at signing. The billing system then holds the original contract currency and the locked rate, generates invoices in local currency, and records FX gain or loss at payment.

Tools that handle this at the required scale: Salesforce CPQ, Conga, or purpose-built catalog logic. The key is that product configuration is data-driven, not hardcoded in a spreadsheet.

Layer 2: Order and Contract Management

After a quote is accepted, the Q2C engine needs to:

1. Generate a contract from the signed order, populated with configured items, payment schedule, and milestones
2. Route for internal approval: revenue recognition pre-approval is required for multi-element arrangements above a materiality threshold
3. Capture the signed contract and trigger the first billing milestone
4. Hold the order in "pending schedule confirmation" status until the group draw date, then auto-trigger the amendment workflow

The critical integration here is between CPQ output and the contract template. Every line item in the quote should appear in the contract without manual re-entry. Manual re-entry is where errors enter the system.

Layer 3: Billing Engine

The billing engine for a multi-stream operation needs to handle several capabilities that standard billing tools do not support out of the box:

Multiple billing schedules per contract. A hospitality package might have: a deposit invoice at signing, a balance invoice 90 days before the event, and a final reconciliation invoice post-event for add-ons consumed. Three invoices from one contract, each with its own trigger.

Event-driven revenue triggers. Revenue is recognized match by match. The billing engine needs to receive a "match completed" signal and use that to close the revenue recognition entry for that match's share of the package value. This cannot be a manual month-end journal entry - at 64 matches and 15,000 packages, the volume is too high.

Multi-currency billing. Each invoice is generated in the customer's preferred currency. The billing system holds the original contract value and the FX rate locked at signing, generates the invoice in local currency, and records FX gain or loss at payment.

Multi-entity invoicing. A German corporate buying a package at MetLife Stadium might be invoiced from FIFA's US entity. A Brazilian corporate at a venue in Dallas might be invoiced from a different entity. Invoice routing needs to be rules-based, not decided case by case.

Layer 4: AR and Collections

With 15,000 hospitality packages, you have 30,000+ invoice events (deposit and balance per package). At a 5% late payment rate, that is 1,500 invoices requiring collection activity. At that volume, collections cannot be manual.

Automated dunning by payment stage. Deposit invoices need different messaging from balance invoices. For deposit invoices, the leverage is clear: the package is held for 48 hours pending payment confirmation. For balance invoices 90 days out, the message is about the timeline to event and the need to confirm final headcount.

Priority queuing by deal size. A $500,000 suite package that is 15 days late gets a phone call from the account manager. A $15,000 group package gets a second automated email and then an escalation to a collections specialist.

FX-aware payment matching. When a payment arrives in EUR for an invoice denominated in EUR, the system needs to apply the correct exchange rate, match to the right invoice, and record the FX gain or loss against the locked rate. Manual cash application at 30,000+ payments is not viable.

Layer 5: Revenue Recognition

This is the most technically complex layer.

For a $150M sponsorship contract with 12 performance obligations, the RevRec engine needs to:

1. Identify each distinct performance obligation at contract inception
2. Allocate the transaction price to each obligation based on SSP
3. Track delivery of each obligation: branding installed, broadcast live, hospitality entitlements used
4. Recognize revenue when each obligation is satisfied, point in time or over time depending on the obligation type

Claude can accelerate the first-pass analysis for each new contract - identifying obligations, flagging variable consideration, and surfacing the controller questions that need to be resolved before the RevRec policy is finalized:

This requires a RevRec sub-ledger: either as part of the billing system (Zuora RevPro, Salesforce Revenue Cloud) or as a standalone module (NetSuite ARM). It cannot live in a spreadsheet. The audit trail requirements alone make spreadsheet-based RevRec untenable at this scale.

Three Key Architecture Decisions

1. Central event bus vs. point-to-point integrations

At this complexity level, a central event bus (Kafka, AWS EventBridge, or similar) is required. When a match ends, that is a single event that needs to trigger revenue recognition entries across hundreds of contracts simultaneously. Point-to-point integrations cannot handle the fan-out volume or guarantee delivery.

For smaller operations, a simple webhook architecture with retry logic handles this adequately. The principle is the same: billing events should be data, not process steps that require human initiation.

2. Contracted FX rates vs. daily spot

Always contracted FX rates for enterprise hospitality and sponsorship deals. Lock the rate at signing, generate all invoices at that rate, and record FX P/L at payment. Daily spot rates create P/L volatility that obscures the true contract economics and makes revenue forecasting harder.

3. Match schedule dependency handling

The cleanest architecture is a "contract amendment trigger" pattern. The base contract is signed with placeholder terms (Match Set A, Group Stage). When the group draw happens, the system generates a contract amendment that populates the real match descriptions and sends it to the customer for acknowledgment. The invoice is not sent until the amendment is acknowledged. This protects both sides: the customer knows exactly what they are getting, and the seller has a signed amendment before releasing the next billing milestone.

What Every Complex B2B Business Can Take from This

You are not running the World Cup. But if you have any of the following:

• Multi-element contracts where different deliverables have different recognition patterns
• Variable consideration such as royalties, usage-based components, or success fees
• Multi-entity invoicing across legal entities or geographies
• Event-triggered billing based on milestones, completions, or usage thresholds

...then the World Cup's Q2C architecture is directly relevant to your operation.

The specific lessons:

The CPQ layer needs to produce contract-ready output. Every field in the quote should be a field in the contract. No manual re-entry. No "can you send me the signed terms as a PDF" workflows.

Multi-currency billing requires FX policy decisions before the first invoice. Lock at signing or lock at invoice date? The answer affects both contract language and system configuration. Document the policy and build it into the billing system before the first deal closes.

Revenue recognition needs to be event-driven, not batch. Month-end revenue recognition is a batch process that creates a deadline. Event-driven recognition eliminates the deadline and produces cleaner financials throughout the month.

Collections at scale requires priority logic. Not every overdue invoice deserves the same response. Build segmentation into dunning rules from the start: amount, relationship tier, payment history, and product type all affect the right escalation path.

The RevRec sub-ledger is a system of record, not a month-end calculation. Too many companies treat revenue recognition as a spreadsheet exercise at month-end. It should be a maintained data model that tracks obligations and satisfaction in real time. The audit trail alone justifies the investment.

The 2026 World Cup is, among other things, a stress test for event-based revenue operations at scale. The companies and leagues that handle this kind of complexity well have clean financials, tight cash flow, and audit trails that hold up. The ones that do not will be reconciling revenue in spreadsheets for months after the final whistle.

The architecture principles do not change based on deal size. What changes is the tooling, the team size, and the tolerance for manual work. The Q2C engine you build for your next complex contract should be designed with the same rigor - just sized appropriately for your volume.