Monthly software subscription audit from Brex card spend

On the first business day of every month at 8am, audit our recurring software spend in Brex and keep a living subscription register in Notion. Schedule this on a cron for the 1st, 2nd and 3rd of each month at 8am, and exit immediately unless today is the first weekday of the month, so the audit runs exactly once a month even when the 1st falls on a weekend.

Start by pulling the trailing 13 months of card activity using the Brex "List primary card transactions" and "List expenses" operations, paging through every result until the cursor is exhausted. Thirteen months is deliberate: it guarantees that any annual renewal appears in the window at least once. Note that Brex returns money as integer minor units plus a currency code, so an amount of 1000 with currency USD means $10.00.

Attribute every charge to a person and a vendor. Use "List cards" to map each card to its owning user, and "List vendors" to match merchants against vendors we already know. Brex has no list-users operation, so owner attribution must be built from card ownership plus the cardholder fields on transactions and expenses. Do not write a step that assumes a Brex user directory exists.

Group merchants into recurring subscriptions. Treat a merchant as a subscription only when the charge amount is consistent and the timing follows a cadence: roughly every 28 to 31 days for monthly, or roughly every 12 months for annual. Concentrate recurring detection on the $5 to $500 per month band, and separately surface larger one-time charges in the $100 to $5,000 range as likely annual billings worth inspecting. Ignore genuine one-off purchases, and ignore categories that are almost never subscriptions such as travel, meals and ad spend unless the cadence is unmistakable.

Compare that inventory against our existing Notion subscription register. Locate the register with "Search by Title" and read its current rows with "Query a Data Source". If no register exists yet, bootstrap one with "Create a Database" using columns for tool, owner, monthly cost, annualized cost, billing cadence, first-seen date, estimated next renewal, status and notes, then treat this first run as the baseline snapshot. For each newly discovered tool, use "Create a Page" to add a row carrying its owner, monthly cost, annualized cost, billing cadence, first-seen date and estimated next renewal date. When a tool already in the register has changed, use "Update a Page" to refresh its cost and next renewal rather than creating a duplicate row.

Flag the three things finance actually cares about. First, price increases: the same merchant now billing more than the prior cycle, reported with the old amount, the new amount and the percentage change. Second, likely duplicate or overlapping tools, where two merchants serve the same function, for example two project trackers or two e-signature tools. Third, zombie subscriptions still charging on a card whose owner is departed or inactive, which you infer from card status and the absence of any other recent activity for that cardholder rather than from a user directory lookup.

Finish by posting a summary to the finance channel with the Slack Bot "Send a Message" operation. Lead with total annualized software spend, then the month-over-month delta, then any renewal landing in the next 45 days so there is still time to cancel or renegotiate, and close with the price increases, duplicates and zombie subscriptions, naming the owner for each. Expose the 45-day renewal window as a configurable knob, since 30 days suits the tool owner while 90 to 120 days suits procurement. This workflow reports only: it must never cancel, pause or modify a subscription, a card or a vendor record.