A group finance team needs to know when a number is current enough for the decision at hand, which entities it includes, and what remains uncertain. Refreshing a dashboard every minute does not answer those questions. Useful multi-entity visibility depends on explicit data freshness, consistent definitions, and a clear distinction between provisional operating information and approved financial results.
For a treasury or group reporting leader, the design decision is which information needs rapid updates and which requires a controlled periodic process. Bank positions, unpaid obligations, project margins, and consolidated earnings do not share one natural clock. Trying to make all of them “real time” can increase integration cost while concealing the estimates and missing records inside the total.
Start with a concrete use case, such as preparing the next day’s payment plan. Define the entities, bank accounts, currencies, obligations, cutoff, and responsible decision-maker. Build a view that supports that decision honestly before attempting an all-purpose financial command center.
An information contract is a working design aid that specifies what a reported number means and when a reader may rely on it. It should identify the business definition, entity coverage, unit or currency, source, effective time, extraction time, transformation version, and approval status.
The distinction between effective time and extraction time matters. A feed extracted at 09:00 may contain a bank balance effective at the previous day’s close. Labeling it “updated at 09:00” can lead the reader to assume it includes morning activity. Similarly, an invoice entered today can relate to an earlier service period. A single timestamp cannot explain both business timing and system processing.
Define the acceptable delay for the decision. A payment-planning view may need sufficiently current bank information before a specific approval window. A monthly allocation analysis may not benefit from intraday refresh. Include a rule for late or missing inputs: stop the decision, use a clearly marked prior value, or obtain an alternative approved source.
The Basel Committee’s 2013 risk-data principles tie timeliness to the nature and criticality of risk while also requiring attention to accuracy and completeness. Those principles concern banks; the information-contract approach here is a broader management design recommendation. BCBS 239, Principles 4 and 5
A group total requires compatible definitions, not necessarily identical local systems. Keep local account codes where needed, but map them to a controlled group definition with an owner and effective dates. A mapping change should explain whether it affects only future reporting or also changes comparative views.
Entity identity deserves the same discipline. Legal entity, business unit, operating location, and management region are different dimensions. An executive may want to view activity by region, while a payment obligation belongs to a specific legal entity. Combining the dimensions into one field makes it difficult to reconcile the view or understand who can act on it.
Currency adds another layer. The system should preserve the original amount and currency, identify the rate and conversion purpose, and distinguish management conversions from values approved for formal reporting. The applicable accounting treatment depends on the framework and facts; a convenient dashboard rate should never silently become an accounting policy.
Use a definition register for the few metrics included in the first release. For each, record inclusions, exclusions, treatment of missing data, and known differences between local and group interpretations. A shared definition does not eliminate legitimate local requirements. It provides a controlled way to explain and reconcile them.
A green refresh indicator is insufficient when one entity has stopped contributing. The view should expose both source freshness and population coverage. For example, show how many expected accounts have supplied usable data, which entities are missing, and the last valid effective time for each source.
Coverage should reflect significance as well as count. Nine of ten accounts may sound complete, but the missing account could contain most of the group’s cash. Where a value-based coverage estimate is used, state its reference basis and uncertainty. Do not calculate a precise completeness percentage from unknown balances and present it as fact.
Separate three states in the interface: received but not validated, validated for the defined operating use, and approved for a specified reporting purpose. These states are an operating convention to be designed with finance, not accounting categories. They prevent readers from treating data arrival as evidence of finality.
A group may also need more than one perimeter. The entities shown in a management view can differ from the entities included in formal consolidation. Under IFRS 10, control is the basis for consolidation, subject to its provisions and exceptions. A reporting dashboard should retain the approved perimeter rather than infer it from whichever companies happen to send a file. IFRS Foundation, IFRS 10 overview
Suppose a hypothetical group shows USD-equivalent cash of USD 1.2 million in Entity A, USD 0.8 million in Entity B, and USD 0.5 million in Entity C. The visible total is USD 2.5 million. For this example, finance has identified USD 0.3 million in A as unavailable for the proposed payments and USD 0.9 million of already committed payments in B.
Subtracting these amounts gives a preliminary arithmetic residual of USD 1.3 million. That does not establish a transferable group surplus. Entity-level needs, access rights, legal restrictions, funding arrangements, currency exposure, and other facts would require separate assessment before any movement of money.
Now assume C’s USD 0.5 million is based on a two-day-old statement, while A and B are current for the planning cutoff. The view should show a current-data residual of USD 0.8 million plus a separately identified USD 0.5 million stale contribution. Presenting USD 1.3 million with a fresh dashboard timestamp would conceal a material uncertainty in this teaching scenario.
The operating response depends on the proposed decision. If the next approval requires only A’s verified local availability, C’s stale feed may not block it. If the decision depends on funding from C, the treasurer needs a current authorized source and any necessary entity-specific approvals. The dashboard should direct attention to the missing evidence, not substitute an arithmetic group total for that assessment.
The worked example illustrates why rapid visibility is useful only when the system preserves the boundaries around the number. A faster total can otherwise amplify an incorrect assumption about what the group can do.
Each source should deliver enough information to establish that a batch or event population is complete for its stated cutoff. Depending on the interface, this can include expected record counts, control totals, sequence identifiers, or an explicit completion message. The engineering design will vary; the finance requirement is to detect missing, duplicate, or changed information.
Make retries safe. An interrupted load should not duplicate balances or obligations when it resumes. Keep the original source identifier and distinguish replacement snapshots from incremental changes. Test a repeated file, a late correction, and an out-of-order update before relying on the view.
A rejected record needs an owner and an effect on the published result. It may be safe to withhold a minor descriptive attribute while displaying the amount. It may be unsafe to include a transaction with an unknown entity or currency. Define these rules with finance and make the effect visible. Quietly discarding rejected records creates totals that look complete because the errors have disappeared.
Retain enough history to explain what a decision-maker saw at a particular time. A live dashboard that overwrites every prior state is difficult to investigate after a discrepancy. The retention period and access design should follow the organization’s obligations and information policy, rather than an arbitrary universal duration.
Real-time integration is justified when faster information changes an authorized action and the organization can respond. If no one will investigate alerts until the next morning, second-by-second refresh may have little operational value. It can also produce distracting fluctuations before business events are sufficiently complete to interpret.
A mixed cadence is often sensible: rapid updates for a narrow set of operational signals, daily validated entity views, and periodic approved reporting. The relationship among them should be documented. Readers need to understand why an operational view differs from a later closed result and which adjustments explain the movement.
Assign a named owner to each freshness breach. The response can be technical restoration, local data repair, or a temporary decision restriction. Measure elapsed time from a breach to a usable resolution, and examine whether stale values were mistaken for current ones. These measures connect infrastructure performance to the business purpose.
For a first release, choose one decision, a small set of entities, and only the metrics necessary to act. Require the team to demonstrate a missing feed and a corrected transaction, not just a successful refresh. Expand when readers can explain what the number includes, how old it is, and what they must verify before acting. That is the foundation of credible real-time financial visibility.
