Reconcile monthly business transactions
Posted on Jun 25. Task: Posted on Jun 25 I run a few small businesses, which means once a month I sit down with a bank export and an accounting platform and turn a pile of transactions into something a tax office will accept. It is the part of self-employment nobody warns you about. The coding is fun. The books are not. So this month I handed the books to Claude Code and watched. The result, up front: it reconciled 200 transactions and miscategorized 11. That is a 94.5% hit rate, which sounds great until you remember that the 11 wrong ones were the difference between a clean filing and a letter from the tax office. This is the story of where the agent shined, where it quietly lied to me, and the exact line I now draw between what it runs and what I sign. The setup: stop asking, start building My first instinct was the obvious one. Paste a CSV into a chat and say "categorize these." I did that for about ten rows before I stopped, because it was the wrong shape of work. A throwaway categorization is a thing you ask for once and then have to babysit forever. What I actually wanted was a process I could re-run next month with a different CSV and trust a little more each time. So I told Claude Code to build the bookkeeping pipeline, not to do the bookkeeping. That distinction matters more than it sounds. When you ask an agent to build the thing that does the work, you get a script you can read, a set of rules you can correct, and an audit trail you can point at later. When you ask it to do the work, you get an answer and a shrug. One is an asset. The other is a chore you now share with a robot. The pipeline it wrote was unglamorous and exactly right: Pull the month's transactions from my accounting platform over an MCP connection. Match each bank row to a receipt or invoice by amount and date. Propose a category for every row, with a one-line reason. Flag anything it was not sure about instead of guessing silently. Step 4 is the one that saved me. More on that in a second. Where the agent earned its keep The reconciliation itself was genuinely good. Matching 200 bank rows against receipts is the kind of tedious pattern-matching that humans are bad at precisely because it is boring. You zone out around row 40 and start rubber-stamping. The agent does not zone out. It correctly handled the cases I expected to trip it: a subscription that renewed on a slightly different day, a refund that showed up as a negative line, a vendor whose name on the bank statement bore no resemblance to the name on the invoice. For the bulk of the month, "AWS-style charge goes to infrastructure, coffee receipt goes to meetings" was handled without me touching anything. This is not a niche experience anymore. A January 2026 Deloitte study found 63% of finance organizations have fully deployed AI somewhere in their operations, and the pattern that keeps winning is the boring one: let the model categorize at volume, then have a human review the output. Machines do the reading, people do the signing. I arrived at the same split independently, which I choose to read as validation rather than as me being unoriginal. The 11 it got wrong Here is the uncomfortable part. The 11 mistakes were not random noise. They clustered in three places, and all three are places where the agent had no way to know what it did not know. Intent it couldn't see (5 rows). A laptop I bought is a business expense if I use it for work and a personal purchase if I do not. The receipt looks identical either way. The agent categorized every device as a business asset because that is the statistically likely call, and for two of them it was wrong. No amount of context in the CSV would have told it otherwise. That information lives in my head. Rules it didn't have (4 rows). Tax categories are not universal logic; they are local law. A meal with a client and a meal alone are deductible to different degrees depending on rules the agent was never given. It made a reasonable, confident, wrong guess. Confidence is the dangerous part. A wrong answer delivered with a hedge is easy to catch. A wrong answer delivered cleanly slides right through. Edge cases that needed a human (2 rows). A single payment that covered two unrelated things, split across categories. The agent picked one. A person would have asked.; tools: Claude Code. Human role: The original post does not say how a person stayed involved.; limitations: The agent cannot infer business intent from receipts alone or apply local tax laws without explicit rules. Confident but wrong answers on edge cases require human review. The workflow depends on accurate receipt data and a reliable MCP connection. Proposed advice: treat the agent as a tireless clerk, not an accountant, and never automate final tax sign-off..
Tools
Published on Agent Work Atlas:
Overview
Posted on Jun 25
Workflow
Posted on Jun 25 I run a few small businesses, which means once a month I sit down with a bank export and an accounting platform and turn a pile of transactions into something a tax office will accept. It is the part of self-employment nobody warns you about. The coding is fun. The books are not. So this month I handed the books to Claude Code and watched. The result, up front: it reconciled 200 transactions and miscategorized 11. That is a 94.5% hit rate, which sounds great until you remember that the 11 wrong ones were the difference between a clean filing and a letter from the tax office. This is the story of where the agent shined, where it quietly lied to me, and the exact line I now draw between what it runs and what I sign. The setup: stop asking, start building My first instinct was the obvious one. Paste a CSV into a chat and say "categorize these." I did that for about ten rows before I stopped, because it was the wrong shape of work. A throwaway categorization is a thing you ask for once and then have to babysit forever. What I actually wanted was a process I could re-run next month with a different CSV and trust a little more each time. So I told Claude Code to build the bookkeeping pipeline, not to do the bookkeeping. That distinction matters more than it sounds. When you ask an agent to build the thing that does the work, you get a script you can read, a set of rules you can correct, and an audit trail you can point at later. When you ask it to do the work, you get an answer and a shrug. One is an asset. The other is a chore you now share with a robot. The pipeline it wrote was unglamorous and exactly right: Pull the month's transactions from my accounting platform over an MCP connection. Match each bank row to a receipt or invoice by amount and date. Propose a category for every row, with a one-line reason. Flag anything it was not sure about instead of guessing silently. Step 4 is the one that saved me. More on that in a second. Where the agent earned its keep The reconciliation itself was genuinely good. Matching 200 bank rows against receipts is the kind of tedious pattern-matching that humans are bad at precisely because it is boring. You zone out around row 40 and start rubber-stamping. The agent does not zone out. It correctly handled the cases I expected to trip it: a subscription that renewed on a slightly different day, a refund that showed up as a negative line, a vendor whose name on the bank statement bore no resemblance to the name on the invoice. For the bulk of the month, "AWS-style charge goes to infrastructure, coffee receipt goes to meetings" was handled without me touching anything. This is not a niche experience anymore. A January 2026 Deloitte study found 63% of finance organizations have fully deployed AI somewhere in their operations, and the pattern that keeps winning is the boring one: let the model categorize at volume, then have a human review the output. Machines do the reading, people do the signing. I arrived at the same split independently, which I choose to read as validation rather than as me being unoriginal. The 11 it got wrong Here is the uncomfortable part. The 11 mistakes were not random noise. They clustered in three places, and all three are places where the agent had no way to know what it did not know. Intent it couldn't see (5 rows). A laptop I bought is a business expense if I use it for work and a personal purchase if I do not. The receipt looks identical either way. The agent categorized every device as a business asset because that is the statistically likely call, and for two of them it was wrong. No amount of context in the CSV would have told it otherwise. That information lives in my head. Rules it didn't have (4 rows). Tax categories are not universal logic; they are local law. A meal with a client and a meal alone are deductible to different degrees depending on rules the agent was never given. It made a reasonable, confident, wrong guess. Confidence is the dangerous part. A wrong answer delivered with a hedge is easy to catch. A wrong answer delivered cleanly slides right through. Edge cases that needed a human (2 rows). A single payment that covered two unrelated things, split across categories. The agent picked one. A person would have asked.
Reported result
The agent reconciled 200 transactions with 11 miscategorizations, achieving a 94.5% hit rate. Errors clustered in intent-based judgments, local tax rules, and split payments, not arithmetic. Seven errors were in the agent's own flagged pile; the remaining four were caught during human sampling. The author notes that AI handled volume while humans handled high-stakes judgment.
Human role
The original post does not say how a person stayed involved.
Limitations
The agent cannot infer business intent from receipts alone or apply local tax laws without explicit rules. Confident but wrong answers on edge cases require human review. The workflow depends on accurate receipt data and a reliable MCP connection. Proposed advice: treat the agent as a tireless clerk, not an accountant, and never automate final tax sign-off.
Try it
I need you to build a reusable bookkeeping pipeline using Claude Code for my small business. Do not just categorize a CSV; create a script I can re-run monthly. The pipeline must: 1) Pull transactions from [replaceable accounting platform] via MCP. 2) Match bank rows to receipts in [replaceable folder] by amount and date. 3) Propose categories with a one-line reason. 4) Flag any row with low confidence or ambiguous intent instead of guessing. 5) Output a CSV with columns: TransactionID, BankAmount, MatchedReceipt, ProposedCategory, Reason, ConfidenceFlag. First, run this on a sample of 10 transactions from [replaceable sample CSV] and show me the output for approval before processing the full month. I will manually review all flagged items and spot-check 5% of unflagged items. Do not post or file anything without my explicit confirmation.
Source reports are not independently verified. Publication date is the catalog publication date, not the original article date.