Calculator girl, no longer

For three months last year, I didn’t reconcile our credit card expenses against projections. We’d significantly increased our software spend in that time, and I had no idea how far off our projections were. When you’re seven people, every dollar is visible. There’s no buffer of scale to absorb a missed projection or a late invoice. If I don’t catch a subscription we projected as cancelled, we’re budgeting for money we don’t have.

I didn’t set out to automate our finance function. I set out to stop dreading it.

I run finance for a seven-person company, in addition to my ten other jobs. We have a fantastic fractional CFO who closes our books every month, handles our tax accountants, and helps us stay in good standing with whatever compliance hurdles come up. But the operational layer is on me: how much money we have, what’s coming in, what’s going out, whether our projections match reality, whether we can make it through the month.

At a slightly larger company, that would be a whole person’s job. I don’t have that luxury. The finance work has to get done, it has to be accurate, and it can’t consume my week. For most of last year, it consumed my week.

Today, most of what I used to dread runs in the background: reconciliation takes fifteen minutes a month instead of ninety via /expense-recon, the cash flow tracker updates from our bank feed whenever I need it using /cash-flow, and invoice reminders arrive in my inbox automatically. What opened up in that space is worth a lot more than the time I got back.

The signal was emotional, not analytical

I didn’t sit down one day and audit my workflows for inefficiency. I opened our financial model and realized I hadn’t reconciled our credit card expenses against projections for three months. The process was tedious enough that I’d been quietly letting it slip. Things get busy, and when every process has friction, the ones you can defer, you defer until you can’t.

The dread was information. It was telling me something a workflow diagram never would. The task is deadly boring and incredibly important at the same time, and the errors it produces don’t stay small. You miss a number, you don’t notice a fluctuation, and suddenly the decisions you’re making downstream are based on data you can’t trust. Your work starts giving you a tinge of anxiety that doesn’t wash off at 6pm.

One Friday, I decided: instead of spending 90 minutes doing the reconciliation manually, I’d spend 90 minutes building the thing that does it.

Describe it until you can see it

The first thing I did was not build anything. I described the process. I turned on my mic and talked through exactly how the reconciliation works, step by step, out loud, to Claude Code in the terminal. Two things happened that I didn’t expect.

First, I noticed friction I’d completely normalized. Every finance workflow follows the same pattern: log into a platform, pull the data out, bring it somewhere else, do the thinking, go back into the platform, make the updates, then communicate the result in a third place. For expense reconciliation, I was going into Ramp, looking up each vendor’s monthly spend, then switching to our financial model and visually cross-comparing what appeared on the credit card against what we’d projected – vendor by vendor, line by line, across hundreds of transactions. For categories like restaurants that don’t map neatly to a single line item, I’d group them on a sticky note and try to reconcile the total. Then manually update future months in the model. I wasn’t managing Ops. I was a calculator girl. Ninety minutes, minimum, and that’s if I didn’t make a mistake.

Second, and this was harder and more important, I started surfacing all the nuance I carry in my head that I’d never articulated. Things in finance don’t fit neatly into boxes: “TWILIO SENDGRID” is SendGrid, “BESTCO FRESH FOODS” is Office Snacks, and a subscription billed in another currency will never be the same amount twice because of foreign exchange fluctuations. Our financial model is intentionally alive and approximate. Its job is to show us the state of our finances in a way that’s informed and easy to maintain, not to predict every penny. Reconciliation is about surfacing trends and known changes, not accounting for every cent. But being able to name that – the nuance that makes this process work for this company, this team, at this time – is what made the system I built trustworthy. Models are remarkably teachable, but only if you can articulate what you’re teaching them.

Models are remarkably teachable, but only if you can articulate what you’re teaching them.

That became /expense-recon. The merchant mapping, the classification logic, the rules about which months to touch and which to leave alone – all of it came from me describing how I actually think through the reconciliation. It pulls Ramp transactions, reads the model, matches everything, classifies discrepancies, and presents me with a report. I review, approve, and it executes – updating projections and highlighting every changed cell so I can scan it visually. Five to eight minutes for something that used to take ninety, and measurably less anxiety about my own human error.

Could I automate this fully? Probably, someday. For now, accuracy and judgment on the edge cases matter too much. We’re small and attentive with our budgets, which makes those ten minutes a worthy investment.

Separate judgment from repetition

Expense reconciliation was the annoying one. Cash flow was the scary one.

The question “do we have the cash to cover what’s coming?” always arrives the same way. Something shifts – a deal timeline moves, a payment doesn’t land when expected – and suddenly I need to know, penny-level accuracy, day by day: are we OK? Before I built the tool, answering that meant pulling up the bank, the financial model, and the AR tracker, then doing math across all three while hoping I wasn’t forgetting anything. It’s a whole-day ordeal.

The margin for error here is different. A wrong number in cash flow doesn’t sit quietly in one budget line. It cascades through every future day’s balance. When something is off by a few dollars across dozens of rows, finding where it went wrong is brutal. A few hundred dollars off in absolute terms isn’t the problem – once I’m off, I’ve lost trust in what’s in front of me. And I can’t make an uncomfortable call, internally or externally, based on projections I don’t trust. This was a process that demanded incredible attention, and any lapse had real consequences for our runway.

When something scares me, I build more carefully.

I think harder about what can and can’t change, about where I still need to be in the loop, and about what “wrong” would look like if the system ran without me. That’s an important design input.

Here’s a distinction I keep coming back to: nuance and judgment are not the same thing as repetition. Moving numbers from a bank account into a spreadsheet, making sure all the decimals line up, checking that you updated the right row – that’s repetition, human error’s favorite hangout spot. My judgment is not required for any of that. Judgment is for the unpredictable: the things that don’t pattern-match, the things that require me to actually think and weigh trade-offs, like an unexpected timing change or a new partnership invoice.

So I built /cash-flow. It connects to our bank, our corporate card, and our financial model. It reconciles transactions against projections (tidy now that we have /expense-recon), then builds a day-by-day forward-looking view of every outflow and inflow with a running balance. The core of it is a 245-line patterns file – not code, but everything I know about how our money moves, written down in markdown. Which contractors get paid on the 13th versus the 30th. How cross-country payroll transfers work. What’s seasonal. Every time something changes in how our money moves, I update a line in the tracker and the next reconciliation learns it.

The thing that made me trust it: every time I reconcile, the bank balance in the sheet matches the real bank balance to the penny. The accuracy is higher than anything I could do by hand, because the system doesn’t forget a contractor payment or misremember which day a transfer posts. It’s a robot.

I handle the judgment. It handles the repetition. Neither of us is good at the other’s job.

Automate the remembering

The skills solved “how do I do this.” But they only run when I invoke them. The equally important problem was “how do I remember to do this.” Sending reminders, checking trackers, following up on invoices: same logic every time with a little bit of nuance, and I had so many Asana reminders for all of it that I’ve grown a new fold in the hippocampus trained to ignore them. Let my bot intern handle this.

If I’m late sending an invoice, our client pays late, and I can’t have that depend on whether I remembered to check a tracker this week. So I built an Apps Script that runs every morning at 8 AM, reads our AR tracker, and emails the team with invoices that are ready to send, coming due, or overdue. It tracks what it’s already notified us about so it doesn’t nag about things we’ve already seen. I built a second one for expense processing. On the first business day of each month, it emails the team with the submission deadline. It handles all the calendar edge cases I used to figure out manually and makes sure there are enough business hours for me, the team, and our accountants to get everything done for month-end close.

The first time the AR reminder landed in my inbox at 8 AM, I was making coffee. I felt a flicker of anxiety: something is running without me. But the email was right. The invoices, the statuses, the amounts, all correct. It told me, with no apology, that a client was late. Oh how magical, to have it simply arrive on my desktop, already organized, already prioritized.

The job I actually want

I built all of this by talking to Claude in the terminal. The skill files, the pattern matching logic, the MCP connection to our banks, the Apps Scripts — no traditional coding. I know our finance function deeply enough to tell the machine what “right” looks like, and it builds the thing. The logic in these skills came from me describing how our finance function works, not from writing API routes myself.

I built these systems to save time, and they did. What I didn’t predict was that I’d stop relating to myself as an executor. The parts of the job I used to put off either run on their own or barely need me, and what opened up in that space is the work I actually want to be doing: talking to people, thinking about strategy, helping my teammates build their own tools, participating in the direction of the company in ways I genuinely didn’t have the headspace for before. We’ve all started identifying new areas for growth. We’ve all found a new voice in shaping where the company goes. In part because we have the space for it, and in part because the systems we’ve built make it more visible and easier to participate in.

The systems aren’t done, though. You can’t build a thing and consider it finished. A process is only as good as you follow it and keep it current as the business changes. Some of the time I reclaimed has been eaten back by maintaining these new tools. That’s a real trade-off, and one I think is worth making.

I found more joy in my work by automating the parts I dreaded. The work feels different now. More creative, more mine. I build this version of my job myself, one Friday at a time. Calculator girl, no longer.