Zapier's free plan cannot run a single one of these. Free Zaps are capped at 100 tasks a month and two steps, one trigger plus one action, which is not enough for any multi-source build here. If you want a free orchestrator, use Google Apps Script (genuinely free, runs on a schedule) or self-hosted n8n. Make's free tier gives 1,000 credits and two active scenarios, which is enough to test.
Free, about 30 minutes, no build. Nobody signs up for two project trackers on purpose. It happens one contractor and one team lead at a time, and then both renew quietly forever. The trick is to group by the job the tool does, not by vendor name, because that is the only view where the duplicate becomes obvious.
The honest verdict on the dedicated tools: there is a whole SaaS-spend-management category and none of it is priced for a solo operator or a small team.
What actually works: a Claude project with the statement attached. Clustering charges by job-to-be-done is a judgement task, not a rules task, which is exactly the kind of thing a model is good at and a spreadsheet formula is not.
Attached is my card statement or accounting export for the last
13 months. Find the software I am paying for twice.
Do NOT group by vendor. Group by the JOB the tool does, because
nobody signs up for two project trackers on purpose. It happens
one contractor and one team lead at a time.
For each job, list every tool I pay for that does it, with the
annual cost, then give a verdict:
- KEEP ONE: they genuinely overlap. Say which to keep and why.
- KEEP BOTH: they look similar but do different jobs. Say the
difference in one line.
- CANCEL: I am paying and there is no sign I use it.
Then three totals: annual software spend, what the overlap
costs me, and what I would save acting on every CANCEL.
Rules:
- Normalise annual and monthly plans to a monthly equivalent
before comparing. The most expensive duplicates hide in
annual billing.
- A charge you cannot identify goes in an UNKNOWN list with the
merchant string and amount. Do not guess what it is.
- Flag anything renewing in the next 60 days first. That is
where I still have leverage.Why 13 months, not 12: annual subscriptions only appear once. A 12-month window can miss the renewal entirely or double-count it depending on where you start.
The honest gate, and this is the part most guides skip: a statement proves you are paying for something. It can never prove you are not using it. Beyond that, bank descriptors lie. Strings like SP * and PADDLE.NET* name the merchant of record, not the software, so two different tools billed through the same payment processor look like one vendor, and one tool switching processors looks like two. Worst of all, Apple collapses apps, subscriptions, iCloud+ and TV+ into a single billing line, so anything billed through Apple cannot be deduplicated from a statement at all. Same for a lot of PayPal. Expect to find most of it and check the rest by hand.
If you want it automated later, the Australian shortcut is a Xero custom connection at about $10 a month including GST, which is machine-to-machine and skips building an OAuth flow. Worth knowing: Xero moved to commercial API tiers on 2 March 2026, priced in AUD, and custom connections are exempt from that tier pricing. A plain CSV export avoids the whole question.
Cledara pricing · Xero custom connections
Free with Sheets and Apps Script, or about $10 a month off the shelf. Nobody negotiates on the day a renewal lands. A month of warning is what turns "ugh, already charged" into a phone call that works.
The single design decision that makes this work: the date you care about is not the renewal date. It is renewal date minus the notice period. A contract that renews on 18 September with a 90-day notice period needs you to act in June. Build your register around that field and everything else follows.
The tools:
How to set it up: one sheet, one row per agreement, with a notice_deadline column calculated from the renewal date and the notice period. A daily Apps Script trigger checks whether anything is 30 days out and emails you. One quirk to design around: Google Calendar reminders max out at four weeks before an event, so create the calendar event on the act-by date rather than trying to set a 30-day offset on the renewal itself.
Here are my contracts and subscriptions [paste the list, or
attach the PDFs].
Build me a renewal calendar for the next 12 months. One row per
agreement, sorted by the date I have to ACT, not the date it
renews.
For each one give me:
- Renewal date, and the notice period, so the ACT BY date is
renewal minus notice. That date is the one that matters.
- Current annual cost, and last year's. Flag any rise above CPI.
- Whether it auto-renews, and for how long if I miss the window.
- One line on what the realistic alternative costs today.
- A verdict: RENEGOTIATE, SHOP IT, or LEAVE IT ALONE.
Then tell me which three to deal with this month, and for the
top one, draft the email that opens the conversation. Calm, not
threatening to leave, with the competitor's number in it.
If a document does not state the notice period, write NOT
STATED. Do not assume 30 days is standard.The honest gate: the renewal dates you most need are usually not in any email. Card-on-file software often sends a receipt only after charging you, which is exactly the moment your leverage is gone, and annual contracts signed as a PDF leave no recurring digital trace at all. So there is one unavoidable manual step: open each contract once, have Claude pull the auto-renewal clause and the notice period verbatim, and store both on the row. After that it runs itself. Reconcile the register against your card statement quarterly, because in Australia that is now the only reliable way to discover a subscription you forgot.
If you ask it to price alternatives, force it to use web search and reject any comparison that does not come with a citation URL and a date. Stale pricing is the entire failure mode of this one.
TrackMySubs · Apps Script triggers · Gmail search operators
Free to about $7 a month, and roughly 30 cents a month in AI. Every business has conversations that stalled for a reason that has since passed. Budget season ended. The person who went quiet got promoted. This finds them and drafts the way back in, referencing what you actually discussed.
The tools:
The best starting point is an existing n8n template that pairs Gmail with Claude and creates a draft on the original thread rather than sending. Swap its unread trigger for a scheduled scan of stalled threads and you have this build.
Here are my stalled conversations [paste the threads or the CRM
export]. Find the ones worth chasing and draft the way back in.
First, sort them:
- CHASE TODAY: real interest, went quiet for a reason that has
probably passed.
- WAIT: they named a date or a condition that has not arrived
yet. Tell me when to come back.
- LET IT GO: they have said no, politely, more than once.
Respect it and tell me plainly.
For everything in CHASE TODAY, draft the message:
- Reference the specific thing we actually discussed. A date, a
number, a constraint they mentioned.
- Never write "just circling back", "touching base" or
"checking in". If the message would work sent to anyone, it
is wrong.
- Give them an easy way to say no. It gets more replies than
pressure does.
- Four sentences maximum.
Sort CHASE TODAY by value and tell me which to send first.What it costs to run: a five-message thread is roughly 2,000 to 4,000 tokens in and 300 out, which is about a cent per draft. Thirty drafts a month is well under a dollar. Strip quoted reply chains and signatures before sending, and cap it at the last five messages.
The honest gate: never let this send. Two reasons, and the second is the real one. A model can hallucinate a rate or a deliverable you cannot retract, and stall detection has false positives, so an obviously templated follow-up to a brand burns a relationship that was fine. The biggest false-positive source for creators specifically: deals that moved to Instagram DMs or a phone call leave no email trace, so the thread looks abandoned when it is actually progressing. That is the argument for a CRM field you can update by hand rather than trusting your inbox alone.
Attio · The n8n draft-reply template · Claude's Gmail connector
Free, about 2 hours to build once. Not a monthly average. The actual dates money lands and leaves, week by week, so you can see the week where the buffer dips before you get there.
How to set it up: one Google Sheet, three tabs. Invoices with an expected payment date, Costs with a frequency and an explicit renewal date, and Forecast with thirteen week columns. A Monday morning Apps Script trigger recalculates, takes the minimum running balance and emails you if any week drops below your comfort number.
The one formula that matters: expected payment date equals due date plus that client's typical days late, snapped to the Monday of that week. Never use the raw due date. A 30-day invoice paid on day 47 can completely change which week is the tight one.
Here are my invoices out, my expected income, and my recurring
costs [paste or attach], plus my current bank balance.
Map them onto the actual dates they land and build me a 90-day
cash position, week by week.
I need:
- The running balance at the end of each week.
- The LOWEST point in the 90 days, the exact date, the amount.
- Any week where the balance drops under [my comfort number].
- Which single payment causes each squeeze.
Then the three cheapest fixes, ranked by how little disruption
they cause. Moving a payment date, invoicing earlier, or
holding money back all beat borrowing.
Rules:
- Use the date money actually ARRIVES, not the invoice date. If
a client is habitually late, use their real average, and tell
me which clients you adjusted and by how many days.
- Do not smooth anything into monthly averages. The whole point
is the bad week.
- Annual costs land as lumps on their real date. Never spread
them across twelve months.The honest gate: three things break this. Due date is not payment date, and every ledger-syncing tool inherits that flaw. Irregular creator income genuinely is not forecastable at three data points a month, so model only contracted income with a signed deal and a real date, and treat everything else as upside sitting outside the forecast. And if you are registered for GST, the GST you have collected is not your money, it just sits in the account looking like a healthy buffer. Put your BAS in the cost tab as a hard-dated lump, because any 90-day window contains at least one. Check your own lodgement dates with the ATO rather than trusting a number in a blog post.
Float pricing · Fathom pricing · A free 13-week template · ATO BAS due dates
Free to about $9 a month. Keeping a customer costs one phone call. Replacing one costs months. This watches the signals weekly and tells you who to ring while there is still time.
The strongest signal by a mile is in your billing, not your analytics. In Stripe, the moment a subscription updates with cancel_at_period_end set, that person has already decided and you have until the period ends to change their mind. Webhooks and the dashboard are free, so this needs no paid add-on.
What each source actually gives you:
Score it with arithmetic, not with a model. This is a weighted flag set, not machine learning, and pretending otherwise is how people end up trusting a number that means nothing. A hundred-member community at five percent monthly churn produces about five events a month. That is noise, not training data. Weight the cancel flag highest, then hard-declined payments, then an explicit cancel or refund message in the inbox, then an unanswered support thread, then long gaps in clicks or posts. Let Claude write the one-line explanation and the opener for the call. Never let it invent the score.
Here is my customer data [usage, clicks, support threads,
billing status, last contact] with a risk score already
calculated for each row.
Do NOT recalculate the scores. Use mine. Your job is the
language, not the maths.
For each account in the top five by value at risk, give me:
- The SPECIFIC signal behind the score. "Cancelled at period
end, effective 14 Sept" or "two failed payments, card
declined as lost". Never "low engagement".
- What is at stake per month.
- Whether the person who championed us is still there. That is
the biggest predictor and the easiest to miss.
- The one action, and the opening line for that conversation.
Sort by value at risk, not by score alone. A shaky $200
account matters less than a wobbling $1,400 one.
If the only signal is that someone has been quiet, say so and
mark it LOW CONFIDENCE. Quiet often just means it is working.The honest gate: email opens are a broken signal now. Apple Mail Privacy Protection pre-loads tracking pixels, so those subscribers register as having opened everything regardless of whether they looked. Use clicks, never opens. With small numbers, score on absolute flags like a cancellation or a failed payment rather than percentage changes, because a percentage drop on tiny numbers is meaningless. And community lurkers are not churners. A large share of any community reads without ever posting, so that signal deserves the lowest weight and should never trigger an alert on its own.
Stripe event types · Stripe Smart Retries · Kit API