# Statement pull method (12 months)

Purpose: build a complete list of every recurring software charge, without relying on memory.

Steps:

1. Gather statements for the last 12 months from every business bank account and every business or personal card used for the business. Include cards no longer in daily use if they might still carry an old subscription.
2. Search each statement for line items that repeat monthly or annually. Sort transactions by merchant name where your bank or card portal allows it; repeated charges from the same merchant are easy to spot once sorted.
3. For each repeating charge, record: tool name (as it appears on the statement, which is sometimes a billing entity, not the product name), monthly or annual amount, billing cycle, and the account or card it hits.
4. Cross-check against your card issuer's own recurring-charges view. Most issuers have one under account settings. This catches charges a statement search misses because the merchant name changed or the charge is annual and fell outside a shorter lookback.
5. Do not stop at charges you recognize. Flag anything billed monthly or annually from a software vendor even if the name is unfamiliar, then check it before dropping it from the list.
6. Compile the full list in the table below: tool name, cost, cycle, account/card, and a blank job column (filled during Phase 1, step 3 of the audit, using the jobs-to-be-done matrix).
7. Present the full list back before moving on to anything else. This step alone regularly turns up a tool nobody remembered was still billing.

## Table template

| Tool name (as billed) | Cost | Cycle (monthly/annual) | Account or card | Job (fill in Phase 1 step 3) |
|---|---|---|---|---|
| | | | | |

## Common places a forgotten charge hides

- An annual charge that only shows up once in a 12-month window and gets missed by a shorter statement pull.
- A tool billed under a parent company or payment processor name instead of the product name.
- A card that used to be the default on file for a tool, replaced later, with the old card still charging a secondary plan nobody noticed.
- A free trial that converted to paid and the confirmation email got buried.

# Jobs-to-be-done matrix (template)

Purpose: map every tool from the inventory to the job it does, so overlapping tools become visible.

One row per tool. The job column uses one of these fixed categories so overlap is easy to spot:

- Lead tracking
- Notes
- Time tracking
- Financials
- Scheduling
- Client messaging
- Other (name it)

Fill this in during Phase 1, step 3, right after the statement pull. See examples/jobs-to-be-done-matrix-filled.md for a worked example of the format.

## Matrix

| Tool | Cost | Job | Notes |
|---|---|---|---|
| | | | |

After every row is filled, group the rows by the job column. Any job with more than one tool listed is overlap and goes to the flag list below. A job with exactly one tool stays untouched this pass.

## Overlap flag list

Copy overlapping rows here:

| Job | Tools claiming it | System of record (decided in Phase 2, step 5) |
|---|---|---|
| | | |

## New-tool candidates

Log a candidate here per the 30-day cooling-off rule (audit-cadence.md) instead of approving it on the spot:

| Tool considered | Job it would do | Date logged | Revisit at next pass? |
|---|---|---|---|
| | | | |

# 30-day login usage lookback

Purpose: confirm whether a tool is actually used before treating it as a cancellation candidate. A stated intent to consolidate is not evidence a tool is unused; only the data is.

For each tool on the overlap flag list:

1. Log into the tool's admin panel and find its activity log, usually under Settings, Team Management, or Admin > Users.
2. Pull the last-login date for every user on the account, and the count of logins in the last 30 days.
3. Record the actual numbers, don't estimate them. If the tool doesn't expose login history, check for an activity feed, a last-edited timestamp on records, or export a usage report if the vendor offers one.
4. If no usage data can be found or provided, mark the figure as unknown. An unknown is not the same as zero, and it is not a green light to cancel.

## Table template

| Tool | Users on the account | Logins in last 30 days | Last login date | Status |
|---|---|---|---|---|
| | | | | |

## Status categories

- **Active**: regular logins from at least one user in the last 30 days.
- **Near-zero**: one or two logins in the last 30 days. Worth a direct question to whoever's name is on those logins before cutting.
- **Zero**: no logins in the last 30 days. Cancellation candidate, pending the retirement checklist.
- **Unknown**: no usage data available. Ask the vendor or the account owner before treating it as a candidate either way.

This same lookback runs again on every recurring audit pass (audit-cadence.md), applied to the full current tool list, not only the tools flagged in the prior pass.

# Retirement checklist (export, then cancel)

Run this once per tool on the approved retirement list, only after the owner has given an explicit yes to that list in the same conversation. A presented list is not approval.

## Per tool, in order

1. Confirm the named cutoff date for this tool from the approved retirement list.
2. Export every record still needed: contacts, deal history, notes, files, past invoices, message threads. Use the tool's own export function (CSV, PDF, or its native backup format); if it doesn't have one, copy the data out by hand.
3. Import or re-enter the exported data into the chosen system of record for that job.
4. Open the system of record and confirm the data actually landed there. Spot check a sample of records (open at least three, more for a large export) against the export file.
5. Once confirmed, cancel or deprovision the tool on the cutoff date, not before (in case something surfaces during the confirm step) and not after. A tool left live past its cutoff date is exactly where people revert under deadline pressure.
6. Record the cancellation: date cancelled, confirmation number or email if the vendor provides one, and the cost that stops recurring.
7. Check the next statement to confirm the charge actually stopped.

## Per-tool checklist (copy for each tool being retired)

- [ ] Cutoff date confirmed: ____________
- [ ] Data exported (format: ____________)
- [ ] Data imported into system of record: ____________
- [ ] Spot check passed (records checked: ____________)
- [ ] Cancelled or deprovisioned on cutoff date
- [ ] Cancellation confirmation recorded
- [ ] Next statement checked, charge stopped

Never skip the spot check. Never cancel before the export is confirmed present in the new system of record.

# Recurring audit cadence

Purpose: keep the software stack from drifting back into overlap after the first cleanup. The audit is not a one-time project, it runs on a schedule.

## Pick a cadence

- **Monthly**: for a stack that's changing fast (new tools added often, team growing, plans changing).
- **Quarterly**: for a stable stack with few changes between passes.

Default to quarterly unless the stack has changed more than twice in the last two months, in which case switch to monthly until things settle.

## Each recurring pass

1. Pull statements for the period since the last pass (method: inventory-method.md).
2. Update the jobs-to-be-done matrix with any new or changed tools.
3. Flag any job with more than one tool.
4. Re-run the 30-day usage lookback (usage-verification.md) against the full current tool list, not only what was flagged last time.
5. Draft and get explicit approval for a retirement list for anything that needs cutting.
6. Run the retirement checklist for approved cuts.
7. Set the date for the next pass before closing this one out.

## Cooling-off rule for new tools

Applies between passes, not only at audit time.

- Before adding any new paid tool, check whether an existing tool already covers that job. If yes, and the existing tool isn't confirmed broken or insufficient (just less convenient), don't add the new one.
- If a new tool still seems worth it, log it in the jobs-to-be-done matrix as a candidate with the date, and wait 30 days before committing to a paid plan. Revisit it at the next scheduled pass instead of deciding in the moment.
- This is what stops a free trial from quietly turning into a permanent charge while nobody's looking at it.

## Standing rule to check at every pass

No detail about a contact or a deal should live only in the tool that's easiest to forget to open, including the system of record itself if it turns out to be the least-opened app. If a lead or detail went stale because it only existed in one place, trace which tool it lived in and correct that job's system-of-record assignment at this pass.

# Jobs-to-be-done matrix, filled example

This is a worked example from a two-person contracting business, shown only to illustrate the format the real matrix (references/jobs-to-be-done-matrix.md) should take. Tools and numbers are illustrative, not a recommendation.

## Matrix

| Tool | Cost | Job | Notes |
|---|---|---|---|
| Basic CRM plan | $49/mo | Lead tracking | Original system of record for leads, mostly unused past the first month |
| Spreadsheet (lead tracker tab) | $0 | Lead tracking | Started as a backup, became the actual place leads get logged |
| Notes app | $10/mo | Notes | Project notes and a few client pages |
| Spreadsheet (job notes tab) | $0 | Notes | Second, separate notes habit living on the same spreadsheet file |
| Time tracker app | $9/mo | Time tracking | Used consistently by both people |
| Bookkeeping app | $30/mo | Financials | Invoicing and bookkeeping, used weekly |
| Booking link app | $12/mo | Scheduling | Client booking link, used consistently |
| Calendar app | $0 | Scheduling | Also used to hold the same appointments, entered by hand a second time |
| Team chat app | $0 (free tier) | Client messaging | One channel per client, mostly quiet |
| Text messages (personal phone) | $0 | Client messaging | Where most real client conversation actually happens |

## Overlap flag list, from the table above

| Job | Tools claiming it | System of record (decided in Phase 2) |
|---|---|---|
| Lead tracking | Basic CRM plan, spreadsheet lead tracker tab | Basic CRM plan (per the rule: lead and client data goes to the CRM or single consolidated record-keeper, never a spreadsheet) |
| Notes | Notes app, spreadsheet job notes tab | Notes app |
| Scheduling | Booking link app, calendar app | Booking link app (calendar app kept only as the display calendar it writes into, not a second manual entry point) |
| Client messaging | Team chat app, text messages | Text messages, logged into the CRM as the lead moves, so the conversation history isn't stranded on a personal phone |

## What the usage lookback found

Using the method in usage-verification.md: the Basic CRM plan showed 2 logins in 30 days, against more than 40 edits on the spreadsheet tracker in the same window. That's why the spreadsheet habit had taken over even though the CRM was the intended system of record. The retirement list moved the live lead data into the CRM, retired the spreadsheet tab, and set a 14-day cutoff for the team to stop entering new leads there.

Pull twelve months of bank and card statements and log every recurring charge by hand, tool name, cost, and the card it bills to. A guessed list of apps under-counts what's actually still billing, including things you forgot you signed up for.

Pick one system of record per job. For anything touching leads or client data, that's your CRM or main record-keeper, never a spreadsheet, chat app, or notes tool, because those are exactly where a detail gets typed once and never reopened.

No. Pull the last 30 days of login or admin-panel activity for that tool first. Cut it on the usage data, not on a hunch or on the fact that you said you wanted to.

Monthly if your stack changes a lot, quarterly otherwise. Set it as a standing recurring pass with a reminder, not a one-time cleanup you do once and forget.

A 30-day cooling-off rule on any new paid tool. Log the candidate and its job, then revisit it at the next scheduled audit instead of approving the subscription in the moment.

Export whatever's still needed, confirm it landed in the new system of record, then cancel or deprovision on the date you named. Don't leave a canceled tool live past its cutoff; that's when people revert under deadline pressure.