FinOps Reporting & Budget Platform

The original workflow required someone to export data from Ternary, transform it in Excel, and import it. I replaced it with a direct API integration — for actuals and forecasts:

• Zero manual intervention — data pulls automatically on startup, no scheduled task required
• Normalization pipeline — three alias maps handle provider codenames, subscription names, and business unit codes that vary across systems
• Deduplication and upsert — safe to run repeatedly without creating duplicate records
• Easy extensibility — adding a new subscription alias is one line of config, not a data migration

Budgets are the deliberate exception. Ternary has a budget feature, and syncing it would have been the easy call. I turned it off. Ternary’s budget entries are scoped too inconsistently to reconcile one-to-one against the Cloud Report Ops Committee workbook, which is the number leadership actually governs against. Two competing budget figures in one tool is worse than one manual import step, so budgets flow from the Ops Committee workbook through the import page and every budget-derived view reads from that single source.

Trade-off accepted: API dependency means if Ternary is down on startup, the app serves stale actuals. Acceptable given the daily cadence of budget reporting vs. the alternative of manual error-prone exports.

A naive “distance from budget” score treats 10% under-budget and 10% over-budget as equally bad. In practice, overspending is far more damaging than underspending. I designed the scorecard to reflect this:

• 2× penalty for over-budget — the budget adherence component penalizes overspending at twice the rate of underspending
• Magnitude-based scaling — a $500K overrun on a $1M budget scores worse than a $5K overrun on a $10K budget, even if the percentage is identical
• Five weighted dimensions — budget adherence alone doesn’t tell the full story; stability, risk, efficiency, and forecast accuracy each contribute
• Methodology transparency — every component of every grade is visible in the UI so stakeholders can see exactly why a subscription received its score

This design pushes decision-makers toward the right priorities without requiring manual judgment on every subscription.

Core financial data lives in cloud_budget. Detailed vendor spend breakdowns live in vendor_spend. This separation was intentional:

• Different granularity — vendor spend (Elastic Cloud, Okta CIAM, New Relic) has 34 solutions and 9 sub-subscriptions that don’t map cleanly to the core subscription schema
• Different update cadence — vendor breakdowns are entered manually on a different schedule than automated Ternary actuals
• Independent schema evolution — adding a new vendor sub-subscription field doesn’t require a migration against the main financial database
• Clean backup and restore paths — a vendor_spend restore doesn’t touch core financial records

Every component in the app thinks in fiscal years (July 1 through June 30), not calendar years. This was a foundational design decision made before the first line of code:

• Date pickers default to FY ranges
• Scorecards filter to the current FY automatically
• Forecasts project through June of the current FY
• Budget entry UI presents all 12 fiscal months grouped by quarter
• Automatic rollover — when July 1 arrives, everything switches to the new FY with no manual configuration

Why it mattered: A calendar-year-aware system would have required constant manual correction every July. FY-native design meant the app matched how leadership actually thought about budgets from day one.

Budget entry for 100+ subscriptions × 12 months is inherently table-heavy work. Standard form inputs would have been unusable at this scale.

• Excel-like inline editing — stakeholders could click a cell and type, matching the workflow they already knew from spreadsheets
• Column sorting, filtering, and pinning — navigating 100+ rows without these is painful
• Row selection and bulk operations — apply a budget value to a filtered set of subscriptions in one action
• CSV/Excel export — finance team could pull a snapshot at any time without building a report

Trade-off accepted: AG-Grid Community license limits some Enterprise features. The missing features (server-side row models, advanced pivot) weren’t required for this use case.

Three roles with progressively more access, enforced on every write operation in the backend — not just the frontend:

• Read-Only — view all dashboards, analysis, and reports
• Tenant — read access plus forecast editing for their own solution area
• Admin — full CRUD: budget entry, data imports, user management, Clean Slate + Backfill operations

Role checks happen in Express middleware on every write endpoint. Frontend role gating is a UX convenience only — the API rejects unauthorized requests regardless of what the client sends.