Your Business Has the Reports. But Can Anyone Explain What Actually Happened?

The question that stops the meeting

Picture a management meeting. Finance has its reports. Procurement has its purchase orders. The stores team has its stock movement tracker. Human Resources has its attendance register. Operations has its daily performance report. The General Manager has a dashboard summarizing all of it.

On the surface, this is a well-managed business. Then someone asks one simple question:

“Can somebody explain exactly what happened?”

The meeting changes. The figures are available, but the explanations are not. One department points to a spreadsheet. Another produces an approval message. Someone remembers a telephone conversation. Someone else insists the transaction was handled. A manager says the supporting document is with Finance. Finance says it was never submitted.

The records exist. The reports exist. Yet nobody can give a complete, reliable account of the event without calling several people, comparing different sources and rebuilding the story by hand.

After years of working in business operations, I've come to believe that one of the most expensive weaknesses in an organization is not necessarily the absence of information. It is the inability to connect information to the events, decisions and responsibilities that produced it.

1. Recording an event is not explaining it

Throughout my career in hospitality, inventory management, cost control and operational excellence, I've worked with stock counts, requisitions, purchase orders, delivery notes, Goods Received Notes, invoices, attendance registers, schedules, cash and expense records, departmental reports and reconciliation trackers. I've also designed operational systems meant to make those records more structured and useful.

One lesson has stayed with me: recording an event and explaining an event are two different achievements.

A stock report may show that an item fell by ten units. So what caused it?

A financial report may show that a supplier has been paid. But was the payment supported by a verified delivery? Was the quantity received consistent with the quantity invoiced? Did someone approve a change, and was that approval valid at the time it was given?

The numbers might be mathematically correct. That does not establish operational truth.

To understand a business, we must be able to explain the events behind the numbers.

2. A dashboard is not evidence

Dashboards are attractive. They make complicated information easier to understand, highlight trends and help managers spot problems. I believe they are valuable. I also believe businesses sometimes expect far too much from them.

Consider a dashboard showing an inventory variance of UGX 2,500,000. That figure gets attention immediately. Perhaps it exceeds management's threshold. Perhaps it appears in red. Perhaps a manager demands an explanation before the end of the day.

But the dashboard has not established what caused the variance. It has only presented a result derived from underlying records. The next question should be: can we trace this figure back to the individual transactions and evidence that produced it?

If the answer is no, the business has a visibility problem disguised as a reporting achievement. A dashboard should not be the end of an investigation. It should often be the beginning.

This is not merely philosophical. In a 2016 Harvard Business Review article, Thomas C. Redman argued that fixing data errors downstream is expensive and does not work well. The problem is not always the report. Sometimes it is the process that produces the data.

A beautiful dashboard displaying unreliable records does not make those records reliable. It may simply make them more persuasive.

3. The shortage that never happened

Imagine a restaurant with several departments. The kitchen raises requisitions. The store issues goods. Procurement manages suppliers. Finance manages payments. Operations monitors performance. Each department keeps its own records, which seems perfectly reasonable until those records disagree.

Suppose the kitchen requisitions five cartons of an ingredient. The store physically issues them. The requisition book is signed. The kitchen receives the goods. But the person updating the central inventory tracker accidentally skips the transaction.

Later, the stock count reveals a discrepancy. The tracker says the quantity should still be there. The physical count says otherwise. One department has evidence that the transaction occurred. Another system behaves as though it never happened.

The apparent shortage isn't necessarily a physical loss. It may be a recording failure. I've encountered operational problems of this nature, and they reveal something important: the more disconnected the recording process becomes, the more effort a business must spend reconstructing its own history.

This is why simply having digital tools is not enough. Five spreadsheets do not automatically create an integrated system. Five applications do not automatically create a coherent operational record. And putting everything into one database does not automatically solve the problem either.

The real question is whether related activities are connected through consistent identities, rules, evidence and responsibilities.

4. Where did this number come from?

Data management has a name for this missing dimension: data lineage. In simple terms, lineage establishes where information originated, how it changed and where it eventually went. IBM describes it as a record of data throughout its lifecycle, including its sources and transformations.

That matters because a report is not an isolated object. It is the result of information passing through a sequence of events. A number on a supplier invoice might eventually appear in a purchasing report, a stock valuation, a cost calculation and a financial statement, after quantity corrections, discounts, returns, unit conversions or adjustments along the way.

If we cannot trace those transformations, we may struggle to explain why two reports disagree. Not every business needs complex enterprise data-governance infrastructure. But even a small business benefits from being able to answer:

• Where did this number come from?
• Who originally recorded it?
• What changed after it was recorded?
• Who authorized the change?
• Which documents support it?
• What other records were affected?

The ability to trace a number is part of what makes that number trustworthy.

5. A purchase is a story, not a row

Process mining examines recorded events to understand how activities actually move through a process. Microsoft's process-mining documentation lists three necessary fields for an event log: a case ID, an activity name and a timestamp.

Think about what that structure implies. A purchase is not one row called “Purchase Completed.” It is a sequence, and the sequence is where the explanation lives. Not every organization follows the same path, and legitimate exceptions exist. But once the actual process is recorded, the business can ask much better questions.

Where did the transaction pause? Who had authority at that stage? Was a required approval missing? Was the quantity changed after receiving? Did the invoice refer to the confirmed delivery? Was an exception permitted? And if the process changed, why?

Now the system is doing more than storing information. It is helping the organization understand how work happened. That is the difference between a transaction record and an explainable business process.

6. Responsibility is not proof

Suppose a manager discovers that an expensive ingredient is missing. The stock controller is responsible for inventory. Does that automatically mean the stock controller caused the loss?

No. Responsibility for a process is not the same as proof of wrongdoing. But neither should an unexplained discrepancy be casually dismissed. What matters is the evidence.

I have previously written about why inventory shortages require investigation before accusations. Here, I want to take the argument further. The purpose of accountability should not be to find the most convenient person to blame. It should be to establish responsibilities, investigate the evidence and reach a defensible conclusion.

This is also why internal controls matter. The Association of Certified Fraud Examiners' 2026 Report to the Nations draws on 2,402 occupational fraud cases across 143 countries and territories, and associates anti-fraud controls with lower losses and quicker detection. Genuine misconduct is a serious business risk.

A thoughtful approach must therefore avoid two equally dangerous extremes: assuming every unexplained discrepancy is dishonesty, and assuming every discrepancy must be an innocent administrative error.

Neither assumption is an investigation.

A reliable process should help distinguish among mistakes, legitimate exceptions, weak controls, unsupported transactions and suspected misconduct, and it should preserve the evidence needed to support the conclusion.

7. Everyone can agree on the wrong number

In software development, we often hear the expression “single source of truth.” I understand why. Organizations cannot operate effectively when five departments maintain conflicting versions of the same information. But a record should not become unquestionable simply because it lives in the main system.

Imagine a receiving officer accidentally entering 100 units instead of 10. The application accepts the entry. Every report reads from the same database. Every department sees 100 units. The organization has achieved consistency, and the information is still wrong.

A good system needs ways to detect mistakes, correct records, preserve evidence and understand the consequences of corrections. It should distinguish the original transaction from later amendments. It should identify who made a correction, when, and under what authority. It should show whether the correction affected inventory, accounting, reporting or other dependent records.

A single source of truth must also be a system capable of explaining how its truth was established.

8. Another button won't fix this

This leads to a difficult question for software developers: what exactly are we building? Applications that make it easier to enter information? Or systems that make business activity easier to understand, control and verify?

Ideally, both. A beautiful interface can make work faster. Automated reports save time. Dashboards improve visibility. None of those achievements guarantees that the underlying process is reliable.

A system could make it incredibly easy to record stock receipts while allowing unauthorized adjustments. It could produce accurate attendance calculations from incomplete biometric events. It could display supplier balances while failing to link invoices to confirmed goods received. It could show that an approval occurred without establishing whether the approver had authority.

These problems cannot always be solved by adding another button or chart. They require understanding business rules, identities, permissions, evidence, exceptions and the sequence in which events are allowed to happen.

This is why I approach software development through operational problem-solving. Before designing a feature, I want to understand the real business activity behind it. Before automating a process, I want to know why it exists. Before presenting a number, I want to know what evidence supports it. And before allowing a system to make an important decision, I want to know what happens when its information is incomplete, disputed or incorrect.

9. The next generation of operational software should explain itself

I'm developing software through OX Labs across inventory, workforce management, reconciliation and business operations. These products address different operational problems and are at different stages of development:

• ITS V.Proinventory and operations control
• HRLogXworkforce management
• Remaindersremainders.space
• ReconSpacereconciliation

A principle increasingly connects how I think about them:

Important business outcomes should be traceable to the events, rules and evidence that produced them.

In inventory, that means understanding stock movements rather than merely displaying balances. In HR and attendance, it means understanding the records and policies behind payable time rather than simply presenting a number of hours. In reconciliation, it means investigating discrepancies rather than merely calculating them. In purchasing and receiving, it means preserving the relationship between what was requested, approved, purchased, delivered, verified and paid.

These are design principles, not claims that every capability has already been commercially delivered. The distinction matters.

Nor am I suggesting that software can independently establish every fact about a business. It cannot. An employee may forget to record an event. A supplier may provide incorrect documentation. A physical count may be wrong. Someone may deliberately conceal information. Even a well-designed system depends on controls, verification and people acting responsibly.

But software can make those weaknesses easier to identify. It can make evidence harder to lose. It can help reveal contradictions, preserve historical decisions and make investigations more systematic. And it can reduce how often a business must rely on someone's memory to explain what happened.

10. Faster is not the same as better

Businesses often invest in technology because they want better control, improved performance and more reliable decisions. Those are legitimate goals. But there's a temptation to begin with the visible parts of transformation: the new dashboard, the new reporting interface, the new mobile application, the new approval screen, the new analytics platform.

These may all be useful. Yet if the business still cannot explain how its information is created, verified, changed and interpreted, its fundamental weaknesses remain.

• Accelerating a poorly understood process is not necessarily progress.
• Digitizing a form is not the same as improving accountability.
• Centralizing records is not the same as validating them.
• Automating a decision is not the same as ensuring it is correct.
• Generating a report is not the same as establishing what actually happened.

I don't believe businesses need to abandon their existing tools. Spreadsheets, paper documents and manual procedures can all serve useful purposes when their limitations are understood and appropriate controls exist. The question is not whether a business uses the newest technology. The question is whether its information supports trustworthy decisions.

11. Five questions I believe every business owner should ask

If I were assessing an organization's operational systems, I would not begin by counting its dashboards. I would start with these five questions.

The three-month test

Imagine tomorrow morning your General Manager, Finance Manager, Operations Manager and department heads are asked to explain a significant transaction from three months ago. Nobody who originally handled it is available. The employees have moved on. The manager who approved it is on leave. No one can rely on memory.

Could the organization reconstruct what happened using the evidence its systems preserved? Could it explain the sequence, the quantities, the decisions, the approvals, the exceptions, the corrections and the final outcome?

If the answer is yes, the organization has achieved something more valuable than producing a report. It has developed the ability to explain its own operations.

If the answer is no, perhaps the next investment shouldn't begin with another dashboard. Perhaps it should begin with understanding what the business needs to know, and ensuring its processes preserve the evidence required to know it.

Because the most dangerous weakness in a reporting system isn't always an incorrect number. Sometimes, it's a perfectly presented number that nobody can explain.

A report tells you what the records say. A trustworthy system helps you establish why the records say it.

And to me, that is where better business software begins.