"Wij hebben een nieuw rekeningnummer." Een factuur die er precies zo uitziet als die van vorige maand, met één ander nummer. Wie dat overneemt, betaalt de oplichter, en betaalt de leverancier daarna nog een keer.
InvoiceStack vergelijkt het IBAN op elke inkoopfactuur met het IBAN van de leverancier in Visma eAccounting. Wijkt het af, dan gaat de factuur niet door. Hij blijft staan tot een mens beslist.
Het leest het rekeningnummer van de factuur en legt het naast het IBAN dat bij die leverancier in Visma eAccounting staat.
Dat gebeurt bij elke factuur, vóór er een concept in Visma komt. Is het hetzelfde nummer, dan gaat de factuur gewoon verder. Staan er meer nummers op de factuur en is het bekende nummer daar één van, dan is er niets vervangen en gaat hij ook verder.
Een nummer dat door een vlek of een slechte scan net anders gelezen is, haalt het controlegetal van het IBAN niet. Dan zegt InvoiceStack dat het waarschijnlijk een leesfout is en vraagt het je het nummer na te lezen. Het gokt niet welk cijfer het had moeten zijn.
De vergelijking staat altijd aan; er is geen schakelaar die hem uitzet. Hoe streng InvoiceStack daarna is, stel je per klant in.
Dan komt de volgende factuur van die leverancier op let op, ook als het nummer op de factuur gelijk is aan het nieuwe nummer in Visma.
Een controle tegen de stamgegevens heeft één zwakke plek: wie het nummer bij de leverancier in Visma omzet, maakt de vervalste factuur kloppend. Dat kan een medewerker zijn, of iemand die in het Visma-account kwam. InvoiceStack onthoudt daarom welk IBAN er bij de vorige factuur van elke leverancier stond.
Is het sindsdien veranderd, en ging dat niet via InvoiceStack met overtypen en verificatie, dan zie je het oude en het nieuwe nummer naast elkaar. Vraag na wie het wijzigde, en bel de leverancier op een nummer dat je al had.
Dan stopt de factuur. Er komt geen concept in Visma dat iemand zo kan doorboeken.
Op het factuurscherm staat welk nummer op de factuur staat en welk nummer bij de leverancier in Visma. Het advies is altijd hetzelfde: bel de leverancier op een nummer dat je al had, niet het nummer op deze factuur, en vraag of het klopt.
Staat het nummer van de factuur al bij een andere leverancier van dezelfde klant, dan zegt InvoiceStack dat erbij: vaak is dan de verkeerde leverancier gekozen, en geen nummer vervangen. Is de leverancier Nederlands maar het nummer van een buitenlandse bank, dan staat dat er ook bij. Dat kan kloppen, maar het is een bekend kenmerk van factuurfraude.
Daarna zijn er twee wegen. Klopt het nieuwe nummer, dan wijzig je het IBAN bij de leverancier, en dan wordt de factuur opnieuw gecontroleerd. Of je boekt alleen deze factuur toch, met het vinkje Verzend niet naar bank. Dan komt hij niet in een betaalbatch, blijft hij op let op, en leest InvoiceStack terug dat het vinkje in Visma echt staat. Die keuze staat in de audittrail.
Alleen een mens, per leverancier, en met weerstand: overtypen, verifiëren en waar je dat wilt een tweede akkoord.
Je typt het nieuwe nummer over van de factuur. Dat moet precies hetzelfde zijn, zodat er echt naar gekeken is. Per klant staat verificatie standaard aan: je legt vast dat je de leverancier hebt gebeld via een nummer dat je al had.
Per klant kun je een tweede akkoord aanzetten. Dan gaat de wijziging pas naar Visma als iemand anders hem goedkeurt: een beheerder, of een medewerker met het recht Akkoord geven. Wie het vraagt, kan het niet zelf goedkeuren. Het kan ook strenger: dan keurt alleen iemand van de klant zelf goed. In de audittrail staan beide namen.
Een factuur van een leverancier die nog niet in Visma staat, is ook een stop. Een nieuwe leverancier aanmaken kan alleen een mens, met het rekeningnummer van de factuur. Of daar verificatie bij verplicht is, stel je per klant in. Standaard staat die bij een nieuwe leverancier uit: er is dan nog geen eerder nummer om tegen te controleren, en een nieuwe leverancier komt vaak met een eerste bestelling die je zelf deed. Wil je het strenger, zet dan per klant de verificatie aan, of het tweede akkoord. Staat het nummer al bij een andere leverancier, of is het buitenlands bij een Nederlandse leverancier, dan zie je dat op het moment dat je beslist.
Een IBAN wijzigen gaat nooit vanzelf en nooit voor meer leveranciers tegelijk. Zo werken autorisatie en het tweede akkoord.
Ja, per klant. Standaard staat alles op het strengst; je zet het lichter waar dat past, en strenger waar je dat wilt.
Lichter: betaalt een klant zijn inkoopfacturen niet vanuit Visma, zoals een schilder die verf aan de kassa afrekent, zet dan bij die klant betaalbatches uit. Er hangt dan geen betaling aan het rekeningnummer. Een ontbrekend nummer is alleen een aantekening, en een afwijkend nummer is geen stop: InvoiceStack haalt het weg bij de leverancier en zet de factuur klaar met Verzend niet naar bank. Dat kan ook voor één leverancier, terwijl de klant verder met betaalbatches werkt. En de verificatie bij een IBAN-wijziging kun je per klant uitzetten; overtypen blijft altijd.
Strenger: een tweede akkoord op elke IBAN-wijziging en nieuwe leverancier, goedkeuren alleen door de klant zelf, en verificatie ook bij een nieuwe leverancier. Wie een IBAN mag wijzigen en wie Verzend niet naar bank mag kiezen, zijn aparte rechten per persoon.
Wat nooit verandert: elke factuur wordt vergeleken, een afwijkend nummer bij een klant die met betaalbatches werkt blijft staan tot een mens beslist, en een IBAN wijzigen doet altijd een mens. Elke instelling staat in de audittrail.
Meer over rechten, het tweede akkoord en goedkeuren door de klant
Als er langs die weg geen geld naar een verkeerde rekening kan.
Staat er op de factuur dat het bedrag wordt geïncasseerd, dan haalt de leverancier het geld zelf op. Het concept krijgt dan altijd Verzend niet naar bank, zodat hij niet ook nog in een betaalbatch komt. Is een bon al betaald, met de pin of iDEAL, dan is een ontbrekend nummer geen probleem; een afwijkend nummer blijft wel een stop.
Betaalt een klant een leverancier niet via betaalbatches, bijvoorbeeld omdat die altijd aan de kassa wordt afgerekend, dan is een afwijkend nummer geen stop. InvoiceStack haalt het nummer dan weg bij die leverancier in Visma en zet de factuur klaar met Verzend niet naar bank. Leegmaken is het enige wat InvoiceStack zelf aan een leverancier verandert.
Staat er op de factuur geen IBAN terwijl de leverancier er wel een heeft, of heeft de leverancier in Visma geen IBAN, dan komt de factuur op let op. Er is dan niets vervangen, maar iemand kijkt even of de factuur echt van die leverancier is. En het rekeningnummer van de klant zelf, dat soms op een factuur of creditnota staat, telt niet mee.
De bank kijkt bij het betalen of de naam bij het nummer hoort. InvoiceStack kijkt eerder, bij het boeken, of het nummer hetzelfde is als dat van de leverancier.
Sinds oktober 2025 controleren banken bij elke overboeking of de naam die je intypt bij het IBAN hoort. Dat vangt veel, maar niet alles. Een oplichter met een rekening op een geloofwaardige bedrijfsnaam komt erdoorheen. En na de waarschuwing mag je toch betalen.
Wie op een vervalst nummer betaalt, betaalt in beginsel twee keer: de leverancier wil zijn geld nog steeds. Of dat anders uitpakt, hangt mede af van de voorzorgsmaatregelen die je nam. Een vastgelegde controle per factuur, met wie wat besloot, is zo'n maatregel.
Het betaalt niets en zet zelf geen ander nummer bij een leverancier.
InvoiceStack zet een concept klaar in Visma eAccounting. Betalen doe je zelf, vanuit Visma of je bank. Een nieuw IBAN komt alleen bij een leverancier na de klik van een mens. Het bellen van de leverancier doet InvoiceStack ook niet voor je; het legt alleen vast dat het gebeurd is. En definitief boeken is altijd een klik van een mens, ook als alles groen is.
De vergelijking zelf niet: elke factuur gaat erlangs. Hoe streng InvoiceStack daarna is, stel je per klant in. Betaalt een klant niet vanuit Visma, zet dan bij die klant betaalbatches uit; dan houdt een ontbrekend of afwijkend nummer de factuur niet meer tegen. Dat kan ook voor één leverancier. Verificatie, een tweede akkoord en wie een IBAN mag wijzigen stel je ook per klant in.
Bel de leverancier op een nummer dat je al had, niet het nummer op de factuur. Klopt het, dan wijzig je het IBAN bij de crediteur vanaf de factuur: overtypen, verificatie vastleggen, en waar dat aanstaat een tweede akkoord. Daarna wordt de factuur opnieuw gecontroleerd.
De bank kijkt bij het betalen of de naam die je intypt bij het rekeningnummer hoort. Een oplichter met een rekening op een geloofwaardige naam komt daar doorheen, en je mag na de waarschuwing toch betalen. InvoiceStack kijkt eerder, bij het boeken, of het nummer hetzelfde is als dat van de leverancier in je eigen administratie. Dat is wat KVK en de Fraudehelpdesk aanraden.
Dan ziet InvoiceStack het bij de volgende factuur van die leverancier. Het onthoudt welk IBAN er bij de vorige factuur stond. Is dat veranderd, en ging dat niet via InvoiceStack, dan komt de factuur op let op met het oude en het nieuwe nummer.
Wie van de beheerder het recht IBAN wijzigen heeft. Per klant kun je verificatie verplicht maken, een tweede akkoord van iemand anders vragen, of alleen de klant zelf laten goedkeuren. Wie de wijziging vraagt, kan hem niet zelf goedkeuren.
Niet als concept dat zomaar doorgeboekt kan worden. Hij blijft staan tot iemand beslist. Kies je per factuur om hem toch te boeken, dan krijgt het concept het vinkje Verzend niet naar bank, zodat hij niet in een betaalbatch komt. InvoiceStack leest terug dat dat vinkje in Visma echt staat.
Op je eigen administraties. Een nieuw kantoor begint in droogloop: InvoiceStack zet niets klaar tot de beheerder dat bewust aanzet.