We have four flagship WordCamps in 2027: Europe (Spain), Asia (Malaysia), US, and a first edition in India. Each one runs somewhere between half a million and a million dollars of income and expense.

Each budget is built by a different team, in its own spreadsheet, in its own currency, in its own shape — and that part is genuinely fine. The people building these budgets are negotiating venue contracts, arguing catering minimums down, and tracking deposits across timezones, mostly as volunteers. They know their events far better than I ever will, and the last thing I want is to tell them how to build a budget.

The part that didn’t work was my side of it. I’m meant to know what’s coming and flag it early, and given how separated everything was, I was more reactive than proactive. With four flagships landing in one year rather than three, the timing of large payments matters more than it used to.

Where the problem actually was

Not the budgets. Each one was reasonable on its own terms. All of the issues were in the gaps between them.

No view across events. Each team could see its own payment schedule. Nobody could see three events with large venue deposits landing in the same three weeks. That’s a cash problem that only exists at the top level, and I wasn’t positioned in a way to notice it.

Every file a different shape. Categories varied event to event, so nothing added up without me mapping it by hand each time — which meant I did it rarely and late.

Currency handled differently in each file. Some used a fixed rate, some pulled a live market rate. A live rate sounds better but is worse: the same event’s dollar total changes every day, so no report ever reconciles to the one before it. And a rate that moves is the wrong rate for a payment made months ago.

What I built

Four separate event budget files and a single rollup file, with the design principle throughout being to ask the event teams for as little as possible.

One budget file per event. Each keeps its own line items, currency and working style. The only shared requirement is that every file has an identical summary tab in the same place. That one tab is the whole integration.

Categories that are our actual account names. Not a set of categories invented for this. Each budget line gets tagged to a real account from our books, which means nothing gets re-keyed at year end and variance conversations use one vocabulary instead of two. Most lines in the template arrive already tagged, so the teams are checking rather than starting cold.

One view that reads all four, live. It pulls each event’s summary tab, populates my rollup, and converts everything to dollars. Nobody sends me a file, and nothing I do writes back into theirs.

Actual dollars spent, read from the books. The most important thing for a local team is to watch their own budget in their own currency. The dollar side is mine to keep tabs on, not theirs to worry about.

Our accounting system already records the actual exchange rate and the local-currency amount on every foreign payment we make, and every event expense is already tagged to the event it belongs to. So rather than re-entering anything, the rollup reads actual dollars paid straight from the ledger, by event, through an importer in the rollup file.

That gives a clean split. Budgets and forecasts come from the teams in their own currency, actual spend comes from the books in dollars, and I can compare the two without anyone doing the same work twice.

Knowing what’s coming, not just what’s gone. The ledger tells me what’s been paid. It can’t tell me what falls due next July, because a venue balance nobody has invoiced yet doesn’t exist in the accounting system.

So each budget line now carries a due date alongside its amount, and the rollup turns those into a cash calendar — expected outflow by month, all four events side by side. That’s the part I couldn’t do before. Each team could always see its own payment schedule; nobody could see three events with large deposits landing in the same three weeks. Now that shows up as a spike in a single row, months ahead of the invoices.

Filling in a due date is optional. A blank one just means the money is in the budget but not yet on the calendar.

The process from here

The rhythm is deliberately light. I’d rather the teams see me at agreed moments than feel watched:

• Kickoff — budget drafted, categorised, in the shared folder
• Approval — cap agreed, and the budget number stops moving from that point
• 90 / 60 / 30 days out — variance checks, with the 60-day one looking across all four events together for cash
• A month after — actuals in, and we see how close the forecast was

In between, I only get in touch if something flags.

In closing

Four teams were each doing perfectly sensible work in four separate spreadsheets, and the problem wasn’t any of the spreadsheets — it was that nobody owned the space between them.

The templates are now with the 2027 flagship organising teams, and I’ve asked all of them for feedback. This is a first version and I fully expect it to have problems I haven’t caught yet. I’ll post again once we’ve run a full cycle with it, including the parts that didn’t work.

#community-team, #finances, #flagship