How to reconstruct a baseline after the AI tool is already live
The tool is already live, and no baseline was written down. That is a common case. Finance still has to produce a “before” that a controller can defend, or say clearly that the records will not support one.
The four-step way to inventory the spend, rebuild a “before,” choose a comparison, and put the result in a ledger is set out in how to measure the return on AI you already bought. This note is the tactical half of that work: which exports to request, what a comparison group has to satisfy, and what to do when rollout dates or data are missing.
A 2026 CloudZero survey of 260 senior finance leaders, 135 of them CFOs, reports that 43% are already being asked for a number they cannot give, and that only 22% can tie AI spend to outcomes. A 2026 Coupa survey of 600 global finance leaders reports that 76% say difficulty quantifying AI ROI is hindering further investment. Both are vendor surveys; sample notes and caveats are in the sources below. Those figures describe a reporting gap. They do not tell you what to pull from the ERP. The rest of this note does.
Start with the go-live date, not the invoice date
The vendor invoice, the contract start, and the day the first user actually did the work are often three different dates. Compare against the wrong one and you will credit the tool for work it had not yet touched, or bury a real change in a period when it was already running.
Look for the date in more than one place, and write down the conflicts: provisioning or single sign-on logs; the vendor’s admin console, by team or site; IT tickets, change records, and training attendance; first material usage, if the product logs it; and the accounts-payable record, which dates cost, not use.
If those sources disagree, do not average them. Pick the date the work actually changed, state the range of uncertainty, and carry it into the confidence labels. A bounded window (“this team had access by the week of June 9, and not before May 12”) is usable. A vague recollection (“sometime last spring”) is not a date. Until you can say who got the tool, and when, you have a cost, not a comparison.
The exports to request
Ordinary extracts from the systems the company already runs are enough. Ask for a period that covers a normal operating cycle before the suspected go-live and the period after it, and, where seasonality matters, the same months a year earlier. Prefer a grain that identifies site, team, or queue if the rollout may have been staggered. Customer personal data is not required. The five extracts below are the usual request.
Cost, from the general ledger and accounts payable. Every invoice and journal line for the initiative — subscription, usage or overage, implementation, integration, training, and professional services — with vendor, description, amount, and period. Separate one-time work from recurring cost, and include internal time booked to a project code. The aim is the full cost of the initiative, not the vendor invoice alone.
Access and usage, from IT or the vendor. Who was provisioned, on which date, in which site or team, and whether those seats were used. Usage is not a return. It recovers the rollout pattern and keeps unused licenses out of the treated group.
The workflow, from the system of record. The unit of work and its outcomes — invoices processed, tickets resolved, orders picked, or whatever the process actually runs on — with volume, cycle or handling time, exception or error rates, and rework, defined the same way across the period. Flag a mid-window change in ticketing systems, queues, or status codes; it may make a single series unusable.
Staffing and related spend, from HR, timekeeping, or accounts payable. Headcount in the function, overtime, contractor or temporary bills, and, if you may claim an avoided hire, the approved staffing plan and when that cost would otherwise have arisen. Hours freed are not a financial result until you can show where the capacity went.
Other changes in the same window. A short list, from finance and the initiative owner, of system migrations, process redesigns, policy changes, volume or mix shifts, and staffing events that hit the same workflow — the shocks you will have to name, or that will stop the comparison.
Ask for the extracts in a stable format, with the same columns for the whole period. Note the source system, the report name, the as-of date, and who pulled it. If a field cannot be produced, write it down as a gap; do not fill it with a vendor’s savings estimate.
What a comparison group needs
How TribuTrace reconstructs a baseline is to pick, for each initiative, the comparison the history will still support, and to review it with the CFO and the controller. For an already-live tool, that is usually a staggered rollout you can still see, a same-team comparison of like periods with other changes named, a similar group that did not get the tool, or a finding that the result is not yet attributable.
A usable comparison group needs a treatment date you can defend, or a bounded window, for each group; the same unit of work, defined the same way before and after, and in both groups; a like-for-like period, so you are not comparing a peak season with a quiet one; other material changes identified, and either ruled out or named as limits; and groups that are alike on mix, volume, complexity, and skill. “The rest of the company” is not a control if it does different work.
A staggered rollout is usually the strongest reconstruction, because the later group can serve as a comparison in the same calendar window. It fails if the groups were already unlike, or if something else changed in only one of them. A same-team before-and-after can still be written down when there is no untreated group; treat it as estimated unless you can isolate the tool from the other changes. A comparison to a similar queue, product line, or sister site holds only if you can show the match, including where the groups differ.
A handful of people, a few days of data, or a single unusual week will not carry a company-wide claim. If you cannot find a group and a period that meet the tests above, the change is not yet attributable. That is a valid finding, and better than a baseline built from memory.
When dates or data are missing
Gaps are normal. They are not a license to complete the series with a guess, a vendor case study, or an interview estimate.
If the official go-live date is missing, rebuild a window from provisioning, first usage, and the cost record, and label the date as reconstructed. If the sources cannot be bounded, do not force a split between before and after. If only some sites or teams can be dated, narrow the baseline to those groups. A measured result at two sites is more useful than an unlabeled company-wide figure. Leave the undated groups off the earnings line, or mark them not yet attributable.
If a system migration or a change in status codes breaks the unit of work, do not join the old and new series and treat the join as a continuous “before.” You may still compare groups after the migration, if access continued to roll out in waves, and you may not be able to use the pre-migration period at all. If the only “before” anyone can offer is a recollection, use the conversation to find the systems and the dates; do not turn it into a numeric baseline. If cost is incomplete, say what is in the figure and what is not.
The confidence labels should get weaker as the record gets weaker. Do not move a figure up a label to close a gap. What you can still do is write down what should be captured ahead of the next renewal or purchase: a go-live date by team, a stable unit of work, and a comparison rule agreed in advance. That is preparation, not a reconstructed result.
A hypothetical reconstruction
The following is a worked illustration only. It is not a client result, and the figures are invented to show the method.
Suppose a portfolio company bought a customer-service drafting assistant under a January contract, with no baseline recorded. In the autumn, finance is asked what the tool returned. The invoice date would make it look as if the assistant had been in use all year. Accounts payable shows a subscription from January and a small implementation invoice in February. Provisioning logs show that one queue received access in April and a second queue in July, and usage confirms the same waves. In June the company migrated its ticketing system, and several status codes changed meaning.
The pre-migration ticket series is not a usable “before” for a year-long comparison: the unit of work broke. What can still be reconstructed is a staggered comparison after the migration, between the April queue and the July queue, in the months when one had the tool and the other did not. Volume and mix look similar, and no other service redesign hit only one queue. Handle time and reopen rates in that window can be labeled measured, limited to two queues, the post-migration months, and this workflow.
The earlier months, and any company-wide earnings claim, stay not yet attributable. Handle time is down in the treated queue, but overtime and contractor bills did not move, and no approved hire was cancelled. The hours are an operational result, not EBITDA, on this record.
None of those numbers should be copied out of this illustration. Only the sequence should be: recover the dates, request the extracts, discard the series that broke, and narrow the baseline to the comparison that remains.
Write the baseline so someone else can rerun it
A reconstructed baseline should be a short, dated note, not a slide. For each initiative it should record the period, the source systems, the go-live date or window and how it was established, the unit of work, the comparison used, the other changes considered, the gaps, and the label. Another person in finance should be able to pull the same extracts and follow the same steps. The ledger and the board pack, described in the earlier method article, should not tell a different story.
If you want a structured pass at this for one portfolio company, the AI Value Baseline is the fixed-scope version of the same work: a handful of initiatives already in use, a reconstructed baseline, a labeled ledger, and a routine your team can run afterward.
Sources
Figures were checked against the live pages on November 10, 2026.
- CloudZero, “Finding the ROI of AI: The Finance Perspective,” 2026 survey of 260 senior finance leaders, 135 of them CFOs. The report states that 43% of finance leaders are already being asked for a number they cannot give, and that 22% can tie AI spend to outcomes. The report also states that figures describe associations in a single point-in-time survey, not proven cause and effect. https://www.cloudzero.com/finance-needs-ai-roi-2026-survey-report/
- Coupa, “The Strategic CFO Report 2026,” a survey of 600 global finance leaders in North America, Europe, Japan, and Australia. The public page reports that 76% say difficulty quantifying AI ROI is hindering further investment. Fieldwork dates were not shown on the page. https://www.coupa.com/resources/the-strategic-cfo-report/