back to work
Case Study / Business Intelligence

The Ledger You Can Talk To

Business intelligence for a multi-channel product company: a deterministic core that never guesses, the knowledge in people's heads turned into rules, and AI only where it has earned its place.

Fortnox APIPostgreSQLPythonMCPClaude
PEOPLEDATAAI
3 weeks
First commit → live ERP sync
0
Model calls in the data pipeline
~90
Decisions logged in 10 weeks

Overview

SECTION 01

Problem

A Nordic product company selling through wholesale, its own webshop, marketplaces and B2B across Europe. Sales lived in the ERP, the plan in spreadsheets, and the rules connecting them in a few people's heads. Every view answered “how are we doing?” a little differently, month-end meant exports and copy-paste, and the logic behind purchasing was understood in full by one person — a classic key-person risk.

Solution

One store, fed every night from the ERP and from the spreadsheets people actually use. One definition per concept across every view. Rules turned into data, each with an owner and a reason. And a read-only AI interface so leadership can question the numbers in plain language. The pipeline itself makes zero model calls: same input, same answer, every night.

The Challenge: Rules, Not Charts

SECTION 02

The first dashboard was quick to build. The hard question came right after: what does “actual” mean? Invoice date or booking date? Is an unfinished invoice a sale? Does a correction belong to the month it was made or the month it corrects? Is a marketplace sale counted before or after returns? Which channel carries a shared cost? Each view had answered on its own, and that is where every disagreement about the numbers came from.

How the Business Asks

  • “Are we on plan?”
  • “What’s our margin in wholesale?”
  • “When do we have to reorder?”
  • “Can we pay everything next week?”

What the System Has to Know

  • Which plan, which version, which date
  • Which costs belong to which channel
  • Lead times, minimum orders, safety stock — set by whom
  • Which payments are critical, and in what order

None of the right-hand column is in the ERP. It lives in people. The work was to get it out of their heads and into the system — without pretending it was more certain than it was.

The Approach: Where AI Comes In — and Where It Doesn't

SECTION 03

The picture at the top is the whole idea. People put what they know into the data as rules, and get new knowledge back. The data does the arithmetic. AI sits at the edge: it reads the data and talks with people, but never writes.

01

A Deterministic Core

Why: Books have to reconcile. A number that changes between two runs of the same data is worse than no number at all.

How: Parsing, customer matching, netting of credit notes, margins and stock projections are plain code. Every row is traced to the file or sync batch it came from. A validation gate checks the data against an answer key frozen from the closed books, so a change in a source shows up as a failed check, not as a quietly different number.

02

Tacit Knowledge, Made Explicit

Why: The rules that make the numbers meaningful — who is who, what counts, when to reorder — were never written down anywhere.

How: Each rule became a row of data, not an if-statement: customer aliases, which cost center means which channel, what counts as sales, lead times and minimum orders. Every value carries an owner and a reason. Whatever the system can’t place lands in a visible bucket instead of being guessed.

03

AI at the Edge

Why: Language is ambiguous; ledgers aren’t. Put the model where ambiguity is the job — understanding a question — and keep it out of the arithmetic.

How: Leadership asks questions in Claude through a read-only MCP server: typed tools, the same permissions as the web app, every call logged. The model is told to walk top-down — area, account, voucher — and never to guess a cause the data can show. It reads the books; it never computes or writes them.

04

Where New Knowledge Is Created

Why: The interesting knowledge isn’t in any single source. It appears at the seams between them.

How: Names the matcher can’t place. Gaps between the dashboard and the books. Rules that each made sense alone but contradict each other. Plan versions next to what actually happened. The questions people ask. Each finding goes back to a person, gets decided, and becomes a rule — so the system gets more explicit every week.

Key Choices

SECTION 04
01

A Database, Not a Spreadsheet in a Browser

The starting point was a dashboard that carried its data inside the file, and the obvious next step was to parse uploads in the browser. The decision on day one was a server database instead: shareable, persistent, and the foundation everything else was built on.

02

Closed Books Are the Official Number

Reports show only months the accountant has locked; the live dashboard shows everything, with unposted items marked. Two answers, each labelled, instead of one ambiguous one.

03

One Definition per Concept

Dashboard, cost report, planning, cash view and the AI interface use the same definitions. A disagreement between two views is a bug, not a matter of opinion.

04

Never Show a Number That Looks Exact but Isn’t

Coverage is printed next to margins. A partial budget is reported as partial. Approximations are labelled, or not shown.

05

Sensitive Data Is Scoped by Account

Salaries and similar accounts are visible only to those who should see them, and the AI interface follows exactly the same scopes as the web.

06

The File Upload Stays

Even with a nightly API sync, anyone can still drop a file. Tokens expire and vendors have outages; a company that can only reach its data through one integration doesn’t really own it.

07

AI Forecasting Is Deliberately Deferred

Plans are stored as versions and never overwritten. Once there is enough plan-versus-actual history, a forecasting model will have something honest to learn from. Not before.

What It Enables

SECTION 05

For Leadership

  • Ask the ledger in plain language, and get answers that point to vouchers
  • Budget versus actual, from area down to a single voucher
  • Month-end reporting straight from the books, no manual exports
  • A 13-week cash forecast that knows which payments are critical

For the Team

  • Sales, margin and plan in one place — by channel, market and product
  • Purchasing rules written down, each with an owner and a reason
  • Projected stock per week and the latest day to place an order
  • Knowledge that stays when people move on

For the Company

  • Sales, books, payables, stock and purchase orders synced every night
  • Every number traceable to its source
  • Data on its own server, with file upload as a fallback
  • A foundation for landed cost, more markets and forecasting — without a rebuild

Status: In production since August 2026; demand planning and purchasing support rolling out
Timeline: 3 weeks to a live ERP connection, 10 weeks to sales, margins, cost reporting, cash and planning in one system
Scope: four channels, from sales to cash, every source synced nightly
Operations: monitored nightly sync and an ongoing operations agreement

Tech Stack & Architecture

SECTION 06

Core Technologies

  • Python: async ingest, FastAPI, raw asyncpg
  • PostgreSQL: one database per client, pgvector ready
  • Fortnox API: OAuth with minimal scopes, nightly incremental sync
  • MCP server: read-only tools for Claude, OAuth, audit per call
  • Docker Compose: on a dedicated server in the EU

What Makes This Different

  • Zero model calls in the pipeline
  • Rules as data, each with an owner and a reason
  • A validation gate against the closed books
  • One definition per concept across every surface
  • AI with exactly the same permissions as the web

Development Journey

Built in ten weeks, one numbered spec at a time:

  • Every architectural and business-rule decision logged as a short ADR — about 90 in the first ten weeks
  • Synthetic test data only; the test suite fails if a real amount appears in the code
  • Migrations tracked and checksummed; deploys run a dry run first
  • Built with an AI-assisted engineering workflow — AI where it speeds up the building, not where it would make the numbers non-deterministic

Lessons Learned

SECTION 07
01

Definitions Before Dashboards

Most “wrong numbers” turned out to be two right numbers answering different questions. Lesson: decide what “actual” means before you draw it.

02

Knowledge Needs an Owner, Not a Form

A parameter nobody owns slowly goes stale. Every rule carries who set it and why. Lesson: make knowledge accountable, not just documented.

03

Put the Model Where Ambiguity Is the Job

Understanding a question is a language problem; summing a ledger is not. Lesson: models at the interface, code in the calculation.

04

Show the Seams

Visible buckets for the unmapped and labels on approximations built more trust than any amount of polish. Lesson: being honest about uncertainty is a feature.

05

The System Is a Relationship

Weekly decisions with the people who own the numbers shaped the system more than any spec did. Lesson: transformation is continuous, not a handover.

What's Next

SECTION 08
→

Parallel run of purchasing support

Three to four weeks next to the old spreadsheet, then a recorded walkthrough of the weekly routine

→

Planned purchases in the cash forecast

Purchases are the largest outflow; they enter the forecast on each supplier’s payment terms

→

Landed cost

Freight, duty and currency per item, on top of today’s margin layers

→

Forecasting on versioned history

The first place a model gets to do arithmetic — once there is history to be honest about

→

The same core for other companies

One database per client, the same rules engine, the same read-only AI interface

Explore More