Data mapping uitgelegd: waarom velden tussen twee systemen nooit vanzelf matchen

Door Clen Mourik

Je boekhouding kent 'Kostenplaats', je ERP noemt het 'Projectcode'. Klinkt hetzelfde, maar je systemen praten langs elkaar heen. Data mapping legt vast welk veld waar naartoe gaat — en waarom die vertaalslag het verschil maakt tussen een werkende koppeling en een duur digitaal rommelhok.

Hoeveel uur per week besteed je aan het overtypen van gegevens? Orders van je webshop naar je boekhouding. Werkbonnen uit je projectsysteem naar je facturatiemodule. Voorraadmutaties van je ERP naar je verkoopkanalen. Elke keer dezelfde handeling, omdat systeem A niet begrijpt wat systeem B bedoelt.

Het probleem zit niet in de systemen zelf. Beide werken prima. Het probleem is dat ze verschillende talen spreken. Waar je boekhoudprogramma een 'Debiteurennummer' verwacht, stuurt je CRM een 'KlantID'. Wat in je productie-ERP een 'Artikelcode' heet, is in je verkoopsysteem een 'SKU'. Zonder vertaling praten ze langs elkaar heen.

Dat is wat data mapping doet: het legt vast welk veld in systeem A overeenkomt met welk veld in systeem B. En hoewel dat simpel klinkt, zit daar het verschil tussen een koppeling die werkt en een koppeling die constant crasht of — erger — stilletjes foute data doorstuwt.

Inhoudsopgave

• Belangrijkste punten
• Wat is data mapping precies?
• Waarom velden nooit vanzelf matchen
• Vier praktijkvoorbeelden uit verschillende sectoren
• Hoe werkt data mapping technisch?
• Vijf fouten die je geld kosten
• Wanneer heb je data mapping nodig?
• Wat kost het en hoe lang duurt het?
• Veelgestelde vragen

Belangrijkste punten

Wat is data mapping precies?

Data mapping is het proces waarin je vastlegt welk veld in systeem A overeenkomt met welk veld in systeem B. Klinkt simpel, en in theorie is het dat ook. Je maakt een tabel of schema waarin staat: veld X gaat naar veld Y. In de praktijk komt daar meer bij kijken.

Volgens Tools4ever gaat het niet alleen om het koppelen van velden, maar ook om transformeren: "In database A wordt een geboortedatum opgeslagen in het veld 'birth_date' in het formaat 12-10-1998. Deze datum wordt dan in database B gemapt naar het veld 'date_of_birth' met het formaat 12oct1998."

Die transformatie is cruciaal. Je koppelt niet alleen 'adres' aan 'address', je vertaalt ook de structuur, het formaat en soms zelfs de betekenis. Een BTW-percentage van 21% moet misschien worden omgezet naar BTW-code 'H'. Een voorraadaantal in kilogram wordt in het verkoopsysteem weergegeven in stuks. Een projectcode uit je ERP wordt een kostenplaats in je boekhouding.

Wat ik in de praktijk vaak zie: bedrijven denken dat een koppeling 'plug and play' is. Je sluit twee systemen aan en alles werkt. Totdat blijkt dat orders met kortingscodes vastlopen, of dat artikelen zonder EAN-code niet worden herkend. Dan pas wordt duidelijk hoe essentieel goede data mapping is.

Bij elke systeemintegratie die wij bouwen, begint het met data mapping. Voordat er één regel code wordt geschreven, maken we een mapping-document waarin precies staat welke velden waar naartoe gaan, welke transformaties nodig zijn, en wat er gebeurt als een veld leeg of ongeldig is.

Waarom velden nooit vanzelf matchen

Als je twee systemen aan elkaar koppelt, waarom weten ze dan niet automatisch wat 'klantnaam' of 'orderbedrag' is? Dat lijkt toch universeel?

Het probleem zit in drie dingen:

1. Elk systeem gebruikt eigen terminologie

Wat in AFAS een 'Relatiecode' heet, is in Exact Online een 'Debiteurennummer'. Een 'SKU' in je webshop is een 'Artikelnummer' in je ERP en mogelijk een 'Productcode' in je boekhouding. Drie namen voor hetzelfde ding, maar geen enkel systeem herkent de andere term automatisch.

Dat geldt niet alleen voor namen. Ook de structuur verschilt. Een adres kan in het ene systeem één veld zijn ('Straat 12, 1234 AB Plaats'), terwijl het andere systeem drie aparte velden heeft: 'Straat', 'Huisnummer', 'Postcode'. Die data moet je splitsen of samenvoegen tijdens de mapping.

2. Dataformaten verschillen fundamenteel

Een datum kan DD-MM-YYYY zijn, of YYYY-MM-DD, of een Unix timestamp. Een bedrag kan '€ 1.234,56' zijn of '1234.56' zonder valutasymbool. Een BTW-percentage kan numeriek (21) of tekstueel ('Hoog tarief') of als code ('H') worden opgeslagen.

Zonder transformatieregels crasht de koppeling, of — gevaarlijker — slaat het foute data op. Een order van 12-10-2024 wordt dan bijvoorbeeld geïnterpreteerd als 10 december in plaats van 12 oktober.

3. Er bestaat geen universele standaard

In sommige sectoren bestaan standaarden (EDI in transport, HL7 in zorg), maar die worden lang niet altijd gebruikt. En ook binnen standaarden zijn er variaties en optionele velden die systeem A wel en systeem B niet ondersteunt.

Het gevolg: bij elke integratie moet je opnieuw vastleggen hoe de vertaling werkt. Er is geen shortcut.

Vier praktijkvoorbeelden uit verschillende sectoren

Voorbeeld 1: Webshop + boekhouding (e-commerce)

Een webshop met 100 orders per dag draait op WooCommerce. De boekhouding staat in Exact Online. Zonder koppeling typt iemand elke order handmatig over. Bij 5 minuten per order kost dat 500 minuten per dag, ruim 8 uur. Bij een medewerker à €25 per uur is dat €200 per dag puur aan dubbele invoer, ofwel ruim €50.000 per jaar.

Maar een koppeling bouwen zonder data mapping werkt niet. Het veld 'shipping_address_1' in WooCommerce heeft geen automatisch equivalent in Exact. Het BTW-percentage (21% vs 9%) moet worden vertaald naar de juiste BTW-code. Kortingscodes uit de webshop moeten als aparte factuurregels worden doorgegeven.

De oplossing: een mapping-tabel waarin precies staat welk WooCommerce-veld naar welk Exact-veld gaat, inclusief transformatieregels voor BTW, valuta en kortingen. Pas dan werkt de integratie betrouwbaar.

Voorbeeld 2: Productie-ERP + verkoopsysteem (maakindustrie)

Een productiebedrijf gebruikt intern een ERP met artikelnummers als 'ART-00312-B'. Naar klanten toe werken ze met verkoopbare SKU's zoals 'SKU-9912'. Beide codes verwijzen naar hetzelfde product, maar de systemen weten dat niet.

Zonder mapping herkent het verkoopsysteem binnenkomende orders niet. De voorraad in het ERP wordt niet gekoppeld aan de beschikbare voorraad in het verkoopkanaal. Het gevolg: klanten bestellen artikelen die niet leverbaar zijn, of productie loopt door terwijl er geen vraag is.

Zoals FasterCapital uitlegt: "Als het ene systeem bijvoorbeeld 'CustomerID' gebruikt en het andere 'ClientNumber', maakt u een toewijzingsregel om deze discrepantie af te handelen." In dit geval: een mapping-tabel die ART-00312-B vertaalt naar SKU-9912, inclusief transformatie van eenheden (kg intern, stuks extern).

Voorbeeld 3: HR-systeem + boekhouding (personeelsadministratie)

Een dienstverlenend bedrijf met 60 medewerkers gebruikt AFAS voor HR en Exact Online voor financieel. Medewerkersinformatie staat in beide systemen, maar in een andere structuur.

AFAS heeft 'MedewerkerNummer' en 'Dienstverband_startdatum'. Exact Online werkt met 'Relatiecode' en 'InDienst'. Zonder mapping weet de koppeling niet dat deze velden bij elkaar horen. Bovendien moet worden vastgelegd welk systeem leidend is: als een medewerker zijn adres wijzigt, waar wordt dat aangepast? En synchroniseert dat dan automatisch naar het andere systeem?

Volgens AIMS Improve is de oplossing: "Spreek met jezelf af dat het CRM altijd leidend is voor NAW-gegevens." In dit geval: AFAS is leidend voor HR-data, Exact voor financiële data, en de mapping legt vast hoe wijzigingen worden doorgegeven.

Voorbeeld 4: Voorraad webshop vs. fysieke winkel (retail)

Een retailer verkoopt zowel online als in een fysieke winkel. Het voorraadveld in het ERP heet 'StockQuantity' (een getal). De webshop werkt met 'stock_status' (tekst: 'in stock' of 'out of stock').

Data mapping moet niet alleen de velden koppelen, maar ook een transformatieregel bevatten: als StockQuantity > 0, dan 'in stock'. Als StockQuantity = 0, dan 'out of stock'. Wordt die regel niet correct ingesteld, dan verkoopt de webshop producten die niet op voorraad zijn, of toont het 'out of stock' terwijl er nog 50 stuks liggen.

Bij Wux leggen ze het zo uit: "Een goede ERP-integratie voorkomt dit: de voorraad wordt direct gesynchroniseerd, zodat je nooit meer verkoopt wat je niet op voorraad hebt."

Hoe werkt data mapping technisch?

De meeste moderne integraties gebruiken API's (REST met JSON-data) om systemen met elkaar te laten praten. AFAS biedt bijvoorbeeld Get Connectors en Update Connectors waarmee andere systemen data kunnen ophalen of updaten.

Data mapping gebeurt in drie stappen:

Stap 1: Extract — data ophalen uit het bronsysteem

Het integratieplatform (middleware of iPaaS zoals Make.com, APIcenter of n8n) haalt data op via de API van systeem A. Die data komt binnen in het formaat dat systeem A gebruikt, bijvoorbeeld JSON met veldnamen als 'customer_id', 'order_date', 'line_items'.

Stap 2: Transform — data omzetten naar het doelformaat

Hier gebeurt de mapping. Het platform past transformatieregels toe:

• 'customer_id' wordt 'DebiteurNummer'
• 'order_date' (YYYY-MM-DD) wordt omgezet naar DD-MM-YYYY
• 'line_items' met BTW 21% krijgt BTW-code 'H'
• Lege velden krijgen een standaardwaarde of triggeren een foutmelding

Deze transformaties staan vastgelegd in mapping-tabellen of scripts. Bij complexere koppelingen kunnen dat honderden regels zijn.

Stap 3: Load — getransformeerde data naar het doelsysteem sturen

De middleware stuurt de getransformeerde data via de API naar systeem B. Als alles goed is gemapt, accepteert systeem B de data en slaat het op. Gaat er iets mis (ontbrekend verplicht veld, fout formaat), dan krijg je een foutmelding.

Bij een klant van ons zagen we dat de orderfoutenratio daalde van 8% naar minder dan 1% na de koppeling. Het verschil? We hadden een uitgebreide validatie- en transformatielaag gebouwd die elke order controleerde voordat die werd doorgestuurd.

Real-time vs. batch synchronisatie

Niet alle data hoeft real-time gesynchroniseerd te worden. Voorraadwijzigingen na een orderplaatsing moeten direct, anders verkoop je iets wat er niet is. Maar productcatalogus-updates kunnen prima eens per dag of per uur.

Real-time sync betekent: elke mutatie triggert direct een API-call. Dat is snel, maar ook belastend voor beide systemen. Bij hoge volumes (Black Friday met duizenden orders per uur) loop je tegen rate limiting aan: systemen hebben limieten om overbelasting te voorkomen.

Batch sync bundelt mutaties en stuurt ze periodiek door. Dat is efficiënter, maar minder actueel. Welke aanpak je kiest, hangt af van je processen. Voor een branche-specifieke aanpak kijk je naar de kritische momenten: wanneer moet data echt actueel zijn?

Vijf fouten die je geld kosten

Fout 1: Starten zonder vast te leggen welk systeem leidend is

Bij een two-way sync — waar beide systemen data kunnen wijzigen — moet je per veld bepalen wie de baas is. Staat de juiste klantnaam in het CRM of in de boekhouding? Wie mag het adres aanpassen?

Zonder die afspraak overschrijven systemen elkaar. Het nieuwe adres in het CRM wordt vervangen door het oude adres uit de boekhouding. Of andersom. Het gevolg: data-inconsistentie en medewerkers die niet meer weten welk systeem de waarheid bevat.

De oplossing: maak een matrix waarin staat welk systeem eigenaar is van welk veld. Bijvoorbeeld: CRM is leidend voor NAW-gegevens, ERP voor voorraad, boekhouding voor factuurdata. En leg vast hoe conflicten worden opgelost.

Fout 2: Aannemen dat dezelfde naam ook dezelfde structuur betekent

Twee systemen kunnen allebei een veld 'Geboortedatum' hebben, maar het formaat verschilt: DD-MM-YYYY vs. YYYY-MM-DD vs. Unix timestamp. Zonder transformatieregel crasht de koppeling of slaat het foute data op.

Datzelfde geldt voor valuta (€ symbool vs. numeriek), BTW (percentage vs. code), eenheden (kg vs. stuks), en adresvelden (één tekstveld vs. aparte velden voor straat/huisnummer/postcode).

Test niet alleen de happy flow (alles ingevuld, correcte formats), maar ook de randgevallen: lege velden, onbekende waardes, speciale karakters in namen.

Fout 3: Rommelige brondata rechtstreeks doorkoppelen

Een integratie kopieert bestaande data. Als je stamdata vol dubbele klantrecords staat, inconsistente artikelnummers bevat, of verouderde BTW-codes gebruikt, krijg je een geautomatiseerd rommelsysteem.

Zoals Wux waarschuwt: "Zorg dus eerst dat het opschonen van je data op de agenda staat." Saneer je brondata voordat je gaat koppelen. Verwijder dubbels, corrigeer inconsistenties, vul ontbrekende verplichte velden aan.

Fout 4: Geen foutafhandeling inrichten voor ongeldige data

Wat gebeurt er als een verplicht veld leeg is? Of als een BTW-code niet wordt herkend? Of als een artikelnummer ontbreekt? Zonder expliciete foutafhandeling crasht de koppeling of — erger — slaat het ongeldige data op.

Bouw validatieregels in: controleer of verplichte velden zijn ingevuld, of formaten kloppen, of waardes binnen het toegestane bereik vallen. En bepaal wat er moet gebeuren bij fouten: order in een wachtrij zetten voor handmatige review? Standaardwaarde invullen? Foutmelding sturen?

Een integratie zonder foutafhandeling is geen integratie, maar een tikkende tijdbom.

Fout 5: Live gaan zonder uitgebreid testen op randgevallen

MKB-bedrijven testen vaak alleen de standaard scenario's: een order met alle velden ingevuld, een artikel met EAN-code, een klant met compleet adres. Maar de praktijk brengt: artikelen zonder EAN, klanten met twee adressen, orders met deelleveringen, speciale karakters in namen, giftverpakking, kortingscodes.

Elk randgeval vereist aparte mapping- of transformatieregels. Test systematisch: wat gebeurt er bij lege velden? Bij onbekende waardes? Bij extreem hoge aantallen? Bij speciale tekens?

Een goede test omvat minimaal 50 scenario's, inclusief alle denkbare uitzonderingen. Pas dan weet je of je mapping betrouwbaar is.

Wanneer heb je data mapping nodig?

Elke keer dat je twee systemen aan elkaar koppelt, heb je data mapping nodig. Geen uitzonderingen. Maar de complexiteit verschilt:

Een simpele webshop-koppeling met standaard producten en orderflows is relatief overzichtelijk. Een multi-channel retailer met 200.000 artikelen, 15 verkoopkanalen en complexe prijslogica vraagt maanden mapping-werk.

Wanneer is het de investering waard? Maak een simpele berekening: hoeveel uur per week besteed je nu aan handmatig overtypen? Vermenigvuldig dat met je uurloon. Tel daar de foutkosten bij op (verkeerde facturen, gemiste orders, voorraadverschillen). Vergelijk dat met de eenmalige investering in een koppeling plus eventuele maandelijkse kosten voor de middleware.

Bij meer dan 5 uur handmatig werk per week verdient een koppeling zich meestal binnen 6-12 maanden terug. Bij meer dan 20 uur per week is het een no-brainer.

Wat kost het en hoe lang duurt het?

De kosten van data mapping hangen af van complexiteit en volume:

• Standaard koppeling (bijv. WooCommerce → Exact Online met standaard orderflow): €2.000 - €5.000 eenmalig + €50-150/maand middleware
• Maatwerk integratie (bijv. productie-ERP → verkoopsysteem met custom transformaties): €5.000 - €15.000 eenmalig + €100-300/maand
• Enterprise koppeling (multi-channel, hoog volume, complexe logica): €15.000 - €50.000+ eenmalig + €300-1000/maand

Volgens Semso bespaart alleen al het automatiseren van gebruikersaccounts 30 minuten per account. Extrapoleer dat naar orders, facturen, productregels: de tijdwinst loopt snel op.

De doorlooptijd hangt af van de kwaliteit van je brondata. Als je stamdata op orde is (geen dubbels, consistente codes, complete velden), kun je in 2-4 weken een standaard koppeling live hebben. Is je data rommelig, dan kan het opschonen langer duren dan het bouwen van de koppeling zelf.

Wil je weten wat het voor jouw situatie kost? Neem dan contact op voor een vrijblijvend adviesgesprek. We kijken dan samen naar je systemen, processen en datavolumes.

Veelgestelde vragen

Kan data mapping niet automatisch met AI?

AI kan suggesties doen op basis van veldnamen en datatypes, maar de definitieve mapping moet je zelf controleren. AI herkent niet dat jouw 'Projectcode' hetzelfde is als 'Kostenplaats' in het andere systeem, of dat BTW-codes bedrijfsspecifiek zijn ingedeeld. Mapping vraagt domeinkennis die alleen jij hebt.

Wat gebeurt er als ik na de koppeling een veld toevoeg in één systeem?

Dan moet de mapping worden aangepast. Nieuwe velden worden niet automatisch doorgegeven. Je bespreekt met je integratieleverancier of het nieuwe veld moet worden gekoppeld, en zo ja, naar welk veld in het andere systeem. Dit is onderhoudswerk dat bij elke koppeling hoort.

Hoe weet ik of mijn data geschikt is voor automatisering?

Exporteer een steekproef van 100 records en controleer: zijn verplichte velden consistent ingevuld? Zijn er dubbele records? Kloppen formaten (datums, bedragen, codes)? Als meer dan 10% van je records incompleet of inconsistent is, begin dan eerst met opschonen.

Kan ik data mapping zelf doen of heb ik een specialist nodig?

Voor eenvoudige koppelingen tussen bekende systemen (bijv. Shopify → Exact via een standaard connector) kun je het zelf met tools als Zapier. Voor maatwerk, complexe transformaties of bedrijfskritische data is een specialist verstandig. De kosten van foute mapping zijn hoger dan de investering in expertise.

Wat is het verschil tussen data mapping en data migratie?

Data mapping legt de structuur vast: welk veld gaat waarheen. Data migratie is het daadwerkelijk overzetten van bestaande data van oud naar nieuw systeem. Bij migratie gebruik je mapping om te bepalen hoe oude data wordt getransformeerd naar de nieuwe structuur. Mapping is dus onderdeel van migratie, maar ook van lopende integraties.

Data mapping: de stille reden waarom koppelingen werken of falen

Het verschil tussen een integratie die werkt en één die constant problemen geeft, zit bijna altijd in de kwaliteit van de data mapping. Niet in de gekozen technologie, niet in de snelheid van de API's, maar in hoe zorgvuldig je hebt vastgelegd welk veld waarheen gaat en hoe data wordt getransformeerd.

Dat vraagt tijd, aandacht en domeinkennis. Je moet je processen begrijpen, je data kennen, en weten wat er kan misgaan. Maar die investering betaalt zich dubbel en dwars terug: in tijd die je bespaart, fouten die je voorkomt, en rust die je krijgt omdat systemen doen wat ze moeten doen.

Wil je weten hoe data mapping eruitziet voor jouw specifieke systemen en processen? Of heb je vragen over een bestaande koppeling die niet lekker loopt? Plan dan een vrijblijvend adviesgesprek. We kijken dan samen naar je situatie en bespreken wat er nodig is om je systemen betrouwbaar met elkaar te laten praten.

Meer lezen over systeemintegraties? Bekijk onze kennisbank met praktische artikelen over koppelingen, automatisering en procesoptimalisatie. Of bekijk direct welke integratiecombinaties we al hebben gerealiseerd.