Notion Masterclass: Build an Expense Tracker from Scratch
Based on Thomas Frank Explains's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.
Create one source database for expenses and drive every dashboard section from filtered/sorted views of that database.
Briefing
A recurring expense tracker built in Notion can eliminate the annual “surprise charge” problem by turning every subscription or recurring bill into a structured record with an automatically calculated next renewal date. The payoff is practical: during weekly planning, users can look ahead at upcoming renewals (via Notion Calendar) and cancel items before charges hit—avoiding refunds or wasted spend.
The build starts from a blank Notion page and creates a full-width “Expense Tracker” dashboard backed by a single underlying database. That database holds the raw details of each expense—how much it costs, when it was last charged, whether it renews monthly or yearly, and where it’s paid from (e.g., specific cards or accounts). It also tracks operational context: category (such as Dev, Marketing, or Website), an owner (who decides whether to keep or cancel), a “used by” list for teams who rely on the tool, a direct link to the billing dashboard, and notes. A status field marks items as active, maybe cancel, or canceled, with an optional cancellation date for recordkeeping.
Two formula properties make the system work. First, “Monthly cost” converts yearly costs into an equivalent monthly outlay by dividing the annual figure by 12 when the recurrence interval is yearly. Second, “Renewal date” calculates the next upcoming renewal relative to today using the charge date plus the recurrence interval (with logic to ensure that if today is the renewal day, the tracker shows today rather than pushing it forward). This turns manual subscription management into a live schedule.
To make the tracker actionable, the database is connected to Notion Calendar. A key requirement is adding a calendar view directly to the source database (not just a linked database view), then using the formula “Renewal date” as the calendar driver. Once connected, upcoming renewals appear on the calendar in week and month views, letting users decide whether to keep or cancel before the charge date.
On the dashboard, multiple linked views provide different ways to review the same underlying data: an “Active expenses” recurrence list sorted by next renewal date, an alphabetical view, a cost-ranked view (monthly cost descending), a calendar layout view showing future renewals, and a grouped categories view that collapses sections by category. A separate “Cancellations” section uses filtered views to show canceled and “maybe cancel” items, sorted by cancellation date or renewal date depending on the status. Together, these views give both forward-looking planning (what’s coming) and retrospective clarity (what was canceled and when). The result is a reusable template that can support business subscriptions or personal budgeting items like streaming services and recurring apps.
Cornell Notes
The core idea is to manage recurring bills as structured Notion database records, then use formulas to compute (1) each expense’s monthly cost and (2) the next renewal date relative to today. Those computed fields power multiple dashboard views—recurrence lists, cost rankings, category groupings, and a calendar view—so planning becomes proactive instead of reactive. Connecting the source database to Notion Calendar makes upcoming renewals visible in week/month layouts, enabling cancellations before charges occur. A status workflow (active, maybe cancel, canceled) plus an optional cancellation date keeps decisions auditable and helps estimate savings from planned cancellations.
Why does the template rely on a single underlying database instead of separate tables for each view?
How do the formulas prevent annual subscriptions from being “forgotten” until the charge hits?
What fields make the system useful for real decision-making, not just tracking?
What’s the critical step for showing renewals on Notion Calendar?
How do the dashboard views differ while still using the same data?
How does the template support planning for cancellations and estimating impact?
Review Questions
- Which two formula properties are essential for turning raw subscription data into a planning schedule, and what does each one output?
- Why must the calendar view be added to the source database (not a linked database) to make Notion Calendar show renewals correctly?
- How would you use status values (active, maybe cancel, canceled) to build a workflow that supports both forward planning and later auditing?
Key Points
- 1
Create one source database for expenses and drive every dashboard section from filtered/sorted views of that database.
- 2
Store raw inputs for each expense: cost, charge date, recurrence interval (monthly/yearly), status, category, owner, used by, payment source, and a billing link.
- 3
Use formulas to compute “Monthly cost” (convert yearly to monthly) and “Renewal date” (next upcoming renewal relative to today).
- 4
Add a calendar view directly to the source database and configure it to use “Renewal date” so Notion Calendar shows the correct upcoming charges.
- 5
Connect the Notion workspace to Notion Calendar, then add the expenses database so renewals appear in week/month planning views.
- 6
Build separate dashboard sections for active expenses and cancellations using status-based filters and different sort/group settings.
- 7
Use category grouping and cost-sorted views to understand where money goes and to prioritize what to cancel first.