Cleared months of neglected books in one sitting with Claude Cowork

I let my company's books drift for months. Claude Cowork cleared the backlog in one sitting - About 1 hour 50 minutes, but the part worth writing up is where it got stuck.

Context. Small agency in India. Zoho Books is our system of record, but I'd only ever entered the "important" stuff - client receipts and vendor payments. Everything else never made it in: bank charges, card spends, freelancer payouts, director drawings. So the bank balance sitting in Zoho and the balance in my actual bank account had drifted a long way apart, and I'd been avoiding it for months.

I gave Claude Cowork my bank statement export and my open Zoho Books tab, and asked it to fix it.

It did the boring part first, which turned out to matter

Before touching anything, it built a reconciliation bridge: the balance Zoho was showing, minus the transactions never entered, plus the opening balance never set, plus one client receipt recorded short, plus one receipt dated wrong, equals the real bank balance. It tied exactly on the first attempt.

That sounds like busywork. It wasn't. It meant there was a hard target to verify against at the end, instead of a vibe. It caught a bug later that I'd otherwise have shipped.

The root causes were all mundane: only a small fraction of the year's transactions were ever entered, the bank account's opening balance in Zoho was left at zero, one payment gateway payout was recorded short, and one receipt was dated eleven days off.

Then the walls

1. Getting the file in. The statement was processed in Claude's cloud sandbox, but Zoho was open in a browser on my machine. Rather than making me download and re-upload, it built the import file and attached it to Zoho's upload control programmatically. Small thing, but it's the kind of gap that usually breaks these workflows.

2. Importing is not the same as posting. Zoho parked every imported line as "uncategorised", and the account balance doesn't move until each line is categorised. So the import reported success and changed absolutely nothing. Easy to declare victory here and be wrong.

3. Bulk categorise caps out, and won't touch equity. Zoho's bulk tool does 50 rows at a time. Worse, director drawings post to an equity account, and equity accounts simply aren't offered in the bulk grid, which killed the obvious approach for the single largest group of transactions.

4. The unlock was rules, not bulk actions. Zoho has Transaction Rules that auto-categorise on import, and those can post to equity. So the real fix was: undo the import, write a handful of description-matching rules, re-import, let the rules do the work on the way in.

5. GST validation, which cost the most time. Rules fired, and every single expense failed with "It is mandatory to apply GST on all expenses." A 0% tax group wasn't enough. Tax Exempt demanded an exemption reason, and the one we created refused to appear in the dropdown. Registered Business demanded a vendor GSTIN we didn't have. The setting that actually works is GST Treatment = Out Of Scope, which drops the entire GST block off the transaction. Nothing signposts that.

6. Rules only fire at import time. Editing a rule doesn't re-run it over rows already sitting there. So every rule fix meant undo the import, fix, re-import. We did that loop twice.

7. A silent duplicate exclusion. Zoho quietly auto-excluded one genuine card transaction as a "duplicate" because an identical amount appeared a few days earlier. It gets parked in a tab you would never think to open. The only reason it was caught is that the reconciliation was expected to tie exactly and it was off by precisely that one transaction.

8. Opening balance semantics. Setting the opening balance made things worse, not better. Turns out transactions dated on the migration date are treated as pre-migration and get overwritten by the opening balance figure. Back-dating the migration date by one day fixed it.

End state: every line categorised, and Zoho's balance matches the bank to the paisa.

What I'd actually take away

  • It was strong on accounting reasoning and relentless on UI grind. The two things I'm bad at, in different ways.
  • It asked instead of guessing on judgement calls — which equity account drawings should hit, whether director pay is an expense or a drawing, whether a regular monthly payee is staff or a contractor. Those aren't lookups, they're decisions, and it correctly treated them as mine.
  • Having a number to verify against changed the outcome. Without the bridge, the silent duplicate exclusion would have sailed through and I'd have been off with no idea why.
  • Most of the elapsed time went to platform quirks, not to the actual work. If you're doing this yourself, the two that will get you are Out Of Scope for GST treatment, and the migration-date-inclusive opening balance.

Happy to answer questions on the rule setup if anyone's fighting the same thing.

reddit.com
u/Fun_Equal_960 — 2 days ago

Thank you to Anthropic

Received ₹10,168.64 in credits as a gift, and it genuinely made my day.

As an indie founder and developer building AI products, every bit of compute matters. Credits like these give builders the freedom to experiment, prototype, and ship ideas without constantly worrying about costs.

A big thank you to the Anthropic team for supporting developers and the broader AI community. Looking forward to building even more with Claude.

Appreciate the gesture!

u/Fun_Equal_960 — 22 days ago
▲ 0 r/aws

US$90,012,031.57 forecasted AWS bill

https://preview.redd.it/xk80lt4qfrdh1.png?width=675&format=png&auto=webp&s=ad1b511bf5b3aa0235588945154ee974ea6fa451

I was terrified, but then Claude analyzed my account using AWS CLI & reported : You didn't misconfigure anything — this is an AWS metering error that's overbilling you by a factor of exactly one billion.

Why it happened

Your account has exactly one RDS resource: a tiny Aurora Serverless v2 PostgreSQL cluster (agent****-data-aurora..., created June 28) holding 45 MB of data. The proof of the bug is a byte-for-byte match:

Source Value
CloudWatch VolumeBytesUsed (actual) 47,333,376 bytes (~45 MB)
Cost Explorer billed quantity (daily) 47,333,376 GB

AWS's billing meter is reading the storage figure in bytes but pricing it as gigabytes — a 10⁹× units error. At Aurora's $0.10/GB-month rate that produces exactly $4,733,337.60/day. The true cost of that storage is about half a cent per month.

Supporting evidence that it's a metering fault, not real usage:

  • The daily charge is flat to the cent for 16 straight days — real storage usage fluctuates; a stuck constant doesn't.
  • 757 PB is physically impossible here — a single Aurora cluster caps at 128 TiB (~0.017% of what's billed).
  • No rogue resources: one cluster, one serverless instance, 7 normal automated snapshots, nothing else in us-east-1.
  • The $9.34M Amplify charge has the same signature (43.5 million "GB" of data transfer for a small marketing site — same units inflation), so it's one metering pipeline fault affecting both services.

Reporting this to AWS support now, hoepfully they'll revoke & resolve this bug.

Anyone else faced this same issue ?

reddit.com
u/Fun_Equal_960 — 1 month ago

Need help retrieving an old DUNS number (India)

Back in 2024, I registered for a DUNS number because it had become a requirement for publishing apps on the Google Play Store and Apple App Store.

The problem is, we never actually ended up using it. Now I need the DUNS number again, but I can't find the original confirmation email, it was probably deleted or misplaced.

I tried looking for a way to retrieve it through the D&B website, but I couldn't find any option for Indian businesses. I also emailed serviceindia@dnb.com a while ago, but haven't received any response.

Has anyone from India dealt with this before?

  • Is there a way to retrieve an existing DUNS number without the original email?
  • Is there a better support channel or phone number that actually gets a response?
  • Or do I need to apply for a new DUNS number altogether?

I'd really appreciate any advice from someone who's been through this

reddit.com
u/Fun_Equal_960 — 2 months ago

Fix one thing, break another : every fix lands in a class that dozens of flows share

One pattern I've been seeing with AI coding agents is this:

They understand the bug well enough to fix the exact line that failed, but they rarely step back and ask, "Where else does this same assumption exist?"

So the reported bug gets fixed, but the root cause remains in multiple other places. A few days later, the same issue pops up again in a different file.

What's even more dangerous is when your test setup isn't actually validating what you think it is. We recently discovered our Jest configuration had been wrong for a long time, so tests were passing while an entire category of issues wasn't being caught at all.

The code looked green. The architecture wasn't.

Another problem - the model is "lazy." It's that it optimizes for making tests pass as quickly as possible, and mocking everything is the shortest path.

reddit.com
u/Fun_Equal_960 — 2 months ago

Hey,

Ran into a frustrating issue today while setting up the MongoDB MCP server for Claude Code and wanted to document the fix in case anyone else hits this.

The Setup

I had this in my .mcp.json:

"MongoDB": {
  "command": "npx",
  "args": ["-y", "mongodb-mcp-server@latest", "--readOnly"],
  "env": { ... }
}

Standard stuff. But the server kept failing to start.

The Error

Running it standalone to debug:

npx -y mongodb-mcp-server@latest --readOnly

Got this:

Error [ERR_MODULE_NOT_FOUND]: Cannot find module 
'/home/.../.npm/_npx/.../ts-levenshtein/dist/index.mjs' 
imported from .../parseUserConfig.js

Did you mean to import "ts-levenshtein/dist/index.cjs"?

Full stack:

node:internal/modules/run_main:107
    triggerUncaughtException(
    ^

Error [ERR_MODULE_NOT_FOUND]: Cannot find module 
'/home/pankaj/.npm/_npx/57c35de36e7d43c4/node_modules/ts-levenshtein/dist/index.mjs'
imported from .../mongodb-mcp-server/dist/esm/common/config/parseUserConfig.js

Node.js v24.6.0

What I Tried First None of it worked.Assumed it was a stale npx cache, tried clearing it Checked if it was a MongoDB Atlas connectivity issue (it wasn't — the server wasn't even starting) Tried a few version flags with npx

Root Cause (Claude's Diagnosis)

Node.js v24 tightened ESM module resolution. The ts-levenshtein dependency that mongodb-mcp-server pulls in only ships a .cjs build, but the package's exports field (or lack thereof) was causing Node 24 to attempt loading .mjs. On earlier Node versions this silently fell back — on v24 it hard-crashes.

The npx path made it worse because it was using a cached install that had the broken resolution baked in.

The Fix

Install globally instead of relying on npx:

npm install -g mongodb-mcp-server@1.10.0

Then update .mcp.json to call the binary directly:

"MongoDB": {
  "command": "mongodb-mcp-server",
  "args": ["--readOnly"],
  "env": { ... }
}

That's it. Global install resolves the dependency tree correctly and avoids the cached broken npx entry entirely.

TL;DR

mongodb-mcp-server@latest via npx crashes on Node.js v24 due to an ESM/CJS mismatch in the ts-levenshtein dependency. Fix: npm install -g mongodb-mcp-server@1.10.0 and switch your MCP config from npx to the direct binary.

Shoutout to Claude Code for diagnosing and fixing this in like 30 seconds flat.

#ClaudeCode #MCP #MongoDB #NodeJS #ESM

reddit.com
u/Fun_Equal_960 — 4 months ago