Quando você vende numa moeda e paga em outra: protegendo a margem do câmbio
As taxas oscilam, o real anda, o euro segue lógica própria. Se você trava o preço do cliente hoje e paga o fornecedor 90 dias depois — quem carrega o risco cambial?
Turismo é um negócio com um hiato longo entre "vendido" e "pago". O cliente paga hoje, o hotel é pago 30 dias antes do check-in, o guia é pago depois do evento, o restaurante é faturado a posteriori. Nesse meio tempo, o câmbio pode mexer 5%, 10%, num dia ruim 15%.
E se você tem moedas diferentes em pontas diferentes do negócio, sua margem evapora sem você participar.
Onde, de fato, o problema se esconde
O caso mais comum: você vende em EUR (ou USD), mas paga a maioria dos custos em moeda local — RUB, KGS, GEL, BRL. Exemplo simples.
Em abril o cliente compra um pacote por €2.500. Margem planejada 25% — €1.875 vai para fornecedores, €625 fica com você. Na hora da venda isso parece, digamos, R$ 14.000 em pagamentos a fornecedores ao câmbio de R$ 5,60 por euro.
Em julho, quando você paga os mesmos fornecedores, o câmbio subiu para R$ 6,30. Os mesmos €1.875 agora custam R$ 11.812. Parece sorte.
Mas a outra cara da moeda. Suponha que seu cliente pagou parcialmente em real ao câmbio do dia, enquanto sua nota era em euros. Se o câmbio for na direção contrária — você ganha €420 em vez de €625. A margem se mexeu 30% e você não fez nada.
Isso não é teoria. Aparece toda alta temporada nos grupos de financeiro de operadoras.
O que significa "travar o câmbio"
Em banco, FX lock é um contrato a termo: o banco garante uma taxa em data futura. Em vida de operadora é mais simples: você registra qual taxa essa reserva específica usa, e nunca recalcula essa reserva, aconteça o que acontecer no mercado.
Funciona nas duas direções. Se a taxa anda a favor, você ganha mais que o plano. Se anda contra, você vê com antecedência exatamente quanto de margem está perdendo, e decide o que fazer: renegociar com fornecedor, mover datas, subir preço para clientes futuros.
A chave é não confundir duas coisas: uma reserva no câmbio antigo, outra no câmbio novo. Reprocessar todo histórico "no câmbio de hoje" é inferno no Excel e mentira absoluta no relatório gerencial.
De onde tirar o câmbio
Aqui é importante — não invente uma "taxa média de mercado". Você precisa de uma fonte externa que dê para apontar no contrato com cliente e nos relatórios gerenciais.
Para o mercado russo, o padrão é o Banco Central (CBR). A taxa é tirada na data de pagamento ou na data do lock, e essa linha vive no audit log: "nesta data a taxa era essa, porque o BC disse."
Na zona do euro o equivalente é o ECB. Nos EUA, o Fed. No Reino Unido, Bank of England. No Brasil, o PTAX do BC. Seu caso de negócio é seu, a regra é a mesma: a taxa precisa ser verificável de uma terceira fonte.
Alternativa arriscada — usar a taxa do site do fornecedor. Tecnicamente conveniente porque o fornecedor calcula igual, mas juridicamente frágil: se ele atualizar retroativamente, você também tem números diferentes nos livros retroativamente. Lugar onde você não quer estar.
O que precisa existir no sistema
Implementação mínima útil:
Tabela de taxas com data e fonte. Todo dia entra um snapshot fresco do CBR e ECB. Sem "médias" — taxas pontuais com a fonte na coluna.
Lock na reserva ou na cotação. Quando você emite a reserva (ou cotação oficial), o sistema registra: esse negócio usa câmbio X travado, fonte Y, data Z. Esse lock nunca muda.
Lock separado para cotações. Entre "mandei cotação para o cliente" e "cliente fechou", passam dias. O câmbio pode andar nesses dias. Se você mandou em euros e o cliente paga ao câmbio do dia uma semana depois, decida na frente: trava no momento da cotação (a gente carrega o risco) ou recálculo no pagamento (o cliente carrega). Sem decisão explícita — os dois carregam e os dois ficam insatisfeitos.
Audit log em todo recálculo. Se alguém de fato recalcular uma reserva antiga, o log registra: quem, quando, por quê. Não é burocracia — é para que seis meses depois numa disputa com cliente ou auditoria fiscal você consiga explicar de onde saiu o número.
Como funciona no INITE Travel
Na Phase 8 subimos FxRate (puxa diariamente do CBR e ECB via cron) e FxLock (congelado em quote OU booking, nunca os dois). A conversão em lib/fx.ts tem três saídas: forward, inverso pelo par recíproco, e null quando não há ponte entre as moedas — null é mais honesto que um número inventado.
E qualquer coisa de pagamento passa pelo nosso inite-billing-service. Stripe, Tinkoff, YooKassa, SBP — a escolha está no billing, não no app. Não amarramos a integração a nenhum provedor específico, porque em 2026 o cardápio de meios de pagamento de uma operadora russa pode mudar três vezes em um ano.
Se você está montando seu próprio stack — a coisa mais simples para fazer hoje: subir uma tabela daily_fx_rate com duas fontes e uma booking_fx_lock que prende uma moeda à outra. A partir disso dá para falar de analytics de margem sem surpresas no fim de temporada.