Investment accounting has spent decades organized around batch processing. Transactions accumulate, processes run at defined points and downstream activity waits for the resulting accounting state.
This model made sense when computing power and storage were expensive. It also shaped the operating processes firms still use today.
Modern technology removes much of the constraint. A trade, price, cash movement or corporate action can update the accounting record when it arrives. Controls can run against that activity immediately. Reconciliations can begin as the necessary records become available, and validated accounting data can reach downstream consumers without waiting for an overnight cycle.
None of this means every process should run continuously.
Some accounting activities need a complete population. Others depend on a cutoff, an approved accounting state or human authorization. The difference is that a real-time architecture does not require the entire operation to wait with them.
This distinction is becoming particularly important as firms consider how AI agents will work within investment operations. AI can only work with the accounting state, controls and context available to it. The architecture underneath determines how current that picture can be.
Batch processing was an architectural necessity. Not anymore.
Many investment operations teams still work within processes designed around fixed processing windows.
Processing transactions individually as they arrived was expensive. It made sense to accumulate activity, process it together and distribute the results afterwards.
The technology has changed considerably since then. Modern cloud infrastructure can process and store far more data, and event-driven systems can respond to individual events as they occur.
Yet many investment operations teams still work within processes designed around the old constraint.
A late trade arrives and several processes need to be rerun. Teams determine whether all the necessary data is ready before starting the next job. Downstream systems wait for files because that is when the accounting platform makes updated information available.
Moving the same software into the cloud does not necessarily change any of those behaviors.
A real-time architecture does.
The accounting state can update as events arrive, while controls determine what happens next.
Real-Time Architecture Does Not Mean Everything Happens Immediately
This is an important distinction.
Consider a stale-price check. The purpose of the control is to identify an expected price that is missing or unchanged. Running it continuously before the day's expected pricing sources have arrived would create exceptions for prices that are not late yet.
The control needs to wait.
But the reason it waits should be a business rule: the required price file has arrived, all expected sources have been accounted for or a defined cutoff has passed.
Other accounting activity does not need to wait alongside it.
The same principle applies to official valuation and NAV controls, regulatory reporting, completeness checks and other processes that depend on a defined population or approved accounting state.
A real-time accounting platform can support those activities without becoming batch architected. Controls establish when a process has enough information to run and what needs to happen before the result can progress.
This gives operations teams much more precision over how work moves through the accounting environment.
Different Processes Need Different Triggers
Within a real-time architecture, work can begin in several ways.
An event arrives. A trade, price, cash movement or corporate action updates the relevant accounting state and initiates the controls that can run against it.
A completeness condition is met. A file arrives, a control total agrees, a cutoff passes or all expected sources are accounted for. The dependent process can then begin.
A decision or authorization is reached. A rules engine, AI agent or authorized person approves the next action within defined permissions and control thresholds. Material, ambiguous or low-confidence decisions can be escalated for human judgment.
These triggers can coexist within the same accounting model.
That matters because investment operations has never operated at one speed. The problem with a batch-dependent architecture is that it often forces unrelated work into common processing windows.
With a real-time foundation, the control framework can determine what moves immediately and what waits.
AI Can Only Work With What the Accounting Platform Knows
The implications become clearer when AI agents enter the operating model.
Suppose a reconciliation exception only becomes visible after an overnight process. An agent can investigate the exception once it appears, compare records and suggest a likely cause.
But it could not have done any of that earlier because the accounting platform had not yet exposed the break.
If matching begins as the relevant records become available, the exception can surface sooner. An agent working with the current accounting state can compare internal and external sources, examine related activity and historical behavior and assemble the likely explanation while operations still has time to intervene.
It might recognize that a particular provider is frequently late. It might identify a recurring break. It could determine which downstream processes are potentially affected and recommend what should happen next.
Anomaly detection provides another example.
A model that identifies an anomaly after the NAV has been struck can still help with correction, impact analysis and prevention of recurrence. Detecting the same anomaly earlier creates an opportunity to address it before it reaches additional books, reports or users.
For time-sensitive AI use cases, the timing of the accounting state matters.
Current Accounting Still Needs Controls
Real-time processing does not make every new piece of information final or approved.
A trade may have updated a position while other controls remain outstanding. A price may have arrived but still requires validation. A reconciliation may be substantially matched while waiting for a final statement or control total.
The accounting platform needs to preserve those distinctions.
The same is true for an AI agent using that information.
An agent needs to understand what has been processed, which controls have passed, what remains provisional and what it is authorized to do at that point in the workflow.
A low-risk exception with a high-confidence resolution may be eligible for automated action. A material valuation issue may need to be investigated by the agent and then escalated to an authorized person.
The control framework provides the boundaries.
This is also why simply giving AI access to more data does not solve the operating problem. The data needs to carry the accounting context, history, status and governance required to use it appropriately.
Reconciliation Can Start As Records Become Available
Reconciliation illustrates how a real-time foundation and controlled processing can work together.
Where the relevant internal and external records are available, matching can begin. There is no reason to wait for unrelated activity elsewhere in the accounting cycle.
Exceptions surface earlier, giving operations teams and AI agents more time to investigate them.
Some reconciliations will still require a complete statement, control total or cutoff before they can be considered complete. The platform can perform early matching as data becomes available and then run the appropriate completeness controls when the required population is present.
Both happen within the same accounting process.
Corrections Can Trigger the Work They Affect
Late and corrected transactions are another familiar challenge.
A correction may affect positions, balances, reconciliations, controls and downstream data. Those dependencies still need to be addressed regardless of the underlying architecture.
In a batch-dependent environment, operations teams may need to determine which jobs were affected, rerun them and verify the results.
With an event-driven accounting foundation, the correction itself can initiate the appropriate processing. The platform can identify affected dependencies, recalculate the relevant accounting state, run the required controls and maintain a record showing what changed and what was rechecked.
This reduces reliance on runbooks and institutional memory. It also gives an AI agent a traceable sequence of events and controls it can use when investigating the impact of a correction.
Validated Accounting Data Can Move When It Is Ready
Accounting data has consumers throughout the organization.
Positions, balances and exceptions may feed portfolio management, risk, performance, oversight, client reporting and other applications.
A batch-dependent architecture often organizes those distributions around fixed windows because that is when the accounting system produces an updated state.
A real-time platform can make information available according to its status and the needs of the consumer.
Some destinations may need a formal approved output at a defined time. Others may be able to consume validated information through an API or event-based channel as soon as it is available.
AI agents are another consumer of that accounting data. Their usefulness depends in part on how quickly they can access a trustworthy state and how much context accompanies it.
The Control Framework Decides What Waits
There will always be investment accounting activities that should wait for a defined condition.
These may include:
- Completeness and control-total checks
- Stale- or missing-price reviews at defined cutoffs
- Official valuation and NAV controls
- Regulatory and client reporting
- Periodic trend analysis and model training
- Processes requiring an approved accounting state
These activities may still use batch or set-based processing, but they do not require the entire accounting architecture to operate that way. Controls determine what waits, what can proceed and when each process is ready to run.
It requires controls.
A modern platform can process accounting activity continuously while holding a particular process until its prerequisites have been satisfied. Once they are, that process can run automatically.
This changes the role of the operations team. People no longer need to be the primary orchestration layer for routine processing, deciding when data looks ready, starting jobs and remembering what needs to be rerun when something changes.
They define the controls and conditions the platform should enforce.
Fixed Processing Windows Carry An Operational Cost
Batch-dependent operating models create work around the accounting itself.
Teams coordinate dependencies, determine whether data is ready, restart processes after late activity, recheck results and maintain integrations and downstream distributions built around fixed windows.
Those routines can persist long after the original technology constraint that created them.
They also consume technology capacity. McKinsey reports that companies typically incur an additional 10% to 20% on projects to address technical debt, while about 30% of surveyed CIOs believe more than one-fifth of their new-product technology budgets are diverted to resolving existing technology issues.
Replacing a core accounting platform is a significant undertaking. Firms evaluating that investment need to consider the ongoing operational and technical cost of maintaining their current model alongside the cost of transformation.
Increasingly, they also need to consider whether that architecture can support the automation and AI capabilities they expect to introduce over the coming years.
Ask How the Accounting Platform Behaves
Cloud-hosted and cloud-native investment accounting platforms can look similar from the outside.
A useful way to distinguish them is to look at what happens when something changes.
When a trade arrives, does the relevant accounting state update or wait for a processing cycle?
When a price arrives, which controls can run immediately and which wait for the remaining sources?
When a transaction is corrected, can the platform identify what was affected and automatically initiate the appropriate recalculations and controls?
When information reaches the required level of validation, can downstream applications access it or do they wait for a common distribution window?
And when an AI agent is introduced, what accounting state can it see? Does it have the history and context needed to investigate what happened? Can controls determine what the agent is permitted to do and what needs human approval?
Those questions reveal much more about the underlying architecture than where the software is hosted.
Moving Investment Accounting Beyond Batch
FundGuard was built around a real-time, event-driven accounting foundation.
Trades, prices, cash movements and other events can update the accounting state as they arrive. Controls can run continuously where that makes sense and hold processes until defined conditions are met where it does not.
This allows event-driven processing, completeness-based controls, scheduled activity and governed approvals to operate against the same accounting record.
For operations teams, that means the timing of a process can be determined by what the business requires rather than by a limitation in the architecture.
For AI agents, it means access to a current accounting state, preserved history and the control context needed to understand what they are seeing and what they can do with it.
Batch processing will continue to have a role in investment operations. It just no longer needs to define how the entire accounting environment works.
Frequently Asked Questions
Does real-time investment accounting eliminate batch processing?
No. Some processes need to operate across a complete population, at a defined cutoff or against an approved accounting state. A real-time architecture allows those processes to wait for the appropriate condition without requiring unrelated accounting activity to wait with them.
What is the difference between batch and event-driven processing?
Event-driven processing responds as individual events arrive. Batch or set-based processing operates across a defined collection of data.
A real-time accounting architecture can support both. Controls determine which processing approach is appropriate for a particular activity and when that activity should begin.
Why does processing architecture matter for AI?
AI agents work with the accounting state and operational context available to them. If an exception, correction or updated position only becomes available after a processing cycle, the agent inherits that delay. Event-driven accounting can make relevant information available earlier while controls establish whether it is validated and what actions the agent is permitted to take.
How can controls determine when processing should occur?
Controls can use defined conditions such as the arrival of expected data, completion of a prior process, agreement of a control total, passage of a cutoff or an approval. This allows activities that require completeness to run at the appropriate time while other accounting processes continue independently.
Request a demo to see how FundGuard supports real-time accounting with controls that determine when and how investment accounting processes run.
