Beyond Reporting: Is Enterprise AI Set to Become the Enterprise Reasoning Layer?

Executive Summary

Much of today's discussion about enterprise AI focuses on adding natural-language or conversational interfaces to existing software, with every vendor appearing to ask the same question: "How do we add AI to our product?" As a primary goal, that framing invites AI-washing. A more productive question is: "How does enterprise software participate in enterprise reasoning?" This paper explores how AI may reshape the role of traditional enterprise systems.

Enterprise Data Management (EDM), portfolio accounting, treasury systems, document management platforms and CRM systems will continue to perform the functions they were designed for, and will keep improving at those functions. But each remains one component in the path towards a Total Portfolio View (TPV). Whether an organisation uses best-of-breed tools or an end-to-end platform, its information must still be assembled and interpreted at enterprise level, including where analytics and data services are outsourced. The fundamental question is:

How do I provide trusted evidence to an enterprise reasoning platform that can answer complex business questions and give the board and regulators a robust, timely Total Portfolio View?

No individual application can answer that question by itself. This points to a significant architectural evolution. Buy-side vendors have spent decades building better systems of record in response to the industry's request for a golden copy of the data required across the enterprise. Each vendor has necessarily answered only part of that request, leaving institutions to integrate the components themselves. The industry can now offer a more ambitious response:

By combining governed systems of record with an enterprise reasoning layer, we can assemble evidence across the organisation and answer questions that no individual system can address.

This is a central role for AI in the modern buy-side: not another system of record, but a more capable coordination and interpretation layer across the systems already in place, particularly considering the refresh cycles of the underlying components.

Specifically, we propose a governed enterprise reasoning system that combines a language model with controlled retrieval, deterministic business rules, validated calculations and human approval. This provides a practical architecture for extending TPV across both structured data and unstructured knowledge.

The following definitions provide a useful guide to the terminology used in this paper:

• Probabilistic layer: interpretation, classification, synthesis and language generation.
• Deterministic layer: calculations, eligibility rules, reconciliations, validation, source permissions and output checks.
• Governance layer: provenance, versioning, access control, approval, audit history and model evaluation.

The objective is therefore not to make the LLM itself deterministic, that is too simplistic. It is to place probabilistic model behaviour inside a controlled system composed of all three layers.

Critically, this shift creates a requirement for trusted, provable inputs. In regulated environments, TPV cannot rely on a probabilistic model operating over loosely governed information. Unless inputs are authoritative and outputs are supported by provenance, validation and approval, conclusions cannot be reliably traced, explained or defended.

Enterprise Software Was Built Around Transactions

For more than thirty years, enterprise software has become increasingly specialised. Financial institutions now typically operate dozens, and often hundreds, of applications covering discrete functions such as portfolio accounting, EDM, treasury, custody, market data, risk management, CRM, data warehousing, document management and workflow. They often outsource some of these components.

Each application performs its own task and owns part of the organisation's information; collectively, they provide a distributed view. Historically, this structure aligned with how software was used: systems executed predefined processes rather than answering open-ended questions. Reports were generated from structured databases using predefined logic. When requirements changed, developers extended SQL queries, added ETL processes or enhanced the data warehouse. The enterprise remained distributed, but the questions were sufficiently well defined for this approach to work.

Regulation Is Changing the Nature of the Problem

Increasingly, regulators are asking organisations questions that span multiple domains. APRA's SRS 551 liquidity reporting framework illustrates this broader trend. SRS 551 does not establish that an LLM is required to complete a regulatory return. It demonstrates that regulatory reporting depends on governed information assembled across custodians, investment managers, investment books of record, treasury systems, classifications and internal controls. The wider process (investigating exceptions, interpreting policy, documenting judgements, explaining movements and preparing board assurance) is where enterprise reasoning can add substantial value.

The reporting framework requires information about liquidity supply and demand, stress events, funding sources and governance decisions. APRA remains technology-neutral: it specifies reporting outcomes and definitions rather than prescribing the technology institutions must use to collect, integrate and govern the underlying information.

In practice, producing those reports may require information from structured systems, such as:

• portfolio accounting
• custodian holdings
• treasury
• market data
• EDM
• risk systems
• security master data

semi-structured information, such as:

• liquidity classifications
• investment mandates
• pricing methodologies
• counterparty information
• operational spreadsheets

and unstructured information, such as:

• Investment Committee papers
• board minutes
• liquidity policies
• operational procedures
• legal agreements
• side letters
• internal emails
• regulatory correspondence
• audit findings

Structured systems provide quantitative data, while documents and communications provide context, interpretation and intent.

This Is a Reasoning Workflow

The workflow increasingly involves finding relevant information, interpreting it, cross-referencing sources, resolving conflicts, applying rules, producing evidence and generating the final report. Reporting is therefore the output of a broader knowledge process. The preceding steps show how enterprise software is evolving from executing transactions to supporting governed reasoning.

In this context, the requirement for TPV becomes clearer. Each step in the reasoning process must be traceable, explainable and reproducible. A governed reasoning system places the probabilistic LLM above tightly controlled retrieval and deterministic controls, so conclusions can be linked to authoritative inputs, and calculations can be independently validated.

This architecture can also meet regulated-environment requirements such as jurisdiction-specific data hosting, data sovereignty, access control, record retention and evidentiary audit trails.

The Emerging Enterprise Architecture

Historically, enterprise architecture looked something like this:

Operational Systems → ETL → Enterprise Data Warehouse → Analytics & BI → Reports

The emerging architecture expands this model:

Structured data + policies + documents + emails +
governance + regulation + external information
        │
        ▼
Enterprise Knowledge Layer
        │
        ▼
Enterprise Reasoning Engine
        │
        ▼
Reports + board papers + risk analysis + regulatory responses +
operational insights + executive decision support

The focus therefore extends beyond integrating data to integrating knowledge. Importantly, the knowledge layer must be governed through clear lineage, permissions, versioning and semantic consistency. It forms the evidentiary foundation for controlled reasoning and TPV outputs.

The Evolving Role of Enterprise Data Management

EDM still plays a significant role in this architecture. Its core task has been to ensure that downstream applications receive clean, consistent and validated structured data. In an AI-enabled enterprise, that responsibility becomes even more important: reasoning systems depend on accurate structured inputs and authoritative identifiers, classifications and hierarchies.

However, legacy EDM platforms have often struggled to adapt quickly to new business requirements. A familiar industry example illustrates the point:

A front-office user requested two additional fields in a legacy EDM data model. The request entered the standard governance and development pipeline, requiring data-model changes, integration updates, testing and release coordination. By the time the fields were implemented two years later, the original requester had left the organisation. The capability was technically delivered, but the business need had moved on.

This sanitised example highlights a structural limitation of heavily governed legacy platforms: rigidity and long delivery cycles can undermine enterprise responsiveness. Newer low-code and no-code platforms improve schema evolution and bring business users closer to data capabilities. That is valuable progress, but it does not by itself solve the wider problem of assembling and reasoning across enterprise knowledge.

EDM therefore evolves from being solely a provider of structured data to being a provider of trusted evidence. It remains responsible for accuracy, validation and control, while the reasoning layer assumes more of the burden of cross-system orchestration. Speed, adaptability and usability become increasingly important alongside data quality, positioning EDM as a foundational component of enterprise reasoning and TPV.

The Difference Between Query Translation and Enterprise Knowledge Reasoning (EKR)

Natural language converted to SQL addresses questions whose answers are contained in structured systems. Enterprise Knowledge Reasoning (EKR) addresses questions that require evidence and orchestration across multiple sources. Compare:

What is our largest Australian equity holding?

which requires retrieval from structured data, while answering:

Why did our reported liquidity position decline despite increased cash balances?

involves multiple perspectives, including holdings data from portfolio systems, cash balances from treasury systems, liquidity classifications from policies, governance context from committee papers and temporary exceptions documented in communications.

An EKR platform assembles these elements into a coherent, explainable response. It extends beyond retrieval by selecting evidence, applying rules, reconciling conflicts and synthesising a conclusion.

Understanding the Role of AI in Enterprise Platforms

Many enterprise vendors are introducing conversational interfaces that improve usability and access. AI may also strengthen data stewardship, exception management, classification, reconciliation, anomaly detection and workflow automation, thus deepening the capabilities of enterprise platforms. These are valuable applications in their own right.

Conversational access to structured data also contributes to the broader evolution towards enterprise reasoning. However, it should not be confused with a governed reasoning layer. High-stakes TPV and regulatory use cases require controlled retrieval, deterministic calculations and rules, evidence, approvals and an audit trail.

Experimentation Is Not a Production Architecture

During discovery and experimentation, a public frontier model such as Claude can be extremely useful. It can help an organisation explore a workflow, test whether a model can interpret the relevant material, identify where human judgement is required and demonstrate the potential value of a new approach. Conducted with synthetic, de-identified or otherwise approved information, this is a sensible way to learn.

What should be dispensed with beyond that phase is the assumption that the same broadly capable public model should be embedded directly into a regulated production process. From the institution's perspective, important aspects of such a service may sit outside its control, including model and version changes, data handling and retention, tool access, service availability and the consistency of model behaviour. Prompt instructions and user caution are useful safeguards, but they do not turn a general-purpose assistant into a controlled enterprise application.

Australian regulators have not prohibited frontier models or prescribed a particular AI architecture. APRA remains technology- and vendor-agnostic. However, APRA's 2026 industry review called for a step-change in AI risk management and governance, while ASIC has warned that governance arrangements are failing to keep pace with adoption. The regulatory direction is towards clear accountability, proportionate risk management, security, testing, assurance, human oversight and the ability to explain and evidence outcomes. Directly embedding a public AI assistant into a material regulated workflow makes those obligations harder to satisfy.

The production architecture should therefore treat the language model as a bounded and replaceable component inside an institution-controlled system. Approved models should operate through enterprise access controls and governed retrieval, with tightly limited tool permissions, deterministic calculations and rules, complete logging, model and prompt versioning, continuous evaluation, human approval and defined fallback procedures. The institution must own the workflow, evidence and control framework rather than relying on the frontier-model provider to supply them.

Claude and comparable models may therefore be excellent environments in which to discover what is possible. They should not, by default, become the production architecture. The relevant test is not whether the model can produce an impressive answer; it is whether the complete process can be governed, reproduced, challenged and defended.

Where Natural Language Does Add Genuine Value to Legacy Platforms

SQL-based platforms remain inaccessible to many people because effective use requires specialist technical skills. Marketing, operations, client service and executive teams consequently rely on central, SQL-capable data teams to act as query intermediaries. Natural-language interfaces provide genuine value by allowing questions such as:

Show me all Australian infrastructure investments with more than $500 million invested.

How many members joined our Balanced option last quarter?

An LLM can translate these requests into reviewed, permission-aware SQL and execute them against governed structured data. This broadens access to information, reduces reliance on specialist SQL expertise and shortens response times. In this setting, AI is best understood as an intelligent query interface: it improves access without changing the underlying source of truth.

This is an important capability, but it is an entrée rather than the main course: enterprise knowledge reasoning.

Enterprise AI as a Coordinating Layer

The longer-term architecture positions enterprise AI as a coordinating layer across systems. Enterprise applications continue to act as specialised providers of trusted data, documents and capabilities. The reasoning layer orchestrates those inputs, building on existing technology investments while enabling questions and analyses that cross application boundaries.

Within this model, probabilistic interpretation, deterministic controls, strong governance and tightly guided retrieval become complementary design principles. The reasoning layer must integrate information in a controlled and auditable way, with material claims traceable to governed enterprise sources.

The Role of MCP and Other Integration Standards

A Model Context Protocol (MCP) connection can provide a standard way for a reasoning system to discover and invoke approved data, tools and workflows exposed by enterprise platforms. In practical terms, an MCP server for an EDM or another system can make governed capabilities (such as retrieving a security record, running a validation rule or requesting a calculation) available through a consistent interface.

MCP does not replace data governance, entitlements, semantic mapping or system-specific controls, and it does not make every platform automatically interoperable. Its value is narrower and more practical: it can reduce bespoke point-to-point integration, preserve the source system's authority and allow the reasoning layer to request evidence or execute approved functions without copying every underlying dataset into a new platform.

For BackPro, MCP is therefore an enabling interface rather than the product thesis itself. The differentiating capability lies in governed orchestration: deciding which sources and tools to use, applying permissions and deterministic controls, retaining provenance and presenting an answer that a human reviewer can verify.

Broader Regulatory Reporting

Once established, this architecture supports regulatory reporting, board reporting, trustee decision support, Investment Committee analysis, due diligence questionnaires, whole-of-fund portfolio analysis, risk investigations, operational resilience, liquidity analysis, ESG reporting, audit preparation, merger due diligence and regulatory-change impact assessments. Each use case requires the organisation to synthesise information across systems and documents.

Across these use cases, the requirement remains consistent: outputs must be explainable, defensible and grounded in authoritative sources. The level of human review and deterministic control should increase with the materiality and risk of the decision.

Conclusion

The evolution of enterprise AI is closely tied to how organisations structure, govern and interpret information. Enterprise software will continue to provide systems of record, with EDM supplying trusted structured facts. Natural-language interfaces expand access to those facts by translating business questions into database queries. Enterprise reasoning platforms go further: they combine structured data and unstructured knowledge, assemble evidence across organisational boundaries and support conclusions that span multiple systems.

Achieving this vision requires more than adding an AI interface. TPV cannot depend on probabilistic output alone. It requires governed knowledge, controlled retrieval, deterministic calculations and rules, provenance, approval and ongoing evaluation. Organisations that develop this capability will improve their ability to understand, explain and act on complex information, in effect becoming enterprises capable of reasoning about themselves.

BackPro's Skin in This Game

Modern regulatory obligations (including APRA liquidity reporting, RG 271 complaints handling, DDQs, investment governance, ESG disclosures and internal board reporting) rarely depend on a single system of record. They require organisations to combine structured data from operational platforms with information dispersed across policies, procedures, committee papers, investment mandates, legal agreements, emails, spreadsheets and historical decisions.

Traditional EDM platforms (and other peer components for the buy-side) remain essential because they create trusted, governed, high-quality structured data. They underpin investment operations and regulatory reporting. They were not, however, designed to interpret policy, reconcile conflicting documents, explain the context behind a reported number or assemble evidence across an entire technology estate.

Frontier language models excel at interpreting and synthesising language, but cannot on their own provide the governance, reproducibility, auditability or data custody demanded by regulated financial institutions. The future is therefore not EDM or AI. It is EDM and AI, together with the other systems already in place, each performing the role to which it is best suited. The reasoning layer reduces the need to force every item of enterprise knowledge into one all-encompassing data model or ETL pipeline.

BackPro sits above an organisation's existing technology estate as a governed orchestration and reasoning layer. It does not replace EDM, data warehouses, document management systems or operational platforms. It connects to them, combining trusted structured data with controlled retrieval of unstructured knowledge to produce evidence-based answers that are traceable to source.

This architecture enables organisations to:

• Answer complex regulatory and operational questions that span dozens of disconnected systems.
• Generate reports supported by paragraph-level evidence rather than unsupported AI-generated text.
• Reduce weeks of manual investigation to minutes while preserving governance and auditability.
• Democratise access to enterprise data through natural-language interfaces, allowing business users to query governed information without requiring SQL expertise.
• Preserve existing investments in EDM while dramatically increasing the value those investments deliver.

In this model, EDM and peer systems continue to own their respective domains. BackPro provides the enterprise reasoning layer that connects structured data, unstructured knowledge, rules and evidence. As regulatory obligations expand, advantage will increasingly flow to institutions that can assemble trustworthy answers quickly, explain how those answers were reached and reproduce them when challenged.

That is the problem BackPro is built to solve.