Sommige Telenet-klanten krijgen 'spookfacturen' uit het jaar 1900

Sommige klanten van de Belgische provider Telenet krijgen facturen uit het jaar 1900, meldt VRT NWS. Telenet zegt dat dit komt door twee IT-problemen die de provider op dit moment probeert op te lossen.

VRT NWS sprak met een van de klanten die last heeft van de problemen. Ze vertelt dat ze al drie jaar lang elke twee tot drie maanden een e-mail krijgt waarin staat dat ze een openstaande rekening van 1 januari 1900 moet betalen. Ze heeft Telenet meerdere keren benaderd. In eerste instantie zei het bedrijf dat ze de facturen moest betalen als deze op haar naam stonden. Later gaf Telenet aan dat zij de facturen kon negeren.

Een woordvoerder van Telenet bevestigt dat het bedrijf de facturen stuurt door 'technische problemen'. "Enerzijds gaat het om bepaalde herinneringen die de verkeerde datum van 1 januari 1900 weergeven en anderzijds kreeg mevrouw ook onterecht herhaaldelijk herinneringen van die melding", legt zij uit.

VRT heeft inmiddels ook van andere klanten gehoord dat zij 'spookfacturen' uit het jaar 1900 ontvangen. Telenet onderzoekt nu hoe groot het probleem is. De woordvoerder zegt dat de situatie vooralsnog zeer zeldzaam is, maar dat de provider de problemen helemaal wil oplossen.

Bron: Getty Images

Reacties (77)

[Killemov]

Ik vrees dat de meeste tweakers hier het mis hebben. Dit lijkt eerder op een vroege of een variant van de 2038 bug dan een late y2k-bug. De oorzaak van de y2k-bug waren natuurlijk simplistische implementaties door het gebruik van slechts de laatste twee cijfers van een jaar. De 2038-bug zou nog wel eens wat meer impact kunnen hebben voor systemen waar we niet direct bij kunnen, satellieten bijvoorbeeld.

[Pecunia-18]

ik denk dat er in 2038 nog maar heel weinig (tijd)systemen draaien op een 32-bit integer. MIsschien de oorspronkelijk klok van de tijdmelding van de PTT destijds, bel 002, 'bij de volgende toon is het 14 uur 27 minuten en 40 seconden "

Maar dan ben ik gelukkig echt met pensioen.... als het goed is

[CH4OS]

Maar dan ben ik gelukkig echt met pensioen.... als het goed is

Anders is dat dus een bug in de tijd weergave begrijp ik, als die datum niet gehaald wordt?

[AW_Bos]

De tijdmelding is sinds 10 jaar volledig digitale software, nadat het daarvoor een speciaal apparaat was.

[Pecunia-18]

Dank je, leuk om te weten/horen.
Mijn kinderen inmiddels allemaal uitgevlogen kunnen zich niet (meer) voorstellen dat zo’n beetje heel Nederland destijds gewoon ‘de tijd’ belde om de klok of het horloge gelijk te zetten.

[beerse]

Die pratende klok achter 002 deed niets met de datum, dat was alleen maar tijd. https://www.telecomerfgoed.nl/telecomcanon/index.php/vensters/2-weet-u-ook-hoe-laat-het-is

[CPV]

Lijkt me sterk: als de 2038 bug overflowt (waarom nu al) begint hij weer bij 1-1-1970.

1-1-1900 is het jaar nul van de IBM mainframe telling.

[Reactie gewijzigd door CPV op 17 juni 2026 14:31]

[FrankHe]

In meer databases wordt 1900-01-01 als standaardwaarde gebruikt voor een datumveld.

[Ablaze]

Lijkt mij ook sterk, maar je redenatie klopt niet helemaal.

Epoch timestamps zijn signed, niet unsigned. Een overflow na 2038 maakt de waarde negatief en brengt de datum terug naar 14 december 1901.

[beerse]

Volgens Wikipedia: Softwareprobleem jaar 2038 is de terug datum 13 december 1901, 20:45:52

Maar toegegeven, het is (net) geen 1 jan 1900.

[FrankHe]

1900-01-01 is gewoon een databaseveld waarin geen waarde is ingevoerd.

De 'meeste' systemen hebben 'ondertussen' een recente Linux kernel waarbij de epoch met 64 bit wordt opgeslagen in plaats van 32 bit. Het addertje onder het gras zijn de 'enkele' systemen waarbij dit 'nog' niet is gedaan of waarbij dit simpelweg niet mogelijk is. We hebben nog hooguit elf jaar om dat te regelen.

[wow7]

Als een datum niet gevonden kan worden door een fout , glitch of wat dan ook of wanneer het de werkelijke datum van een transactie verliest of niet kan berekenen dan komt er 01-01-1900. Dus de software die Telenet gebruikt heeft nul datum die 01-01-1900 gebruikt.

Het is dus een fout in de stoftware en geen 2038 bug * de Unix Epoch bug omdat het 01-01-1900 weergeeft en dus geen 1970 .

[rjmno1]

Ik dacht al dit leikend op een milenium bug maargoed,zo zie je maar weer dat ook in de moderne tijd nog altijd fouten voorkomen.

[beerse]

Het '2038' probleem gaat om de unix tijd met als middelpunt 1 jan 1970 en het aantal secondes in 32-bits (signed) formaat. Als daar iets mee fout gaat dan zal je datums zien van iets van 68 jaar voor en 68 jaar na 1 jan 1970. Dat komt wel dicht bij 1 jan 1900 maar net niet helemaal.

Als ik bedenk welke systemen bij issues mogelijk 1 januari 1900 gebruiken, dan is msExcel de eerste en voornaamste die bij mij in gedachten komt. Als daar de waarde 0 wordt omgezet naar een datum komt daar wel eens 1 januari 1900 uit. Daarmee is dat voor mij de hoofdschuldige. Wie heeft er andere software die 1 januari 1990 kan teruggeven bij issues met datums? En dan het liefst inclusief hoe/wanneer het optreedt.

Datum velden in databases hebben allemaal hun eigen offset. En vergeet niet dat er ook best veel software is geschreven waarbij zelf een datum veld is gedefinieerd door nummers en named-values (voor maanden).

[Aerkhanite]

Pfoe, herinneringskosten, administratiekosten, incassoboetes voor het laat 126 jaar te laat betalen, rente...

Wordt een dure grap voor die klanten.

[Toet3r]

Rekeningen voor diensten verjaren na 5 jaar in NL en ik denk dat België wel een vergelijkbare regel kent.
Dus veel plezier met het innen van de vordering.

[Lagonas]

Dit is inderdaad na 5 jaar, maar daar zit wel een dikke maar aan. Als je een klant schriftelijk aan de schuld herinnert door deze een brief te sturen, dan reset de verjaring en is die weer 5 jaar geldig. Of Telenet dit sinds 1900 gedaan heeft betwijfel ik

[Lothlórien]

Een e-mail valt ook onder schriftelijke communicatie lijkt me, dus daar is aan voldaan. Ik vraag me wel af voor wat voor soort dienst de factuur is. Telegraaf?

Dit is gewoon een slorrdige maar hardnekkige ICT fout, ééntje waarvan de gevolgen wellicht nog wat verder gaan want wie vertrouwt nu de facturen van een partij dat per abuis facturen uit 1900 verzend?

[D11]

Je moet het dan wel ieder 5 jaar herhalen na de bewuste datum. Daar is dus niet aan voldaan.

[dasiro]

Laat ze eerst maar eens bewijzen dat ze toen contractueel diensten hebben verleend waarvoor ze factureren. Het antidateren van een factuur is trouwens boekhoudkundige fraude, geen enkele advocaat van Telenet die daarvoor zijn gezicht in een rechtbank durft laten zien.

[Heroic_Nonsense]

In 1900 was ik minder dan minderjarig, dus ieder contract dat men weet op te hoesten op mijn persoon is per definitie ongeldig

[CH4OS]

Inflatie niet vergeten!

[pieterboes]

Als het bedrag nog in Franken staat vermeld, dan valt het misschien nog wel mee....

[Vuurvleugelhart]

https://www.janssen-janssen.nl wil dit wel gaan innen voor Telenet.

[Killemov]

Ah, ik dacht eerder aan https://www.tintin.com/nl/characters/jansen-en-janssen

[rjmno1]

lol

[Aegir81]

Een late Y2K-bug? ;-)

Vreemd dat dit eerst al jaren aansleept en dat Telenet de problemen 'helemaal wil oplossen' nu VRT NWS er aandacht aan besteedt 🙄

Telenet is zeker niet de goedkoopste in België, dus een betere klantenservice zou je toch mogen verwachten.

[Reactie gewijzigd door Aegir81 op 17 juni 2026 13:58]

[jongetje]

Dan had het 1970 moeten zijn (voor een Unix/Linux achtig systeem).

[CH4OS]

Dat betekend niet dat een database dat systeem ook gebruikt.

[FrankHe]

Een factuur uit 1900 klinkt meer als een leeg databaseveld waarbij 1-1-1900 als standaard waarde is ingesteld.

Over twaalf jaar verwacht ik facturen te ontvangen uit het jaar 1970. #epoch

Wikipedia: Softwareprobleem jaar 2038

[Yeshua]

De klantenservice van Telenet is al een tijd uitbesteed. Nog niet zo lang geleden een Surinaamse met krijsende kinderen in de achtergrond aan de lijn gekregen. Kon me niet helpen, maar toen ik opnieuw belde en een Vlaamse aan de lijn kreeg was het probleem binnen 10 minuten opgelost.

Vroeger was de klantenservice zeker niet slecht en werd er snel opgenomen, maar tegenwoordig volgen ze gewoon hun draaiboek zonder enige kennis van zaken. En het probleem met Nederlandse medewerkers: zij verstaan ons Vlaams niet en omgekeerd zijn ze ook niet altijd te verstaan en meestal arrogant op de koop toe. (Althans, dat is mijn ervaring.)

[Pasteis]

In eerste instantie zei het bedrijf dat ze de facturen moest betalen als deze op haar naam stonden. Later gaf Telenet aan dat zij de facturen kon negeren.

Degene die dit besloten had wist echt niet wat hij of zij aan het doen was.

Deze fout klinkt alsof er een variabele van tijd niet gevuld wordt en er een default waarde op 1-1-1900 ingesteld staat en daar dus op terugviel.

[Lothlórien]

of juist wel. Als hij of zij de weet dat je dit kan verklaren d.m.v. een foutje in een variabele dan weet je ook dat de rest van de rekening mogelijk wel klopt. Tijd genoeg om intern uit te pluizen wat er aan de hand is en er is geen noodzaak tot een incassoprocedure aangezien de klant gewoon heeft betaald.

Eventueel terugstorten als restpuntje is makkelijker, niet per sé klantvriendelijker, maar zeker makkelijker dan de incassoprocedure voor klant x op hold zetten omdat er mogelijk iets niet klopt.


Zelfs de fiscus werkt op deze manier: betaal maar vast en dan kijken we aan het eind van het jaar wel of het klopt.

[Pasteis]

Ja, dat vind ik dus nog steeds kwalijk. Het zal misschien niet om schrikbarende bedragen gaan, maar omdat je als bedrijf zelf een probleem heeft, moeten anderen het maar gaan voorschieten? Dat is de omgekeerde wereld (fiscus vind ik niet vergelijkbaar).

Dit probleem heb ik dus eerst een keer bij een telecombedrijf gehad. Abonnement afgesloten, maar de aanvraag bleef hangen dus mijn nr. werd niet geactiveerd, maar ik had wel het toestel al. Op advies van de klantenservice het abonnement gecancelled zodat hij opnieuw kon... toen kreeg ik een rekening wegens het opzeggen van mijn abonnement terwijl de looptijd nog niet voorbij was... of ik ruim 1000+ euro kon betalen.

Contact opgenomen... of ik de rekening eerst wilde betalen zodat zij het daarna terug zouden storten als het probleem aan hun kant opgelost was.

[Lothlórien]

Dat is inderdaad andere koek. Zoals ik het zie zijn zij nooit in staat geweest om te leveren wat jij had aangevraagd. Daarmee heb je op advies van klantenservice de aanvraag gecanceld en zou het voldoende moeten zijn de telefoon terug te leveren.

[Groningerkoek]

Dit vind ik een van de meest ergerlijke dingen, net als dat je verhuist of van leverancier veranderd in Januari, en dan krijg je vrolijk nog rekeningen in Februari en Maart, en als je dan belt "ja het systeem heeft tijd nodig, het is het beste dat u betaald en dan krijgt u dit later automatisch terug.."

Nee, nee en nogmaals nee, je zoekt het maar uit aan jullie kant. No way dat ik dat eerst betaal.

[PdeBie]

In eerste instantie zei het bedrijf dat ze de facturen moest betalen als deze op haar naam stonden.

Dat waren de eerstelijnmedewerkers die het draaiboek volgde waarschijnlijk.

[X-DraGoN]

Zelfs dan hoop ik dat er medewerkers van de servivedesk zitten die meer verstand hebben als alleen hun draaiboek te volgen en dat intern even aan de kaak te stellen. In plaats van te wachten tot het in de media komt en dan ineens te reageren.

Dan is het kwade reeds geschied en de reputatie van je bedrijf al naar de klote, mocht dat nog verder kunnen natuurlijk.

Ik ben zelf meer als 20 jaar klant geweest en recent veranderd en heb er nog geen seconde spijt van gehad. Ook op kabel, zonder limieten, met dezelfde snelheid tegen een lager tarief, het kan wel!

https://www.heytelecom.be/nl/internet-thuis

[Auredium]

De eerste lijn krijgt voor de eerste keer een klant met een spookfactuur. Denkt 'dat is vreemd' en loopt naar een afdelingshoofd. Die denkt; vreemd maar is wss een datumfoutje. Dus die zegt tegen de agent dat de klant moet betalen. Dan komen er meer en meer, die gaan naar de klachtenafdeling die weer verder communiceert op de achtergrond. Uiteindelijk levert het een oplossing op maar tot die oplossing er is en deze naar de eerste lijn is terug gecommuniceerd is normaliter het devies om het initiële draaiboek te volgen. Waarbij waarschijnlijk betaalde spookfacturen worden terug gestort en de overige worden geschrapt.

Dat is hoe ik vermoed hoe het zal gaan. Maar daar gaat dus wat tijd overheen en in de tussentijd wordt dan advies gegeven wat achteraf foutief was met de nieuwe informatie.

Dit soort perikelen zijn overigens schering en inslag bij bedrijven. Ieder bedrijf heeft wel een dergelijk oeps momentje om de zoveel jaren in meerdere of mindere maten. Vaak ligt het ergens op de achtergrond. Iets wat is gereset of geupdate diep in het systeem waarbij iemand niet doorheeft dat er een koppeling de mist in is gegaan.

[jongetje]

Of de eerste lijns denkt, wat vreemd, maar facturen moeten gewoon betaald worden. Einde gesprek en op naar het volgende want anders wordt ik afgerekend dat ik te lange gesprekken voer.

[Auredium]

Dat kan maar hangt vaak niet lang. Bij de tweede of derde zien ze een patroon en stappen ze alsnog naar 1 laag erboven. Maar over het algemeen wordt naar de default gehandeld (ook door de laag erboven) tot er een foutief patroon is vast gesteld. Dan kan het zijn dat er wordt gezegd dat mensen vooralsnog niet moeten betalen tot er een oplossing is. Maar ik begrijp wat je zegt en voor een deel klopt dat. De meeste mensen zullen echter ook aan de bel trekken intern als ze eerste lijn zijn. Patroonherkenning is een ding.

[mphilipp]

Of de eerste lijns denkt, wat vreemd.

Dat is inderdaad vreemd, een eerste lijns die denkt...

[robiebab]

Ik vermoed een fout in hun datawarehouse, waar een of meer tabellen met SCD type 2 voorkomen. Het eerste record begint met 1-1-1900, wat klopt, maar ze moeten ook de aanmaakdatum gebruiken bij het eerste record, niet de SCD-datum.

[FrankHe]

Bedrijven factureren 'doorgaans' niet vanuit het data warehouse, maar ik begrijp wat je wilt zeggen. In het bronsysteem, klantbeheer- en facturatiesysteem, is op één of andere manier een fout geslopen in het datumveld.

Een data warehouse is vrijwel uitsluitend een management informatiesysteem voor het genereren van rapportages en volgen van KPi's. Operationele processen worden nooit tot zelden uit een data warehouse gevoed.

[NoReason]

select CONVERT(date,'') geeft in MSSQL als resultaat: 1900-01-01

[WeirdScience]

Ik snap niet dat de systeembeheerders van Telenet niet eraan denken om de BIOS-batterij te vervangen op het moederbord van de server. Tijd & datum opnieuw instellen en "probleem" opgelost.

_{Het is een grap, but..you never know!}

[kodak]

Als ik me niet vergis is het strafbaar om verkeerde data toe te passen op facturen, niet slechts een foutje. Dat ze de facturen achteraf 'juist' willen maken klinkt leuk, maar ze hadden gewoon meteen de juiste factuurdata horen toe te passen. Correct facturen is absoluut geen vrijblijvendheid.

Je klanten opzadelen met onjuiste tot onwettige facturen terwijl het correct facturen juist een van de belangrijkste taken van een professionele organisatie is komt wat mij betreft overeen met niet in staat (willen) zijn om behoorlijke bedrijfsvoering en dienstverlening te leveren. Zeker als men kennelijk ook geen enkele serieuze moeite gedaan lijkt te hebben dit probleem te voorkomen voor de facturen de deur uit gingen.

En om opmerkingen als 'kan gebeuren' of 'als mensen het hadden gedaan zouden er ook fouten gemaakt worden'. Automatisering is geen excuus om de wet te overtreden en problemen bij je klanten te leggen en daarna pas alleen te verhelpen op een manier dat je als bedrijf zelf het beste uit komt. Dit zijn administratief nogal grove fouten.

[Reactie gewijzigd door kodak op 17 juni 2026 15:28]

[JazzKatua]

Al DRIE jaar een factuur; wat een bende AMATEURS bij telenet!
Zelf bewust overgestapt naar een andere provider, want inderdaad de 'service' bij telen-i-et is werkelijk beneden ALLE peil.