Crypto-betalingen afletteren tegen je facturen

Bij een bankoverboeking staat er een omschrijving bij: "factuur 2026-041". Bij een transactie op een blockchain staat die er niet. Je ziet een hash, een bedrag, een afzenderadres en een tijdstempel, en verder niets. Afletteren van cryptobetalingen betekent daarom dat jij het verband legt dat de betaling zelf niet meedraagt, en dat je het zo vastlegt dat het over twee jaar nog navolgbaar is.

Komt precies het juiste bedrag binnen van een klant die je kent, dan is dat seconden werk. In de praktijk komt er te weinig binnen, betaalt iemand twee facturen in één keer, of verschijnt er een adres dat je niet kent. Hieronder eerst hoe je de koppeling voorspelbaar maakt, dan de vijf gevallen die iedereen tegenkomt, en tot slot wat je bij het afletteren vastlegt.

Waarom er geen omschrijving bij een cryptobetaling zit

Een bankoverboeking is een bericht tussen twee banken met velden erin: bedrag, naam, IBAN, omschrijving. Een on-chain transactie is een instructie die zegt dat er van adres A naar adres B een aantal eenheden van een munt of token gaat. Wat je terugkrijgt is een transactiehash, het bedrag, de betrokken adressen en het tijdstip van het blok, in UTC. Er is geen veld waarin "factuur 2026-041" past.

Er zijn uitzonderingen, maar minder dan mensen denken. XRP kent een destination tag, Stellar een memo, en een paar andere netwerken hebben iets vergelijkbaars, vooral omdat exchanges duizenden klanten achter één adres bedienen. Bitcoin en Ethereum hebben zo'n standaardveld niet, en waar het wel bestaat moet de wallet of exchange van je klant het ook ondersteunen én invullen. Vragen kan, erop bouwen niet.

Wat je wél hebt is het ontvangende adres: het enige stuk informatie in de transactie waar jij vooraf invloed op hebt. Daar draait de rest van dit artikel om.

Maak de koppeling voordat je hem nodig hebt

De betrouwbaarste methode is één ontvangstadres per factuur. Een moderne wallet leidt uit dezelfde seed een onbeperkt aantal adressen af; je gebruikt er een nieuw voor elke factuur en zet dat in de betaalinstructie. Komt er iets binnen op dat adres, dan weet je meteen bij welke factuur het hoort, ook als het bedrag afwijkt, in twee delen komt of van een onbekende afzender komt. Het adres ís de referentie.

Werk je met één vast adres, dan val je terug op bedrag, tijdstip en bevestiging van de klant. Bij lage volumes kan dat, maar het wordt onbetrouwbaar zodra twee klanten in dezelfde week een vergelijkbaar bedrag sturen. Spreek dan af dat de klant je de transactiehash mailt zodra hij betaalt; dat kost hem tien seconden en scheelt jou het meeste giswerk. Het helpt ook om vooraf duidelijk te zijn over wat er op een factuur in USDC of bitcoin hoort.

Neem factuur 2026-041: € 1.450 exclusief btw, € 304,50 btw, totaal € 1.754,50. De klant betaalt in USDC op Polygon en op het moment van bevestiging is de koers 1 EUR = 1,08 USDC, dus 1.894,86 USDC. Aan die factuur laten we hieronder zien wat er misgaat.

Deelbetalingen

Er komt 1.000,00 USDC binnen, drie weken later nog eens 894,86 USDC. Twee transacties, twee hashes, één factuur.

Houd de factuur als één post en hang er meerdere ontvangsten aan, elk met eigen hash, tijdstip, koers en eurobedrag. De eerste 1.000 USDC is bij koers 1,08 gelijk aan € 925,93. De tweede tranche komt binnen bij koers 1,10 en is € 813,51. Samen € 1.739,44, tegenover een factuur van € 1.754,50.

Let op wat er níet verandert: je omzet blijft € 1.450 en je btw blijft € 304,50. Die volgen uit de factuur, niet uit wat er toevallig binnenkwam. Het verschil van € 15,06 is een koersverschil dat je apart boekt. Splits een factuur dus nooit in tweeën om het kloppend te maken.

Eén betaling, twee facturen

Dezelfde klant heeft ook factuur 2026-047 openstaan: € 605,00 inclusief btw, oftewel 653,40 USDC. Hij maakt alles in één keer over, 2.548,26 USDC, één hash.

Je splitst die ontvangst in je administratie, niet op de blockchain. Leg dezelfde transactiehash bij beide facturen vast, met per factuur het toegewezen bedrag, en noteer dat het om een gesplitste ontvangst gaat, met verwijzing naar de andere factuur. Wie later één van de twee opzoekt, ziet meteen dat de hash ook elders voorkomt en waarom.

Een bedrag dat net te laag is

Bij factuur 2026-052 van € 2.420 inclusief btw verwacht je 2.637,80 USDT bij koers 1 EUR = 1,09 USDT. Er komt 2.632,80 USDT binnen: vijf USDT te weinig, oftewel € 4,59.

Bijna altijd zijn dat opnamekosten: de klant betaalde vanaf een exchange en die trekt haar opnamevergoeding van het verzonden bedrag af. Vanuit een eigen wallet gebeurt dat meestal niet: dan betaalt de afzender de netwerkkosten los, bovenop het bedrag. Wat je ziet hangt dus af van waar je klant vandaan betaalt.

Laat een factuur niet openstaan voor € 4,59. Merk hem als betaald, boek het tekort als betalingsverschil op een aparte rekening en ga door; je btw verandert niet, want die volgt de factuur. Zie je structureel tekorten, dan is dat geen boekhoudprobleem maar een afspraakprobleem: zet in je betaalvoorwaarden dat de klant de kosten draagt.

Een betaling op een ander netwerk

Je vroeg om USDC op Polygon en er komt niets binnen, maar de klant zegt dat hij betaald heeft en stuurt een hash.

Bij EVM-netwerken, zoals Ethereum, Polygon, Arbitrum, Base en Optimism, is hetzelfde adres op elke keten geldig. Een betaling die naar "jouw adres" ging op Arbitrum staat dus gewoon op jouw adres, alleen op een keten die je niet bekeek. Je voegt het netwerk toe in je wallet en de tokens verschijnen. Voor je administratie is het een normale ontvangst, met het feitelijke netwerk vastgelegd, niet het afgesproken netwerk.

Buiten de EVM-familie ligt het anders. Een Solana- of Tron-adres heeft een ander formaat, dus daarheen kan een klant niet per ongeluk sturen met jouw Ethereum-adres in de hand: zo'n transactie komt niet tot stand, of het geld belandt ergens waar je niet bij kunt. Dat is geen afletterprobleem meer. Vermeld daarom altijd het netwerk expliciet in je betaalinstructie, naast de munt.

Een afzender die je niet herkent

Er staat 653,40 USDC op je adres, vanaf een adres dat je nooit eerder zag, en zonder naam erbij.

Match dan op bedrag en tijdstip en bevestig het bij de klant. Eén mail, "ik zie 653,40 USDC binnenkomen op 14 maart om 11.02 uur, is dat jouw betaling van factuur 2026-047?", en dat antwoord bewaar je bij de transactie. Dat antwoord is je koppeling, het adres alleen niet.

Bouw daarnaast een adresboek op: zodra een betaling bevestigd is, leg je het afzenderadres bij die klant vast, zodat je hem de volgende keer meteen herkent. Dat is een aanwijzing, geen bewijs. Betaalt je klant vanaf een exchange, dan is het adres van de exchange, kan het per opname wisselen en kan het door duizenden anderen gedeeld worden. Een bekend adres maakt afletteren sneller, niet zeker.

Wat je vastlegt op het moment van koppelen

Afletteren is pas af als de koppeling zelf is vastgelegd. Leg per gekoppelde betaling zeven dingen vast: factuurnummer, transactiehash, netwerk, het ontvangende en het verzendende adres, de munt met het exacte aantal eenheden, het bevestigingstijdstip, en het eurobedrag met de koersbron die je gebruikte.

Daar komt bij, en dat wordt het vaakst vergeten, waaróm je die koppeling hebt gelegd: bij een deelbetaling het toegewezen bedrag en het restant, bij een gesplitste betaling de andere factuur, bij een tekort waar je het geboekt hebt, bij een onbekende afzender de bevestiging van de klant. Een afgeletterde regel zonder reden is een aanname, en een aanname van twee jaar geleden reconstrueer je niet meer.

Reken het tijdstip consequent om. Blockchains loggen in UTC en je administratie loopt in Nederlandse tijd; in de zomer scheelt dat twee uur, genoeg om een betaling van 1 januari 00.30 uur in het verkeerde kwartaal te laten vallen. En doe het meteen: een betaling van gisteren letter je af met de mail van de klant nog in beeld, een van acht maanden geleden op basis van een bedrag dat ongeveer klopt.

Precies dit handwerk, inkomende transacties opzoeken, omrekenen naar euro's, aan de juiste factuur hangen, deelbetalingen en tekorten uitzoeken en de koppeling documenteren, is waar stbl admin voor gemaakt is. Het volgt je wallets over meerdere netwerken, waardeert elke ontvangst op het bevestigingstijdstip tegen een vaste koersbron, stelt de match met de openstaande factuur voor en legt hem vast inclusief hash, koers en toewijzing, ook bij deelbetalingen en gesplitste betalingen. Je sleutels blijven van jou: stbl admin is niet-custodiaal en raakt je geld nooit aan. De Pro-versie kost € 49 per maand exclusief btw.