Hoe de CSV-Betalingsimporteur Betalingen Koppelt aan Facturen
In dit artikel
Bank- en betaalverwerker-exports gebruiken zelden dezelfde kolomnamen, en ze komen nooit met een factuur-ID erbij. Het importeren van zo'n CSV in Invoice Generator betekent het omzetten van een spreadsheet met "er is ergens een storting gebeurd op een bepaalde datum van iemand" naar een set betalingen die correct is gekoppeld aan de facturen die ze afbetaalden — en dat doen zonder dat een mens elke rij handmatig hoeft te koppelen. Hier is precies hoe die koppeling werkt, en waar deze bewust weigert te gokken.
Kolommen Herkennen Zonder Vast Sjabloon
De importeur vereist niet dat je CSV een specifiek schema volgt. Voor elk veld dat hij nodig heeft, controleert hij een korte lijst met veelvoorkomende koptekstaliassen en neemt de eerste die aanwezig is: een bedrag kan komen uit een kolom genaamd amount, credit, paid of deposit; een betaaldatum uit payment_date, date of posted_date; een naam van de betaler uit payer, name of client; een memo uit reference, description of memo. Daarom kun je meestal een CSV rechtstreeks exporteren vanuit je bank, Stripe of PayPal en die zonder aanpassingen importeren — de importeur doet het werk van raden welke van je kolommen wat betekenen, in plaats van je te vragen eerst koptekstlabels te hernoemen.
Rijen Die Worden Overgeslagen Voordat Matching Zelfs Begint
Niet elke rij in een geüploade CSV wordt een betalingsrecord. Elke rij waar het ontleedde bedrag geen geldig positief getal is, wordt stilletjes verwijderd voordat de matchingstap draait — een lege bedragcel, een niet-numerieke waarde, een nul of negatief cijfer (bijvoorbeeld een terugbetalingsregel) vallen allemaal in deze categorie. Dit is een bewuste filter: de taak van de importeur is stortingen omzetten in geregistreerde betalingen, niet elke rij van een willekeurig bankafschrift getrouw reproduceren, waarvan een deel kosten, overboekingen of andere ruis zal zijn die helemaal geen klantbetaling is.
De Matchingheuristiek Zelf
Voor elke rij die de bedragcontrole doorstaat, bouwt de importeur één string in kleine letters op uit de referentie, betalernaam, notities en de volledige ruwe rijgegevens van die rij, en controleert deze op twee manieren tegen elke factuur in de werkruimte. Eerst kijkt hij of het factuurnummer ergens in die samengevoegde tekst voorkomt — een veelvoorkomend geval wanneer het memo van de bankoverboeking van een klant het factuurnummer bevat dat je hem hebt gevraagd te vermelden. Als er geen match op factuurnummer wordt gevonden, valt hij terug op controleren of de klantnaam van de factuur voorkomt in de samengevoegde tekst en het betalingsbedrag binnen één cent van het factuurtotaal ligt. Beide signalen — naam en bedrag — moeten kloppen voordat dit tweede pad als match telt; alleen een betalernaam die opduikt, met een niet-kloppend bedrag, wordt niet als voldoende beschouwd.
Wat "Ongekoppeld" Eigenlijk Betekent
Een rij die geen van beide matchingpaden voldoet, wordt niet weggegooid — hij wordt nog steeds ingevoegd als betalingsrecord, alleen zonder gekoppelde factuur en met een status van "unmatched" in plaats van "matched". Die betaling is volledig zichtbaar in je betalingenlijst en kan later handmatig worden afgestemd op de juiste factuur, wat belangrijk is omdat de matchingheuristiek met opzet conservatief is: hij laat liever een betaling ongekoppeld dan deze verkeerd te koppelen aan de verkeerde factuur op basis van een vage gelijkenis. Als je CSV dubbelzinnige rijen bevat — een klant die meerdere bijna-identieke factuurbedragen in dezelfde maand betaalt, bijvoorbeeld — verwacht dan dat sommige daarvan als ongekoppeld terechtkomen en een handmatig duwtje nodig hebben.
Wat Er Gebeurt Bij een Succesvolle Match
Wanneer een rij wel matcht, tagt de importeur niet alleen de betalingsrij en stopt daar. Binnen dezelfde databasetransactie herberekent hij de betalingssnapshot van die factuur — het betaalde bedrag en de status — vanuit de volledige set gekoppelde betalingen die nu geregistreerd staan, en schrijft hij een vermelding in het controlepad die vastlegt dat een betaling is afgestemd via de CSV-import, apart van een betaling die handmatig één voor één is ingevoerd. Dit zorgt ervoor dat een via CSV geïmporteerde bulkbetaling zich, vanuit het perspectief van de factuur, identiek gedraagt aan een betaling die je met de hand hebt ingevoerd — de status van de factuur wordt op dezelfde manier bijgewerkt, ongeacht welk pad daartoe leidde.
Valuta Komt Uit de Rij, Niet Uit de Factuur
Elke geïmporteerde betaling registreert de valutacode en het valutasymbool die de rij specificeert — met USD en een dollarteken als terugvaloptie als de rij er geen bevat — in plaats van de valuta over te nemen van de factuur waaraan hij uiteindelijk wordt gekoppeld. In een werkruimte met één valuta komt dit onderscheid nooit naar voren, maar als je met meerdere valuta's werkt, is het de moeite waard om te controleren of je export een valutakolom bevat, aangezien een importeur-standaard van USD toegepast op een rij die eigenlijk een betaling in een andere valuta was, het daadwerkelijk betaalde bedrag zou onderschatten of overschatten zodra deze wordt afgestemd tegen het valutabewuste totaal van een factuur.
Waarom Dit Ontwerp Gemak Inruilt voor Voorzichtigheid
Een agressievere matcher zou aannemelijk meer rijen automatisch kunnen afhandelen — vage tekstmatching, gedeeltelijke bedragtoleranties, matching op datumnabijheid — maar elk van die versoepelingen verhoogt de kans dat een betaling op de verkeerde factuur terechtkomt, waardoor stilletjes de factuur van de ene klant als betaald wordt gemarkeerd terwijl de factuur van de daadwerkelijke betaler onaangeroerd blijft. Het huidige ontwerp van de importeur accepteert dat meer rijen ongekoppeld blijven in ruil voor een kans van bijna nul dat een verkeerde match ongemerkt doorglipt, met als redenering dat een betaling die ongekoppeld in je lijst staat een gemakkelijk, zichtbaar probleem is om op te lossen, terwijl een betaling die stilletjes aan de verkeerde factuur is toegeschreven het soort fout is dat maandenlang onopgemerkt kan blijven.
Gerelateerde Artikelen
Gekoppeld, Ongekoppeld, Afgestemd: Hoe Betalingsstatus Echt Werkt
Elke geregistreerde betaling draagt een status die bepaalt of deze überhaupt meetelt voor het betaalde bedrag van een factuur — en het verwijderen van een factuur verwijdert de betalingen niet, het ontkoppelt ze.
Waarom je Rapporten Aparte Totalen per Valuta Tonen
Er vindt nergens in de rapportagelaag een wisselkoersconversie plaats — dit is een bewuste ontwerpkeuze, geen ontbrekende functie.
Hoe het Belastingoverzicht Berekent wat je Verschuldigd Bent
Waarom het belastingoverzicht groepeert op factuurdatum in plaats van betaaldatum, en hoe belastbare omzet wordt afgeleid in plaats van opgeslagen.
De Psychologie van Betalingsvoorwaarden: Netto 15 vs. Netto 30 vs. Bij Ontvangst Verschuldigd
Begrijp de psychologie achter factuurbetalingsvoorwaarden, inclusief Netto 15, Netto 30, Bij Ontvangst Verschuldigd, boetes, opvolging, en zakelijke betalingsonderhandelingen.
Aanbetalingsfacturen 1001: Veilig Vooruitbetaling Veiligstellen Voordat Je een Project Start
Leer hoe je vooruitbetalingen in rekening brengt, aanbetalingsfacturen structureert, aanbetalingen koppelt aan eindsaldofacturen, en professioneel omgaat met klantweerstand.