Somvilla
SQL

Why Sage 50 KPI reporting is broken for most NI manufacturers (and how to fix it) | Somvilla

Sage 50 holds all your operational data. Your MD wants weekly KPIs. Here's why the spreadsheet bridge fails and what a proper SQL reporting setup looks like.

3 min read

Every week, someone at a Northern Ireland manufacturing firm opens Sage 50, exports a CSV, pastes it into a spreadsheet, and emails it around. By Tuesday it’s out of date. By Thursday someone’s made a decision based on last week’s numbers.

This is not a technology problem. It’s a workflow problem that technology has already solved — most firms just haven’t implemented the fix.

What Sage 50 actually contains

Sage 50 uses a Pervasive (now Actian Zen) database under the hood. It’s ODBC-accessible, which means you can query it with standard SQL tools. Every transaction, every stock movement, every sales order — it’s all in there, structured, queryable, and current.

The problem is that most Sage 50 users don’t know this. They use the built-in reports (limited, slow, hard to customise) or they export to Excel (manual, stale, error-prone).

The Monday morning spreadsheet problem

Here’s the typical pattern:

  1. Friday afternoon: someone exports the week’s data from Sage
  2. They paste it into a master spreadsheet and update some formulas
  3. Monday morning: the MD receives it by email
  4. Tuesday: a decision gets made based on Friday’s data

In manufacturing, Friday’s stock levels may be meaningfully different from Monday’s. Delivery schedules shift. Production runs complete. The spreadsheet is already a historical document by the time it’s read.

What a proper setup looks like

The alternative is a read-only SQL connection directly to the Sage database, with a handful of queries that calculate your KPIs in real time:

-- Example: Stock value by product category
SELECT
    prd.STOCK_CODE,
    prd.DESCRIPTION,
    prd.CATEGORY,
    prd.QTY_IN_STOCK,
    prd.SALE_PRICE,
    (prd.QTY_IN_STOCK * prd.COST_PRICE) AS stock_value
FROM
    STOCK_ITEM prd
WHERE
    prd.QTY_IN_STOCK > 0
ORDER BY
    stock_value DESC;

That query runs against live data. No export. No paste. No Monday delay.

Wrap it in a simple web dashboard — a read-only page that runs the queries on load — and the MD can check it from their phone before they walk onto the floor.

Add an automated email that runs the same queries at 7am every working day, formats the numbers, and sends them to whoever needs them. No manual steps at all.

The Windsor Framework wrinkle

For NI manufacturers trading across the Irish Sea, there’s an additional layer. The Windsor Framework compliance requirements mean you need to know, at any given time, which stock is “at risk” for EU tariff purposes and which isn’t.

Sage 50 doesn’t have a built-in Windsor Framework report. But it does have the underlying data — supplier, country of origin, destination, commodity code. A properly built query can surface the at-risk calculation automatically.

This is one of the most common requests I get from NI manufacturing clients: “Can you build us a Windsor Framework dashboard that connects to Sage?” The answer is yes, and it typically takes 2–3 days of the DataPulse project scope.

Is this only for Sage 50?

No. The same approach works for Sage 200 (which has a more accessible SQL Server database), MySQL, MSSQL, PostgreSQL, and even Excel/CSV-based setups (using a SQLite migration).

If your operational data lives anywhere that can be queried — and it almost certainly can — a proper reporting setup is achievable.

What it costs and what you get

A DataPulse Report starts at £1,800. For that you get:

  • 5–8 KPI queries written against your schema
  • A live web dashboard with token-gated access
  • An automated daily or weekly email digest
  • One revision round
  • A Loom walkthrough video

The spreadsheet doesn’t go away immediately — habits take time. But within a month, most clients have stopped reaching for it.