Valuta in je boekingssysteem regelen betekent één ding: klanten rekenen af in hun eigen valuta (presentment), terwijl jouw betaalprovider de settlement en de fx_rate vastlegt en rapporteert. Dat zijn twee losse processen die je apart moet registreren, niet één rekensom die je runtime uitvoert.
Het advies is kort: werk met een expliciet price book per valuta in plaats van live conversies op het moment van boeken. Heb je geen prijs klaarstaan voor een valuta, gebruik dan een vaste fallback currency met duidelijke PSP-presentment in plaats van een geïmproviseerde omrekening. Platforms zoals Raxbooker ondersteunen dat model al: vaste prijzen per valuta, gekoppeld aan de betaalprovider die de daadwerkelijke afhandeling doet.
Drie zaken bepalen of dit goed gaat:
- Prijzen staan vast per valuta, niet berekend op het moment van boeken.
- Bedragen worden opgeslagen in minor units (centen) met een ISO-4217 code erbij.
- Presentment en settlement worden allebei apart gelogd, inclusief de gebruikte wisselkoers.
Belangrijkste inzichten
Correcte valutaondersteuning in een boekingssysteem vereist een per-valuta price book, minor-unit opslag met ISO-4217 codes, en aparte registratie van presentment en settlement.
| Punt | Details |
|---|---|
| Presentment versus settlement | Leg altijd apart vast wat de klant ziet en betaalt, en wat er uiteindelijk wordt afgerekend door je PSP. |
| Werk met een price book | Stel per valuta een vaste prijs in, reken niet live om op het moment van boeken. |
| Sla bedragen correct op | Gebruik minor units met ISO-4217 codes, zodat geen enkel bedrag zonder valuta-context bestaat. |
| Beperk FX-timingrisico | Stem depositoschema's en quote-validity windows af op de wisselkoersvensters van je PSP. |
| Kies een geschikt platform | Raxbooker combineert price book, PSP-koppeling en rapportage in één systeem, zonder losse koppelstukjes. |
Inhoudsopgave
- Hoe werkt valuta in een boekingssysteem precies?
- Welke functies moet je eisen van je boekingssysteem?
- Hoe voer je valuta stap voor stap in?
- Lokale prijzen of één basisvaluta: wat kies je?
- Hoe voorkom je marge-erosie door wisselkoersen?
- Waarom de meeste adviezen over valutabeheer te technisch of te vaag zijn
- Multi-valuta regelen zonder losse koppelstukjes
- Bronnen
- Veelgestelde vragen
Hoe werkt valuta in een boekingssysteem precies?
Presentment is wat de klant ziet en betaalt: het bedrag in zijn eigen valuta, op het moment van boeken. Settlement is wat er uiteindelijk op jouw bankrekening belandt, vaak in een andere valuta en tegen een koers die pas later definitief wordt. Wie deze twee door elkaar laat lopen, krijgt vroeg of laat een rapportage die niet klopt met de bankafschriften.
De oplossing heet een price book: een tabel met expliciete, vooraf ingestelde prijzen per valuta. Geen enkel bedrag wordt op het moment van boeken omgerekend. Een dagtrip die in euro's een vaste prijs heeft, heeft een eigen, vastgestelde prijs in ponden of dollars, niet een real-time berekende variant. Dat voorkomt vreemde afrondingen en onvoorspelbare eindprijzen voor de klant.
Elk bedrag hoort te worden opgeslagen als minor unit (dus in centen, niet in euro's als decimaal getal) samen met de bijbehorende ISO-4217 valutacode. Dat klinkt overdreven technisch voor een boekingssysteem, maar het voorkomt precies het soort fouten dat leisurebedrijven het vaakst treft: een bedrag dat ergens in het systeem als "89" wordt behandeld zonder dat duidelijk is of dat euro's, dollars of yen zijn.
Drie momenten waarop je de wisselkoers vastlegt, en waarom het uitmaakt:
- Bij autorisatie – de koers op het moment dat de klant boekt en betaalt.
- Bij settlement – de koers die de bank of PSP daadwerkelijk hanteert bij afhandeling, vaak enkele uren tot dagen later.
- Bij rapportage – een gecachete koers die je gebruikt voor interne cijfers, nooit voor de klantprijs zelf.
Een goed ingericht ledger slaat presentment_minor, settlement_minor, de valutacodes én de fx_rate apart op, zodat je tot op de cent kunt reconciliëren wanneer de bank en het boekingssysteem niet exact hetzelfde bedrag tonen.
Welke functies moet je eisen van je boekingssysteem?
Niet elk boekingssysteem dat "meerdere valuta" claimt, doet dat op een manier die je marge beschermt. Een aantal functies zijn niet optioneel als je serieus internationale gasten bedient.
- Een price book met aparte prijsvelden en een eigen Price ID per valuta, zodat elke prijs los instelbaar en traceerbaar is.
- Een valutaswitcher die de valuta van de bezoeker automatisch detecteert, met een handmatige overschakeling die de klant altijd kan gebruiken.
- PSP-presentment support: je betaalprovider moet de klant kunnen factureren in zijn eigen valuta en dat via webhooks terugmelden aan je systeem.
- Een ledger die presentment_minor, settlement_minor én de gebruikte fx_rate per transactie bijhoudt, niet alleen een totaalbedrag.
- Ondersteuning voor zero-decimal currencies zoals de Japanse yen, en lokale formatteerregels (komma versus punt, symbool voor of na het bedrag).
Niet elk systeem ondersteunt elke valuta gelijk. Sommige boekingsplatforms dwingen één bedrijfsvaluta af en laten de klant enkel zien wat dat ongeveer is in zijn eigen geld, zonder dat de PSP daadwerkelijk in die valuta afrekent. Vraag dus expliciet door bij een leverancier: rekent de klant af in zijn eigen valuta, of wordt alleen een indicatie getoond?
Pro-tip: Vraag je leverancier om een voorbeeldtransactie in drie verschillende valuta te laten zien, inclusief het ledger-record erachter. Zie je geen aparte presentment- en settlement-velden, dan werk je met een schijnoplossing die bij de eerste koersschommeling voor rapportageproblemen zorgt.
Hoe voer je valuta stap voor stap in?
Een goede uitrol volgt een vaste volgorde. Sla je een stap over, dan ontdek je de gaten meestal pas als een klant al heeft betaald.
- Bepaal je mapping en fallbackbeleid: welke valuta hoort bij welk land, en wat gebeurt er als een klant een valuta kiest die je niet ondersteunt.
- Vul het price book met per-valuta prijzen en publiceer deze pas na controle door een tweede persoon.
- Configureer je PSP en test zowel de autorisatie- als de settlementflow apart, niet alleen de gecombineerde uitkomst.
- Controleer of de webhookdata daadwerkelijk presentment_currency, settlement_currency en fx_rate meestuurt.
- Bouw of controleer je ledger en reconciliatieproces voordat je live gaat.
- Draai een aantal proefuitbetalingen en reconcilieer die handmatig tegen de bankafschriften.
Test daarna de klantervaring apart van de techniek:
- Werkt de currency selector duidelijk, en toont deze het juiste symbool en de juiste notatie?
- Wordt de prijs vergrendeld op het moment van boeken, zodat een koersschommeling tijdens het afrekenen geen ander bedrag toont?
- Wat gebeurt er bij een refund: krijgt de klant terug in de valuta waarin hij betaalde, tegen welke koers?
Deze laatste vraag wordt vaak vergeten en leidt tot de meeste klachten achteraf. Een gids over mislukte betalingen oplossen helpt om dit soort scenario's vooraf te doordenken in plaats van pas bij het eerste incident.
Lokale prijzen of één basisvaluta: wat kies je?
Twee routes zijn mogelijk, en beide hebben een prijs. Presenteren in de lokale valuta van de klant voorkomt verrassingen: klanten die in een andere valuta worden gefactureerd, krijgen vaak te maken met extra fx-kosten van hun eigen bank, wat leidt tot verwarring en soms een mislukte betaling. Werken met één centrale valuta scheelt jou administratie, maar schuift die verborgen kosten door naar de klant.
Wat de keuze concreet beïnvloedt:
- PSP's en kaartnetwerken rekenen hun eigen fx-marge, vaak afhankelijk van het moment van conversie, niet van het moment van boeken.
- Presentment via je PSP (zoals bij grote providers gebruikelijk is) voorkomt dat de klant een dubbele conversie ondergaat: één keer door jouw systeem, één keer door zijn bank.
- Cache wisselkoersen voor interne rapportage met een vaste interval, maar gebruik ze nooit als basis voor de klantprijs zelf.
Stel daarnaast vaste afrondingsregels in per valuta. Een prijs van € 49,99 wordt in yen niet automatisch een net getal, en een boekingssysteem dat dat niet netjes afhandelt, toont uiteindelijk bedragen als ¥7.234 waar ¥7.200 logischer was geweest.
Hoe voorkom je marge-erosie door wisselkoersen?
Het grootste risico bij multi-valuta zit niet in de koers zelf, maar in de timing. Tussen het moment dat een klant een prijs ziet (de quote), de aanbetaling doet en de dienst daadwerkelijk levert, verschuift de koers vaak genoeg om marge te laten weglekken. Standaardiseer daarom:
- Een vaste quote-validity window: hoe lang een getoonde prijs geldig blijft voordat deze opnieuw wordt vastgesteld.
- Depositoschema's die aansluiten op je FX-vensters, zodat een aanbetaling niet weken los staat van de einddatum van de boeking.
- Batchgewijze uitbetalingen per valuta, in plaats van los per transactie, wat reconciliatie en staging van grote uitgaande betalingen een stuk overzichtelijker maakt.
- Een refundbeleid dat expliciet vermeldt tegen welke koers wordt terugbetaald bij annulering.
Pro-tip: Leg wijzigingen in koersen en refundbesluiten vast met tijdstempels in logbestanden. Bij een terugvorderingsverzoek van een klant of een chargeback ben je zo binnen een paar minuten klaar met bewijs in plaats van dagen te zoeken in oude e-mails.
Denk ook aan de link met depositobeleid: een tijdslotensysteem dat losstaat van je betaalflow maakt het lastiger om deposito's en FX-vensters op elkaar af te stemmen.
Waarom de meeste adviezen over valutabeheer te technisch of te vaag zijn
De meeste stukken over multi-valuta gaan óf helemaal op in boekhoudkundige journaalposten, óf blijven steken bij het advies "toon prijzen in de lokale valuta van je klant" zonder te zeggen hoe. Beide missen het punt voor een leisure-manager: jij hoeft geen valutaspecialist te worden, je moet weten welke vragen je aan je leverancier stelt en welke drie dingen structureel misgaan als niemand ze checkt.
Wat ik onderschat vind worden: de timing van deposito's. Iedereen praat over wisselkoersen als een getal dat toevallig verandert, maar het echte probleem is dat de meeste boekingssystemen geen enkele koppeling leggen tussen wanneer een aanbetaling binnenkomt en wanneer de koers wordt vastgezet. Dat gat, niet de koers zelf, veroorzaakt de meeste marge-erosie.
Prioriteer daarom in deze volgorde: eerst een kloppend price book met minor-unit opslag, dan een PSP die presentment daadwerkelijk ondersteunt, en pas daarna de fijnere operationele regels rond deposito's en refunds. Een systeem dat de eerste twee niet goed regelt, kan geen enkele operationele regel daarna nog repareren.
— Bernard
Multi-valuta regelen zonder losse koppelstukjes
Losse koppelstukjes tussen een boekingsmodule, een aparte betaalpagina en een los rapportagepakket zijn precies waar valutafouten ontstaan: elk onderdeel houdt zijn eigen versie van de waarheid bij. Raxbooker brengt price book, betaalkoppeling en rapportage in één systeem samen, zodat een prijs die je instelt in euro's, ponden of dollars overal hetzelfde bedrag toont, van boekingsbevestiging tot financieel overzicht.
Voor leisurebedrijven met internationale gasten betekent dat: prijzen per valuta instellen in het reserveringssysteem, een betaalprovider koppelen die presentment ondersteunt, en rapportages die presentment en settlement niet door elkaar husselen. Raxbooker helpt bij het opzetten en testen van die koppeling, inclusief de koppelvlakken met kassasystemen en CRM die de meeste leisurebedrijven al gebruiken. Bekijk de volledige functionaliteit voor leisurebedrijven en vraag een demo aan om te zien hoe je eigen valutastructuur er in de praktijk uitziet.
Bronnen
- FX Best Practices In Travel: Payments, Pricing, Timing | Xe Blog
- Multi-Currency Checkout & Localization | SaaS Billing
- SaaS Multi-Currency Pricing | Viprasol
Veelgestelde vragen
Wat betekent presentment currency in een boekingssysteem?
Presentment currency is de valuta waarin de klant het bedrag ziet en betaalt tijdens het boeken, los van de valuta waarin jij het geld uiteindelijk ontvangt via settlement.
Moet ik prijzen live omrekenen of vooraf vastzetten?
Zet prijzen vooraf vast in een price book per valuta. Live omrekenen bij het boeken leidt tot onvoorspelbare eindprijzen en maakt reconciliatie achteraf lastiger.
Welke gegevens moet mijn ledger bijhouden bij meerdere valuta?
Minimaal presentment_minor, presentment_currency, settlement_minor, settlement_currency en de gebruikte fx_rate per transactie, zodat je tot op de cent kunt controleren.
Ondersteunt elk boekingssysteem automatisch meerdere valuta?
Nee. Sommige systemen dwingen één bedrijfsvaluta af en tonen andere valuta enkel als indicatie. Raxbooker ondersteunt wél een echt per-valuta price book gekoppeld aan PSP-presentment.
Hoe voorkom ik verlies door wisselkoersschommelingen?
Standaardiseer quote-validity windows, stem depositoschema's af op je FX-vensters en batch uitbetalingen per valuta om timingrisico te beperken.