A procurement officer at a manufacturer with four sites runs the same check at the start of every morning. She opens the inventory dashboard, filters to the materials her team is responsible for, and looks at the current available quantity per location. The numbers look right. They always look right. What she has learned over the years is that the numbers are not actually current. They reflect whatever state the system was in at the last sync, which depending on the day could be ten minutes ago or several hours ago. She knows this because she has been burned. Twice in the last quarter she committed to a procurement decision based on a healthy on-hand figure at one site, only to discover that a transfer dispatched late the previous day had not yet propagated. The stock she thought she had was already on a truck. The decision she made on Tuesday morning had to be reversed Tuesday afternoon, with apologies. The vendor who heard the apology now adds a margin for what they call planning instability. This is the gap between the marketing word real-time and the operator's real-time inventory definition, and the gap costs money in every direction.
The Operator's Definition
Real-time, for an operator, is not a property of a screen. It is a property of cause and effect. When a movement happens at site A, how long until a decision-maker at site B can see it and act on it. The honest answer should be measured in seconds, not minutes, and certainly not in scheduled job intervals. If the answer is anything else, the system is not real-time in the only sense that matters operationally. It is something weaker, often called near-real-time, which in practice means that the data is current most of the time but stale during exactly the windows when it matters most.
This distinction is invisible in a demo. A demo shows the new value appearing on the screen after a refresh, and the lag of a few seconds looks acceptable. The demo does not show what happens when site A and site B are running concurrently, when a transfer is mid-flight, when an MRP recalculation is in progress, when the user at site B happens to load their dashboard exactly between two sync intervals. The user experience in those windows is not slow. It is wrong. The screen displays a coherent picture that does not match reality, and the user has no way to know that the picture is stale until the consequences appear.
Where Most Systems Fall Short
Many inventory systems advertised as real-time are built on architectures that update a central store on a schedule. The schedule might be every minute, every five minutes, every hour, every overnight cycle. The faster the schedule, the more convincing the real-time claim, but the architectural property is the same in every case. The system is batch-synced with a small batch interval. Inside any given interval, different parts of the system hold different versions of the truth, and the system has no mechanism to detect or expose this inconsistency to the user.
A live inventory vs near-real-time comparison reveals the difference in two places. The first is propagation latency. In a live event-driven system, an event recorded at one site is visible across the entire network within a single transaction commit, typically under a second. In a near-real-time system, propagation waits on the next sync window, and the worst case is the full interval. The second is computational consistency. In an event-driven system, every projection that depends on the underlying data, available-to-promise figures, MRP shortages, alert thresholds, recomputes as part of the same transaction that recorded the event. In a near-real-time system, projections often update on their own schedules, so even after a stock movement has propagated, the downstream calculations may not reflect it until their own next cycle.
The compound effect of these two latencies is what makes near-real-time systems quietly unreliable. A movement might propagate in five minutes. The MRP recalculation might run every fifteen minutes. The alert evaluation might run every five minutes. None of these intervals look bad on their own, but the worst-case path from event to actionable signal can stretch into half an hour, and during that window the operators are making decisions against a stale view they have no way to identify as stale.
Why Inventory Latency Compounds
Inventory latency is not a linear cost. Each second of stale data multiplies the number of decisions that have to be undone or hedged against. A procurement officer who places an order based on stale stock has to reverse the order, apologize to the supplier, and re-plan the procurement window. A production planner who confirms a run based on stale material availability has to halt the run when the missing material is discovered, reschedule downstream operations, and explain the delay to the customer. A warehouse manager who dispatches a transfer based on stale destination capacity has to re-route the truck or absorb the cost of an over-receipt.
Each of these reversals carries an explicit cost, the labor and cash impact of undoing the decision, and an implicit cost, the erosion of trust between the operator and the system. Operators who learn that the system is sometimes wrong adapt by hedging. They call to confirm before acting. They maintain side spreadsheets to bridge the gap. They add buffer to every commitment. The buffer becomes an organizational habit, and the habit costs more in aggregate than any single reversed decision. We have written before about how this dynamic plays out when teams rely on spreadsheet-based inventory practices, and the same pattern reappears in any system whose latency exceeds the operator's tolerance for uncertainty.
What Real-Time MRP Requires
Material requirements planning is the place where real-time properties matter most because MRP is the layer at which inventory becomes commitment. An MRP run takes a set of confirmed production orders, explodes them against current bills of materials, subtracts current available stock, accounts for scheduled receipts, and produces a list of net requirements with order-by dates. Every input to that calculation is a snapshot in time. If the snapshots are taken at different moments, or if the underlying data is mid-sync at the moment of calculation, the output is internally inconsistent and the procurement decisions made from it are wrong.
A real-time MRP system recomputes against a consistent point-in-time view that includes every event committed up to the moment of recalculation. There is no window during which a movement has been recorded but not yet reflected in the projection. The recalculation can be triggered by any event that meaningfully affects requirements, a production order confirmation, a purchase order receipt, a stock movement, a BOM activation, and the result is available immediately to whoever needs it. This is what deterministic MRP on live data actually means, and it is only achievable on top of an event-driven inventory architecture in which every state change is captured atomically.
The connection between event-driven inventory and reliable MRP is not incidental. It is structural. We have explored the broader implications in earlier writing on the immutable audit ledger and how every movement matters, and the same property that makes the ledger trustworthy for audit purposes is what makes downstream calculations like MRP and available-to-promise honest in real time. A system that cannot guarantee that every movement is captured exactly once, in order, with timestamp and actor, cannot guarantee that any projection built on those movements is consistent.
Sub-Second Visibility Across Sites
The practical test of a real-time inventory claim is observable. Pick any two sites in the network. Have an operator at site A record a stock movement. Time how long it takes for the corresponding change to appear on a screen at site B without manual refresh, for the available-to-promise figure on any affected product to update, for any related alerts to either fire or auto-resolve, and for any MRP projection that depends on the affected material to reflect the new state. If all of these happen within a second or two, the system is real-time in a meaningful sense. If any of them take minutes, hours, or scheduled jobs, the system is something else, and the marketing word is doing more work than the architecture.
This kind of test is unfamiliar to most buyers because it is not what demos optimize for. Demos optimize for the appearance of capability. Operational reality optimizes for consistency under concurrent load. A buyer who runs the test ahead of a purchase decision, with two operators on two screens performing simultaneous actions, will learn more about the system than any number of feature comparisons can convey.
The Honest Definition
The honest real-time inventory definition is straightforward. An event at any point in the system is visible everywhere it matters within a single transaction commit, typically under a second. Every derived value that depends on the event recomputes as part of the same commit. There is no window during which different views of the system show different truths. There is no scheduled job standing between the operator who records reality and the decision-maker who needs to know it. This standard sounds aggressive only because so much of the market has been allowed to use the term real-time without meeting it. Inside the operations of a manufacturer, the standard is not aggressive. It is the minimum required to make multi-site coordination work without verbal hedging and side-channel reconciliation.
The vendors who can meet this standard are the ones who built their systems around event-driven architectures, derived projections, and atomic transactions from the beginning. The vendors who cannot meet it are the ones who built around scheduled syncs and stored aggregates, then added a faster schedule when the market demanded real-time. The architecture is upstream of the claim, and the operator is downstream of the architecture. Bridging the gap between the claim and the architecture is what determines whether a system is genuinely real-time or merely fast enough to look like it.
FalOrb is built on an event-driven architecture with derived stock quantities and sub-second propagation across sites. Every movement, every projection, every MRP recalculation reflects the same point-in-time truth. Book a 30-minute walkthrough or email us at [email protected] to see how it applies to your operation.