One view of what a portfolio spends, built from each company's monthly file.

The client is a private equity firm, and the system is spend analytics for its portfolio. A private-equity data team collects a procurement spend file from each portfolio company every month. It wants one view of what the portfolio spends, with whom, under which contracts, and what the savings are worth.

How the data arrives

Each portfolio company prepares its own monthly spend file and sends it to the data team outside the system, for example by email. The portfolio companies do not log in. Nothing is pulled from their accounting systems. A member of the data team uploads each file on the company’s behalf.

So the quality of every figure downstream depends on two things: whether each company has filed, and whether its file can be trusted. Files vary. Dates can arrive in more than one format. A row may carry no contract number. A value can be negative, because a supplier issued a credit.

What we built

Jetbro built the firm’s spend analytics platform on Phlo. It registers the portfolio companies, takes in and validates their monthly spend files, and analyses the result beside three other records: supplier contracts, savings initiatives and each company’s quarterly financials.

It is an analytics system. It does not raise, approve or pay anything. Every change is stored as an event, and the screens are read from those events.

How a month’s file moves through it

1. Register the company. A member of the data team adds the portfolio company: sector, lead partner, contact and status. Nothing else can be entered for a company until this record exists.
2. Watch the pending list. For each period, the Spend Data screen lists every active company with no file yet, with its due date and the days past due.
3. Upload the file. When the file arrives, the user picks the company and attaches it. The file has a fixed layout: supplier, spend, category, commodity, country, contract number and so on.
4. Validate, in two passes. The first pass checks the format: the columns, the types, the allowed category values. The second checks the data: the company name must match a registered company, and spend must be a number.
5. Accept or reject, whole. A file that passes is recorded as validated and all its rows are stored. A file that fails is recorded with its errors and none of its rows are stored.
6. Analyse. Validated rows feed the Spend Analysis screen: total spend, spend under contract, spend over time, by category, by company and by supplier.

What the first build described

A first build is where an operation gets written down: the things it tracks, what can happen to each of them, and the cases that do not fit. Here the operation is a monthly filing discipline, and the description is short on purpose.

The things the business tracks:

• A portfolio company. Registered once, with its sector, lead partner, contact and status. Everything else hangs from it.
• A monthly spend file. Each file belongs to one company and one reporting period, and carries the date it was received.
• A spend row. One line of a validated file: supplier, spend, category, commodity, country and, where there is one, a contract number.
• A supplier contract. A contract number, a supplier, an expiry date and a risk rating, held per company.
• A savings initiative. A piece of procurement work with a baseline, a negotiated figure, a status and a stage gate.
• A realisation record. One initiative in one period: planned, actual and forecast.
• A quarter’s financials. The inputs for one company and one quarter, kept as a snapshot.

What can happen to them, in the system’s own words:

• To a portfolio company: created, updated, status changed.
• To a spend file: accepted or rejected. There is no third outcome and no half-loaded file.
• To a contract: created, updated.
• To an initiative: created, updated, savings realisation updated.
• To a quarter’s financials: created, updated.
• To a question asked of the data: thread created, message added, report requested, report completed or report failed.

An accepted file’s event carries the company, the period, the file name, the date received, the row count, the total spend and the supplier count. A rejected file’s event carries the same identity and the list of errors. That is why the filing history can be read back month by month.

The awkward cases were modelled, not worked around:

• The file that fails. There is no partial load. The rejection stays on the record with its reasons.
• The same month, twice. Uploading again for the same company and month asks for confirmation, and states how many existing records will be replaced.
• An unknown contract number. It is logged as a warning. It does not block the file.
• Supplier credits. Negative values are valid and are included in the totals.
• A contract shared across companies. A group contract is stored as one record per company, all sharing the same contract number.
• The company that has not filed. Absence is shown, not inferred. An active company with no accepted file for the period stays on the pending list with its days past due.
• The report that does not finish. A background analysis that fails is recorded as failed, beside the request that started it.

The rules it holds

Only rows from validated files are ever counted in the analysis. Spend, contracts and savings use the same category list, so a category means the same thing in all three.

A contract’s status is calculated from its expiry date, not typed in: Active, Expiring Soon or Expired. Its risk rating is entered by a person.

A savings initiative has a baseline and a negotiated figure, and its total saving is derived from the two. It carries a status and a stage gate. Each period it gets one realisation record with the planned figure already filled in. The user enters the actual and the forecast, and picks one of four fixed comments.

What the record makes possible

The savings tracker charts planned, actual and forecast savings from those period records. The contracts screen shows what expires, and when.

Impact KPIs translate procurement savings into value terms. For each company and quarter the user enters the financial inputs. The platform works out how the savings flow through to EBITDA, enterprise value and equity returns. Each quarter is a new snapshot, so the earlier ones are kept.

The same data can be asked questions in plain language. A language model turns the question into a structured query. The platform validates that query and answers it with its own aggregation code. The model never touches the database directly. A longer analysis runs in the background and returns a written report. Both are read-only.

What the foundation carries forward

The description above is the lasting part of a first build. The portfolio company, the monthly file, the contract and the initiative are defined, and spend, contracts and savings use the same category list. Every acceptance, every rejection and every quarterly snapshot is recorded as an event, in order.

A further process for a portfolio like this would start from that, not from an empty page. Another record about a portfolio company would attach to the same registered company, as contracts, savings and financials already do.