Most Dutch SMEs do not need a data warehouse before they start with AI. A direct connection between your AI system and Exact Online, AFAS or e-Boekhouden — reading live through the API, no ETL pipeline, no staging database — covers the large majority of first automation and reporting use cases. A warehouse earns its cost only once one of three specific triggers shows up, and this piece names them.
The vendor incentive nobody states out loud
Search the question and the advice is remarkably consistent: get your data house in order first, then think about AI. Read carefully and almost all of that advice comes from companies that sell data warehouse projects, for whom a build in the €8,000–€12,000 range, plus 15–20% of that per year in maintenance, is a healthy line item. That is not dishonest — a warehouse genuinely makes later projects easier. But “easier later” and “necessary now” are different claims, and the mkb owner signing the invoice needs to know which one they are being sold.
What a direct connection actually means in 2026
The default pattern in 2026 is not a nightly export into a staging table. It is a live read through the Model Context Protocol (MCP), the open standard Anthropic introduced in November 2024 to let AI systems query external tools and data sources in a structured way. In practice: an AI agent asks Exact Online for invoices over 60 days past due, or asks AFAS for this week's completed work orders, and gets a structured answer inside the same request — no second copy of your bookkeeping sitting in a database someone has to keep synchronised. MCP servers for Exact Online and for AFAS already exist and are in active use for exactly this pattern.
One detail is worth being precise about, because it changes the framing rather than the conclusion. Peliqan, whose connectors are cited above, does not do a pure pass-through read — it syncs your data into its own managed Postgres warehouse behind the scenes, refreshed on a schedule, and the AI queries that copy rather than Exact Online or AFAS directly. By any reasonable definition, that is a warehouse, not a cache. What has actually changed is who builds and owns it: instead of commissioning your own €8,000–€12,000 project, you are renting a pre-built one bundled into a connector subscription. That is a genuine third option worth knowing about — it is just not “no infrastructure,” and it is worth checking exactly what a given connector does with your data before assuming otherwise.
This is not just our own read. Independent SME-analytics commentary reaches the same conclusion from the other direction: modern AI does not have to be centralised to deliver value, and a business without a full-time data engineer is usually better served connecting its existing tools directly than owning a warehouse it cannot maintain. A Dutch AI implementer and an SME-analytics platform with no warehouse to sell reach the same conclusion because the underlying constraint is identical: someone has to keep a warehouse correct, and most companies at 20–50 FTE do not have that person on staff yet.
Three triggers that mean you actually need one
In years of connecting AI to Dutch back-office systems, the businesses that genuinely needed a warehouse before they could start were the exception, not the rule. Three situations reliably separate them from everyone else.
- Multi-year joins the source system was never built to do. Matching five years of Exact Online invoices against AFAS project hours to find which client types are quietly unprofitable is a join no live API performs in one call, and running it against production every time someone asks is what breaks a warehouse-free approach.
- Query volume the live system cannot sustain. Exact Online and AFAS both rate-limit API calls. A dashboard forty employees refresh every few minutes hits that ceiling well before most mkb transaction volumes do. Scheduled reporting absorbs this with a modest cache; only genuine, concurrent, near-real-time load across many users justifies a full warehouse.
- A number that has to survive a system swap. If Exact Online, AFAS or e-Boekhouden ever gets replaced, an AI reading live from it breaks on day one of the migration. A warehouse decouples reporting and AI from any single source system, which matters for a five-year trend line, or for an audit trail that must not have a gap the week a new ERP goes live.
The payback math, worked through
Take a 30-person company running Exact Online for finance and a separate CRM for sales. A scoped direct integration — AI reading live from both systems to automate overdue-invoice follow-up, say, or the handoff from accepted quote to order — is priced from roughly €2,500 for one well-defined workflow, rising toward €20,000 for a multi-step agent spanning both systems, at our own published rates. A full data warehouse build for an organisation this size runs €8,000–€12,000. On top of that build cost, Dutch IT-project pricing typically runs 15–20% of it per year in ongoing maintenance, plus roughly €50–500 a month in hosting, as a rule of thumb — before a single AI use case sits on top of it.
At the low end, the warehouse alone already costs more than the entire direct integration, and the integration still has to be built afterward, on top of the warehouse. The arithmetic only turns around once the warehouse's data actually gets reused: across a finance dashboard, an AI agent and statutory reporting, not one. As a rule of thumb, a warehouse earns its cost when at least three genuinely separate use cases will draw on it within about eighteen months. Fewer than that, and the €8,000–€12,000 — plus ongoing maintenance — is infrastructure with one tenant.
A staged path that avoids paying twice
Start with the single highest-value direct connection — usually the workflow with the clearest business case, not the most technically interesting one. Add a small, purpose-built cache only if that specific workflow needs it, for example a large batch report or a query pattern the live API genuinely cannot sustain. Commission a full warehouse only once two of the three triggers above are actually true today, not anticipated for next year. The order matters: building a warehouse first and finding a use case for it afterward is the classic overspend we see mkb owners walk into. Building the direct integration first means that if a warehouse ever gets commissioned, it gets built around real, observed query patterns instead of a vendor's best guess.
Where this goes wrong
- Building the warehouse “to be safe.” No AI use case is scoped yet, and nobody has budgeted the ongoing 15–20% maintenance, which is where these projects quietly become the most expensive line in next year's IT budget.
- Treating a connector's internal cache as “no infrastructure.” A vendor built it, but your business still owns the operational risk if that connector goes down or changes its terms.
- Ignoring the audit-trail question until an AI Act review asks for it. A high-risk AI use case needs traceable, reproducible inputs; a live API call whose shape changes the day the ERP updates its schema is a compliance gap that a warehouse, or at minimum a versioned log, actually closes.
What this looks like on a typical Dutch mkb stack
For the common Dutch combination of Exact Online or AFAS for finance, a separate CRM, and e-Boekhouden for the smallest firms, a direct MCP-style connection covers almost every first automation request a 20–50 FTE company brings us: chasing overdue invoices, handing a signed quote through to an order, triggering a WhatsApp update from an order-status change. The warehouse conversation turns real closer to the 250–500 FTE band, where finance, sales and operations already run on genuinely separate systems and a BI function usually exists already that a warehouse would serve with or without the AI project attached to it.
None of this is an argument against ever building a warehouse. Plenty of 250–500 FTE organisations we work with have one, and it earns its keep every month. The argument is against sequence: build the connection that solves today's problem first, let the query pattern tell you whether a warehouse is actually load-bearing, and only then commit real budget to owning one.
Where to start
Map which systems the AI actually needs to read from, and check honestly whether the query pattern is occasional and scoped, or constant and cross-system, before committing to either path. We cover the mechanics of the direct-connection route — API limits, write-back permissions, what breaks — in our companion piece on connecting AI to Exact Online, AFAS and e-Boekhouden, and how we scope both directions of this decision on our data engineering page.
