Odoo airline loyalty: an open-source frequent-flyer stack for LATAM

Why airline miles are debt, not marketing

Frequent flyer programs are not a tiny rewards card. They are financial products with their own P&L, their own audit, and their own accounting trap. LATAM Pass, Smiles, LifeMiles and AeroMéxico Rewards together hold over 100 million accounts and contribute up to 40% of operating profit at their parent carriers. Anyone who books them as a marketing expense ends up with a broken balance sheet and a qualified opinion from the Big-4 audit.

American Airlines invented AAdvantage in 1981 to sell empty seats. Forty-five years later, miles are a financial instrument: airlines sell them in bulk to banks for co-brand cards, to hotels for reward redemption, and to retailers for cross-sell programs. The carrier no longer earns only by moving aircraft; it earns by managing a parallel currency with breakage rates, conversion tables and contractual liabilities.

The technical consequence is direct. Under IFRS 15, in force in every LATAM jurisdiction since January 2018, every issued mile must be booked as a contract liability. It is not a methodological choice; it is regulation. Carriers that ignore it learn what it costs: SAT, SUNAT, DIAN and AFIP reclassify revenue recognition and reopen entire fiscal years.

None of this is news for top-tier carriers. The interesting question sits one tier down: the LATAM LCCs, regionals and cargo operators that do not have a loyalty engine — what architecture do they use to comply? The short answer: open-source Odoo covers 60–70% out of the box and the rest gets built. The long answer fills this article.

The LATAM market: four big names, then nothing

Above the line, four programs concentrate roughly 90% of the miles issued in the region:

• LATAM Pass (Chile, Peru, Colombia, Brazil, Ecuador, Argentina): about 40 million members. Moved to revenue-based accrual in 2022 — miles are computed on USD spent, not on distance flown.
• Smiles (Brazil, inside GOL): listed as Smiles Fidelidade S.A. on the B3 in 2013, delisted and folded back into GOL in 2021. Fully operationally integrated after the group's restructuring.
• LifeMiles (Avianca; legal domicile in Panama): around 12 million members. Sells miles to Citibanamex, Bancolombia and BCP, among others.
• AeroMéxico Rewards (formerly Club Premier, rebranded after the 2020–2022 bankruptcy): about 7 million members. Main partners: American Express México and Banamex.

Below the top four, the landscape shifts. Viva Aerobus moves roughly 24 million passengers a year and launched Doters in 2022 — a basic program with no real CRM integration. Volaris runs V.Club, which is a discount subscription, not a classic FFP. Sky Airline in Chile launched Sky+ in 2023 with minimal functionality. JetSMART operates JetSMART Smart Club as a subscription, with no mileage-based earning. Wingo, Plus Ultra and Star Peru have no functional FFP. Aerolíneas Argentinas Plus still sits on Comarch with no public API.

Add up LCCs, regionals and cargo, and roughly 150 LATAM operators either have no loyalty program at all, or run a raw subscription with no accrual, no partner network and no member portal. That is the gap Odoo fills: implementations between USD 25,000 and USD 80,000 against the USD 1.5 million to USD 8 million price tag of enterprise platforms (IBS iLoyal, Sabre Loyalty, Comarch FFP, Loylogic).

#1. Regulatory timeline for 2025–2026

Five fiscal changes relevant to airline loyalty land in the next twelve months. Each one touches the miles ledger in a different way.

The IFRS 15 core is brutally simple: when a ticket is sold, the transaction price splits between two obligations — transporting the passenger and providing miles for a future trip. The miles portion gets an estimated fair value — typically 0.8 to 2.5 USD-cents per mile, depending on the program and the redemption category — and is deferred on the balance sheet as a contract liability. When the mile redeems, that portion flows to revenue. When it expires unused, the actuarial breakage rate releases it.

What Odoo covers out of the box, and what it does not

Odoo 18 — and version 19, released in October 2025 — ships a stack that covers most of an airline loyalty workflow. What is missing is the part that separates an airline from a retailer: route-based calculation, GDS integration, fiscal localization and actuarial revaluation of the liability.

#1. Base modules that ship by default

The loyalty module (Community and Enterprise) handles loyalty programs, cards, points, gift cards, ewallet, discounts, coupons and promo codes. Multi-tier is modeled with loyalty.rule plus condition expressions. Native reward types include percentage and flat discount, free product and free shipping. Multi-company and multi-currency are baked into the core.

The accounting stack (sale + account) creates the sale order with a loyalty-card discount and records redemption as a journal entry. Deferred revenue runs on account.deferred.revenue (Enterprise module account_asset_management).

The member portal ships out of the box via website + portal: balance, history, redemption, tier status, benefits. The member signs up through the website signup flow. Member profile lives in res.partner with custom fields for tier, anniversary and preferred airport. The hierarchy partner → corporate account → travel agency is the one Odoo already uses for B2B.

#2. Functionality that comes for free

• Mile accrual on ticket sale through sale.order.line with a loyalty rule
• Redemption on ticket purchase as a discount line
• Tier progression based on qualifying miles, run by cron with a custom field
• Cron-based expiration — no activity in X months, miles burn
• Self-service portal: balance, history, tier benefits
• Multi-currency with FX-conversion to USD for the global ledger
• Multi-company for alliances where several legal entities share the program
• Tier benefits via product.product records with conditional pricing

#3. Functionality that needs to be built

The following is not shipped and always — always — turns into the bulk of the project:

1. Route × RBD × tier multiplier calculation. A custom flight_loyalty_calculation module, a lookup table for route distance (sourced from OAG, IATA or manually), a booking class (RBD) multiplier, plus tier and promo multipliers. Four to six weeks of development depending on fare matrix complexity.
2. GDS and PSS integration. Amadeus Soaring (REST), Sabre Web Services (SOAP/XML), Travelport Universal API, Hitit Crane PSS (popular among LATAM LCCs), Navitaire New Skies (Accelya). The standard middleware is Kafka plus a dedicated worker for real-time accrual.
3. PCI-compliant co-brand credit cards. Tokenization (Visa Token Service, Mastercard MDES), PCI DSS scope segmentation — PAN never touches Odoo — and daily settlement per issuer (Visa Direct, Mastercard Send).
4. Fiscal localization for miles. l10n_pe for CPE under SUNAT Resolución 000040-2025 with a special mileage payment code; l10n_mx for CFDI 4.0 with discount as a separate line; l10n_co for DIAN with redemption as a separate item; l10n_ar for AFIP/ARCA with a loyalty comprobante.
5. Actuarial revaluation of the deferred liability. Recalculate breakage rate quarterly, adjust fair value when the award chart changes, leave it all audit-ready for Big-4. Skip this and the qualified opinion is waiting.
6. B2B partner settlement. Banks that buy miles in bulk for co-brand, hotels that buy miles for guest rewards, monthly settlement, invoice, FX-conversion. This is the first module regional airlines underestimate.
7. RFM segmentation and propensity-to-churn models. Recency-Frequency-Monetary, ML models (XGBoost, LightGBM), integration with marketing automation (Mautic, ActiveCampaign, Mailgun). Usually left for phase 2, which is fine.

When Odoo works, and when it is out of its league

The simple rule: Odoo fits carriers up to about 5 million members and around 200 transactions per second. Above that, the choice is hybrid architectures or enterprise platforms.

#1. Yes — LCC and regionals up to 5M members

The typical architecture: Odoo Community or Enterprise plus four custom modules (flight_loyalty_calculation, pnr_integration, deferred_miles, partner_settlement) plus PSS middleware (Kafka + worker) plus l10n_{cc} localization. Cost: USD 35,000 to USD 80,000 initial plus USD 1,500 to USD 3,000/month for support.

Carriers where this path is worth evaluating: Wingo Rewards (Colombia, ~5M passengers/year), JetSMART Loyalty (Chile, Argentina, Peru, ~9M) if they migrate from subscription to mileage, Plus Ultra Peru to build an FFP from scratch, and the cargo loyalty programs of Aerolíneas Cargueras Argentinas or LATAM Cargo. Supported throughput: up to 200 TPS, up to 5M members and 100M miles/year accrued — assuming PostgreSQL is tuned right (partitioning by member_id range, materialized views for daily aggregates).

#2. Hybrid — Odoo as back-office for mid-tier

For carriers between 5 and 20 million members (Avianca, Copa, AeroMéxico, Volaris once it matures), the sane architecture is hybrid. Odoo keeps HR, finance, partner relations and IFRS 15 deferred revenue accounting. The front-office loyalty engine is sourced externally: Comarch FFP (the legacy LATAM choice), PROS Loyalty (newer SaaS), Loylogic (premium) or Sabre Loyalty for carriers already on Sabre PSS. Integration via REST API. Cost: Odoo USD 60,000 to USD 120,000 plus loyalty engine license USD 200,000 to USD 800,000/year.

The cutoff is throughput and uptime: 500 to 2,000 TPS, 99.99% availability on the member portal 24/7, and contractual SLAs with partners that no longer tolerate maintenance downtime.

#3. No — top-tier 30M+

LATAM Group post-restructuring and AeroMéxico post-Delta JV are out of scope for Odoo as a loyalty engine: 30 million members or more, sustained throughput above 2,000 TPS, partner-accrual schemes cross-wired between alliances (SkyTeam, oneworld) with inter-carrier offsets, strict alliance-level SLAs, and 24/7 multi-region failover. IBS iLoyal, Sabre Loyalty, Lufthansa Systems FMS or Amadeus Altéa Customer Management Suite own this tier. Odoo can stay in finance — where IFRS 15 lives — but not as loyalty core.

Six mistakes that wreck an Odoo loyalty rollout

The mistakes below appear in order of frequency. The first three are accounting and break the balance sheet; the last three are operational and break trust with members or partners.

#1. Booking miles as marketing expense

What breaks. The balance sheet understates liabilities and the P&L overstates revenue. The Big-4 audit issues a qualified opinion. SAT, SUNAT, DIAN or AFIP, when they review, reclassify hidden revenue and apply the retroactive adjustment.

What works. On accrual: Dr Sales / Cr Contract liability at fair value (0.8–1.5 USD-cents typical). On redemption: Dr Contract liability / Cr Revenue. Quarterly revaluation of the contract liability against actuarially-calculated breakage.

#2. No segregation of miles by state

What breaks. Partner reporting lies. Citibanamex, Bancolombia and BCP pay for earned-not-redeemed. If the ledger does not distinguish earned, redeemed, expired and bonus, the calculation is wrong and 8% to 15% of monthly partner-channel revenue is left on the table.

What works. Add a status field on the loyalty.card line plus an audit log through mail.thread. All mile operations go through a service layer — no direct loyalty.card.write().

#3. Manual or missing tier downgrade

What breaks. A member who qualified for Premium a year ago and only flew twice this year should drop to Silver. With no cron, they keep seeing "Premium" in the portal while benefits fail at the gate — or the other way around. NPS drops 15 to 25 points on that cohort.

What works. A monthly cron: recompute qualifying-miles on a rolling 12-month window, compare against the threshold, execute upgrade or downgrade, fire a notification. Message to the member: "Dear [name], this year you flew X miles; your level for next year is [tier]". No surprises at the gate.

#4. Partner settlement in Excel

What breaks. Banks and hotels expect a monthly invoice for mile purchases. Manual calculation runs 5 to 7 days and leaves 8% to 12% error from FX conversion mistakes and cutover mismatches. Collections drag, and worse, partners stop trusting the numbers.

What works. A partner_mile_settlement module: month-end cron pulls every mile purchase per partner, generates the invoice via account.move, sends the PDF via mail.message. Time: 1.5 days instead of 5–7.

#5. PCI compliance broken on co-brand cards

What breaks. If Odoo handles a PAN directly, the airline lands in PCI DSS scope. Visa and Mastercard fines run from USD 5,000 to USD 100,000 per month, and severe cases lose the merchant agreement. Co-brand card issuance pauses and loyalty collapses with it.

What works. Token-based storage. Card data never touches Odoo: an external vault (Stripe, Adyen, Cybersource, Kushki, Mercado Pago) issues a token; Odoo stores token + last 4 + brand only. Daily settlement arrives as a batch import of journal entries.

#6. No expiration policy

What breaks. Legacy carriers sometimes "forget" to burn inactive miles. That inflates the deferred revenue liability — and when Big-4 audits the actual breakage rate, it reclassifies revenue to the current period and blows up the close.

What works. Explicit policy: a mile expires after 36 months of inactivity and reactivates on ticket purchase. Cron job plus notifications at 60, 30 and 7 days from expiry. No surprises for the member, no surprises for the audit.

A CIS airline case: +22% retention, –68% on settlement

Anonymized client: flag carrier in a CIS market, around 10 million registered members, legacy program on Comarch FFP through 2017. Q4 quarterly churn: 15%. Partner settlement: manual, 5 to 7 days. IFRS 15 misaligned with local GAAP. A qualified opinion from the audit hanging in the air.

The project ran from 2017 through 2019 across five parallel workstreams.

The core member ledger migrated to Odoo with a custom loyalty_miles module. PostgreSQL partitioning by member_id range; materialized view for daily aggregates; a covering index on (member_id, accrual_date) that pushed portal queries to under 80ms p95.

The IFRS 15 deferred revenue stack ran on account.deferred.revenue with a custom rule. On accrual: Dr Sales at a fair value near USD 0.012/mile, Cr Contract liability. Quarterly breakage revaluation against an actuarial model fed by years of history.

The RFM segmentation came from three materialized views — Recency (days since last flight), Frequency (flights in 12 months), Monetary (USD spent) — with a Champion-to-Lost sieve across seven buckets. Those segments fed a behavioral triggers layer: e-mail + push after 30 days of inactivity (win-back), 90 days (personalized award), tier downgrade detected 60 days out (retention bonus). The propensity-to-churn model ran on XGBoost under Airflow, refit weekly.

Finally, partner settlement was automated: monthly cron, REST API into banks and hotels, invoice generated on the first of the month.

Results, twelve months after go-live:

• +22% in retention Q1–Q4 against the prior fiscal year
• –68% in settlement time (5–7 days → 1.5 days)
• IFRS 15 compliant, qualified opinion removed at the next close
• Mile redemption rate rose from 12% to 18% — the mile shifted from ballast to live currency

The fight was not building the ledger. The fight was convincing planning that the mile was a liability, not a marketing lever.

The architecture ports to LATAM mid-tier with three adaptations: real multi-currency (USD primary plus COP, MXN, PEN, CLP, ARS, BRL running in parallel), full fiscal localization (CFDI 4.0, CPE SUNAT, DIAN factura electrónica, AFIP comprobante), and PCI scope for co-brand cards. For LCCs and regionals (Viva, JetSMART, Wingo, Plus Ultra, Star Peru) the architecture simplifies — fewer partners, fewer tiers, lighter RFM — but the base stack (Odoo + deferred revenue + RFM + retention triggers) is exactly the same. Conceptually adjacent to the QIC data warehouse case: an analytical layer over a well-partitioned transactional core.

Closing and where to dig deeper

The conclusion is uncomfortable for legacy carriers and obvious for regionals: airline loyalty is a financial product with its own P&L, and most of the LCC LATAM market is treating it like a brochure. The top tier has already spent millions on IBS, Sabre and Comarch. In the Viva, Wingo, JetSMART, Plus Ultra, Star Peru and cargo tier — most of LATAM's operators — there is a gap that open-source Odoo closes at 5% to 10% of the enterprise platform cost.

The CIS case shows the Odoo + PostgreSQL + RFM + IFRS 15 architecture lifts retention by 22% when it is tuned right. The principles port to LATAM with corrections for multi-currency and fiscal localization.

To go deeper:

• Odoo implementation — methodology and pricing
• Odoo audit — diagnostic on an existing deployment
• Odoo + Analytics — RFM, churn prediction, loyalty metrics
• Odoo Perú — SUNAT CPE for aviation
• Odoo México — SAT CFDI 4.0 for airlines
• Odoo Colombia — DIAN factura electrónica for airlines
• Odoo Argentina — AFIP/ARCA loyalty deferred revenue
• QIC Data Warehouse case — related analytical architecture

If you are a CFO, Head of Loyalty or CIO at a regional LATAM carrier and you want a specific read on your deployment, request a 30-minute Odoo audit or read the author profile first.

Frequently asked questions