Hoe vindt de matching van leverancier of klant plaats?
Het relatie selectie algoritme wordt toegepast in de processen tussen Lyanthe's Scanstreet en het IBA Robotics platform / Boekportaal MFO. Het algoritme probeert aan de hand van de uitgelezen factuur een bestaande klant of leverancier te bepalen vanuit de stamgegevens van de desbetreffende administratie.
Om de gedigitaliseerde gegevens van een factuur te matchen met een relatie (leverancier of klant) wordt dit algoritme toegepast. Het bestaat uit een beslisboom om facturen nauwkeurig te koppelen aan de juiste leverancier of klant. Deze beslisboom maakt gebruik van velden, zoals KVK, BTW, IBAN, postcode en naam. Dit algoritme werkt met vooraf gedefinieerde regels en consistente manier van gegevensverwerking, waarbij verschillende stappen en criteria in een specifieke volgorde worden doorlopen. Deze zorgen voor een uniforme en gestructureerde aanpak bij het verwerken van de inkomende relatie data. Hieronder vindt u de uitleg van de beslisboom van het leveranciers/klant algoritme.
Beslisboom
Het algoritme gebruikt een reeks selectiecriteria om de gedigitaliseerde gegevens te koppelen aan de juiste leverancier of klant. De stappen van de beslisboom zijn:
- KVK-matching
- BTW-matching
- 100% naam match
- IBAN- en postcodematching
- IBAN-matching
- 70% Naam- en Postcodematching
- 70% Naam matching wanneer masterdata in MFO leeg is (enkel leveranciers)
- 70% Naam OCR Direct matching (enkel voor leveranciers)
De uitwerking van deze stappen is hieronder gespecificeerd en waarbij er onderscheid is in scenario's met en zonder third-party code¹.
Tip: Wordt er een nieuwe relatie voorgesteld op basis van bovenstaand algoritme, terwijl al een relatie bestaat? Controleer de bestaande relatie in het boekhoudpakket en vul deze aan (KVK, BTW nummer, naam) in het boekhoudpakket. Synchroniseer vervolgens de administratie. Toekomstige boekingsvoorstellen worden dan gegenereerd op de bestaande relatie.
1. KVK-matching
- Voorbewerking: Spaties, komma’s, punten en andere speciale tekens worden verwijderd uit het KVK-nummer.
- Één enkele gevonden: De leverancier/klant zal gematcht worden.
- Meerdere matches met third-party code:
- IBAN wordt als eerste gecontroleerd (indien het een gevalideerde IBAN betreft).
- Vervolgens wordt gekeken naar de laatst geboekte factuur.
- Als er geen laatst geboekte factuur is, wordt de eerste aangemaakte record gekozen.
- Meerdere matches zonder third-party code:
- De leverancier/klant die het eerst bekend is, wordt geselecteerd.
Indien er geen match wordt gevonden in stap 1, wordt automatisch stap 2 toegepast.
2. BTW-matching
- Voorbewerking: Spaties, komma’s, punten en andere speciale tekens worden verwijderd uit het BTW-nummer.
- Één enkele gevonden: De leverancier/klant zal gematcht worden.
- Meerdere matches met third-party code:
- IBAN wordt als eerste gecontroleerd (indien het een gevalideerde IBAN betreft).
- Vervolgens wordt gekeken naar de laatst geboekte factuur.
- Als er geen laatst geboekte factuur is, wordt de eerste aangemaakte record gekozen.
- Meerdere matches zonder third-party code:
- De leverancier/klant die het eerst bekend is, wordt geselecteerd.
Indien er geen match wordt gevonden in stap 2, wordt automatisch stap 3 toegepast.
3. 100% Naam match
- Voorbewerking: Bedrijfsnamen worden ontdaan van rechtsvormen (zoals "BV" of "NV") en speciale tekens.
- Één enkele gevonden: De leverancier/klant zal gematcht worden.
- Meerdere matches met third-party code:
- IBAN wordt als eerste gecontroleerd (indien het een gevalideerde IBAN betreft).
- Vervolgens wordt gekeken naar de laatst geboekte factuur.
- Als er geen laatst geboekte factuur is, wordt de eerste aangemaakte record gekozen.
- Meerdere matches zonder third-party code:
- De leverancier/klant die het eerst bekend is, wordt geselecteerd.
Indien er geen match wordt gevonden in stap 3, wordt automatisch stap 4 toegepast.
4. IBAN- en Postcodematching
- Voorbewerking: IBAN moet gevalideerd zijn. Spaties en speciale tekens worden verwijderd uit zowel de IBAN als de postcode.
- Één enkele gevonden: De leverancier/klant zal gematcht worden.
- Meerdere matches met third-party code:
- Eerst wordt gekeken naar de laatst geboekte factuur.
- Zonder laatst geboekte factuur wordt de eerst aangemaakte record gekozen.
- Meerdere matches zonder third-party code:
- De leverancier/klant die het eerst bekend is, wordt geselecteerd.
Indien er geen match wordt gevonden in stap 4, wordt automatisch stap 5 toegepast.
5. IBAN matching
- Voorbewerking: IBAN moet gevalideerd zijn. Spaties en speciale tekens worden verwijderd.
- Één enkele gevonden: De leverancier/klant zal gematcht worden.
- Meerdere matches met third-party code:
- Eerst wordt gekeken naar de laatst geboekte factuur.
- Zonder laatst geboekte factuur wordt de eerst aangemaakte record gekozen.
- Meerdere matches zonder third-party code:
- De leverancier/klant die het eerst bekend is, wordt geselecteerd.
Indien er geen match in stap 5 gemaakt wordt automatisch stap 6 toegepast.
6. 70% Naam- en Postcodematching
- Voorbewerking: Er wordt gebruikgemaakt van een 70% naamovereenkomst gecombineerd met de postcode. Rechtsvormen en speciale tekens worden verwijderd uit de naam, en spaties worden verwijderd uit de postcode.
- Één enkele gevonden: De leverancier/klant zal gematcht worden.
- Meerdere matches met third-party code:
- Eerst wordt gekeken naar de laatst geboekte factuur.
- Zonder laatst geboekte factuur wordt de eerst aangemaakte record gekozen.
- Meerdere matches zonder third-party code:
- De leverancier/klant die het eerst bekend is, wordt geselecteerd.
Indien er geen match wordt gevonden in stap 6, wordt stap 7 toegepast voor leveranciers. Voor klanten wordt er een nieuwe klant (contact) voorgesteld nadat er bij stap 6 geen match is.
7. 70% Naam matching wanneer masterdata in MFO leeg is (enkel leveranciers)
- Toepassing: Deze stap wordt alleen gebruikt als de masterdata in MFO (KVK, BTW & postcode) leeg is. Indien een van deze velden wel gevuld is, wordt deze stap overgeslagen. Bedrijfsnamen worden ontdaan van rechtsvormen (zoals "BV" of "NV") en speciale tekens.
- Één enkele gevonden: De leverancier/klant zal gematcht worden.
- Meerdere matches met third-party code:
- Eerst wordt gekeken naar de laatst geboekte factuur.
- Zonder laatst geboekte factuur wordt de eerst aangemaakte record gekozen.
- Meerdere matches zonder third-party code:
- De leverancier/klant die het eerst bekend is, wordt geselecteerd.
Indien er geen match wordt gevonden in stap 7, wordt stap 8 toegepast indien het een factuur is die middels OCR Direct uitgelezen wordt. In de alle andere gevallen wordt er een nieuwe leverancier (contact) voorgesteld.
8. 70% Naam OCR Direct matching (enkel voor leveranciers)
- Toepassing: Deze stap wordt gebruikt bij facturen die geüpload worden via OCR-direct. Er wordt gezocht naar een 70% naamovereenkomst. Bedrijfsnamen worden ontdaan van rechtsvormen (zoals "BV" of "NV") en speciale tekens.
- Één enkele gevonden: De leverancier/klant zal gematcht worden.
- Meerdere matches met third-party code:
- Eerst wordt gekeken naar de laatst geboekte factuur.
- Zonder laatst geboekte factuur wordt de eerst aangemaakte record gekozen.
- Meerdere matches zonder third-party code:
- De leverancier/klant die het eerst bekend is, wordt geselecteerd.
Wanneer er na stap 8 geen match is gevonden wordt er een nieuwe leverancier (contact) voorgesteld.
Verwerkingsregels
1. Verwijderen van business types
Tijdens de verwerking worden rechtsvormen zoals "BV" en "NV" verwijderd om een zuivere naamvergelijking mogelijk te maken. Hierdoor kunnen bedrijfsnamen zonder juridische toevoegingen beter worden gematcht. Landaliassen, zoals "BV" en "SRL," worden eveneens in acht genomen.
2. Verwijderen van speciale tekens
Het algoritme verwijdert speciale tekens zoals koppeltekens, en-dashes en leestekens om consistentie te waarborgen. Cijfers en Latijnse letters worden behouden, evenals enkele specifieke symbolen zoals enkele spaties.
3. Landgebaseerde filtering
Als het land van herkomst wordt meegegeven vanuit het inputkanaal, wordt dit in elke stap van het selectieproces meegenomen. Hierdoor kunnen land-specifieke regels correct worden toegepast.
¹ Een relatie met een third-party code is een relatie die reeds bekend is in het boekhoudpakket. De third-party code is de unieke identifier van desbetreffende relatie in de specifieke administratie.