Van facturatiesoftware naar rapportering waar echt op gestuurd wordt

De situatie

Dit is een klein, groeiend handelsbedrijf in gereedschap en verbruiksartikelen: slijpschijven, boren, werkhandschoenen, sprays. Veel artikelen, veel herhaalaankopen, en een klantenbestand waar iedereen zijn eigen prijsafspraken heeft. Gefactureerd wordt er via Billit, waar de volledige klanten-, product- en orderhistoriek dus ook zit. Die data is correct en compleet. Het probleem zat niet in de administratie, maar in wat je eruit krijgt: de standaardrapportering van Billit is gemaakt om een boekhouding op te volgen, niet om commercieel te sturen.

Concreet betekende dat het volgende. Wie wilde weten wat een bepaalde klant vorig jaar besteld had en aan welke prijs, moest facturen openen en vergelijken. En dat is bij dit bedrijf geen detail: verkoopprijzen variëren per klant en over de tijd, dus die historiek is precies wat je nodig hebt voor je een gesprek ingaat. Dezelfde puzzel voor de vraag hoe de gemiddelde bestelwaarde evolueert, welke artikelgroepen naar welke klanten gaan, en waar de brutomarge per product zit.

Het gevolg is voorspelbaar: die vragen worden niet meer gesteld. Niet omdat het antwoord niet interessant is, maar omdat het te veel werk kost om het op te zoeken.

Wat ik gebouwd heb

De data uit Billit halen. Billit heeft een API, dus haal ik klanten, producten en orders rechtstreeks op in plaats van iemand exports te laten maken. Dat loopt automatisch, zonder dat er nog iemand naar hoeft te kijken.

Een databank die de historiek bewaart. De opgehaalde data komt terecht in een PostgreSQL-databank. Belangrijk detail hier: de databank houdt bij welke prijs op welk moment gold, zodat een prijswijziging vandaag de historiek van vorig jaar niet overschrijft. Facturatiesoftware is niet gebouwd om die vraag te beantwoorden; een datamodel wel.

Dezelfde opzet bouw ik ook in Microsoft Fabric, wanneer de datavolumes, het aantal bronsystemen of het bestaande Microsoft-landschap van een bedrijf daar naar vragen. Voor dit bedrijf was dat overbodig: één bronsysteem en een overzichtelijke hoeveelheid data komen prima toe met een PostgreSQL-databank, tegen een fractie van de kost. De architectuur volgt hier de omvang van het probleem, niet omgekeerd.

Een semantisch model. Dit is de laag die van tabellen iets maakt waar je vragen aan kan stellen. Marges, gemiddelde bestelwaarde per maand, omzet per artikelgroep per klant: dat wordt hier één keer correct gedefinieerd, en daarna is elke berekening in elk rapport per definitie hetzelfde. Zonder die laag krijg je twee overzichten met twee verschillende cijfers en discussie over welk cijfer nu juist is.

Een Power BI-dashboard dat zichzelf bijwerkt. Automatische verversing, dus geen handmatige stap tussen een nieuwe factuur en een bijgewerkt overzicht.

Een portaal om het te bekijken. Power BI vraagt normaal per gebruiker een Pro-licentie, wat voor een KMO snel oploopt tegenover wat het oplevert. Ik bied de dashboards daarom aan via een eigen portaal, gebouwd op Power BI Embedded: het model dat Microsoft voorziet om rapporten aan externe gebruikers te tonen. De licentiekost blijft aanzienlijk onder die per-gebruikerprijs.

Dat portaal werkt met beveiligde embed-URL’s via een service principal: de toegang loopt via de applicatie, niet via een publieke link, en er komt geen rapport op het open internet terecht. Waar nodig komt daar row level security bovenop, zodat elke gebruiker enkel de rijen ziet die bij hem horen. Dat is relevant zodra niet iedereen in een bedrijf dezelfde marges of dezelfde klanten hoort te zien.

Praktisch gevolg: de dashboards zitten niet vast op één computer op het bureau.

Wat het oplevert

De zaakvoerder zit bij een klant en opent op zijn tablet het klantenoverzicht: wat die klant in het verleden besteld heeft, aan welke prijzen, in welke frequentie, met welke marge. Dat gesprek verloopt anders dan wanneer je het uit je hoofd moet doen.

En de vragen die vroeger te veel werk waren, worden nu wel gesteld. Welke artikelgroepen groeien bij welk type klant. Of de gemiddelde bestelwaarde stijgt of daalt. Op welke producten er eigenlijk verdiend wordt. Dat zijn geen rapporteringsvragen maar commerciële vragen, en ze worden nu beantwoord in seconden in plaats van in een halve namiddag.

Van eerste gesprek tot in gebruik: twee weken.

Waarom dit ook voor jou kan gelden

Als je facturatie- of ERP-software gebruikt, zit je waarschijnlijk in dezelfde situatie: de data is er, maar de rapportering die erbij zit is gemaakt voor een ander doel dan het jouwe. Zodra er een API is, en die is er bijna altijd, is er geen reden om die informatie handmatig samen te sprokkelen.

Deze aanpak werkt niet alleen voor Billit. Hetzelfde patroon geldt voor Exact, Teamleader, Odoo, WinBooks en de meeste andere pakketten.