Om dubbele facturering tijdens een WHMCS-migratie te voorkomen, wijs je aan elke klant één systeem toe voor de volgende serviceperiode. Registreer de laatste factuur uit het oude systeem, de eerste nieuwe verlenging en eventuele betalingen die al in de wachtrij staan voordat je de vervangende facturering activeert. Het verplaatsen van klantgegevens houdt geen overdracht van de factureringsverantwoordelijkheid in en beëindigt geen bestaande betalingsovereenkomst.
Deze handleiding is bedoeld voor hostingproviders die de terugkerende facturering van klanten naar een nieuw portaal verplaatsen, terwijl een deel van de hostingautomatisering behouden blijft. De nadruk ligt op de overdrachtsdatum. Gebruik de ‘Checklist voor WHMCS-migratie’ voor een uitgebreider overzicht van gegevens en modules. Het onderstaande werkblad is een handmatig planningshulpmiddel, geen automatische WHMCS-importer.
Wat kan tijdens een WHMCS-migratie een dubbele afschrijving veroorzaken?
Een dubbele afschrijving kan het gevolg zijn van overlappende facturen, twee onafhankelijke terugkerende overeenkomsten of een herhalingspoging waarvan het resultaat nog niet is binnengekomen. De belangrijke vraag is welk systeem nog geld kan vragen voor dezelfde serviceperiode. Een succesvolle export geeft geen antwoord op die vraag.
De factureringslogica van WHMCS documenteert het genereren van facturen, vervaldata en automatische betalingspogingen. Controleer de geïnstalleerde versie en je instellingen voordat je de overdrachtsdatum selecteert. Er kan al een factuur bestaan voor een toekomstige periode, zelfs als de klant de verlengingsdatum nog niet heeft bereikt.
Maak onderscheid tussen een factuur en een betalingspoging. Twee facturen betekenen niet dat er twee succesvolle afschrijvingen zijn geweest, en één zichtbare factuur bewijst niet dat slechts één systeem kan incasseren. Controleer zowel de factureringsapplicaties als de daadwerkelijke transactiestatus bij de aanbieder. Een lopende incasso, een voltooide betaling en een mislukte betaling vereisen elk een andere vervolgactie.
Externe doorlopende overeenkomsten verdienen een aparte controle. WHMCS beschrijft optionele gateway-abonnementsbeheeren voor terugkerende afspraken die buiten WHMCS worden verwerkt. Module-ondersteuning en instellingen zijn van belang. Ga er niet vanuit dat het wijzigen van een servicerecord automatisch elke overeenkomst aan de kant van de provider annuleert.
Vermeld ook herinneringen, herhalingspogingen en opschortingstaken. Zelfs wanneer slechts één systeem incasseert, kunnen beide systemen de klant een e-mail sturen of een actie voor achterstallige diensten in gang zetten. Een overdracht die dubbele geldstromen voorkomt, kan klanten nog steeds in verwarring brengen als twee verschillende portalen verschillende saldi weergeven.
Leg elke verlenging apart vast
Gebruik één rij voor elke terugkerende dienst, in plaats van één rij voor een heel klantenaccount. Hosting, onderhoud en een domeinvernieuwing kunnen verschillende data en verantwoordelijkheden hebben. Gedeelde contactgegevens zijn handig om identiteiten te koppelen, maar maken de diensten niet onderling uitwisselbaar.
Download het CSV-bestand voor de overdracht bij verlenging. Het bevat Engelstalige kolomkoppen en fictieve voorbeeldrijen. Vervang de voorbeelden in je eigen exemplaar. Het is geen importformaat voor beide platforms en bevat geen betalingsgegevens.
| Veld | Fictief voorbeeld | Controleer vóór activering |
|---|---|---|
| Klant- en servicereferentie | Voorbeeld A / managed hosting | Moet overeenkomen met de daadwerkelijke dienst, niet alleen met een e-mailadres |
| Betaald tot | 31 oktober 2026 | Controleer de periode op de voltooide factuur |
| Laatste factuur uit het oude systeem | Hostingfactuur van oktober | Maak onderscheid tussen betaalde, onbetaalde en betwiste saldi |
| Eerste nieuwe serviceperiode | 1–30 november 2026 | Zorg ervoor dat deze periode geen andere facturatieverantwoordelijke heeft |
| Eerste nieuwe facturatiedatum | 1 november 2026 | Controleer de timing van de provider en openstaande pogingen |
| Gereedheid voor automatische betaling | Nader te bevestigen | Controleer de machtiging vóór incasso |
| Verantwoordelijke voor de hostinglevenscyclus | Bestaande hostingworkflow | Bepaal wie storingen en opzeggingen afhandelt |
Voeg het bedrag, de valuta, de belastingbehandeling en de persoon die verantwoordelijk is voor het goedkeuren van de rij toe. Deze velden voorkomen een migratie die qua datums correct is, maar qua totalen onjuist. Bij een jaarlijkse hostingovereenkomst die maandelijks wordt gefactureerd, moeten de daadwerkelijke contractuele gegevens en de informatie over de serviceperiode ook afzonderlijk worden vastgelegd.
Bewaar historische factuurreferenties. Het vervangen van een portaal mag het bewijs van wat er is gefactureerd en betaald niet wissen. Bepaal waar klanten oude documenten kunnen opvragen en hoe medewerkers vragen zullen beantwoorden over periodes die tot het vorige systeem behoren.
Breng bestaande facturen in overeenstemming voordat je begint met de vervangende facturering
Begin met een kleine groep waarvan je de gegevens afzonderlijk kunt controleren. Scheid onbetaalde historische schulden van de volgende verlenging. Het overzetten van een openstaand saldo naar een nieuw portaal en het aanmaken van een nieuwe afschrijving voor hetzelfde saldo is geen methode voor afstemming.
Vergelijk voor elke klant de oude factuur, de transactie van de leverancier en de serviceperiode. Registreer tegoeden en terugbetalingen apart. Een creditsaldo kan de volgende factuur compenseren; als alleen het bruto terugkerende bedrag wordt overgedragen, kan die koppeling verloren gaan. Laat de verantwoordelijke facturatiemedewerker beslissen hoe het saldo wordt overgedragen.
Controleer de periodes waarin facturen worden gegenereerd, niet alleen de vervaldata. Als er al een oude verlengingsfactuur is uitgegeven, beslis dan of die factuur het te innen document blijft of dat er een passende correctie nodig is. Volg je boekhoudproces en de geldende vereisten in plaats van records te verwijderen louter om het nieuwe dashboard er netjes uit te laten zien.
Voordat je een lopende poging wijzigt, vraag dan de huidige status op bij de leverancier. Een trage bevestiging kan op een mislukking lijken terwijl het geld nog onderweg is. Stuur de klant geen tweede te betalen factuur, alleen omdat de weergave van de eerste aanvraag nog niet is vernieuwd.
Houd uitzonderingen buiten de eerste groep. Betwiste betalingen, saldi in meerdere valuta’s en diensten met ongebruikelijke pro rata-berekeningen vereisen een afzonderlijke beoordeling. Het doel van een pilot is om een herhaalbare overdracht tot stand te brengen, niet om ingewikkelde rekeningen te verbergen binnen een groter migratietotaal.
Doorloop een fictieve maandelijkse hostingoverdracht
Stel dat Example Hosting managed hosting verkoopt voor € 29 per maand. Klant A heeft voor oktober betaald en moet vervolgens voor november betalen. Volgens het planningsrecord is oktober eigendom van WHMCS; PayRequest wordt pas eigenaar van november nadat de installatie en betalingscontroles zijn voltooid.
Controleer of het oude systeem de betaling voor november nog niet heeft aangevraagd. Als dat wel het geval is, los dan die bestaande factuur of poging op voordat je nieuwe facturering autoriseert. Wijzig de eerste nieuwe datum niet in vandaag, simpelweg omdat de klant vandaag is geïmporteerd. De importdatum en de datum waarop de betaling is verwerkt, dienen verschillende doelen.
Ga er voor klant B vanuit dat november al vooruit is betaald. De eerste nieuwe periode moet dan aansluiten op die betaalde periode, met inachtneming van de daadwerkelijke servicevoorwaarden. Een algemene regel als „alle klanten beginnen op 1 november“ zou ertoe leiden dat B wordt gefactureerd voor een periode die al gedekt was.
Stel voor klant C dat oktober nog onbetaald is. Zorg ervoor dat die schuld herkenbaar blijft als oktober. Stel de facturatieverantwoordelijke voor november apart vast en beslis hoe het achterstallige saldo wordt gecommuniceerd. Het activeren van het abonnement in een nieuw portaal betekent niet dat de oudere factuur is betaald.
Dit zijn originele voorbeelden, geen verslagen van voltooide PayRequest-migraties. Hun waarde ligt in de beslissingsregel: elke te betalen serviceperiode heeft één gedocumenteerde verantwoordelijke nodig, en eerder betaalde dekking moet zichtbaar blijven in het nieuwe schema.
Houd factureringswijzigingen gescheiden van beëindiging van de hosting
Gebruik het opzeggen van een dienst niet als een snelkoppeling om oude facturering uit te schakelen zonder de gevolgen daarvan te beoordelen. In de WHMCS-documentatie inzake opzegging wordt uitgelegd dat beëindiging van een dienst gepaard kan gaan met een provisioningmodule en bijbehorende toegang. Een factureringsmigratie mag niet per ongeluk uitmonden in het stopzetten van de hosting.
Leg vast welk systeem accounts aanmaakt, domeinverlengingen afhandelt en acties voor achterstallige diensten verwerkt. Als je WHMCS voor deze taken gebruikt, controleer dan hoe de factureringsresultaten daar terechtkomen. De aanwezigheid van een API of webhook betekent nog niet dat er een werkende integratie is; iemand moet de daadwerkelijke levenscyclus implementeren en controleren.
Beperk elke wijziging in de automatisering tot de goedgekeurde groep. Het uitschakelen van een algemene taak kan gevolgen hebben voor klanten die nog steeds via WHMCS worden gefactureerd. Houd een overzicht bij van gewijzigde instellingen en de beoogde reikwijdte, en laat een operator controleren wat er actief blijft voor nog niet gemigreerde accounts.
Gebruik de handleiding voor de overdracht bij opzegging wanneer klanten openstaande opzeggingsverzoeken hebben. Een klant die al heeft gevraagd om op te zeggen, mag tijdens de migratie niet stilletjes een nieuw, doorlopend abonnement krijgen.
Vertel klanten welke factuur en welk portaal ze moeten gebruiken
Stuur een kort bericht waarin het nieuwe factureringsportaal, de eerste betrokken periode en eventuele daadwerkelijk vereiste acties worden vermeld. Beloof niet dat alle opgeslagen betaalmethoden worden overgedragen. Gebruik de handleiding voor het opstellen van betalingsmandaten voordat je beslist of iemand opnieuw toestemming moet geven.
Een herbruikbaar bericht is: „Vanaf [eerste betrokken serviceperiode] wordt de facturering voor [dienst] verplaatst naar [nieuw portaal]. Uw eerdere facturen blijven beschikbaar op [locatie van documenten]. Uw volgende geplande bedrag is [bedrag en valuta] op [datum]. [Vermeld de bevestigde betalingsactie]. Als je twee facturen voor die periode ontvangt, neem dan contact op met [ondersteuningskanaal] voordat je nog een betaling verricht.”
Vervang elk veld tussen haakjes door de geverifieerde gegevens. Verstuur het sjabloon niet als een algemene mededeling wanneer klanten verschillende betalingstermijnen hebben. Groepeer de communicatie op basis van de daadwerkelijke overgangsperiode en leg afzonderlijke domeinverlengingen uit wanneer deze in het oude systeem blijven.
Bekijk de pagina van het openbare portaal vanuit het perspectief van een klant. Controleer de servicenaam, valuta, volgende datum en toegang tot de factuur. Een correcte interne spreadsheet is alleen nuttig als de klant overeenkomende informatie ziet en weet bij welk ondersteuningskanaal hij terecht kan met een vraag over de wijziging.
Controleer de eerste verlenging en bepaal wanneer je moet terugdraaien
De eerste verlenging is het moment waarop de planning samenkomt met een daadwerkelijk factureringsresultaat. Controleer de factureringsperiode, de transactie van de provider, het saldo van de klant en de hostingstatus samen. Als er een poging van de provider in behandeling is, wacht dan op een betrouwbaar resultaat voordat je besluit opnieuw te incasseren.
Stel een stopvoorwaarde vast voordat je de groep uitbreidt: onverklaarbare dubbele facturen, niet-overeenkomende bedragen, ontbrekende autorisatie of onjuiste toegang tot de dienst. Wijs iemand aan om de uitzondering op te lossen. Een kleinere, gecontroleerde migratie is gemakkelijker uit te voeren dan een grote batch waarvan de fouten door klanten worden ontdekt.
Terugdraaien vereist dezelfde verantwoordingsdiscipline als de lancering. Controleer lopende en voltooide pogingen in het nieuwe systeem voordat je de oude incasso opnieuw inschakelt. Het herstellen van de oude taak terwijl een nieuwe poging nog in behandeling is, kan de duplicatie veroorzaken die je juist probeerde te voorkomen.
Het ‘documentatie over abonnementsbetalingen’ van PayRequest maakt onderscheid tussen handmatig betaalde terugkerende facturen en automatische incasso via een geldige machtiging. Controleer dat onderscheid en het ‘demo van het portaal’, en stuur het ingevulde werkblad vervolgens naar de ‘migratiebeoordeling’.
PayRequest Business kost € 20 per maand en omvat het klantenportaal en terugkerende facturering. De standaard betalingskosten van het platform bedragen 0% zolang het betaalde abonnement actief is. Verwerkingskosten van de aanbieder worden apart in rekening gebracht; voor commissiebetalingen geldt een afzonderlijk tarief. Voltooi de accountconfiguratie en activeer Business bij het afrekenen. Het selecteren van Business tijdens de aanmelding geeft op zichzelf nog geen toegang tot de betaalde versie. Raadpleeg huidige prijzen voordat je je configuratie kiest.
Redactionele opmerking: AI heeft bijgedragen aan dit artikel en de illustratieve omslagafbeelding. De officiële documentatie is op 7 oktober 2026 gecontroleerd. Werkbladen en klantberichten zijn originele planningssjablonen. Alle voorbeelden zijn fictief; er zijn voor dit artikel geen daadwerkelijke afboekingen, klantmigraties of beëindigingen van hosting uitgevoerd.


