The expense I no longer have to log.

Keeping up was the hard part.

For years, I have used a spreadsheet based on the template shared by Mr RIP. It gives me the view I want: spending by category, multiple currencies converted to EUR, and net worth alongside income and expenses. The useful part is looking back at a month and understanding it. First, though, every transaction has to arrive there.

The older public version still shows the structural idea: asset and liability groups, a currency field, monthly columns, net worth and annual summaries. My version has changed over time, but it kept that useful separation between recording transactions and understanding the wider picture.

I had already made a decent start. An Apple Pay Shortcut could capture a payment and send its merchant, amount, currency and time to n8n. For payments covered by that automation, the row appeared without me typing it in.

Then I would book a flight or buy something online using my card details. That payment never passed through my Apple Pay shortcut. I was back to opening the sheet, entering the merchant, checking the currency and choosing two categories. A small task, repeated often enough to become a backlog.

I had automated part of the habit. The gaps were still mine to remember.

The missing input was already on my phone.

Revolut sends me a notification when a card payment happens. I could trigger a Shortcut from that notification, including for purchases that never went through Apple Pay.

The Shortcut looks for “Available credit” in the notification, then pulls the currency and amount from the “you spent” message. The regular expression below is fussy for a reason: the next steps expect the currency in group 1 and the number in group 2. If I change the pattern, those positions have to stay put.

Once the other fields are assembled, the Shortcut sends them to an n8n webhook. Both input routes use the same fields and identify their source. The payment becomes something the workflow can compare.

{
  "merchant": "Cloud Picker Coffee",
  "amount": "PLN18.50",
  "currency": "PLN",
  "source": "revolut_notification",
  "timestamp": "2026-09-19T10:30:00Z"
}

The receiving code handles formats such as €40.00, PLN150.00 and 40.00€. It separates the number from the currency, normalises the merchant name and adds an internal transaction ID. Then it inserts the event into an n8n Data Table: the transaction inbox.

Then one payment became two events.

A tap with Apple Pay can also produce a Revolut notification. Both automations were doing their jobs, but together they could put the same purchase into my sheet twice. I needed a place to pause the payment before adding the row.

I made the “same payment” decision fairly narrow: the events must come from different sources, use the same currency, have almost exactly the same amount, and arrive within five minutes of each other. The merchant name gets a little leeway: Lidl can match Lidl Coolock.

Those timings do different jobs. Five minutes defines which events could describe the same payment. Thirty seconds gives the second source a chance to arrive. In this export, an event with no match takes the wait path regardless of which source sent it.

Apple Pay has higher priority. When it matches a lower-priority inbox event, the workflow confirms the winner and marks the other record as a duplicate. A lower-priority matching event stops. After the wait, the workflow reads the inbox again and repeats the decision before an unmatched event proceeds.

See the complete n8n workflow

This is the actual workflow screenshot from this project. Open it at full size to inspect the branches.

Open full-size workflow ↗︎

The wait helps with normal arrival order. It does not make late events or retries disappear; those are the cases I would tackle next.

A useful job for the model.

Once a payment has made it through that check, Gemini 2.5 Flash gets the merchant, amount and currency, plus the categories I actually use and a few merchant rules I have added. I ask it to return the expense fields and two categories as JSON.

That is where the model earns its place. A generic label can sound plausible and still be wrong for my sheet. I want a purchase to land where I would have put it myself.

Code does the parts I can state as rules: reading the payment, comparing possible duplicates and preparing a row for the sheet. The model handles the fuzzier question of what kind of purchase a merchant name represents.

For now, I tell the model to stick to my category list and honour the merchant rules. I have not yet added a final code check that rejects an invented category or reapplies an override. That is one of the reasons I still review the sheet.

Finally, the row appears.

The output looks like the sheet I already use. Merchant, original amount, currency, date and categories are appended to their existing columns. A formula provides the EUR view for foreign-currency expenses.

It runs in n8n on an Oracle Cloud Always Free instance, inside Docker. That keeps the server footprint small, although model calls are a separate cost to watch.

The satisfying part is how ordinary the end result is. A purchase that used to become a task for later now has a route into the same record as a tap payment. I can spend my attention reviewing the month instead of reconstructing it.

The spreadsheet is still there. I still look at it. I still decide what the numbers mean.

I just spend less time getting the numbers into it.

A little further under the hood.

I like what this does for me now, but I do not want to pretend it catches every edge case. These are the parts I would revisit if I relied on it more heavily or shared it with someone else.

// Excerpt from the workflow's merchant comparison
if (a === b) return true;
const shorter = a.length <= b.length ? a : b;
const longer = a.length <= b.length ? b : a;
return longer.startsWith(shorter + ' ');