Waarom Power BI direct op Exact Online geen goed idee is

Power BI Desktop biedt een ingebouwde connector voor Exact Online. Technisch gezien kun je daarmee tabellen ophalen en rapporten bouwen. Toch is dit in productieomgevingen sterk afgeraden, en wel om de volgende redenen:

  • Rate limits: De Exact Online API staat maximaal 5.000 API-aanroepen per dag per account toe. Elke keer dat Power BI een scheduled refresh uitvoert, verbruikt dat aanroepen. Bij een dataset met tientallen entiteiten verbruik je snel je quotum — zeker bij meerdere gebruikers die tegelijkertijd refreshen.
  • Geen historische data: Exact Online slaat transacties op in de huidige staat. Als je een factuur verwijdert of een boekingsperiode sluit, verdwijnt die informatie uit de API-response. Een tussenlaag die dagelijks snapshots maakt, is noodzakelijk om historische analyses te kunnen doen.
  • Trage performance: DirectQuery op de Exact Online API is erg traag. Elke visualisatieklik genereert een API-call die seconden duurt. Import mode via de connector is sneller, maar je bent dan volledig afhankelijk van de stabiliteit van de OAuth-sessie van Power BI Service.
  • Geen controle over de datastructuur: Exact Online levert data in een genormaliseerd formaat dat niet direct geschikt is voor rapportage. Zonder transformatielaag bouw je complexe Power Query scripts die moeilijk te onderhouden zijn.

De conclusie is helder: een directe koppeling werkt prima voor experimenten en prototypes, maar niet voor betrouwbare productie-rapportages. De professionele aanpak introduceert een tussenlaag.

De architectuur: Exact Online → Python ETL → Azure SQL → Power BI

De architectuur die Argus BI hanteert bestaat uit vier lagen:

  1. Exact Online REST API: De brondatabron. Hier zitten al uw financiële transacties, relaties, budgetten en balansen.
  2. Python ETL-pipeline: Een Azure Functions-applicatie die dagelijks data ophaalt uit de Exact Online API, valideert en laadt naar Azure SQL. De pipeline beheert ook de OAuth-tokens.
  3. Azure SQL Database: De staging- en rapportagelaag. Data wordt hier opgeslagen in een gemodelleerd formaat (Star Schema), compleet met historische snapshots.
  4. Power BI Service: Het rapportageplatform. Power BI leest uit Azure SQL in Import mode en verwerkt data in de in-memory engine. Dagelijkse scheduled refresh via Power BI Service.

Dit patroon heeft meerdere voordelen: de brondatabase wordt niet belast, historische data blijft bewaard, en de transformatielogica zit op één plek (in de ETL-pipeline en het SQL-datamodel) in plaats van verspreid over Power Query en DAX.

Stap 1: OAuth 2.0 authenticatie instellen

Exact Online maakt gebruik van OAuth 2.0 voor API-authenticatie. Voor een machine-to-machine ETL-pipeline gebruik je de authorization code flow: je autoriseert eenmalig als gebruiker, en de applicatie slaat een refresh token op voor hergebruik.

Het proces werkt als volgt:

  1. Registreer een applicatie in de Exact Online App Center. Je ontvangt een client_id en client_secret.
  2. Leid de gebruiker naar het autorisatie-endpoint: https://start.exactonline.nl/api/oauth2/auth?client_id=...&redirect_uri=...&response_type=code
  3. Na goedkeuring ontvang je een autorisatiecode die je inwisselt voor een access token en refresh token via een POST naar https://start.exactonline.nl/api/oauth2/token.
  4. Sla het refresh token veilig op in Azure Key Vault. Het access token heeft een TTL van 10 minuten; gebruik het refresh token om een nieuw access token te genereren bij elke API-sessie.

In Python ziet een token-refresh er als volgt uit:

import requests
response = requests.post(
    "https://start.exactonline.nl/api/oauth2/token",
    data={
        "grant_type": "refresh_token",
        "client_id": CLIENT_ID,
        "client_secret": CLIENT_SECRET,
        "refresh_token": current_refresh_token
    }
)
new_tokens = response.json()

Bewaar het nieuwe refresh token na elke refresh — Exact Online invalideert het oude token zodra je een nieuw hebt aangevraagd (sliding window).

Stap 2: Data ophalen via de Exact Online REST API

De Exact Online API volgt de OData-standaard. Endpoints retourneren JSON-responses met paginering via een __next-link. De meest relevante endpoints voor financiële rapportages zijn:

EndpointInhoudGebruik
financialtransactions/GLTransactionsGrootboektransactiesW&V, balans
financial/ReportingBalanceGeaggregeerde saldi per grootboekrekeningSnel overzicht balans
budget/BudgetsBudgetregels per rekening en periodeBudget vs. realisatie
salesinvoice/SalesInvoicesVerkoopfacturenDebiteurenadministratie
crm/AccountsRelaties (klanten/leveranciers)Dimensietabel
purchaseorder/PurchaseOrdersInkoopordersCrediteurenadministratie

Voor incrementele laadstrategie is de $filter-parameter essentieel. Door te filteren op Modified gt datetime'YYYY-MM-DDTHH:MM:SSZ' haal je alleen de records op die zijn gewijzigd na de laatste succesvolle run. Dit beperkt het API-verbruik aanzienlijk.

Let op paginering: de Exact Online API retourneert maximaal 60 records per request bij de meeste endpoints (500 bij ReportingBalance). Verwerk alle pagina's door de __next URL op te volgen totdat die ontbreekt.

Stap 3: Staging en validatie in Azure SQL

Na het ophalen van de data voer je een validatiestap uit voordat je naar Azure SQL laadt. Minimale validatiechecks zijn:

  • Volledigheid: Zijn alle verwachte dagboeken aanwezig? Klopt het totaalaantal transacties met de verwachting op basis van historische volumes?
  • Saldo-check: Debiet moet gelijk zijn aan crediet. Als dat niet zo is, is er een fout in de extractie.
  • Datum-validatie: Transactiedatums moeten binnen de verwachte boekingsperiode vallen.
  • Referentiële integriteit: Elke transactie verwijst naar een bestaande grootboekrekening die in de rekeningschema-tabel aanwezig is.

In Azure SQL gebruik je een laadstrategie met een staging-tabel (Bronze-laag) en een getransformeerde rapportagetabel (Gold-laag). De ETL-pipeline laadt eerst naar de staging-tabel, validatie draait op staging, en na goedkeuring wordt de data gepromoveerd naar de rapportagetabel via een MERGE-statement (UPSERT).

MERGE dbo.gl_transactions AS target
USING staging.gl_transactions AS source
ON target.transaction_id = source.transaction_id
WHEN MATCHED THEN UPDATE SET ...
WHEN NOT MATCHED THEN INSERT (...);

Stap 4: Power BI datamodel en scheduled refresh

Met de data in Azure SQL bouw je een Star Schema in Power BI. De feittabel is fact_gl_transactions met sleutels naar dimensietabellen voor datum, rekening, dagboek en relatie. Dit datamodel is geoptimaliseerd voor snelle DAX-berekeningen.

Voor scheduled refresh in Power BI Service:

  1. Publiceer het rapport naar Power BI Service.
  2. Stel een gateway in (on-premises of Azure SQL kan ook zonder gateway via de cloud-connector).
  3. Configureer scheduled refresh in de dataset-instellingen: dagelijks om 06:00 is een gangbare instelling voor financiële dashboards.

Met Power BI Premium of Premium Per User is incrementele verversing mogelijk, waarbij alleen nieuwe of gewijzigde partities worden geladen. Dit verkort de refreshtijd bij grote datasets aanzienlijk.

Welke financiële rapporten kun je maken met Exact Online data?

Met een volledig gevulde Azure SQL staging-laag zijn de volgende rapportages standaard beschikbaar:

  • Verlies- en winstrekening — per periode en jaar-op-jaar vergelijking
  • Balans — activa, passiva, eigen vermogen op elke gewenste peildatum
  • Budget vs. realisatie — per kostenplaats, rekening of periode
  • Ouderdomsanalyse debiteuren — openstaande facturen per vervalperiode (0–30, 31–60, 61–90, 90+ dagen)
  • Ouderdomsanalyse crediteuren — zelfde analyse voor uitstaande inkoopfacturen
  • Omzetanalyse per klant — cumulatieve omzet, aantal facturen, gemiddeld factuurbedrag
  • Cashflow — ontvangsten en betalingen per periode, gecombineerd met banksaldo

Door gebruik te maken van de historische snapshots in Azure SQL kun je ook tijdreeksanalyses bouwen: hoe ontwikkelt de marge zich over de afgelopen 24 maanden? Wanneer was de debiteurenpositie het hoogst? Dit soort analyses is onmogelijk bij een directe koppeling op de Exact Online API.

Exact Online rapportages professionaliseren?

Argus BI heeft uitgebreide ervaring met Exact Online API-koppelingen. Wij bouwen de volledige stack: OAuth-authenticatie, ETL-pipeline, Azure SQL staging en Power BI dashboards.

Bespreek je Exact Online rapportage

Veelgestelde vragen

Kan ik Exact Online direct koppelen aan Power BI zonder Azure SQL?

Technisch gezien is dat mogelijk via de ingebouwde Exact Online connector in Power BI Desktop, maar dit is sterk afgeraden voor productieomgevingen. Je bent afhankelijk van rate limits, hebt geen historische data, en scheduled refresh werkt onbetrouwbaar. Een tussenlaag via Azure SQL is de professionele aanpak die Argus BI altijd hanteert.

Hoe vaak wordt de data ververst?

Bij de standaardopzet die Argus BI hanteert wordt de ETL-pipeline elke nacht gedraaid via een Azure Functions timer trigger. Elke ochtend is het dashboard actueel met de data van de vorige werkdag. Vaker verversen (meerdere keren per dag) is technisch mogelijk maar verhoogt de API-belasting en de kosten van Azure Functions.

Werkt de koppeling ook met meerdere Exact Online administraties?

Ja. De Exact Online REST API ondersteunt meerdere administraties onder één account. In de ETL-pipeline itereer je over alle divisies en laad je de data gecombineerd in Azure SQL, inclusief een kolom voor de divisie-identifier. Power BI kan dan filteren per administratie of alles geconsolideerd weergeven voor een consolidatierapportage.

Welke Exact Online licentie heb ik nodig voor de API?

API-toegang is beschikbaar in alle Exact Online abonnementen. Je hebt wel API-credentials nodig die je aanmaakt via de Exact Online App Center als developer. Voor productiekoppelingen is een registered app vereist. Argus BI begeleidt dit registratieproces standaard tijdens de implementatie en zorgt voor een correcte OAuth-configuratie.