ProSports sells football analysis software to more than 200 clients across clubs, leagues, federations, agencies and education, billed in two currencies on three different renewal calendars. We built an agent that forecasts a book of that shape without ever touching the signed contract value.
We start with your contract data and your renewal calendar, agree what the agent is never allowed to touch, and build the guardrails before the model.
ProSports builds football analysis software: match analysis, scouting and player profiles, running on optical tracking that captures three million data points a match. The company serves more than 200 clients worldwide, processes over 10,000 matches a year, and has profiled more than 225,000 professional players. It works from Zeist in the Netherlands, with a second office in Pottstown, Pennsylvania.
For any finance team, a book with that shape is harder to forecast than it looks. It spans eight customer types in two groups. On the professional side, clubs, leagues, federations and player agencies. On the youth side, academies, youth leagues, colleges and universities, and high schools. Those groups do not renew at the same time of year, and they do not renew for the same reasons.
Clubs buy before a season starts, so their renewals cluster in June and July. Leagues and federations run on a calendar fiscal year and land in January. Colleges, high schools and youth programmes follow a US academic year and land in August. One company-wide renewal rate averages three rhythms into a number that is wrong in every month of the year.
The harder problem is that the information which actually predicts a renewal does not live in the finance system at all. A relegated club cuts its budget. A federation publishes a smaller line item. A new head of recruitment arrives with tooling of their own. Every one of those is public and knowable on the day it happens, and none of it reaches a forecast on time. It arrives second hand, weeks after the source was published, usually once the number has already been committed.
Two offices adds a third complication. Part of the book is billed in dollars and part in euros, so a chunk of signed revenue has to be translated before anything can be added up, and it moves with a rate nobody in the building controls.
The first design decision was subtraction. The contracted base, the revenue already covered by signed contracts, is arithmetic. It is not a model output and it is not an opinion, and the agent has no write path to it. It sits behind a lock in the interface, carries its own number, and stays exactly where it is no matter what any driver or any signal does.
That one constraint is what makes the rest of the forecast worth reading. Everything above the locked base is explicitly a probability, which is why it is drawn as a band rather than a line. A reviewer can see at a glance how much of next year is already signed and how much is still an assumption.

Four drivers sit in a panel that stays on screen in every view: professional renewal rate, youth renewal rate, the euro to dollar rate, and new business per quarter. Moving one redraws the band and the committed number immediately, so a scenario takes a second rather than a rebuild. Push all of them to their extremes and the contracted base does not move by a cent.
One exception proves the rule. The currency driver does change the base, because a signed dollar contract really is worth fewer euros when the euro strengthens. That is translation, not an assumption, and the interface says so rather than pretending otherwise.
Each segment carries its own renewal curve across the twelve months rather than a shared average. Laid out as a grid of value renewing per quarter, the three rhythms separate immediately: the January block belongs to leagues and federations, the June to August block is clubs going into pre-season, and the August concentration is the education book following the US academic year.
That view is also the answer to a question a rolling forecast has to answer every month, which is not how much will renew but when the exposure actually lands.

The agent watches published material: final league tables, federation budget filings, club press releases. Each signal is stored with the publisher, the date and a confidence score, then attached to the account it affects. It never edits the forecast. It proposes a revision, states the effect in money, and shows the comparable cases the estimate rests on.
A relegation is the clearest example. The agent does not predict relegation and will not be drawn into doing so. It reads a published final table, notes that the club is in a lower division next season, and reports the revenue that assumption puts at risk. What happens next is a person accepting or rejecting that revision.

Two requests in the agent are refused outright, and they are the two that matter. Asked to predict whether a club will be relegated and price the renewal on that prediction, the agent declines: it reads published tables and published budgets, and reports exposure rather than forecasting a result on the pitch. Asked to lift the contracted base to cover a gap until pipeline catches up, it declines again, because the base is outside its write path and there is simply no mechanism to honour the request.
Neither refusal is a sentence in a prompt. Both are the absence of a code path, which is the only version of a guardrail that survives contact with a determined user.

1. Reconcile the base. Contract, billing and renewal dates are pulled into one revenue base and agreed with finance before any model exists. Nothing downstream is allowed to alter it.
2. Map each account to its own calendar. Every account is placed on the renewal rhythm of its segment rather than a company-wide date, and the twelve-month curve is built from those, not from an average.
3. Collect signals with their sources. Published tables, budgets and releases are captured with publisher, date and URL. A source that cannot be attributed to a named publisher is logged and dropped there.
4. Score and gate. Each signal is scored for confidence. Below the floor it is recorded against the account, shown to the reviewer, and given no path to the forecast. Above it, the agent may propose.
5. Propose, never commit. A proposal states the account, the probability change, the money effect and the comparable cases behind it. It sits there until a named person accepts or rejects it, and both outcomes are logged.
6. Recompute and show the working. Accepted revisions and driver changes redraw the band, the bridge and the committed number together, so the difference between last month and this month can always be traced to a decision somebody made.

It is software that assembles a revenue forecast from contract data, applies documented renewal assumptions, and monitors external sources for evidence that those assumptions have changed. t proposes revisions with the source and the comparable cases attached, and a named reviewer decides whether each one is applied.

No, and this one is built so that it cannot. The contracted base is arithmetic the agent has no write path to, and every risk-adjusted change needs a person to accept it before it reaches the committed number. What the agent removes is the collection work: finding the published budget, table or release, scoring it, and attaching it to the right account with a citation.

A spreadsheet holds one set of assumptions and has to be rebuilt to test another, which is why scenarios tend to be produced once a quarter rather than when a question is asked. Driver-based forecasting exposes the assumptions as inputs, so a reviewer moves the renewal rate or the exchange rate and watches the band redraw. The agent keeps four drivers on screen in every view and keeps signed contract value outside all of them.gent

Three things, each of them code rather than instruction. A confidence floor a signal must clear before it can even propose a change. An attribution test that rejects any source without a named publisher. And a rule that no revision reaches the committed forecast until a reviewer accepts it, with that decision logged against their name.

Yes. A production build would read contract, billing and renewal data through permission-scoped integrations and write nothing back except an audit record. Keeping the forecasting layer separate from the systems of record is what allows the contracted base to stay a straight read of signed contracts rather than another modelled figure.