A fully automated fund reporting process is usually not in production after 30 days, but the first month decides whether it gets there quickly afterwards. Three things are realistic after four weeks: a measured baseline, a clear data path for every figure on the factsheet, and a proof of concept that shows what the automated output looks like in your own design. Use that month well and the decision on a full build rests on evidence rather than assumptions. This holds for investment foundations and pension funds as much as for fund management companies and asset managers, FINMA-regulated or not.
The first week belongs to the baseline. Record how many hours a reporting cycle actually takes today, who works on it, how many factsheets are produced in which languages, and where someone signs off. Then deliberately choose a narrow slice: one factsheet type, one group of funds or investment groups, one language. Without a measured baseline you can neither prove the benefit later nor spot a deviation, and without a narrow slice the first month turns into an inventory that never ends.
In the second week, every figure on the factsheet is traced back to its source. Where do performance, allocation, key figures and commentary text come from? Which values are taken from data deliveries, which are recalculated in Excel, which are corrected by hand? Those manual corrections are the real work of a reporting project, not the layout. By the end of the week there is a map of the data path that shows what can be automated deterministically and traceably, and where a professional sign-off deliberately stays.
The third week makes the result visible. A proof of concept rebuilds a handful of key pages of the report in your own design with dummy data, for example on Power BI, and shows layout, language variants and calculation logic before any real data flows. It is the moment portfolio management, compliance and the executive board can judge the same output for the first time, rather than a description of it. A proof of concept establishes feasibility; it is not yet production and not a commitment to a full build.
The fourth week is for the decision. Put the proof of concept next to the measured baseline and answer three questions: does the data path hold, does the output meet your requirements, and in what order should the remaining factsheets, languages and share classes follow? That produces a build scope shaped by your work rather than by a platform. You own the pipeline, templates and logic; it runs on the Microsoft licences you already have.
The most common anti-pattern is trying to tackle everything at once in the first month: every fund, every language, ESG disclosures and regulatory output in one go. Projects like that typically stall in data clarification, because every additional variant brings new exceptions. The realistic pace looks different. At IST Investmentstiftung, the first production pipeline went live about two months after the strategy phase began. Amula AI's reporting pipeline has been live there since October 2025: 39 investment groups are in scope and being rolled out group by group, the factsheets are produced in German and French in IST's own design, and monthly effort is down from 20+ to 3–4 hours (an internal estimate based on first measurements).
Thirty days are not enough for finished automated fund reporting, but they are enough for a sound decision about it. That is what the proof of concept for reporting automation is for: up to 10 key pages of your report rebuilt in your design with dummy data, so you can judge the output before committing to a full build. Know your bottleneck? Start with reporting. Not sure where to start? Start with the AI Assessment.