Teaching Claude What Wrong Looks Like

I spend my entire day automating accounting and finance workflows, and the hardest part has nothing to do with the AI.

I'm a Financial Controller. I've been in accounting and finance for about 21 years, I live in NetSuite, and I use Claude and Claude Cowork every day. I've built about 50 Claude skills that cover a big part of our close: balance sheet recs, month end accruals, the CEO month end deck, sales vs prior year, budget vs actual, the 13 week cash forecast and more.

The work is getting the instructions right. Claude is already very good at the reporting. What it doesn't know is what wrong looks like in your books, so you have to teach it.

Here's how we're doing it.

What a skill actually is

A skill is a written procedure Claude follows every time it runs a process. Think desk instructions for a new staff accountant, only a lot more specific. Ours spell out:

1. Where the data comes from (which NetSuite report or saved search, which SuiteQL query)
2. What the output has to look like (tabs, columns, formats, file names, which folder it lands in)
3. What has to tie, and to what
4. What to do when something doesn't tie
5. What it is never allowed to do

That last one ends up being the most important part.

Phase 1: produce what we produce now

When we started automating balance sheet reconciliations we kept the goal simple. Don't reinvent anything. Just produce the rec we already produce, in the same format our team already reviews.

Customer deposits is a good example. High volume liability account, deposits come in at checkout or order entry and get applied when orders ship. The skill opens last month's rec first, before it touches NetSuite. Last month's working paper is the source of truth for everything that's already been researched. It rolls forward from there instead of re-deriving the whole account from history.

It checks that its GL query reproduces last month's balance exactly, then builds the same four tab workbook we've always used. Every open item gets traced to its sales order with expected ship date, actual ship date and cancel date. The variance to GL row has to show $0.00, built with real formulas, not hardcoded numbers.

That's Phase 1. Boring on purpose. If it can't match what a good accountant produces by hand, nothing else matters.

Phase 2: teach it what wrong looks like

Phase 2 is where it gets interesting. Now we educate Claude on what it should be flagging or researching on each account, so it knows what wrong looks like.

Most of that comes from things that actually went wrong. A few real examples:

1. Old items coming back from the dead. An early draft of the deposits rec used a cumulative query to find new items. It dragged back a couple of old balances that had been deliberately excluded the month before. Our accountant caught it because the total looked off. Now the skill uses one query for the GL tie-out and a separate current month only query for new items, with the reason written in so the mistake doesn't come back.
2. Blank customer tags. Some channel activity posts with no customer attached. The skill now reads the memos on that bucket, finds wash pairs that net to zero, and logs what it ruled out instead of carrying them as open items.
3. A passed ship date isn't automatically bad news. The skill doesn't just flag it as overdue. It follows the sales order forward to the fulfillment and invoice and reports what actually happened.
4. Never plug. This one came out of our retirement payable rec. For a long time that rec ended in a true-up. When we sat down and wrote out the math, it turned out one piece of the employer contribution never showed up on any payroll provider report, so it only hit the GL when someone added it by hand. Every so often a plug would clean it up. The skill now proves the balance as an exact identity, payroll by payroll. If the math doesn't close, the rec isn't finished. It reports the gap and stops. Payroll now adds that piece automatically, and the rec is the backstop that catches a miss in the month it happens.

"If the variance isn't explained, the rec isn't finished. Report it and stop."

None of that came out of the box. It's 21 years of knowing where accounts go sideways, written down so a bot can follow it.

A check that can't fail is worse than no check

This is the lesson that surprised me most.

Our 13 week cash forecast had a sanity panel built into the model. One run, nine of ten checks said PASS on a forecast where projected cash-in was way above what those same weeks actually collected the year before. Going through them one by one, half couldn't fail. Each one tested a number against something the model had calculated from that same number.

So we built a separate skill that only audits the forecast and shares no code with it, because an audit that shares code with the thing it audits picks up the same blind spots. Every diagnostic has to prove on historical snapshots that it can both fire and pass before it ships.

"A check that cannot fail is worse than no check, because it launders a bad forecast as a PASS."

That idea now shows up across most of our skills. Ties to $0.00, roll forward checks, duplicate checks. Real checks, not decoration.

Two lanes

When it comes to AI in accounting I think there are two lanes.

The reporting lane is where Claude is very good. Mind blowingly good. The month end CEO deck, the financial statement review files, sales vs prior year and budget vs actual tied to the income statement to $0.00. All read only against NetSuite. On the commentary side we have Claude score its own draft against a rubric, rewrite the weak parts using prior months for context, and propose changes to the rubric itself. I approve or reject those proposals. It doesn't change its own standard without me signing off.

The transactional lane is getting better but there's still work to do. That's anything that posts to the GL. Our journal entry skills are preview first writers. They build the entry and the backup, run a duplicate check and a balance check, and show me the preview. A few of the routine accruals auto-post, but only after those checks pass and only after the backup file has landed where it belongs. The sensitive ones, like payroll, never post without me approving them first.

Preparer and approver

The way I think about it is simple. The bots do the repetitive work. A controller still signs off on every number.

Preparer and approver can't be the same, whether the preparer is a person or a bot. Claude is a really good preparer. It pulls the data, builds the workpaper, ties it out and tells me what looked unusual. I'm still the approver.

What's changed is where my time goes. It saves me somewhere around 20 to 30 hours a month. Less of it is spent building the file and more of it is spent reviewing what the file is telling me.

If you're a small business thinking about this

If you're wondering where to start, here's what I'd tell you:

1. Start with a report you already produce every month, not a brand new one.
2. Make Phase 1 an exact match of today's output. Same format, same tie-outs.
3. Write down every mistake it makes as a rule in the skill, with the reason.
4. Add checks that tie to the GL, and make sure they can actually fail.
5. Keep the reporting lane read only until you trust it. Put a human approval in front of anything that posts.

The first one took me a couple of days to get to something I trusted. Now a new one doesn't take nearly as long, because I've gotten a lot better at it.

A lot of people think everyone already knows this stuff. It couldn't be further from the truth.

That's what we're building Books & Bots Advisory around: bringing this same approach to small and mid-size businesses that want a cleaner, faster close.