14 min read
—
V7 Go
A smarter way to manage due diligence and underwriting
A fund administrator with 90 fund clients receives around 360 general partner (GP) report packages a year. No two arrive in the same shape. One GP sends a 40-page PDF with the capital account statement tucked into an appendix. Another sends an Excel workbook with twelve tabs, three of them hidden. A third publishes to an investor portal that exports a CSV with the column headers sitting in row seven.
Reading them is not the hard part. The hard part is that all 360 have to come out the other side as one consistent set of capital account statements, performance reports and portal uploads, delivered against the same deadline, in the same schema, with the same definitions standing behind every number. Most fund administration teams spend the first two to three weeks of every quarterly cycle on exactly that, and almost all of it goes into retyping figures that already exist inside a document somebody has already read.
The usual case for AI in this workflow is cost. It is the weaker argument. Fund administration is a capacity business: the quarterly cycle has a fixed length, the fund count keeps rising, and the binding constraint is how many packages a team can get through before the reporting deadline, not what each analyst costs per hour.
This guide covers the third-party administrator's side of that work. Fund administrator and third-party administrator (TPA) are used interchangeably throughout. It is not about what GPs produce, and not about what limited partners (LPs) do with the numbers once they have them. It is about the stage in between, where reports arrive in whatever form the manager chose and have to leave in the form the client agreed, on the quarterly reporting cycle everyone downstream is waiting on.
In this article:
What LP report normalisation actually involves, and which fields it turns on
Why the format problem is a definitional problem, not a document-reading problem
Why ILPA templates widen the normalisation workload before they narrow it
The six-step ingestion workflow, and how the canonical schema gets built
What automating extraction and mapping does to a fund administration business
Data quality, governance and the review gate that has to stay
Five criteria for choosing a tool, and where V7 Go sits
What LP report normalisation actually involves
Normalisation is a translation problem with an audit trail attached to it.
The shape of the work is the same at every fund administrator. GP reports arrive through whatever channel each manager happens to use. An analyst opens each one, finds the figures that belong on the client's LP statement, keys them into the administrator's own template, checks them against the prior quarter, and passes the result to a reviewer. The reviewed data then goes into the accounting platform the administrator runs on, whether that is Geneva, Investran, Allvue or FundCount, and comes back out as capital account statements, performance reports and investor portal uploads.
The fields that have to come out of every package are consistent even when the documents are not:
Net asset value (NAV). Opening and closing, at fund level and at the client's partner level.
Capital movements. Contributions, distributions, recallable amounts, and the unfunded commitment that falls out of them.
Performance measures. Internal rate of return (IRR), multiple on invested capital (MOIC), total value to paid-in (TVPI) and distributed to paid-in (DPI), each gross and net.
Fees and carry. Management fees charged, offsets applied, and carried interest accrued, earned or paid.
Holdings. The schedule of investments, with cost, fair value and ownership percentage per position.
Five of those seven steps are logistics. Only two involve judgment, and those two are the ones that get squeezed when the deadline moves.
The format problem is not a PDF problem
Optical character recognition (OCR) settled the legibility question years ago. A scanned capital account statement is machine-readable now, and treating that as the obstacle is what makes most fund administration automation projects stall at the pilot.
The obstacle is definitional. Two GPs can use the same label for figures that were calculated differently, and both can be correct.
Gross IRR may or may not include the effect of the subscription credit facility. One GP shows the fund with the facility, another shows it as though every call had been made on time.
Net multiple may treat recallable distributions as returned capital or as still-outstanding, which moves DPI and unfunded commitment in opposite directions.
Since inception may run from the first close, the first capital call, or the start of the investment period.
Fair value may be struck at quarter-end or at the last available valuation date, which for a co-investment line can be a quarter behind.
Two GPs can both be right and still be incomparable.
That is the actual normalisation work: not retyping the number, but recording which definition produced it and restating it on the administrator's basis. An analyst does this from memory and from a note in a shared drive. It is the part of the job that is hardest to hand over and easiest to get wrong.
Why GP-side standardisation will not remove the work
So the answer is to get every GP onto a standard template, and the Institutional Limited Partners Association has already written it.
Wrong again.
The ILPA Reporting Template version 2.0 replaces the 2016 version for funds still investing during Q1 2026 and for funds commencing operations on or after 1 January 2026. GPs may keep using the 2016 template for mature funds that are past their investment period. Both are legitimate, at the same time, for different funds in the same client book.
Run that through an administrator's fund list. A book spanning 2014 to 2026 vintages now receives version 2.0 from the newer funds, the 2016 template from the older ones, and whatever the non-adopting managers were already sending. Standardisation, in its first years, adds a format. It does not remove one.
The content changes point the same way. BDO's summary of what the updated templates require notes a new gross-to-net reconciliation for management fees and a split of carried interest into accrued, earned and paid. An administrator whose schema carried one carry field now needs three, and needs a rule for the funds that will keep reporting one. Our guide to the ILPA templates covers the GP side of the same change.
There is a second reason the GP side cannot solve this. Administrators who push managers to conform to a house template usually get compliance, and get it at the expense of granularity: the GP fills in the fields that were asked for and drops the supporting detail that was not. The report becomes easier to parse and less useful to the client reading it.
Which leaves one place where the problem can actually be solved. Ingestion.
How AI normalisation works at the ingestion layer
Three things are stacked here, and only the third one is new.
Document conversion. OCR turns scans and image-only PDFs into text. Mature, cheap, uninteresting.
Extraction that reads meaning rather than position. A template-based parser encodes where a value sits on a page and breaks the quarter a GP moves the table. A language model reads the label, the row it belongs to and the footnote attached to it, which is why it survives a layout change.
Schema normalisation. The mapping from a GP's label to the administrator's canonical field, plus the definitional rule that was applied, recorded alongside the value.
The third layer is where the value sits and where most tools stop short. Extracting "Net IRR: 14.2%" is not the deliverable. Knowing that this GP quotes net IRR with the credit facility included, and that the client's statement shows it without, is the deliverable.
The six steps, in order
1. Ingest. Collect from every channel the manager book uses: email attachments, investor portals, data rooms, SFTP drops. Classify the document type before anything else runs, because a capital account statement, a quarterly report and an audited financial statement need different extraction logic.
2. Extract. Read the whole document, tables and narrative both. The commentary matters more than it looks: definitional caveats, valuation policy changes and subsequent events sit in prose, not in the tables.
3. Map. Apply the canonical schema. Where a GP label has no mapping, flag it as unmapped rather than guessing at the nearest match. A silent wrong mapping is worse than an exception queue.
4. Validate. Confidence-score each extracted value, compare it against the prior quarter and against the fund's own arithmetic, and route anything that moves more than a set threshold to a person.
5. Normalise. Apply the definitional rules: IRR basis, recallable treatment, currency, period alignment. Record which rule was applied to which value.
6. Deliver. Push the normalised set into the accounting platform and the client reporting outputs, with each value still linked to the page it came from.
Steps one, two and six are engineering. Steps three and five are the business. Step four is what makes the whole thing defensible when a client asks where a number came from.
What the canonical schema looks like in practice
The schema is the asset. Not the model, not the connector, not the extraction accuracy figure in the vendor deck. The mapping library that says what each of 90 managers means by each of their labels is the thing that took years to accumulate in analysts' heads, and writing it down is most of the project.
What the GP report says | Canonical field | Rule the administrator applies |
|---|---|---|
"Gross Multiple", "Investment Multiple", "MOIC" | moic_gross | Before fees, before carry, realised plus unrealised over invested capital |
"Net IRR", "Net IRR to LPs", "Fund Net IRR" | irr_net | Restate excluding subscription facility where the GP discloses both |
"Ending Capital", "Closing NAV", "Partner's Capital, end of period" | nav_close_partner | Partner level, quarter-end date, before any subsequent-event adjustment |
"Distributions", "Cash Distributed", "Return of Capital and Gain" | distributions_total / distributions_recallable | Split recallable from permanent before DPI is calculated |
"Management Fee", "Advisory Fee", "Priority Profit Share" | fees_management_gross / fees_offsets | Gross fee and offset kept as separate values, never netted at ingestion |
Three principles hold that library together.
Design for the least standardised GP you service, not the most. A schema built around the managers who already send clean workbooks fails on the ones who cost the most time, which are the only ones worth automating.
Version the mapping per manager. A GP changing report format is a scheduled schema event, not an incident. When the mapping is versioned and dated, last quarter's numbers stay reproducible after this quarter's change.
Route exceptions with a reason. Bespoke fee arrangements, side-pocket allocations and side-letter economics need a person. The workflow should hand those over with the unmatched label attached, not default them to the closest field and move on.
What the mapping library buys once it exists: funds and managers held as resolved entities rather than as file names, with every figure still pointing back to the document it was taken from.
What this does to a fund administration business
The published numbers are better than most operations directors expect and worse than most vendor decks imply.
Grant Thornton's account of AI in fund administration records one administrator cutting operational labour costs by close to half after deploying anomaly detection and exception reporting on reconciliations, and puts the reduction in investor reporting generation time at 50 to 70 per cent. Those are real figures from real deployments. They are also figures for the mechanical stages, not for the whole cycle. The review, the client queries and the sign-off do not compress.
The more useful way to read them is as capacity. An administrator whose analysts spend fifteen days a quarter on extraction and mapping and four days on review does not become an administrator that needs half the analysts. It becomes an administrator that can take on the next thirty funds without a hiring round, and that is a different conversation with the board.
The volume is coming either way. CSC's Future Private Capital CFO 2025 survey, covering 300 GPs and 200 LPs, found just over half of general partners planning to expand outsourcing, and roughly three quarters of limited partners expecting portfolio performance on a daily or on-demand basis. More funds arriving on shorter cycles is the growth case and the operational problem at the same time.
It also matters most to the firms with the least scale. A boutique administrator running 40 funds cannot outspend SS&C or Citco on operations headcount, and never could. It can run the same ingestion workflow they do. The gap that used to be structural becomes a configuration question.
Two administrators bid for the same thirty-fund mandate. One quotes six weeks to onboard and a hiring round. The other quotes three weeks and no new hires. The client's decision is not a hard one to predict.
The prerequisites nobody wants to hear about
RSM's position on AI in fund administration, published in March 2026, is the one worth taking seriously: AI will not fix weak foundations, it magnifies them. Point an extraction workflow at a book where the same manager appears under four spellings and you get the same mess back, faster and in higher volume.
Four things have to be in place before the first package goes through:
Resolved entities. One identifier per fund, manager and share class, with the aliases mapped. This is dull and it is the whole foundation.
Provenance on every value. Source document, page, and field. Without it the output cannot be defended to a client or an auditor, and the workflow becomes an unauditable black box that operations will refuse to rely on.
An exception log. Every human override recorded, so the pattern in the overrides can be read. Overrides clustering on one manager mean the mapping is wrong, not the analyst.
Schema versioning. Dated mappings, so restating a prior period reproduces what was reported at the time.
And the gate stays. The administrator is accountable to the client and to the regulator for the accuracy of what goes on an LP statement, and that accountability does not move because the first draft was prepared by a workflow instead of an analyst. Extraction prepares. A qualified person approves. Every serious deployment in this space is built that way, and the ones that are not tend to be pilots that never left the pilot.
What to look for in a normalisation tool
Five criteria separate tools that survive a real manager book from tools that demo well:
Multi-format ingestion without per-format setup. If onboarding a new manager means building a template, the tool has moved the work rather than removed it.
Private markets vocabulary. Generic document extraction does not know that DPI and TVPI are not interchangeable, or what a recallable distribution does to unfunded commitment. That knowledge has to be in the tool, not in the prompt an analyst writes each quarter.
A mapping library the operations team owns. The people who know what a manager means by "Priority Profit Share" are the analysts. If changing a mapping needs an engineering ticket, the library will go stale.
Confidence scoring with routed review. Values below threshold go to a queue. Values that move materially against the prior quarter go to a queue. Nothing is auto-accepted because it looked plausible.
Traceability and a route into the accounting system. Every value opens its source, and the normalised set lands in Geneva, Investran, Allvue or FundCount without a re-key at the end.
That list is what V7 Go is built around. It is not a fund accounting system and does not try to be one: the general ledger, the allocations and the NAV pack stay where they are. It sits at ingestion, where GP reports arrive in whatever form the manager chose, and runs a defined sequence over each one, with each step carrying its own instruction and output type so the five hundredth package takes the same route as the first. The mapping between a manager's labels and the house schema is configured once and maintained by the people who understand it, and every extracted value opens to the exact sentence or cell it came from.
The part that matters beyond a single package is the context layer. V7 Go's Context Graph holds funds, managers and their documents as resolved entities across quarters, so a value is checked against what the firm already knows about that manager rather than against one PDF in isolation. That is the difference between reading a report and having a book of record you can query.
Once the mapping holds across managers, questions that used to require a spreadsheet build can be asked against the book itself.
Administrators who want to see the shape of it before committing anything can start from the fund administration workflow or the private equity fund report setup, both of which run the ingestion sequence described above. The GP report normalisation use case covers the mapping stage specifically.
What to do before the next quarter-end
None of this needs a platform decision to start. It needs four weeks and an honest count.
Time the current cycle properly. Not the estimate. Log extraction, mapping, validation and review separately for one full quarter across the whole book. Most teams find the split is not where they assumed.
Count the formats, not the funds. Ninety clients may be thirty distinct report formats. That number is the size of the mapping problem and it is usually smaller than the fund count.
Name the five managers that cause the most rework. They are known already. They are also the correct place to start, because a workflow that handles them handles the rest.
Write the canonical schema for the twelve fields that appear on every client statement. Just those. On paper, with the definitional rule beside each one. This is the artefact the whole project depends on and it costs nothing but argument.
Run one quarter in parallel. Automated extraction alongside the manual process, on one client, with the differences logged. The log is the business case and the specification for the exception rules at the same time.
Fund administration is one of the few places in private markets where the operational work and the client relationship are the same product. Reports going out three days earlier, with the definitional basis stated and every figure traceable to its source, is a service difference the client notices without being told about it. It is also the only version of the job that scales when the LP reporting cycle keeps getting shorter and the fund count keeps going up.
The next quarter-end is already on the calendar. The formats will not have improved by then.
What is LP report normalisation in fund administration?
LP report normalisation is the process by which a fund administrator turns performance and capital data received from many general partners, in incompatible formats and under inconsistent definitions, into one consistent set of client-ready reporting outputs. It has two parts. The first is extraction: pulling net asset value, contributions, distributions, IRR, multiples, fees and carried interest out of documents that arrive as PDFs, Excel workbooks or portal exports. The second is the harder part: restating those figures on a common basis, because two managers can use the same label for values calculated differently. One may quote gross IRR including the effect of a subscription facility while another excludes it. Normalisation records which definition produced each figure and converts it onto the administrator's standard basis, so a client holding twenty fund positions sees numbers that can actually be compared with each other.
+
What AI tools are used in fund administration?
Three categories are in use, and they solve different problems. Document conversion tools handle optical character recognition, turning scanned statements and image-only PDFs into machine-readable text. Extraction tools built on language models read labels, tables and the surrounding narrative to pull named fields out of documents without a per-manager template, which is what makes them survive a format change. Reconciliation and anomaly detection tools compare extracted values against prior periods and against the fund's own arithmetic, flagging what looks wrong before a report goes out. Platforms such as V7 Go combine the second and third categories with a mapping layer that translates each manager's labels into the administrator's canonical schema. Fund accounting systems including Geneva, Investran, Allvue and FundCount remain the book of record. The extraction layer feeds them; it does not replace them.
+
How does AI improve NAV production in fund administration?
It compresses the data-gathering stage that sits upstream of the calculation rather than changing the calculation itself. Most NAV timetables lose their days before any accounting work starts, while analysts chase statements from managers and custodians and rekey figures into the accounting system. Automated extraction removes the rekeying and the transcription errors that come with it, and automated validation flags anomalies at ingestion rather than at review, which is where a late correction costs the most time. Grant Thornton reports one fund administrator cutting operational labour costs by close to half after deploying anomaly detection and exception reporting on reconciliations. The NAV sign-off itself does not compress. It still requires a qualified person, appropriate controls and the same accountability to the client, and any tool that implies otherwise is describing something an administrator cannot use.
+
How can AI reduce errors in fund administration reporting?
By removing the step where errors are actually introduced. Manual transcription from a GP report into a reporting template is where most reporting errors originate, and they are hard to catch because the wrong figure usually looks reasonable. Automated extraction removes that step. Confidence scoring then flags values the extraction was unsure about, and a comparison against the prior quarter flags values that moved more than expected, so review time concentrates on the items most likely to be wrong instead of being spread evenly across everything. Provenance matters as much as accuracy: when every value links back to the page and field it came from, an error can be traced in minutes rather than reconstructed. What does not change is the review gate. Extraction prepares the data and a qualified analyst approves it before anything reaches a limited partner.
+
What is the difference between a fund administrator and a fund manager?
Not for several years, and in the short term they widen the work. The ILPA Reporting Template version 2.0 replaces the 2016 version for funds still investing during Q1 2026 and for funds commencing operations on or after 1 January 2026, while general partners may continue using the 2016 template for mature funds past their investment period. Both are legitimate at the same time. An administrator with a client book spanning a decade of vintages therefore receives version 2.0 from newer funds, the 2016 template from older ones, and whatever the managers who have adopted neither were already sending. Templates also standardise structure more effectively than they standardise definitions, so the restatement work that normalisation exists to do survives the transition. The long-run direction is genuinely towards comparability. The transition is where the volume sits.
+
Do the ILPA reporting templates remove the need for normalisation?
Go is more accurate and robust than calling a model provider directly. By breaking down complex tasks into reasoning steps with Index Knowledge, Go enables LLMs to query your data more accurately than an out of the box API call. Combining this with conditional logic, which can route high sensitivity data to a human review, Go builds robustness into your AI powered workflows.
+
Casimir is a seasoned tech journalist and content creator specializing in AI implementation and new technologies. His expertise lies in LLM orchestration, chatbots, generative AI applications, and computer vision.
