Sit through four software demos and you will hear the same phrase in all four. Real-time visibility. Real-time reporting. Real-time data across your portfolio. Nobody in the room asks what it means, because everyone assumes they already know, and because asking feels like a question with an obvious answer.

It is not an obvious answer. Two vendors can both say real-time while describing arrangements that differ by orders of magnitude. One means there is a single record, so there is nothing to update. Another means a job runs every fifteen minutes. A third means the screen refreshes instantly while displaying figures last touched at two in the morning. All three statements are made in good faith, using the same word, and the differences between them determine whether the number you are looking at can be acted on.

This is a word worth interrogating, because you are almost certainly buying on it, and possibly making decisions on it.

What the term actually meant

The phrase has a precise technical origin, and the precision is instructive because the marketing usage inverts it. In computing, a real-time system is not one that is fast. It is one that guarantees a response within a defined deadline. As the ROS design documentation puts it, a real-time system is not defined by low latency but by a deterministic schedule, where it must be guaranteed that the system finishes a certain task by a certain time.

The distinction carries real weight in the field it came from. A hard real-time system, such as an anti-lock braking controller or an avionics system, treats a missed deadline as a total system failure. A soft real-time system degrades gracefully instead. The classification is entirely about the consequence of missing the deadline, not about the speed of the response.

Notice what this means for the software you are being sold. The original term was a promise about guarantees. The marketing term is a claim about feeling current, and it comes with no deadline, no guarantee, and usually no stated maximum age. The word was borrowed from a domain where it meant something exact, and stripped of the exactness on the way over.

The four things vendors mean

In practice, real-time in property and financial software refers to at least four distinct arrangements.

• One record: There is a single stored version of the fact, so when it changes, everyone reading it sees the change, because no copy exists to fall behind. This is the strongest version of the claim and the only one where currency is structural rather than operational.

• Event-driven propagation: Two or more systems hold copies, and a change in one triggers an update to the others within seconds. Genuinely fast, and dependent on the propagation mechanism working.

• Scheduled batch: A job runs every fifteen minutes, every hour, or overnight. This is very commonly described as real-time, and in fairness it is a great deal better than manual reconciliation. But the data you are looking at has an age, and that age can be substantial.

• A live interface over stale data: The dashboard updates instantly, animates nicely, and reflects a dataset last refreshed hours ago. This is the most misleading of the four, because the responsiveness of the interface is doing rhetorical work the data cannot support. The screen feels current. The numbers are not.

A buyer who does not distinguish these is not making an informed purchase, and more importantly, a leader who does not know which one they have is making decisions on numbers of unknown age.

The distinction that matters most in finance

There is a fifth issue that cuts across all four, and it is the one that catches finance teams. Current and correct are different properties, and freshness does not imply readiness.

A general ledger balance can be perfectly up to date and still not be a number you should act on, because accruals have not been posted, allocations have not run, intercompany activity has not been eliminated, and the period has not been reviewed. The figure reflects everything entered as of this moment, which is precisely why it is not yet the figure that will appear in your statements.

So a real-time financial view can be simultaneously the most current number available and the wrong number to make a decision on. Vendors selling real-time reporting rarely draw this distinction, because it complicates the pitch, and buyers rarely ask, because the assumption that newer means better is deeply intuitive and, in finance, frequently false. The number you can act on is usually the reconciled one, not the newest one.

Fresher data can make decisions worse

Even where the data is genuinely current and genuinely correct, there is a further problem that almost nobody raises during a procurement conversation: seeing numbers more frequently can degrade the quality of decisions made on them.

W. Edwards Deming demonstrated this with the funnel experiment, which shows the adverse effects of adjusting a process in response to variation without understanding what caused it. He called the behavior tampering, and his conclusion was blunt: if anyone adjusts a stable process for a result that is undesirable, or for a result that is unusually good, the output that follows will be worse than if the process had been left alone. Reacting to individual data points in a stable system increases variation rather than reducing it.

Now consider what happens when a leadership team gains hourly visibility into collections, occupancy, or work order throughput. Most of the movement they will see is ordinary variation, the noise any stable process produces. But the data is now arriving faster than the process can meaningfully change, and the natural response to a visible dip is to do something. That is tampering, delivered at higher frequency, and the more real-time the feed, the more opportunities it creates.

This does not argue against measurement. It argues that the value of increased data frequency depends entirely on whether the organization can distinguish signal from noise at that frequency. Without that discipline, more current data produces more reactions, not better ones.

The honest part: sometimes it genuinely matters

None of this means real-time is a marketing fiction, and there is a class of decisions where it is exactly the right requirement and worth paying for.

Anywhere the decision cycle is faster than the refresh cycle, staleness causes real errors. Unit availability during active leasing, where two people can commit the same unit. Work order dispatch, where a technician needs to know the job status now. Payment authorization and fraud checks. Access control. In these cases the cost of acting on a fifteen-minute-old picture is concrete and immediate, and the argument for genuine currency is strong.

It is also worth being fair to vendors. The term has no agreed technical definition in business software, and its dilution is genuine linguistic drift rather than coordinated deception. Most salespeople using the phrase believe it accurately describes their product, because within their industry's usage, it does.

And the instinct behind wanting it is sound. Stale data has caused enormous problems in property operations, and a leader who has been burned by discovering a number was three weeks old is right to care about currency. The correction here is not to stop caring. It is to get specific about how much currency each decision actually requires, rather than buying the word wholesale.

The question to ask instead

The useful reframe is to stop asking whether something is real-time and start asking about decision latency: what decision does this number drive, how often is that decision made, and how stale can the input be before the decision goes wrong?

That question produces different answers for different data, which is the point. Unit availability during a leasing conversation tolerates almost no staleness. A rent roll for weekly review tolerates a day. Consolidated financials for a monthly close tolerate considerably more, and benefit far more from being reconciled than from being fresh. Matching data currency to decision cadence, rather than to the strongest claim on the slide, is how you avoid paying for currency you cannot use and how you avoid trusting currency you do not have.

With that framing, four questions make any demo more informative:

• What is the maximum age of this figure at the moment I am looking at it?

• Is that a guarantee or a typical case?

• Is this number reconciled, or only current?

• And if the update process fails, how would I know?

That last question matters more than it appears, because an update mechanism that fails quietly presents stale data with a completely current-looking interface, which is the failure mode covered in the integration that quietly runs your company. A vendor who can answer all four precisely is describing a real property of their system. A vendor who cannot is describing a feeling.

This is also, at bottom, the same discipline that applies to every technology requirement: define what the business actually needs and stop there, rather than pursuing the strongest available version of a capability because it sounds better, an argument made at more length in when good enough is the right call. Real-time everywhere is expensive, architecturally complex, and in several places actively unhelpful. Real-time where the decision requires it is simply good design.

FAQs

Q1. What does real-time actually mean in computing?
It refers to a system that guarantees a response within a defined deadline, not one that is merely fast. The classification depends on the consequence of missing that deadline: a hard real-time system treats a missed deadline as total failure, while a soft real-time system degrades. The defining property is the deterministic guarantee, which is precisely what the marketing usage omits.

Q2. What are the different things vendors mean by it?
At least four. A single stored record where no copy can fall behind. Event-driven propagation between systems within seconds. Scheduled batch updates running every fifteen minutes, hourly, or overnight. And a live-feeling interface displaying data refreshed hours earlier. All four get described with the same word, and they differ enormously in what they let you rely on.

Q3. Which of those is most misleading?
A responsive interface over stale data, because the interface's behavior implies a currency the data does not have. The screen refreshes instantly, which the eye reads as freshness, while the underlying figures may be many hours old. This is the version most likely to produce confident decisions on outdated numbers.

Q4. Why isn't the newest financial number the best one?
Because current and correct are different properties. A live ledger balance may lack accruals, allocations, intercompany eliminations, and review, all of which are what make the number authoritative. In finance, the figure you should act on is usually the reconciled one rather than the most recent one, and real-time reporting rarely draws this distinction.

Q5. How can more current data make decisions worse?
Through what Deming called tampering: reacting to ordinary variation as though it were meaningful change. His funnel experiment showed that adjusting a stable process in response to individual results increases variation instead of reducing it. Higher-frequency data creates more opportunities to react to noise, so its value depends on whether the organization can distinguish signal from noise at that frequency.

Q6. When is real-time genuinely worth paying for?
Whenever the decision cycle is faster than the refresh cycle and staleness causes concrete errors. Unit availability during active leasing, work order dispatch, payment authorization, and access control all qualify, because acting on a fifteen-minute-old picture produces real mistakes. The requirement should be driven by the decision, not by the category of software.

Q7. What is decision latency and how do I use it?
It is the framing that replaces asking whether something is real-time. For each number, ask what decision it drives, how often that decision is made, and how stale the input can be before the decision goes wrong. Different data will tolerate very different staleness, and matching currency to decision cadence prevents both overpaying for freshness and over-trusting it.

Q8. What should I ask a vendor?
Four things: the maximum age of the figure at the moment of viewing, whether that maximum is a guarantee or a typical case, whether the number is reconciled or only current, and how you would know if the update process failed. Precise answers describe a real system property. Vague answers indicate the word is doing the work the architecture cannot.