Odoo Events Implementation
Registration, ticketing, tracks and on-site check-in.
Odoo Events runs registration and ticketing, publishes the agenda to the website, takes payment and handles check-in on the day with a barcode scan.
Odoo Events is one core app with a ring of optional modules bolted to it. The core holds the event, its ticket types and one registration per seat. Sales adds paid tickets and invoicing, Website publishes the page and the agenda, and separate modules add talks, sponsors, booths and CRM lead creation. Those modules install themselves as the matching settings are switched on, which is why two databases both described as running Events can behave very differently. All of it sits on the same partner and product records as the rest of the system, so a delegate, a customer and a sponsor contact are one record rather than three lists that drift apart.
Nearly all of that is Community, which surprises buyers who expect ticketing to be an Enterprise upsell. Tickets, the public event site, tracks, sponsors, booths and lead rules are all on the free side. The Enterprise pull on an events project usually comes from accounting rather than from events. Community stops at Invoicing, so ticket income taken in January for an event that runs in June can be invoiced but not deferred into June, and deferred revenue is an Enterprise feature. Marketing Automation, Planning, Sign and Studio sit on that same side of the line if the programme needs them.
What makes an Events project harder than it looks is that it is three systems wearing one name: an operations record for the day itself, a public website, and a sales channel with tax and payment behind it. Most weak configurations do one of the three properly and treat the other two as an afterthought. The registration record is where all three meet, and almost every decision below comes back to what is stored on it.
Who Odoo Events is for
- → Associations and training bodies running a recurring calendar of paid sessions where the delegate, the invoice and the membership record have to be one contact rather than three lists.
- → Conference and exhibition organisers selling tickets, sponsorship and floor space against the same event and wanting one revenue figure at the end of it.
- → Manufacturers and distributors running dealer days, launches and roadshows where the point is capturing qualified leads rather than selling seats.
- → Universities and professional bodies that need a verified attendance record feeding a certificate or a CPD log.
- → Not for allocated seating. There is no seat map and no numbered seat selection, so a theatre, an arena or a gala dinner with a table plan needs a specialist platform alongside Odoo.
- → Not for high volume public on-sales either, where several thousand buyers hit one ticket type inside the same minute and expect a queue and a held basket.
Key features
- ✓ Ticket types and pricing
- ✓ Registration pages on the website
- ✓ Payment at registration
- ✓ Barcode check-in on the day
- ✓ Speaker and track management
- ✓ Follow-up email automation
What Odoo Events actually does
Ticket types, sale windows and seat caps
Each event carries its own ticket types, and each ticket has a product, a price, a maximum number of seats and its own sales start and sales end datetime. Early bird pricing is therefore two ticket records rather than a discount rule, and the changeover happens on the clock with nobody touching the site at midnight. The event can hold a separate overall cap on top of the per ticket limits. Price sits on the ticket while tax comes from the linked product and the buyer's fiscal position, which is the split that catches teams out the first time an overseas delegate is charged the wrong rate.
How a sale order becomes a registration
A ticket only produces an attendee if the product behind it has its service tracking set to Event Registration, the field labelled Create on Order on the product form in recent versions. Miss that and the order confirms, the money is taken, and no registration is ever created. It is the most common configuration fault on a new events database and it stays invisible until somebody counts attendees. With it set, the order line carries an event and a ticket, confirming the order creates one registration per unit, and increasing the quantity on that line adds seats. Booths use the same mechanism through their own tracking value.
Registration questions asked per order or per attendee
Questions are configured on the event or inherited from the event template, and each one is asked either once per order or once for every attendee. The types available are name, email, phone, company, a free text box and a single choice from a list you define. Answers are stored on the registration itself, which is what the badge layout, the attendee list and the export all read from. Dietary requirement, job title, session choice and accessibility need are all questions, so a normal conference needs no custom fields at all.
Website pages, agenda and call for papers
Website Events gives each event its own submenu, and the items are switched on per event or per template: introduction, location, register, agenda, exhibitors and community rooms. Tracks hold the talks, each with a speaker, a room, a start time and a duration, and they move through stages from proposal to published so the public agenda shows only what the committee has accepted. Turning on track proposals opens a public submission form that files proposals straight into that same pipeline, instead of a shared mailbox and a spreadsheet the programme chair maintains by hand.
Booths and sponsors sold as ordinary products
Booth management is a setting in the Events app rather than a separate purchase. Switching it on creates booth categories, each pointing at a product with a price, and that product is configured to create the booth when the order is confirmed. An exhibitor is quoted through the normal sales flow, and confirming the order marks the booth unavailable, so the floor plan and the revenue stay in step without a second spreadsheet. Sponsor levels are a different thing entirely and only control how logos are grouped on the event page, which is worth knowing before somebody tries to price sponsorship through them.
Badges and Registration Desk check-in
Every registration carries a unique code that prints on the badge and full page ticket layouts. Registration Desk in the Events app has two modes: scan a badge, which uses the camera on a phone or tablet, and select attendee, which is a searchable list for the person who arrives with no printed badge. Either route sets the attendee to attended and counts the arrival in reporting. A USB or Bluetooth scanner behaves as a keyboard and types into the same screen, which at a busy door is faster than a phone camera and worth budgeting for.
Scheduled messages and CRM lead rules
Each event carries its own list of scheduled messages, every one with a mail or SMS template, an interval, and a trigger of after each registration, before the event or after the event. Lead rules turn registrations into CRM leads or opportunities, one per attendee or one per order, fired when a registration is created, confirmed or marked attended, and narrowed to a given event or a set of event templates with a further filter on the registration itself. That rule is the difference between a roadshow producing pipeline and producing a spreadsheet nobody opens again.
How we configure Odoo Events
Build the event template before the first event
Event templates hold the default ticket types, questions, scheduled messages, website menu items, booth categories and the timezone. Build the template first and every event after it inherits the same shape. Skip it and a year later there are twelve events with twelve slightly different question sets, which turns any cross event report into manual work. Templates are also how a one hour webinar format and a two day conference format stay apart without somebody having to remember the difference each time.
Timezone belongs to the event, not to the user
Each event carries its own timezone, and displayed times, reminder intervals and agenda slots all resolve against it rather than against whoever happens to be logged in. For an organiser running sessions in Riyadh, London and Karachi from one database, that single field decides whether a reminder saying nine in the morning arrives at nine in the morning. Set it on the template, confirm it on the event before the page is published, and avoid changing it afterwards, because it moves every track on the agenda with it.
Prove the mail scheduler before you rely on it
Scheduled messages do not fire when the event is saved. They fire when the event mail scheduled action runs, found under Settings, Technical, Automation, Scheduled Actions with developer mode on, so confirm it is active and check its interval on a fresh database. Adding a scheduler to an event that already holds registrations does not behave the same as adding it before anyone booked. Test by moving a draft event date and watching what queues, rather than discovering the behaviour on the real send window the night before.
Tax, payment and the gateway lead time
Paid tickets use the standard payment providers and the standard tax engine, so the fiscal position on the buyer decides treatment, not the event. Decide before launch whether prices are shown tax inclusive or exclusive, because changing it after the first sale means credit notes and reissued invoices for everyone who already paid. Treat the payment provider as a lead time item rather than a configuration item. Gateway and bank onboarding runs on somebody else's clock and is the usual reason a finished site still cannot open ticket sales.
Badge layout and the print run
Badge and ticket layouts print from the registration, so anything that appears on a badge has to exist as a field or a question answer on that record. Agree the layout with whoever supplies the lanyard stock early: margins that line up with pre-printed card, a code large enough to read at arm's length under venue lighting, and a name block wide enough for the naming conventions of the market, which is a real constraint for Arabic names printed alongside a Latin transliteration.
Fix the reporting shape before the first event
Attendance sits on registrations, ticket income sits on sale orders and invoices, and cost sits on supplier bills. The event record carries no analytic field of its own, so the join has to be made deliberately: create an analytic account per event or per season, then set the analytic distribution on the ticket order lines and on the bills for venue hire, catering and speaker travel. Apply event tags consistently at the same time, because tags are what the standard reports group by. Doing this on event one costs an hour. Reconstructing it across two years of history is a data project with its own budget.
Where Odoo Events projects go wrong
Five tickets, the same name on all five badges
When somebody buys a block of seats, Odoo creates one registration per seat and fills every one of them from the buyer unless at least one question is set to be asked per attendee rather than per order. Teams find this out at badge printing, two days before the doors open. Turn on per attendee name and email from the start. There is also no self service route for a buyer to come back later and complete the other four names, so the real choice is asking for everything at checkout or collecting the rest by email and typing them in. Somebody should make that choice on purpose.
There is no waiting list
A sold out ticket shows as sold out on the registration form and cannot be selected. Nothing queues behind it, nothing releases automatically when a registration is cancelled, and nobody who missed out is told when a seat frees up. An organiser who genuinely runs a waitlist needs either a second unpublished ticket type worked by hand or a small custom model. Decide which before tickets go on sale, not on the morning after they sold out in an hour.
Cancelling a registration refunds nothing
The registration state and the sale order are separate records. Setting a registration to cancelled frees the seat and leaves the invoice standing, so the money returns only through a credit note and a refund raised in the payment gateway by a person. Write the cancellation policy into the process before launch: who may cancel, inside what window, what fee is retained, and whether the freed seat goes back on public sale or to somebody being handled by email.
Comped seats added in the back office never reach the accounts
Adding attendees directly on the event's attendee list creates a registration with no sale order behind it. That is correct for genuine invitations, staff, press and speakers, and it quietly breaks the numbers as soon as the sales team starts using it as a shortcut for real bookings. Seats taken and revenue booked then disagree and nobody can say by how much. Agree who may create a registration by hand, and give those seats their own ticket type so the gap shows up in reporting instead of hiding inside the total.
Concurrent checkout can pass the seat limit
Seat availability is worked out from the registrations that already exist rather than held as a hard reservation, so several buyers completing payment in the same moment can take a ticket type slightly past its cap. On a fifty seat workshop this never happens. On a free webinar promoted to a large mailing list it does. Publish a number with a little room in it and keep a small overflow allowance at the venue, rather than arguing with the platform on the morning of the event.
Attendee data outlives the event
Registrations hold names, emails, phone numbers and sometimes dietary or accessibility answers, and they sit in the database indefinitely unless somebody decides otherwise. That is personal data with a retention limit under GDPR and its Gulf and Turkish equivalents. Agree how long registrations are kept, who is allowed to export them, and whether the marketing consent captured at registration actually covers the campaign somebody plans to send eighteen months later.
What it works with
- + Sales and Invoicing, so tickets, sponsorship and booths all bill on ordinary sale orders
- + eCommerce, putting tickets in the same cart and the same payment providers as merchandise
- + CRM, through event lead rules that turn registrations into an owned pipeline
- + Email Marketing and SMS, for the invitation list and the per event reminders, with SMS bought as in-app credits and priced per message per country
- + Surveys, linked from a post event message for feedback and for scored certification tests
- + Point of Sale, for catering and merchandise at the venue, remembering that a ticket rung up at a till does not create a registration by itself
- + Marketing Automation, Planning and Sign on Enterprise, for nurture flows, shift rotas and speaker contracts
- + Contacts and pricelists, where a member or partner rate is a pricelist held on the buyer rather than a discount typed in by hand
Odoo Events by country
Saudi Arabia (KSA)
A ticket sold to an individual is a simplified tax invoice: 15 percent VAT, a QR code on the document, and reporting to the Fatoora platform within 24 hours of issue. A sponsorship invoice to a company is a standard invoice and has to be cleared by ZATCA before it reaches the buyer, so two documents from the same event follow two different flows. Badges and certificates need the Arabic name as its own registration question rather than a transliteration somebody produces by hand at print time. Check the dates against the Hijri calendar and against Ramadan working hours before anything goes to print.
United Arab Emirates
The trap here is registration rather than the rate. Admission is taxed where the event physically happens, so a Dubai conference charges 5 percent even to overseas delegates, and a foreign organiser running a UAE event can create its own UAE VAT registration obligation before it has sold a ticket. Sponsorship billed to a UAE company is business to business and falls inside the Electronic Invoicing System, phased from 1 January 2027 for the largest taxpayers and 1 July 2027 for everyone else, with an accredited service provider appointed well ahead of each date.
India
Delegates from other states usually cannot recover the tax on their ticket, because place of supply for admission is the venue and the invoice carries host state CGST and SGST rather than IGST. Finance teams argue about that every year, so put it in the booking terms rather than in an email afterwards. Above the e-invoicing turnover threshold, currently five crore, both delegate and sponsorship invoices need an IRN and a signed QR code from the portal, and moving stands, printed material and giveaways between states needs an e-way bill.
Pakistan
Tax on event management is provincial rather than federal: the Sindh Revenue Board or the Punjab Revenue Authority sets the rate and the registration for the service, while FBR digital invoicing governs the goods side. Checkout matters more than tax here. JazzCash and Easypaisa are what delegates actually hold, Odoo ships no connector for either, and most organisers fall back to bank transfer reconciled by hand against the registration. Settle that before the page goes live, because it decides how many bookings need a person to confirm them.
Turkey
A ticket sold to an individual is an e-Arsiv document reported to GIB, while a sponsorship invoice to another registered taxpayer goes out as e-Fatura over the UBL-TR flow, both sealed through a licensed private integrator. The archive rule shapes hosting as much as the tax rule does. Those documents have to be preserved and produced on demand for five years under tax law and ten under the commercial code, and the electronic copies are expected to sit in Turkiye rather than only on a server abroad, which makes hosting a decision to settle before the first ticket is sold.
United Kingdom
Exemption is the decision that matters. Admission by an eligible body to a qualifying cultural or educational event can be exempt, and that changes the ticket price, the input tax recoverable on the venue and the wording on the website, so it is settled before tickets go on sale. Otherwise admission is standard rated at 20 percent, including for business delegates. An organiser with no UK establishment has no registration threshold to shelter behind and registers from the first taxable sale. VAT records are kept digitally and filed under Making Tax Digital.
Germany
Any till taking catering or merchandise money on site falls under the Kassensicherungsverordnung and needs a certified technical security device, which Odoo covers with a cloud based TSE in its German point of sale localisation. That certification covers Enterprise rather than Community, and the device has to be ordered and registered well before the doors open. Sponsorship invoicing is the other half: since January 2025 a German business has to be able to receive a structured e-invoice, so XRechnung and ZUGFeRD arrive whether or not you issue them yet. Records sit under GoBD retention and the accountant will ask for a DATEV export, which comes from the Enterprise German reporting module.
France
Selling tickets to consumers at a desk or a till puts the cash software inside the anti fraud rule of article 286 I-3 bis of the tax code, which Odoo answers with its certified point of sale module and the certificate of conformity that goes with it, again on Enterprise rather than Community. Sponsorship and exhibitor invoices to French companies fall under the e-invoicing reform: every business has to be able to receive a structured invoice from September 2026, large and mid sized companies have to issue from the same date and smaller ones from September 2027, in Factur-X, UBL or CII through an approved platform.
Odoo Events FAQs
Is Odoo Events part of Community or Enterprise?
Events, paid ticketing through Sales, the public event site, tracks and the call for papers, sponsors, booths, CRM lead rules and the Registration Desk check-in screen are all standard rather than an Enterprise add-on, so a paid conference runs end to end on Community. What Community does not give you is deferred revenue in accounting, Marketing Automation for multi step nurture, Planning for staffing rotas, Sign for speaker contracts and Studio for changes without code. One more point catches European organisers: the French and German fiscal certifications for point of sale cover Enterprise only, so a till at a venue in either country is an Enterprise decision on its own.
Can a delegate transfer their ticket to somebody else?
There is no self service transfer. A delegate who cannot attend either has the registration cancelled and a new one created, which detaches the seat from the original payment, or has the name and email on the existing registration edited by an administrator, which keeps seat and payment together on the same order. Pick one of those as policy, put it in the terms with any transfer fee, and expect to enforce it by process rather than by configuration.
Does Odoo support seat maps or reserved seating?
No. Tickets are types with a quantity, not numbered seats, and there is no seating chart and no hold mechanism. An event with allocated seats needs a specialist ticketing platform plus an integration that writes the registration and the revenue back into Odoo. Rebuilding the Events module into a seat map is not a sensible project, and the cost of carrying that customisation through version upgrades usually exceeds the licence it was meant to avoid.
Can attendees pick individual sessions with limited places?
Not with capacity control. Tracks describe the agenda and an attendee can build a personal list from them, but a track holds no seat count and has no check-in of its own, so nothing stops forty people walking into a workshop room laid out for twenty. A session with a real limit is modelled either as its own ticket type on the same event, which gives it a cap and a line on the badge, or as a separate event linked from the parent page. Decide before the agenda is published, because moving a session from a track to a ticket after sales open means reissuing what people already bought.
Can we run free events without buying Sales?
Yes. The Events app on its own handles free registration, questions, badges, scheduled reminders and check-in. Publishing a public page adds Website, taking money adds Sales and a payment provider, and pushing registrations into a pipeline adds CRM. That modularity is why an association can start with free member evenings and add paid ticketing a year later without rebuilding the part that already works.
How do we report on revenue and repeat attendance across a season?
Events ships two reports of its own. Attendees analyses registrations by event, ticket type, state or any question answer. Revenues shows ticket income per event once Sales is installed. Neither one includes sponsorship, booth sales or any cost at all, so a margin per event comes from analytic accounting rather than from the Events app. Repeat attendance is a count of registrations per contact, which is only true if the same partner is matched at booking instead of a fresh contact being created on every purchase.
Can Odoo run an online or hybrid event?
Odoo is not a streaming platform. The workable pattern is registration, ticketing and reminders in Odoo, the session itself on an external webinar tool, and the join link sent from the scheduled message that goes out before the event. The event page can carry community rooms for attendees to talk to each other, and a track can link out to a recording afterwards, but the video and its capacity limits belong to the other vendor.
Can one database run events in several countries and currencies?
Yes, through multi-company, or at minimum multi-currency with a fiscal position per buyer. Set the timezone on each event, price tickets through pricelists in the local currency, and let the fiscal position decide tax rather than hard coding it per event. The harder half is payment, because each market expects the gateways and wallets its buyers already hold, and a checkout that only offers a card fails quietly in several of the markets covered above.
What usually takes the time on an Events implementation?
Rarely the Events configuration itself. Payment provider onboarding runs on the gateway's clock and the bank's, and it is the item most likely to sit between a finished site and an open ticket sale. Badge printing needs a rehearsal on the real stock and the real printer, because margins that look right on screen drift on pre-cut card. Historical attendees import as contacts plus registrations against back dated events, which is the only way repeat delegate reporting works from the first live event. Question design comes last and matters more than it looks: every question asked per attendee is a field somebody fills five times when they book five seats.