Welcome, Guest
Username: Password: Remember me

TOPIC: FRST - RECOR

FRST - RECOR 09 jan 2014 08:50 #1


  • Posts:1
  • Rob's Avatar
  • Rob
  • Offline
Het duizelt mij een beetje met de FRST en de RECUR, maar misschien kan iemand het mij eenvoudig uitleggen aan de hand van mijn situatie:

Ik incasseer(de) maandelijks een huurbedrag van zo'n 300 klanten die een incasso verklaring getekend hebben.

Wat moet ik vanaf 1 feb anders doen mbt FIRST/RECUR?
- Moet ik de eerste incassoronde voor elke incasso een FIRST meegeven, en daarna alleen nog maar RECUR?
- Wanneer moet ik daarna nog een FIRST meegeven voor de bestaande klanten?
- Hoe ga ik om met een nieuwe klant? (Bij de eerste incasso, en die daarop volgen?)
The administrator has disabled public write access.

FRST - RECOR 09 jan 2014 09:12 #2

Dat ligt aan de fout die je op een incasso krijgt. Het duizelde mij ook :)

Er is een keten van (tenminste) 5 partijen: incassant - bank incassant - CSM - bank debiteur - debiteur.
Beide banken houden een administratie bij van incasso's. Bij een FRST worden eventueel extra controles gedaan, en worden de gegevens van de machtiging opgeslagen (bij beide banken). Bij een RCUR wordt minder gecontroleerd, maar moet de machtiging wel bekend zijn. Banken vullen die controles verschillend in.

Dus als een FRST qua inhoud geaccepteerd is door de bank van de debiteur, dan mag/moet een volgende als RCUR. Als er door fouten een incasso nooit de bank van de debiteur heeft bereikt, dan moet een volgende weer als FRST. Er zijn een heleboel types fouten (R-messages), de fouten die optreden voor de incasso-datum (pre-settlement, dit zijn volgens mij vooral fouten die opgemerkt worden door controles op rekeningnummer, incassoblokkades enz.) of daarna. Voor fouten pre-settlement moet je een volgende weer als FRST doen - de gegevens van de machtiging zijn immers nog niet in de database van de bank debiteur gekomen. Als er alleen een tijdelijke fout is die pas op of na incassodatum is (bijv. saldo-tekort, stornering door klant), dan mag de volgende als RCUR. En uiteraard ook als er geen fouten zijn.
Last Edit: 09 jan 2014 09:13 by Alex Hekstra. Reason: opslag gegevens machtiging verduidelijkt
The administrator has disabled public write access.
The following user(s) said Thank You: Rob
Time to create page: 0.244 seconds
Powered by Kunena Forum

Enigma Consulting