How I Have AI Automatically Check My Card Spending Every Night — and Flag Only the 'Expenses Worth Discussing'

Good morning. It’s まさきん.

A while back, I wrote about a system that combines AI with the accounting app freee to review my household finances every morning. This time it’s the night-time version. I’ll walk through a setup where AI automatically checks that day’s card spending before I go to bed.

If the morning review is about pulling one insight out of yesterday’s trends, the nightly system is a bit different in nature. It’s designed to catch, on the same day, whether there’s any spending worth flagging today. This time I’ll cover everything down to the formulas behind the judgment rules and the fine-grained controls that run at execution time.

The Trigger: “The Bigger the Expense, the More Likely It Gets Put Off”

Small, everyday spending naturally gets logged by budgeting apps without any effort. One-off big purchases are a different story, though. You tell yourself “I’ll bring it up later,” and then it slips your mind.

So I built a system that specifically targets larger purchases and surfaces them on the same day they happen. It’s not something I trigger manually — it runs as a scheduled task that fires automatically at a set time.

What I’m Careful About, Precisely Because It Runs Automatically

Since it runs automatically at a fixed time, there’s no one around to check in with on the spot. So I’ve laid down the following ground rules for how it operates:

• If any single data fetch fails partway through, keep going with the rest instead of stopping the whole process
• When a judgment call can’t be made confidently, skip it rather than forcing a decision, and just leave a note in the log
• On days when an external API call fails, give up on the normal tally and fall back to a simplified summary

I’ve designed the automated task to prioritize “producing some result every single day” over “working perfectly.”

Sorting Spending Into Three Categories

If I checked every single expense against the same standard, I’d end up buried in notifications and start ignoring them entirely. So I sort spending into the following three categories:

Fixed costs are the same every month, so checking them each time is pointless. Pre-agreed spending has already been discussed, so there’s no need to notify anyone about it either. The only thing worth checking is everything else — the spending that happens in the moment.

The classic examples of fixed costs are things like rent or your mobile bill. Precisely because the amount barely changes, I exclude them from the daily checks.

For merchants where I can’t tell whether something is a genuine recurring subscription or just a one-off purchase, I don’t force them into the “subscription” bucket. Instead, I record them separately as “pending judgment,” one line at a time. If I let that stay ambiguous, I feel it ends up undermining the reliability of the whole tally down the line.

That said, there’s an exception even among the spending I exclude from checks. Fixed costs like your mobile bill are exactly the kind of thing that’s worth revisiting once in a while. Even if daily monitoring can be automated, only you can actually move the needle on the fixed cost itself.

The Rule for Judging an “Expense Worth Discussing”

Among the spending that gets checked, only the purchases that cross a certain amount get treated as an “expense worth discussing.” Here’s a generalized version of the instructions I give the AI:

From today's card transaction history, extract "expenses worth discussing" using the following steps.

1. Exclude transactions already classified as fixed costs or subscriptions
2. Exclude transactions already registered on the pre-agreed list
3. From what remains, extract any transaction of a certain amount or more per purchase (as a guideline, around 10,000 yen)
4. List each extracted transaction with three fields: "amount," "merchant," and "time"

If no transaction exceeds the threshold, simply respond "None today."

I think the right threshold amount varies from household to household. What matters more than the specific figure, I’ve found, is deciding on a standard in advance. Without one, you end up arguing every single time after the fact about whether something should have been discussed or not.

Turning Sync Delays Into Numbers

Card syncing on budgeting SaaS tools normally lags by a few days. It lags even more right after long holidays. If I treated that as an “anomaly,” I’d end up drowning in false-positive notifications. So I quantify the delay using the following metrics:

• latest_txn_date: the date of the most recent transaction observed for that card
• lag_days: today’s date minus latest_txn_date (in days)
• lag_status: classified into the following four stages based on the size of lag_days

The key point is not to immediately jump to “the integration is broken” the moment something hits stalled — no sync for a long stretch. In practice, it’s far more often simply a case of “I just haven’t used that card in a while.”

Separating “Just Not Using It” from “Integration Trouble”

When I observe a stalled status, before jumping to any conclusion I check the transaction pattern over the past 30 days.

• There’s at least one transaction in the past 30 days, and only the most recent stretch has gone 10+ days without one → simply a case of not using the card for a while; the integration itself is fine
• There are zero transactions at all in the past 30 days, but I actually remember using the card → suspect an integration problem

That said, even the latter case alone isn’t enough for me to immediately call it a “malfunction.” I only treat it as an integration problem once all three of the following conditions are met:

1. Multiple cards are hitting stalled at the same time
2. There’s separate evidence of actual use — a receipt, a note, etc. — that never shows up in the budgeting SaaS
3. I can visually confirm a sync error message on the budgeting SaaS’s own screen

Unless all three conditions line up, I treat it neutrally as “haven’t used this card for N days — a continuing savings streak,” and avoid firing off alerts for no good reason. Before I added this distinction, I used to get anxious every single time about a card that simply wasn’t being used, wondering “is the integration broken?”

Capping the Number of External API Calls

Since this is an automated task, I’ve capped the number of calls per run so it can’t accidentally spiral into an infinite loop of API calls.

• Count in advance the number of calls expected under normal patterns — fetching just today’s data, fetching the cumulative total since the start of the month, and so on
• Even if an unexpected error occurs, stop retrying the moment the cap is reached and immediately fall back to a “fetch failed” state
• Prioritize cutting off processing because the call cap was hit over waiting for a timeout

Without a cap in place, there’s a risk that something like an authentication error triggers repeated retries and keeps firing off pointless requests. The more automated a system is, the more I feel it needs this kind of safeguard.

Distinguishing “An Ongoing Issue” from “A New Issue”

I also have a rule that sends a notification when spending for the month crosses a certain percentage of a target. But if I used that as-is for daily notifications, once I crossed it once, I’d get the exact same notification every night for the rest of the month. That makes it impossible to tell apart “the day the threshold was newly crossed” from “a day that’s still over the threshold, unchanged from before.”

So I count how many days the overage has continued and attach it as “Day X of ongoing overage.” Being able to distinguish a brand-new issue from an ongoing one also makes it much easier to grasp the situation correctly when I review things weekly.

I Keep the Notifications Deliberately Plain

Even on days when an “expense worth discussing” turns up, the notification stays matter-of-fact. It just presents the amount and the merchant — it doesn’t pass judgment on whether it was good or bad.

The judgment call is ours to make. I’ve settled on the idea that the AI’s job stops at “making sure we notice a purchase we might have overlooked.”

What I’ve Noticed Since Doing This

The biggest payoff has been the disappearance of “he-said-she-said” arguments over big purchases. Because the information gets shared the same day, it’s much harder to miss the window to talk about it.

On the other hand, I couldn’t get the threshold amount right from the start. Set it too low and you get so many notifications that they stop meaning anything; set it too high and you miss purchases that actually matter. I adjusted it a few times before settling on where it stands now.

Who This Is a Good Fit For

• Anyone who has card syncing set up in a budgeting app, but still finds a time lag before big purchases actually get shared
• Anyone who wants their family to have a clear line for “what counts as an expense worth discussing”
• Anyone who doesn’t mind the grind of gradually tuning out an automated task’s false positives and over-triggering

Wrapping Up

Exclude fixed costs and pre-agreed spending, and pick up only the other big purchases. I’ve found that this simple filter is the trick to keeping notifications from becoming meaningless noise.

Quantifying sync delays to separate “just not using it” from “an actual problem,” and capping the number of API calls as a safeguard — both are unglamorous, but I really feel they’re what keeps this automation running stably.

What this system picks up on is ultimately variable spending. Fixed costs like your mobile bill, on the other hand, are a different animal. Rather than checking them over and over, wouldn’t a single review have a longer-lasting effect? Alongside the automation, I want to turn my attention there too.

This article contains affiliate advertising. If you sign up for a product or service through a link on this site, we may receive compensation from the partner company. The site operator is also an employee of Rakuten Group and may receive compensation through an employee referral program. The content and opinions here are based on the operator’s own experience and research regardless of any advertising relationship, but please read with the above in mind. See the Disclaimer & Affiliate Disclosure for details. Disclaimer & Affiliate Disclosure

This article includes machine-translated content. Please check the official Rakuten Mobile multilingual page for exact terms.

If you have concerns about Rakuten Mobile coverage or signal quality, you can consult through the official signal improvement request form .