Ask any ERP vendor if their analytics are real-time and the answer is almost always yes. Ask what "real-time" means to them, and the honest ones will admit it's a scheduled refresh — usually every 15 minutes, sometimes hourly, occasionally overnight for the heavier reports. That's not real-time ERP analytics. That's batch reporting wearing a real-time label, and for a lot of day-to-day decisions the difference doesn't matter. For the decisions where timing is the whole point, it matters enormously.

Batch refresh vs. true real-time — what's actually happening under the hood

A batch-refreshed dashboard works like this: at fixed intervals, a job runs, pulls data out of the transactional database, crunches it, and writes the result to a reporting table your dashboard reads from. Between refreshes, the number on screen is frozen — it was accurate at the last run, not now. If a customer places a large order two minutes after the refresh, your stock dashboard doesn't know yet.

True real-time analytics works differently: the dashboard is wired to the same event stream the transactional system writes to, so a change lands on screen within seconds of happening in the ERP, not at the next scheduled interval. That requires a different architecture — event-driven data pipelines rather than a nightly (or hourly) extract-transform-load job — which is why it's more expensive to build properly and why so many vendors quietly settle for "frequent batch" and call it real-time anyway.

Why the gap actually costs money

For a lot of reporting — monthly sales trends, quarter-over-quarter margin, headcount planning — a 30-minute or even daily lag changes nothing. Nobody needs last quarter's numbers to the second. The problem shows up specifically in workflows where a decision has to be made before the next refresh, and being wrong for that window is expensive:

  • Stock and reorder points. If your ERP's inventory dashboard refreshes hourly, a fast-moving SKU can cross its reorder point, get sold through, and go out of stock entirely inside that hour without anyone seeing a warning until it's already too late.
  • Credit and collections. A customer near their credit limit places another large order in the gap between refreshes. If the check happens against stale data, you've just extended credit you didn't mean to.
  • Production scheduling. A machine goes down or a batch fails quality on the floor. A dashboard that's 20 minutes behind means the next shift's plan is built on a floor state that no longer exists.
  • Fraud and anomaly detection. Unusual transaction patterns are far easier to catch and stop while they're still in progress than after a batch job surfaces them an hour later.

None of these are edge cases for the businesses they affect — they're the exact moments a dashboard exists to catch.

How to tell what you actually have

You don't need to take a vendor's word for it. A few direct questions expose the architecture fast:

  • "If I create a transaction right now, how many seconds until it shows up on the dashboard?" A real-time answer is "seconds." A batch answer will be phrased as a refresh interval — "every 15 minutes," "on the hour."
  • Ask to see the dashboard update live while a test transaction is entered elsewhere in the system. If nothing changes within a few seconds, it isn't real-time, regardless of what the marketing page says.
  • Ask what happens to that dashboard during peak load. A genuinely event-driven pipeline degrades gracefully; a batch job that's already tight on its schedule tends to fall further behind exactly when you need it most.

Where honest batch reporting is the right call

This isn't an argument that everything needs to be real-time — building true real-time ERP analytics costs more, and that cost should go where the timing actually matters. Monthly financial close, annual industry benchmarking, and most executive-level trend reporting are legitimately fine on a daily or even weekly batch, and paying for real-time infrastructure there is money spent solving a problem you don't have. The mistake is applying that same batch assumption to inventory, credit, or floor-level operational dashboards where minutes are the difference between catching a problem and explaining one after the fact.

How we scope this at Krisol

When we build out analytics for a client's ERP, the first step is mapping which dashboards genuinely need second-level freshness against which ones are fine on a scheduled refresh — not defaulting everything to the more expensive option, and not quietly shipping batch reporting under a real-time label either. That same triage often surfaces a related gap: a dashboard that's technically fast but still requires a person watching it to act, which is exactly the handoff Agentic AI is built to close — reacting to the live data the instant a threshold is crossed instead of waiting for a human to notice. If your industry's operating rhythm runs on minutes rather than days, it's worth an honest conversation about which of your dashboards are actually keeping up. Get in touch and we'll tell you plainly where you stand.