Revenue Command Center

The Revenue Command Center is the flagship example for the Boardflare application model. It is designed to show the complete path from workbook assumptions to reactive Python logic to an operator-facing application and published Excel results.

Open the web demo

What the workbook contains

The workbook exposes the assumptions that a finance or planning user would reasonably expect to review in Excel. The current demo reads two structured input blocks from the Drivers sheet:

inputs = bf.inputs(
    drivers=bf.ref("Drivers!A4:B12", headers=True),
    seasonality=bf.ref("Drivers!A15:B27", headers=True),
)
inputs

The driver table includes inputs such as starting monthly recurring revenue, new-business growth, churn, gross margin, operating expense, volatility, target ARR, and simulation count. A second table supplies monthly demand/seasonality factors.

The worksheet remains the durable assumptions surface; Python does not hide these values inside notebook state.

What the Run-mode application adds

The notebook adds controls that are more natural as an application UI than as additional spreadsheet cells:

• Scenario: Base, Upside, or Downside;
• Growth lift: an incremental growth adjustment;
• Risk multiplier: scales forecast volatility.

Changing either a workbook assumption or one of these controls flows through the same reactive model.

Deterministic forecast

The model calculates a 12-month MRR path using the workbook growth, churn, and seasonality assumptions plus the selected scenario and growth-lift control.

From that path it derives metrics including:

• annual revenue;
• ending ARR;
• EBITDA;
• EBITDA margin.

The purpose of the example is not to claim that this is a production forecasting methodology. It is to demonstrate how domain logic can be isolated in normal Python while Excel remains the assumptions and review layer.

Monte Carlo simulation

The same reactive cell runs a Monte Carlo forecast using NumPy. The current demo:

1. uses a deterministic random seed for reproducibility;
2. creates at least 500 simulation paths;
3. applies workbook volatility adjusted by the Run-mode risk multiplier;
4. calculates P10, P50, and P90 ARR paths;
5. calculates the probability that ending ARR reaches the workbook target.

The notebook then displays a chart comparing the selected scenario with the P10-P90 range, median path, and target.

This is a good example of the division of labor Boardflare is designed for: Excel is convenient for assumptions and target review, while NumPy is a much more natural place for vectorized simulation.

Published worksheet outputs

The notebook publishes two output tables:

bf.publish(
    outputs={
        "kpis": kpis,
        "forecast": forecast,
    },
    functions={
        "project_arr": project_arr,
    },
)

Excel can consume those live results with normal formulas such as:

=BF.OUTPUT("kpis")

and:

=BF.OUTPUT("forecast")

That means the notebook UI does not become a dead-end dashboard. The workbook can continue to use the application results in formulas, reports, reconciliations, or downstream sheets.

Published Python function

The example also publishes project_arr, a short function that projects ARR for a requested period count and optional growth delta.

A worksheet can invoke it through:

=BF.FUNCTION("project_arr", A1, B1)

This demonstrates the second publication pattern: use BF.OUTPUT() for state already calculated by the reactive application, and BF.FUNCTION() for short callable calculations over the live notebook model.

Why this is an application rather than a notebook example

The important sequence is:

Workbook assumptions
        │
        ▼
Reactive workbook inputs
        │
        ▼
Python model
        │
        ├── scenario controls
        ├── deterministic forecast
        ├── Monte Carlo simulation
        └── visualization
        │
        ▼
Published outputs + function
        │
        ▼
Saved workbook
        │
        ▼
Operator opens in Run mode

A one-time notebook can calculate a forecast. A workbook application also defines the inputs, controls, outputs, startup behavior, and handoff to the next user.

What this example is intended to prove

The Revenue Command Center is deliberately used across the website because one coherent example can demonstrate several product capabilities at once:

• live Excel-to-Python input binding;
• marimo reactivity;
• notebook application controls;
• numerical Python packages;
• visual output;
• BF.OUTPUT();
• BF.FUNCTION();
• Edit versus Run presentation;
• a workbook artifact that can be saved and reopened.

It should therefore remain the primary example used for screenshots, short videos, and the end-to-end author-to-operator demonstration.

Try it

Open the Python web demo and select Revenue Command Center from the demo catalog.

The browser demo uses Univer rather than Excel as its spreadsheet host, so final Excel deployment behavior—especially persistence and custom-function startup—should be validated in the actual Excel add-in. See Architecture for the host model and Sharing and Trust for the distribution checklist.