Bringing Four Flagship Budgets Into One View  🔗 **Source:** [Bringing Four Flagship Budgets Into One View](https://make.wordpress.org/community/2026/09/11/bringing-four-flagship-budgets-into-one-view/) > [!note]+ Document Notes > --- > tags: [wordcamp, event-budgeting, cash-flow-forecasting, multi-currency-accounting, wordpress-community] > author: Harmony Romo > source: Make WordPress Community > reference: https://make.wordpress.org/community/2026/09/11/bringing-four-flagship-budgets-into-one-view/ > date created: 2026-09-12 > --- > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > # 🏷️ Title: Bringing four flagship budgets into one view > ## 🧭 Table of Contents > - [📝 Summary](#-summary) > - [📖 Main Content](#-main-content) > - [🗒️ Notes](#️-notes) > - [📚 References](#-references) > - [🗣️ Paraphrase](#️-paraphrase) > - [📰 Newsletter](#-newsletter) > - [✅ Action Items](#-action-items) > - [🧪 Hypotheses](#-hypotheses) > - [📊 Methodology](#-methodology) > - [❓ Questions](#-questions) > - [🔮 Future Research](#-future-research) > - [💡 Implications](#-implications) > - [🧠 Learning Styles Assessment](#-learning-styles-assessment) > - [📊 Accessibility Assessment](#-accessibility-assessment) > - [🌍 DEIB Assessment](#-deib-assessment) > - [✅ Logical Validity](#-logical-validity) > - [🛡️ DARVO Analysis](#-darvo-analysis) > - [🎯 Conclusion](#-conclusion) > ### 🔗 References (in-page) > - [Bringing four flagship budgets into one view](https://make.wordpress.org/community/2026/09/11/bringing-four-flagship-budgets-into-one-view/), Harmony Romo, published 2026-09-11 19:25 UTC > - Post tags: [#community-team](https://make.wordpress.org/community/tag/community-team/), [#finances](https://make.wordpress.org/community/tag/finances/), [#flagship](https://make.wordpress.org/community/tag/flagship/) > - The post body contains no outbound links. The templates, the rollup file, the spreadsheet platform, and the accounting system are described but not linked or named (checked against the stored HTML, which holds one link: a sidebar image). > ## 📝 Summary > - **What happened.** Harmony Romo posted on the Make WordPress Community blog about a new budget setup for the four 2027 flagship WordCamps: Europe (Spain), Asia (Malaysia), US, and a first WordCamp India. Each event runs between $500K and $1M of income and expense. > - **The setup.** Each event keeps its own budget file. Every file carries one identical summary tab, and budget lines are tagged to real account names from the books. A single rollup file reads the four summary tabs, converts to US dollars, imports actual dollars paid from the accounting ledger, and turns per-line due dates into a monthly cash calendar. > - **Why it matters.** 2027 has four flagships instead of three, so large payments can collide. The post's example is three events with large venue deposits landing in the same three weeks, a risk no single event team could see. > - **Key stakeholders.** The four organizing teams (mostly volunteers, per the post), the author's finance role, whoever runs the accounting system, and the sponsors and attendees whose money funds the events. > - **Risks and tradeoffs.** Due dates are optional, so the cash calendar only covers lines teams date. The cash calendar shows outflow only; the post doesn't mention income timing. The post doesn't say which exchange rate converts forecasts to dollars. The author calls it a first version and has asked every team for feedback. > - **Bottom line.** The fix standardizes one interface (the summary tab) and one vocabulary (account names), reads actuals from the books instead of asking teams for them, and leaves everything else to the teams. > ## 📖 Main Content > - **The problem sat between the budgets.** The author says each budget was reasonable alone. Three gaps caused the trouble: no cross-event view of payment timing, categories that differed per file (so the author mapped them by hand "rarely and late"), and currency handled differently per file. > - **Why a live exchange rate is worse than a fixed one.** A live market rate changes an event's dollar total every day, so no report reconciles to the previous one. It also applies today's rate to a payment made months ago, which is the wrong rate for that payment. > - **Design principle: ask the teams for as little as possible.** Teams keep their own line items, currency, and working style. The shared requirements are the identical summary tab and account-name tags. Most template lines arrive pre-tagged, so teams check tags instead of creating them. Due dates are optional. > - **Two data sources, split by who owns them.** Budgets and forecasts come from the teams in local currency. Actual spend comes from the accounting ledger in dollars, which already records the actual exchange rate and local-currency amount on each foreign payment, with each expense tagged to its event. An importer in the rollup file reads it. > - **Read-only direction.** The rollup pulls from the event files; nothing writes back into them, and nobody emails files. > - **The cash calendar.** The ledger can't show obligations nobody has invoiced yet, such as a venue balance due next July. Due dates on budget lines fill that gap, and the rollup shows expected outflow by month with all four events side by side. > - **Review cadence.** Kickoff (budget drafted and categorized), approval (cap agreed; the budget number stops moving), variance checks at 90, 60, and 30 days out (the 60-day check looks across all four events for cash), and a month-after review comparing actuals to forecast. Between those points, the author only contacts a team if something flags. > **Terms** > - *Flagship WordCamp*: the large regional WordCamps. The post lists Europe, Asia, US, and India for 2027. > - *Rollup*: a file that aggregates summary figures from several source files. > - *Variance check*: a comparison of budget against forecast or actual spend. > - *Ledger*: the accounting system's record of transactions. > - *Cash calendar*: expected outflow grouped by month. > **Uncertainties and gaps** > - The post doesn't name the spreadsheet platform, the accounting system, or how the "live" pull and the importer work. > - The post argues against live rates, then says the rollup "converts everything to dollars" without naming the rate used for budgets and forecasts. Actuals use the booked rate; forecasts need a rate too. > - The outcome claims ("Now that shows up as a spike") describe design intent. The closing says no full cycle has run yet. > ## 🗒️ Notes > - 2027 flagships: Europe (Spain), Asia (Malaysia), US, India (first edition). Four in one year, up from three. > - Size per event: $500K–$1M of income and expense. > - Budget builders: a different team per event, mostly volunteers, negotiating venue contracts, catering minimums, and deposits across timezones. > - The author's own admission: the finance side was "more reactive than proactive." > - Gap 1, no cross-event view: each team saw its own payment schedule; no one saw deposit collisions across events. > - Gap 2, file shapes: categories varied, so totals needed manual mapping each time. > - Gap 3, currency: fixed rate in some files, live market rate in others. > - Build: four event files plus one rollup. > - Integration contract: one identical summary tab in the same place in every file. > - Categories: real account names from the books; year-end re-keying goes away; budget and accounting use one vocabulary. > - Rollup behavior: reads all four summary tabs live, converts to dollars, writes nothing back. > - Actuals: read from the ledger by event through an importer; the ledger holds the actual rate and local amount per foreign payment. > - Local teams watch their budget in their own currency; the dollar view belongs to the author. > - Due date per budget line → monthly cash calendar across all four events; a collision shows as a spike in one row months before invoices exist. > - A blank due date means budgeted but not scheduled. > - Cadence: kickoff → approval (number freezes) → 90/60/30-day variance checks (60-day is cross-event cash) → month-after actuals review. > - Status: templates are with the 2027 teams; feedback requested; the author plans a follow-up post after a full cycle, "including the parts that didn't work." > - Spelling: the post uses British forms ("categorised," "org 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. [](https://make.wordpress.org/community/files/2018/04/wapuu-collector-pin-for-community.png), Bringing Four Flagship Budgets Into One View, Harmony Romo, 01m2ayezxz0xhwtbwa5h1geaj1.