AI for finance teams, without access to move money

AI for finance teams is the case where an assistant is most useful for the least access, and that is an unusual and convenient thing to be able to say.

The reason is the shape of the questions. Nearly everything finance asks an assistant to do is a lookup that spans systems which do not talk to each other. Did this payment clear. Who is still holding a seat on that expensive tool. Which direct debits failed overnight and why. What did order volume look like on this channel last month. All reads, all across two or three systems, all currently done by exporting a spreadsheet and joining it by hand.

Nearly none of it requires the ability to move money, and that gap is the whole design.

Step one: what AI for finance teams should reach, read-only

Four categories cover most of it.

• The accounting system. QuickBooks or Xero. The record of record, and the one where a write is most expensive to unwind.
• The payment processor. Stripe most often, and whatever handles direct debits alongside it.
• Spend and card management. Ramp or Bill, for what is being spent and by whom.
• The seat and subscription surface, which in most companies is several tools rather than one, and is where the recoverable money usually is.

Connect each one once, by whoever owns that system, and share it with finance. If the vendor offers a read-only credential, use it, because a constraint enforced by the vendor is worth more than the same constraint enforced by you.

If you run Gusto or another payroll system, hold it back and decide on it separately. It is the highest-sensitivity data most companies hold, and the questions asked of it are narrow enough that an assistant adds less than it does elsewhere.

Step two: block the operations that move money

The rules here are easier to write than in most teams, because the line is unusually clear.

Block outright:

• Refunds and payment cancellations
• Payment approvals and releases
• Anything that creates or voids an invoice
• Journal entries and anything touching the chart of accounts
• Deleting or merging a customer or vendor record

Leave open:

• Reading payments, charges, payouts and their statuses
• Reading invoices, bills and their aging
• Reading transactions, receipts and categorizations
• Listing seats, users and subscription state
• Reporting endpoints of every kind

The principle: if the operation has an approval workflow around it, it does not belong behind an assistant. Not because the assistant would get it wrong, but because routing it through a second path bypasses the control rather than applying it. The value in that area is telling a person which four payments failed and why, quickly, so the retry happens sooner. The retry itself should stay where the approval lives.

The mechanical reason this holds: a blocked tool is never advertised. The model does not see a refund tool in its list, so it cannot propose one, and there is no instruction for a persuasive conversation to override.

Step three: freeze the entity

If you run more than one legal entity, more than one currency, or a sandbox alongside production, this step is not optional.

The failure is quiet. Somebody asks for last month's revenue during close, the tool reports on the wrong entity, the number is plausible, and it goes into a deck. Nothing errors. Nobody notices until a reconciliation later.

Freeze the entity or organization argument on each shared tool. The parameter disappears from what the model sees, so it cannot be set or guessed, and the value is forced at execution, so it cannot be overridden by passing it.

If finance genuinely needs to work across entities, make that explicit: one shared tool per entity, each frozen, each named for the entity it reports on. More tools, and each one is unambiguous, which during close is worth more than brevity.

Step four: look at the tool list

Have somebody in finance open their client and read the tool list they receive.

A restricted tool is not advertised, so that list is the exact answer to what this team can reach. It takes half a minute and it is the step that finds the mistake.

The specific mistake to look for: an allow rule that names nothing denies everything. Create an allow rule, save it before filling it in, and the team's list is empty for a reason that looks like a bug. Checking from their side is how you catch it before they report it.

What finance actually asks it

Four shapes that come up constantly.

The seat audit. List every account on an expensive tool, compare it against the people who should have one, and flag the rest. This is the one that pays for the project. Most companies are carrying seats for people who changed teams a year ago, and nobody runs the comparison because it means exporting two lists and joining them by hand.

Checking a payment before reconciling. Look up a payment by its identifier and read back the amount and status, so you know whether it was captured, cancelled or refunded before closing the books. Small, constant, and exactly the kind of lookup that costs four minutes and three tabs.

Chasing failed direct debits the same morning. Ask which payments failed overnight and why, and which of those have a mandate still active. The answer arrives before the customer has noticed, which is the difference between a retry and a support conversation.

Pulling numbers for the weekly report. Order statistics across a date range, volumes by channel, summarized without an export. Reporting endpoints are almost always read-only, which makes this the safest useful thing on the list.

More of these, by team and by connector, are on what teams do with Elaichi.

The seat audit, in more detail

Of everything on that list, the seat audit is the one worth setting up first, because it pays for the project in the first month and it needs nothing but read access.

The shape of the problem is familiar. You pay per seat on a dozen tools. People change teams, projects end, contractors finish, and nobody tells the person who owns the subscription. The comparison that would catch it means exporting a user list from each tool, exporting a current roster from the HR system, and joining them by hand, per tool. So it happens annually at best, usually during a cost review, usually after the renewal.

With the tools connected it is a question rather than a project: list the accounts on this tool, compare against the people who should have one, and tell me the difference. All reads. Nothing is revoked automatically, and it should not be, because the output is a list for a person to act on rather than an action.

Three refinements once it is working.

Include last activity where the vendor exposes it. A seat held by somebody who is still employed but has not signed in for six months is a different conversation from a seat held by somebody who left, and both are worth having.

Run it before renewal, not after. The saving is only available at the renewal date, so the useful cadence is driven by contract dates rather than by the calendar quarter.

Keep the comparison list somewhere durable. The answer to who should have a seat on a given tool is real institutional knowledge, and it is usually in somebody's head. Writing it down once turns a recurring investigation into a recurring check.

Two things specific to finance

Segregation of duties still applies, and the assistant does not change who is doing the thing. If your controls say the person who enters a payment cannot approve it, that control is about people. An assistant acting for the person who enters payments is still that person. It does not become a second party by being software, and treating it as one is how a control gets quietly voided. The read-only default sidesteps most of this, which is another reason to start there.

Period-end is when people ask for exceptions. Somebody will need a write during close, urgently, and the temptation is to widen the team's rules for an afternoon. Widening for one person is a person-level rule, and it replaces the role's rules for them completely rather than layering on them, so it has to restate what still applies. That is more work and it is the right kind: the exception is a readable statement of what that person can do, and it does not quietly widen the team when somebody forgets to undo it. Note also that it takes about two minutes to take effect, so do not write it thirty seconds before it is needed.

The order

Connect read-only. Block the money movement. Freeze the entity. Check the list from a finance seat.

Then wait. The requests that arrive in the first month are the real requirements, and they will be narrower than anything you would have designed in advance. Grant the second one only when somebody asks for the same write twice.

The reasoning behind the rules is in how the restriction rules work. What a reviewer will ask for afterwards is in producing audit evidence for agent access. The support version of this post, which has a very different risk profile, is your support team in Claude.