Setting Up a Notion-Based Travel Journal That Actually Works
I built three different travel journals in Notion before settling on something functional. The second one was beautiful. It used five databases, twelve linked properties, a custom gallery cover for each trip, and color-coded statuses that took twenty minutes to set up. I used it for one weekend trip to Seattle. By the time I finished writing the intro page, I had already forgotten to log the coffee shop I went to the next morning. The third attempt was a mess of duplicated data and broken rollups. The system I ended up using is deliberately boring. It tracks destinations, itineraries, expenses, and a shared packing list. That is it. Here is how to build it without going down the rabbit hole.
Professional Travel Journal Notion
The first thing you need is a main Dashboard page. Create a new page called Travel Dashboard. In the top row, you will place four database-linked views. These are not full databases. They are filtered slices that give you quick entry points. The four databases are Locations, Trips, Expenses, and Items. Every other view pulls from these four. If you add more databases later, you will regret it. The template I use has exactly four core databases and no additional tracking layers. Here is the structure for each database: Locations database — columns: Location Name (title), Country (select), City (text), Date Visited (date), Notes (text). You fill this in after each trip, not before. Trying to pre-fill it leads to abandoned trips cluttering the database. I keep this hidden from the main dashboard and only surface it as a filtered gallery view when I am planning a future destination.
Trips database — columns: Trip Name (title), Destination (relation to Locations), Start Date (date), End Date (date), Budget (number), Total Spent (rollup from Expenses), Status (select: Planned, Active, Completed). This is the backbone. Everything else connects here. Do not use checkboxes for status. Use a select with exactly three options. Checkboxes create a lot of maintenance overhead and Notion rolls them up poorly. Expenses database — columns: Description (title), Amount (number), Currency (select), Category (select), Trip (relation to Trips), Date (date), Paid By (text), Receipt (attachment or external link). The Receipt column is where most people fail. I recommend linking to a Google Drive folder instead of attaching files inside Notion. Notion's file handling gets slow with large batches. My rule is simple: if a receipt is a PDF over 5 MB, it goes to Drive. Everything else can be attached. Items database — columns: Item Name (title), Category (select), Quantity (number), Included In (multi-select linked to trips). This is a shared packing list. You do not create a new one per trip. You tag items to trips using the multi-select property. When planning a trip, you filter this database by the destination name. This takes maybe twelve seconds per trip setup.
Get the Full Details
Creating the Trip page template inside the Trips database reduces setup time from about eight minutes to about forty-five seconds. Inside the template, you add a daily log section. This is a toggle list where each toggle is a date. Inside each date toggle, you paste a daily notes page or embed a simple text block. Do not create a separate page for each day. The toggle structure keeps everything on one level and saves you from navigating between twelve sub-pages during a trip when you only have ten minutes between activities. The biggest mistake I see people make is creating nested sub-databases inside trip pages. You do not need a separate database for daily expenses inside each trip. The main Expenses database with a Trip relation handles this cleanly. Nested databases add friction without adding information. When I was building my first version, I created a separate Daily Expenses database inside each Trip page. After the third trip, I deleted it. Moving data between two databases manually is slower than just filtering the main one. Here is the setup sequence I follow now:
Open the Dashboard. Create a new Trip entry. Fill in destination, dates, budget. Switch to the Trip page. Open the Expenses database and apply a filter for that trip. Log expenses as they happen. When the trip ends, change the Status to Completed and review the rollup. If the Total Spent exceeds the Budget by more than fifteen percent, I note the reason in the Trip Notes. Most of the time it is food or transportation. Not always a disaster, but it helps me adjust future budgets. The rollup field for Total Spent uses the Expenses database, filters by Trip relation, and sums the Amount column. This is straightforward in Notion's built-in rollup formula editor. If your rollup is returning zero, check two things. First, confirm the relation property on the Expense entry actually points to the correct Trip page. Second, verify the Amount column on the Expense database is set to Number format, not Text. A text-formatted amount column breaks rollups silently. I spent an afternoon troubleshooting a broken rollup before realizing I had accidentally set the column type to text during initial creation. There is a quirk with the multi-select property on the Items database that almost nobody mentions. When you add a new item to the shared packing list and then try to use it across multiple trips, Notion sometimes creates duplicate tags with slightly different capitalization. For example, Toothbrush versus toothbrush. The database treats them as separate values. The fix is to go into the multi-select property editor, merge the duplicates manually, and standardize capitalization. I did this once every six months when I was actively traveling. It takes about three minutes.
Another common failure point is the Currency column. I recommend keeping expenses in your home currency and adding a Exchange Rate column if you travel internationally. Converting currencies inside Notion is clunky. You can use a formula like Amount * Exchange Rate, but the formula editor does not support live exchange rate APIs. You update the rate manually each month. For most travelers, this is fine. If you travel frequently across many currencies, consider exporting to a spreadsheet instead. The template I use right now is a single-page Notion document with four embedded databases. It takes approximately ten minutes to replicate for a new account. The main page structure looks like this: Dashboard at the top, four sidebar links to the core databases, a quick-add button for expenses, and a filtered view showing upcoming trips in the next ninety days. That is the entire system. No extra calendars, no flight trackers, no weather widgets. Those features attract attention but add almost nothing to actual trip planning. When planning a new trip, I start by creating the Trip entry, tagging the destination, and then pulling up the Items database filtered by that destination. I add items from the shared list, duplicate any items that are trip-specific, and move on. The whole process usually takes under three minutes. Before I switched to this structure, I spent twenty minutes per trip rebuilding packing lists. The difference is the shared database approach versus recreating from scratch every time.
One limitation worth stating plainly: Notion is slow with very large travel journals. If you accumulate over two hundred trips and ten thousand expense entries, page load times increase noticeably. The interface lags. If you are a frequent traveler logging daily expenses across dozens of countries per year, this template will eventually become unwieldy. In that case, a dedicated expense-tracking app with offline sync and receipt scanning works better. The Notion journal is designed for moderate use, roughly ten to thirty trips per year with occasional daily logging. For a downloadable copy of this template structure, you can search for a public template or clone the four-database setup from the template gallery by searching Professional Travel Journal Notion. The built-in templates are often over-engineered. I recommend cloning any clean template, deleting the extra databases, and restructuring to the four-core setup described here. The result is lighter, faster, and easier to maintain. The one edge-case I keep running into is last-minute itinerary changes. A flight gets canceled, a hotel is double-booked, you add a day in a new city. The Templates handle this okay. You just edit the dates, add the new location to the Locations database, and log any new expenses under the existing Trip entry. The rollup recalculates automatically. Where it breaks down is when you need to split one trip into two because the itinerary diverged mid-trip. Notion does not have a native trip-split feature. You end up creating a new Trip entry and manually moving some expenses over. I handle this by keeping a Notes property on the Expense database where I document the split reason. It is not elegant, but it keeps the data intact without requiring complex property manipulation.
If you only take one thing from this, it is the principle of starting minimal and adding only when a gap appears. The temptation is to build a comprehensive system before your first trip. Do not do that. Build the four-database core, use it for three trips, and add anything you miss along the way. That is how the template evolved from something broken into something usable. The template link is available through the search mentioned above. The structure does not require a premium Notion subscription. All features described work on the free tier. You do not need any automation tools, third-party integrations, or API connections to make this function. It runs entirely within Notion's native capabilities.
