From Accounting to Navigation: Why Retail and HoReCa Reporting Needs a New Model

Twenty-some years ago I built my first ERP system alone, in about two months, for a company that sold newspapers and magazines through more than fifty kiosks. No team, no playbook. I handled stock, returns, and treasury myself, sleeping in the server room more nights than I'd like to admit. Two months in, it worked, and it went on to run the books for a business with hundreds of wholesale buyers.

That system recorded deliveries, returns, cash, and stock, nothing more. In the strict sense of the word, it was accounting.

I've spent the two decades since watching reporting stacks in retail and hospitality get more capable. Auto-replenishment arrived, then warehouse systems that told a picker which shelf to walk to next, then dashboards, then BI, and now some flavor of AI sitting on top of all of it, summarizing and forecasting. Every layer moved faster and looked better than the one before. A manager still has to sit down with the numbers and work out, alone, what matters this week and what to do about it.

I think that gap is why retail and hospitality reporting needs to move from managing by KPI to managing by signal. That's a different job than the one a dashboard already performs.

What a dashboard is genuinely good at

I want to be fair to dashboards here, because the industry's instinct is often to declare them obsolete, and that instinct is wrong. A dashboard shows sales for the day, stock levels, margin, plan attainment. That's necessary. Without it, a multi-location business quickly ends up living in several incompatible versions of reality, one store manager convinced things are fine while another is sure they're not, with no shared ground truth to even start the conversation.

What a dashboard answers is what already happened. That's a real question, and a genuinely useful one. It just isn't a complete one. Historical sales figures show you where the business has been. They don't show you where it's heading. A network average can look healthy while three specific locations quietly develop a problem underneath it. A forecast can be right for the portfolio and still be useless to the person who has to make a call today about one store.

Reports tend to speak in KPIs, averaged across stores and periods. A signal needs to work the opposite way, narrow enough to act on immediately. "Margin is down 2% this month" is a report. "Margin moved in this location, during this period, and here's the cost line that shifted" is a signal. "Stock levels are elevated" is a report. "This batch, at this location, is approaching its expiry window" is a signal, because someone can still act on it before the window closes.

Why the average number is usually hiding the real story

Retail and hospitality businesses are not linear systems. That word sounds abstract until you've run one of these businesses, so it's worth being concrete about what it means in practice.

An assortment change shifts stock levels, and shifted stock changes product availability, quietly, before any of it shows up in a weekly report, even though availability is exactly what a customer experiences at the shelf. A promotion can lift turnover in precisely the week you wanted it to while compressing margin and loading extra work onto a staff that wasn't planned for it. A cost cut can produce a perfectly good month-end number and a real operational problem six months later, once the thing you cut turns out to have mattered after all. None of this shows up in a spreadsheet on its own, things like weather, a local public holiday, an Easter tradition specific to one country, or a supplier who quietly raised a price without telling anyone.

Every decision inherits what came before it, plus the state of the business, plus conditions nobody in the room controls. A system that only shows this week's KPI snapshot is reporting your speed and position on the map. It says nothing about what's around the next turn, or which of the last three decisions put you where you are now. Research on information overload backs this up. Past a certain point, more information does not produce better decisions. People start missing the signals that matter most, lean harder on intuitive shortcuts, and spend more time working out what is happening than deciding what to do about it (Eppler & Mengis, 2004). A better-looking chart isn't automatically a better answer.

From KPI to signal: what navigation means

The reframe I keep coming back to is this. A KPI dashboard interprets your position and stops there. A navigator interprets your position against a destination and tells you the next move. Take a wrong turn, and it doesn't scold you for it. Your car's navigation system doesn't say you're lost and the trip is ruined. It says: route recalculated. Reporting should carry the same posture, not a verdict on what already went wrong, but a next step given where things stand.

Your car's navigation system doesn't say you're lost and the trip is ruined. It says: route recalculated.

In practice, a useful signal has to be specific, tied to one SKU, one location, one supplier, one period, since a portfolio average hides more than it reveals. It has to be traceable, so you can ask why and get pointed at the actual source data instead of a bigger number. And it has to be timed to a decision. An insight that arrives after the operating call already happened is a postmortem, whatever else you call it.

I'll admit this is also why I'm wary of any product, an AI one included, that offers a single instant answer with no visible path to how it got there. A number without a source attached is a claim someone is asking you to trust, not evidence you can check yourself. The hard part was never generating more numbers faster. It's shortening the path from question to evidence to decision enough that someone walks it during their working day.

Why marql starts with a question instead of a dashboard

This is the reasoning behind how marql works. It isn't another panel to set up, and we've been careful not to promise full automation or an instant, unquestionable answer. Both are easy claims to make and hard ones to stand behind. marql is a chat-first layer on top of the systems a retail chain, restaurant group, or franchise network already runs (POS, accounting, and inventory among them), with read-only access, hosted in the EU. You ask a real operating question in plain language, and the answer comes back tied to its source, showing the period, the location, and the context behind it, all visible and inspectable. Your existing stack doesn't move. Only the layer on top does.

Publicly, the commitment we've made is narrower than "full visibility, instantly." It's a qualified stack review, followed by a first live view within 24 hours, with pricing starting from EUR 200 a month. It's a smaller claim than the category usually makes. I'd rather it stayed accurate than sounded bigger, and it's the same discipline a COO watching operations across sites would expect from any system claiming to replace a gut check.

The question worth asking your current stack

Twenty years of watching reporting systems get more sophisticated without getting more useful taught me this: more data was never the constraint. The constraint was always the distance between a number and the decision it should trigger.

Before your next operating review, ask a blunt question about whatever you're currently looking at. Does it tell you what to check next, or only what already happened? If it's the second one, the fix probably isn't a bigger dashboard. It's a navigator.