Welk systeem heeft gelijk bij verschillen?

Dezelfde klant staat in het CRM op de Industrieweg en in Exact Online op de Nijverheidsstraat. Het CRM zegt betaaltermijn 30 dagen, de boekhouding 14. De contactpersoon in het CRM is vorig jaar vertrokken; in de boekhouding staat zijn opvolger, want die belde over een factuur. Geen van beide systemen is fout. Ze zijn allebei juist geweest op een ander moment, en niemand heeft afgesproken welk moment telt.

De vraag "welk systeem heeft gelijk" heeft daar geen antwoord op, omdat hij verkeerd is gesteld. Gelijk hebben is niet iets van een systeem maar van een gegeven. Het CRM kan gelijk hebben over de contactpersoon en tegelijk ongelijk over de betaaltermijn.

Bron is een eigenschap van een gegeven, niet van een pakket

In gegevensbeheer heet het systeem dat over een bepaald gegeven het laatste woord heeft het system of record: de gezaghebbende bron voor dat ene gegevenselement. De beschrijving noemt ook waarom systemen uit elkaar lopen: ze bedoelen met hetzelfde veld iets anders, ze worden op verschillende momenten bijgewerkt, of er zit een fout in de overdracht. Alle drie zijn in een klantkaart voorstelbaar. "Adres" is in het CRM het bezoekadres en in de boekhouding het factuuradres; de accountmanager werkt zijn kaart bij na een bezoek en de administratie de hare na een factuur; en de export van twee jaar geleden heeft een kolom verschoven.

De bron wordt aangewezen, niet gevonden; het is een afspraak. Een bruikbare vuistregel voor die afspraak is: de bron is het systeem waarin de wijziging als eerste bekend wordt en waar iemand bevoegd is hem in te voeren. Wie hoort als eerste dat een klant verhuist? De accountmanager, dus het CRM. Wie hoort als eerste dat een betaaltermijn is aangepast? Degene die het heeft afgesproken, dus ook het CRM, of de offerte. Wie weet als eerste dat een btw-nummer niet klopt? De administratie, bij de aangifte, dus de boekhouding. De bron ligt in de regel bij degene die de wijziging meemaakt, niet bij het duurste pakket.

De tabel

Hieronder per gegeven de bron, wie het daar wijzigt, hoe het in de praktijk uit elkaar loopt, en wat één verschil kost zodra het aan het licht komt. De bedragen zijn berekende indicaties op de aannames die onder de tabel staan; ze zijn geen meting.

De aannames achter de bedragen

Alle regels rekenen met een uurtarief van €45 aan loonkosten voor de administratie inclusief werkgeverslasten, €90 per uur voor de accountant, een factuur van €5.000, en 6% per jaar als kosten van geld dat later binnenkomt. Ook elke duur en elke vertraging in de uitleg hieronder is een aanname, geen meting. Vul uw eigen getallen in en de tabel verschuift, ook in volgorde.

Het factuuradres: een factuur naar het oude adres wordt niet betaald, omdat hij niet aankomt. Dat blijkt bij de eerste aanmaning. Een half uur uitzoeken en opnieuw versturen is €22,50; de betaling komt drie weken later, wat op €5.000 bij 6% per jaar €17,26 is. Samen ongeveer €40.

De betaaltermijn heeft twee kanten. Staat de boekhouding op 14 dagen terwijl 30 is afgesproken, dan krijgt de klant een aanmaning waar hij recht op heeft te klagen. Twintig minuten bellen en rechtzetten: €15. Staat de boekhouding ruimer dan afgesproken, bijvoorbeeld op 60 dagen, dan komt elke factuur dertig dagen later binnen dan nodig. Op €5.000 is dat €24,66 per factuur, en niemand belt daarover.

De verkoopprijs: de klant heeft een afspraak op €12,50 per stuk, de boekhouding factureert 1.000 stuks tegen de lijstprijs van €13,20. De klant belt. Creditnota, nieuwe factuur, telefoongesprek: drie kwartier, €33,75, plus twee weken latere betaling, €11,51. Ongeveer €45. Loopt het de andere kant op en is de lijstprijs lager dan de afspraak, dan belt de klant niet en is het verschil, hier €700, weg.

De contactpersoon: de factuur en de aanmaning gaan naar een mailadres van iemand die niet meer bij de klant werkt. Bij de tweede aanmaning belt iemand. Een half uur, €22,50, en dertig dagen latere betaling, €24,66. Ongeveer €47.

Het btw-nummer is de regel die uit de toon valt. Bij een levering aan een ondernemer in een ander EU-land geldt het 0%-tarief alleen als u het btw-identificatienummer van de klant op de factuur zet en opgeeft in de Opgaaf intracommunautaire prestaties; de Belastingdienst raadt aan het nummer altijd te controleren, en schrijft dat wie 0% rekent terwijl bij controle blijkt dat de klant geen ondernemer is, een naheffingsaanslag krijgt. Een verkeerd nummer dat op tijd wordt gezien kost in dit voorbeeld een uur eigen werk en een half uur van de accountant: €45 plus €45, dus €90. Blijkt bij een controle dat er 0% is gerekend aan een afnemer die daar geen recht op had, dan gaat het om de btw over de levering: op €5.000 is dat €1.050. Een typefout bij een echte ondernemer is niet automatisch dat tweede geval, maar dit is wel het gegeven waarbij een verschil het duurst kán zijn.

Wat de tabel laat zien is dat een verschil op zichzelf goedkoop is. Vier van de vijf regels blijven onder de vijftig euro. De kosten zitten in de herhaling en in de tijd tussen het uiteenlopen en het opmerken. Een prijsverschil dat één keer voorkomt is een telefoontje; hetzelfde verschil elke maand, omdat niemand de bron heeft aangewezen, is een vaste post.

Hoe een koppeling de bron afdwingt

Een koppeling die twee systemen synchroon houdt, moet per veld weten welke kant op. "De laatste wijziging wint" is geen regel maar het ontbreken van een regel: dan wint wie toevallig het laatst heeft getypt. De eenvoudigste inrichting die houdbaar is, is per gegeven één richting. Twee kanten op kan ook, maar dan met een conflictregel per veld, en die moet iemand opschrijven en onderhouden.

Exact Online geeft daar de middelen voor. Het endpoint voor relaties heeft aparte velden voor bezoekadres, betaalconditie voor verkoop en btw-nummer, en registreert per record wie het het laatst heeft gewijzigd, in de velden Modified en Modifier, zo staat het in de documentatie van CRMAccounts. Voor het ophalen van wat er sinds de vorige keer is veranderd is er een Sync-endpoint met een timestamp die bij elke wijziging oploopt; Exact schrijft zelf dat dit betrouwbaarder is dan filteren op wijzigingsdatum, omdat meerdere records dezelfde datum kunnen hebben. Die Modifier staat op het record, niet op het veld, en bij een koppeling is het vaak de koppelgebruiker zelf; maar hij laat wel zien wie of wat de klantkaarten in de praktijk aanraakt, en dat is nogal eens een ander dan afgesproken.

Bij AFAS loopt schrijven via een UpdateConnector, waarbij een PUT een bestaand record wijzigt en Profit de wijziging eerst langs zijn eigen bedrijfsregels haalt voordat hij wordt opgeslagen, aldus de AFAS Help. Een koppeling die per veld één richting aanhoudt, past in beide pakketten; hoe dat er per pakket uitziet staat op /koppelingen/exact-online/ en /koppelingen/afas/, en de valkuilen van de AFAS-connectoren staan apart uitgeschreven.

Wanneer dit niet werkt

De tabel gaat ervan uit dat een verschil een fout is. Dat is niet altijd zo. Het bezoekadres in het CRM en het factuuradres in de boekhouding mogen verschillen; dat zijn twee gegevens met dezelfde naam. De lijstprijs en de klantprijs ook. In die gevallen lost synchroniseren niets op en maakt het iets kapot: de koppeling overschrijft een juist gegeven met een ander juist gegeven. De oplossing is dan het veld splitsen, zodat elk gegeven een eigen naam en een eigen bron heeft.

Het werkt ook niet als twee afdelingen hetzelfde gegeven allebei als eerste horen. Een betaaltermijn die zowel door verkoop bij de afspraak als door de administratie bij een betalingsregeling wordt aangepast, heeft geen natuurlijke bron. Dan is er een afspraak nodig over wie het invoert, en die afspraak is geen koppelingsvraag.

En het werkt niet zonder de rij die het duurst kan zijn. De vier andere regels blijven in dit voorbeeld bij elkaar onder de €160 per keer; de btw-regel kost bij een naheffing in één keer meer dan dat. Als er één gegeven is waarvoor u vandaag de bron aanwijst, is het die.

Wat u zelf kunt doen, zonder software: neem tien klanten die in beide systemen staan en leg de vijf velden naast elkaar. Tel de verschillen per veld, en schrijf er per veld bij wie het als laatste heeft gewijzigd en welke waarde de juiste is. De kolom met de meeste verschillen is niet per se de dure; de kolom die het langst onopgemerkt blijft, is dat wel.