What a data foundation actually is

A data foundation is the combination of sources, connections, storage, definitions and checks that your reporting rests on. Think of it as the foundation under a building. You never see it, but everything above it depends on it.

In practice it has four layers. First the sources: your accounting package, your CRM, your point of sale, your time tracking, sometimes a spreadsheet nobody dares to delete. Then the connections that pull data out automatically, usually through an API. Then a data layer where data is stored, cleaned and joined. And on top the definitions: the agreements about what counts as a customer, when revenue is recognised and how you count a partially delivered order.

That last layer is the one people forget, and the one that causes the most trouble. Technology is rarely the problem. Unclear definitions are.

Why SMEs benefit most

A large company has a team guarding the numbers. In an SME the owner usually does it on the side, or a controller who also runs invoicing. That is exactly why every hour lost to copy-and-paste work counts.

Sound familiar?

  • Monthly figures are only ready halfway through the next month.
  • Two reports show different revenue and nobody knows which one is right.
  • When one colleague is on holiday, reporting stops.
  • Questions like "which customers bought less this year?" stay unanswered because finding out takes too long.

Those are not data questions, they are steering questions. A data foundation does not solve them by magic, but it removes the manual steps and makes the outcome traceable. You can click from a total through to the underlying rows and see where a number came from.

Five signs your foundation is shaky

You do not need to be a data expert to notice something is off. Watch for these signs:

  1. Exports as standard procedure. Downloading and merging the same files every month is work a computer does better and faster.
  2. Debating the numbers instead of the conclusion. If a meeting opens with "this figure is wrong", the rest of the hour is not about decisions.
  3. Knowledge in one head. If nobody else understands how the file works, you do not have reporting, you have a risk.
  4. No history. Many packages only show the current state. Without storing yesterday, you cannot show a trend.
  5. Looking backwards only. Reporting that only says what happened, and never what to watch, stops being opened.

One sign is fine. Three or more usually means you spend more time producing numbers than using them.

How to start without a big project

The biggest mistake is starting with "everything". Connect everything, store everything, report on everything. That takes long, costs a lot and only delivers at the end. We flip it around: start with one decision you want to make better.

A workable order:

  1. Pick one question. For example: which customers deliver less margin this year than last? One question decides which sources you really need.
  2. Map the sources. Which system holds the answer, which fields, who has access, what does the API offer?
  3. Write down the definitions. What is margin, which date leads, how do credit notes count? Put it in plain language.
  4. Build the connection and the data layer. Fetch, store, clean and join — outside the report, so the dashboard does not redo the heavy lifting every time.
  5. Show something working early. A rough version with real data gets better feedback than a polished mock-up with invented numbers.
  6. Then expand. Only once the first question is answered reliably do you add the next source.

That is exactly how our approach works: start small, show something tangible quickly, scale only when it holds up.

What it delivers

You notice a solid foundation mostly by what disappears: the monthly export ritual, the argument about which list leads, the waiting until someone has time to dig.

What comes back is less spectacular but far more valuable. Numbers ready in the morning. One place everyone looks. The ability to answer a new question in days instead of weeks, because the sources are already unlocked. And, not unimportant, a base you can later use to automate processes or apply AI. Both only make sense when the underlying data is right.

We build that foundation with data engineering and put reporting on top with dashboarding that people actually open. Running on standard packages like Moneybird, Odoo or Teamleader? There is often a ready integration to start with.

Common mistakes

Three pitfalls we see often, and how to avoid them.

Starting with the tool. Buying a licence is not a foundation. Start with the question and the definitions, then choose the technology.

Copying data without cleaning it. If customer names are spelled differently in three systems, you get three customers. Connecting starts with agreeing on the source of truth.

No owner. A dashboard without an owner goes stale. Record who guards the definitions, who gets alerted when a refresh fails and who decides on changes. A proper handover includes documentation, not just a link.