I keep hearing the same complaint.

Recently I heard about an accountant who connected Claude Cowork to his accounting system. He dropped in a bank statement and the general ledger, asked it to match transactions, flag anomalies, propose journal entries. Then said: “It’s too slow. It has to re-learn the vendor mappings every time. I can do this much faster on my own.”

I hear this and I already know what went wrong. Not with Claude. With the setup before Claude.

I’ve built invoice and reconciliation workflows on top of e-Boekhouden, Mollie, and QuickBooks. The difference between fast and slow is almost never which model you use. It’s whether the data underneath is structured before the model ever sees it.

If your vendor names are inconsistent across invoices — “Acme BV”, “Acme B.V.”, “ACME” — the model has to guess every time. If your chart of accounts isn’t mapped to your suppliers, it starts from scratch every session. If transactions arrive raw with no normalization, you’re asking the model to do data cleaning and matching at the same time.

That’s expensive. Slow. And it keeps breaking.

The approach that actually works: build the integration layer first. Connect your payment processor, your invoicing system, your bank. Normalize the data. Map the vendors. Create a staging table where transactions land before they go anywhere.

Once that foundation exists, the AI part is fast. Not because the model got smarter — because it finally has clean inputs to work with.

There’s a rule I follow before bringing AI into any accounting workflow: build the system that feeds it first. The model is the last step, not the first.

Garbage in, garbage out is not a new idea.

It just becomes more frustrating when you paid for Claude and it’s still not working.