Early in my career, while working in sovereign reserve management, I joined a project to replace legacy Excel-based performance and reporting models with a more automated system.
The investment-reporting team understood the calculations and portfolio logic, but much of that knowledge lived inside the spreadsheets and in the accumulated experience of the people using them.
Before the in-house technology team could begin building, we had to explain how the portfolios worked: the instruments they contained, the way those instruments were priced, the meaning of duration, the returns that had to be measured and the way attribution should be interpreted. None of this was unusual within an investment team, but it did not arrive as a ready-made system specification.
Both teams had the expertise they needed. One understood the financial logic and its purpose; the other knew how to build once that logic had been made explicit. What slowed the project was the distance between them.
The same problem in a different setting
I encountered a related problem later in a very different investment setting: a climate-focused portfolio of funds and co-investments. My main role was to understand how the investments were developing and prepare portfolio and performance reviews. Before that analysis could begin, information arriving from different managers, in different formats and on different timelines had to be brought into a consistent portfolio view.
A fund commitment gives an LP exposure to investments selected by the GP, with information about the underlying companies arriving through periodic reporting rather than a live market feed. Co-investments bring the investor closer to an individual company but add their own operating, financing and valuation questions. Across a portfolio containing both, commitments, cash flows and NAV sit alongside fund performance, deployment, manager commentary and activity in the underlying investments.
Platforms such as eFront can collect and organise private-market data, while ILPA’s reporting templates have pushed the industry towards greater consistency. Adoption remains uneven, however, and availability varies by manager, fund, vintage and operational capability. Even a well-designed system can only reflect the information that has reached it and passed the necessary checks.
The climate mandate added another complication. Companies sat at very different stages of technological and commercial development, so progress at a software business could not be assessed on the same timetable as a new industrial process or a capital-intensive energy technology. The financial questions remained central, but context often mattered as much as the number itself.
Testing a different way to work
Quarterly updates often mean returning to lengthy GP reports, investment updates and capital-call notices to establish what has changed. Those documents cannot simply be reduced to a table: investment rationale, developments within a company, valuation movements and intended next steps provide context that structured data alone cannot reproduce.
The case for testing AI came from the repetitive part of that work. The documents changed each quarter, but the questions driving the portfolio analysis were often the same. Information had to be found, compared with earlier reports and mapped to the existing portfolio before the portfolio analysis could begin. I wanted to see whether AI could handle more of that first pass without displacing source review or the analyst’s interpretation.
I began with a general chat tool and then developed a structured AI workflow that could draw on historical information about the investments. It extracted selected fields from new reports and notices into common templates, compared the latest material with earlier records and helped distinguish new investments from follow-on rounds, exits and valuation movements. Documents prepared by different managers could then feed into a more consistent downstream structure.
Because the resulting data fed investment reporting and portfolio analysis, every extraction was cross-checked against the source and mapped to the correct fund or investment before it entered the portfolio records. That is not a special concession to AI; financially consequential data should be subject to controls regardless of how it enters a system. More systematic source citations and exception flags would make that review faster and easier to audit.
Building the portfolio view
Once the information followed a common structure, I built a Power BI reporting workflow from scratch to bring it together with eFront data, external benchmarks and internal records. I had used Power BI before, but there is a considerable difference between knowing a tool and building an end-to-end process yourself. As the reporting needs developed, I used AI to work through unfamiliar measures, queries, tables and transformations, troubleshoot problems and test alternative ways of structuring the report.
That made the learning more immediate. An unfamiliar piece of logic no longer had to become a separate research project before I could move forward: I could examine it, test an implementation and understand what had gone wrong. Over time, AI became less a way of obtaining an answer and more a way of learning enough to extend and improve the report myself.
Transformation and validation rules checked that figures belonged to the correct fund, investment and reporting period, while links back to the source made discrepancies easier to investigate. The resulting portfolio view supported reviews of deployment, cash flows, performance and changes in NAV; traced new investments, follow-ons and exits across the underlying holdings; and fed into investment reviews, performance discussions and presentation material.
By that stage, the relevant question was rarely only what had changed. The analysis had to explain why it changed, whether the explanation was consistent with the underlying activity and what it meant for the investment plan. A report records the portfolio at a point in time; monitoring carries its history forward and connects each movement with the decisions and developments behind it. The workflow did not supply that judgement, but it created a clearer starting point from which to exercise it.
What changed for me
Compared with the earlier reporting project, the practical difference was that I could remain involved after the work became technical. AI made it easier to move from understanding the reporting problem to testing a solution myself.
A workflow built for one team is different from a secure, scalable production system. Code and extracted data still need to be checked, while access controls, reliability and governance may require specialist engineering. Those requirements should shape how a tool is used, but they need not prevent someone who understands the work from testing whether an improvement is useful.
The experience changed the range of technical work I was willing to attempt. Analysts do not need to become developers, but there is value in being able to move further into implementation when repetitive preparation is crowding out the analysis itself. The reports still had to be read, valuations questioned and performance interpreted. AI made it easier to improve the process around that work without confusing the process with the judgement it was meant to support.