Featured image of post Before Firing My Bookkeeping Agency, I Sent 134 AI Agents Down the Rabbit Hole

Before Firing My Bookkeeping Agency, I Sent 134 AI Agents Down the Rabbit Hole

Can open-source finance systems plus AI fully replace your contracted bookkeeping agency in China? A 134-agent parallel research run with adversarial verification: 80-90% of bookkeeping is automatable, but filing submission and legal liability have no API. Small-scale taxpayers: 60-75% end-to-end replacement, 2-4 hours/month steady state. Recommended stack: Beancount + e-invoice XML + three-gate LLM pipeline.

Conclusion first: not a 100% replacement — but closer than you’d think. Open source plus AI can take over 80-90% of what a bookkeeping agency does (ledgering, reconciliation, invoice collection and parsing, draft vouchers). But there is one loop no software can ever close: tax filing submission and compliance liability. For small-scale taxpayers, end-to-end replacement is roughly 60-75% at a steady-state cost of 2-4 hours a month. One sentence: the ledger can be open source; filing cannot; liability cannot be outsourced to software.

I pay my bookkeeping agency a bit over 200 RMB a month, and what I get in return is having to ask permission every time I want to look at my own books. As someone who self-hosts everything, this question has bugged me for a long time: can I just do it all myself?

This time I didn’t answer from vibes. I spawned 134 parallel AI agents across five research tracks (open-source project audit, tax compliance boundaries, AI stack, fit analysis), then sent 3 adversarial verifiers per key claim specifically to try to refute them — six claims that sounded perfectly reasonable died in that round, and I’ll show you which ones.

Why 100% Is Impossible: Three Hard Boundaries

Boundary one: the filing gate. The official filing channels available to small businesses are effectively the e-Tax Bureau web/app, the individual income tax withholding client, and the annual industry-commerce reporting system — all requiring a real-name authenticated tax officer, with mandatory face recognition for invoice operations. The e-Tax Bureau itself is highly automated — 96 million taxpayers, 97% of tax matters online, 86 pre-filled items, 90% of filings done within 3 minutes (official figures) — but that automation dividend belongs to the web portal itself, not exposed via any API.

There is one exception: the LeQi direct-connection API, which includes filing and payment capabilities and went live in 2025 (104 enterprises in Beijing, including JD’s 1000+ entities). But admission depends on revenue, invoice volume, and A/B tax-credit ratings — the threshold is on the order of “50M RMB+ annual revenue and 50,000+ invoices or 5B RMB in billed amount.” One rumor died in verification here: the “50M/50,000 is a unified national threshold” claim was refuted 3:0 — those numbers come from provincial guidance documents, not national policy. Either way, small businesses are effectively excluded for the foreseeable future.

So-called “fully automated tax filing software” on the market comes in exactly three forms: the LeQi channel (institutional access), RPA mimicking the web portal (gray market, relying on account lending and face-rec spoofing), or — a human clicking submit for you.

Boundary two: centralized e-invoice control. Since 2024-12-01, fully digitalized e-invoices are rolled out nationwide. Invoicing goes through the free e-Tax Bureau channel, with quota dynamically controlled by the tax system. The invoice verification platform has no public API, and the open-source verification projects (InvoiceSpider 128★, inv-veri 54★) are all abandoned — automation there risks captchas and IP bans.

Boundary three: the structural asymmetry of liability. Bookkeeping is a licensed, regulated business. I queried the 12366 tax-professional-service disclosure API live (2026-09): 133,425 registered bookkeeping agencies, each with a TSC credit rating. Every open-source project surveyed disclaims liability. The legal responsibility for truthful filings always stays with the taxpayer: agencies share it, software doesn’t. No software replaces that layer.

The Open-Source Landscape: Who Can Actually Keep Books?

ProjectStarsAccounting depthChina localizationVerdict
Odoo (accounting)54,550Deep, native invoice OCRl10n_cn chart; golden-tax needs paid modulesMost mature, China tax costs money
ERPNext39,510Full double-entry + 3 statementserpnext_china plugin (81★, stale)Best standard ledger, heaviest ops
Beancount+Fava6,029+2,579Most rigorous plain-text double-entrychina_bean_importers (157★)Best AI-pipeline foundation
Akaunting10,134Shallow-mediumNoneBSL 1.1, commercial distribution restricted
jshERP4,609Cash-flow only, no vouchers/ledgerNative ChinesePopular, not real bookkeeping
JinBooks73Chinese-style vouchers, month-end closeNativeRight concept, tiny community

One hard detail: a full-code grep of jshERP’s HEAD commit (2026-09-24, same day) for “filing/invoicing/e-invoice/tax-control/e-Tax Bureau” hits zero — it’s inventory plus cash flow. Meanwhile the initial claim “jshERP has been unmaintained for two years” was also refuted 3:0; it had a commit that same day.

Replacement rates by taxpayer type
Layered replacement rates (end-to-end)|Data: this 134-agent research run

Can LLMs Do Accounting? A Maturity Map

The most counterintuitive part — data first:

LLM double-entry benchmarks
Raw LLM voucher accuracy|Data: Beancount LLMFinLiteracy (2026-06) and Modern Treasury evals

  • Raw LLM generating double entries: unreliable. Beancount’s official LLMFinLiteracy benchmark (2026-06): 7B-class open models get only 2.3% fully-correct end-to-end (7 of 300) — the syntax compiles, the accounting reasoning is wrong. Frontier models in Modern Treasury’s eval do far better (Gemini 3 perfect, Opus 4.5 at 15/16), yet even the perfect ones require full human review in practice. “Compiles but semantically wrong” is the biggest risk.
  • What’s actually mature: e-invoice XML parsing (the biggest dividend in the whole chain — more below), mailbox invoice collection (Invoice-Downloader, 438★), Beancount itself, PaddleOCR (90,140★) infrastructure, Alipay/WeChat statement import (double-entry-generator, 720★).
  • Half-mature, needs self-build: corporate bank statement parsing (no ready templates), reconciliation matching (the top GitHub project is a 14★ teaching exercise), LLM Chinese chart-of-accounts classification (nearly blank — both risk and opportunity).

Why e-invoice XML is the biggest dividend: the native data form of a fully-digitalized invoice is an XML file with a tax digital signature; PDF/OFD are just layout renderings. GB/T 44554.2-2025 allows XML as the archiving format, and mailbox delivery is officially supported. That turns the old OCR-hard problem of “recognizing invoices” into “parsing XML” — zero recognition error, locally verifiable signature. Point all your invoices at one dedicated mailbox and your document pool builds itself.

Component-level, for a low-invoice software/services micro-business:

  1. Ledger core: Beancount (plain text, git-versioned) + self-hosted Fava for review
  2. Collection: one dedicated mailbox for all invoices, IMAP scripts fetch PDF/OFD/XML
  3. Parsing: XML direct-read (zero error + signature verification); OFD via ofdrw (1,877★); pure images only then go through RapidOCR → VLM structured extraction
  4. Entry generation: the LLM only outputs account suggestions + narrative + tax-rate judgment; entries are assembled by deterministic code templates (special-VAT input → debit expense + input tax / credit payable), the LLM never touches amount math; bean-check enforces debit-credit balance and rejects anything unbalanced; invoices deduplicated by sha256
  5. Bank statements: corporate CSV → rule matching (amount + date ±3 days + account name), LLM fuzzy-match for the long tail, month-end balance assertions
  6. Scheduling: Windmill daily collection + month-end close on the 1st; review diffs pushed to Telegram; entries posted only after human approval
  7. Filing terminus: manual submission on the e-Tax Bureau web portal — the single non-API-able link in the chain, ~10 minutes for a zero-filing quarter

The alternative, head-to-head: Odoo Community vs ERPNext (source-level verified 2026-09-24)

DimensionOdoo 18 Community + l10n_cnERPNext v16 + China fork
Chinese chart of accountsOfficial, two sets (small-enterprise ~30 accounts / general 100+, auto-installed)Built-in China COA unusable (82 accounts, no codes, “unverified”); best patch = NolanZONG fork (190 coded accounts, single maintainer, 0 stars)
VAT templatesOfficial (13% / small-scale)NolanZONG fork (13/9/3/1/0%, special-vs-ordinary taxpayer)
Chinese-format financial statementsNone (enterprise’s aren’t either); fix = OCA account_financial_report + mis_builder, or CLuedoo’s $251 China Reports moduleNative none; NolanZONG fork has balance sheet / income statement (account-code mapping + omission checks) / direct-method cash flow
Bookkeeping vouchersNative QWeb voucher PDF with RMB amount-in-words (cn2an); account.move has a fapiao field19 journal entry types, no Chinese voucher format
E-invoice / golden-tax integrationZero (0 hits in the official app store for 数电票/电子税务局/金税)Zero (0 GitHub hits; ERPNext e-invoice integrations cover Malaysia/EU/Saudi — China is the one blank)
Invoice OCRCommunity has none (enterprise IAP-locked); free third-party apps exist, OCA/ai can plug Ollamainvoice2erpnext (37★) is European-format + paid API, unsuitable for Chinese invoices
Multi-company / multi-ledgerBasic multi-ledger works; consolidation & inter-company locked to the $40.90/user/mo Custom tier (≈3,900 RMB/yr)Strongest natively: multi-site isolated ledgers + multi-company + consolidation + cost centers, no plugins
Deployment footprint~0.5-1.5GB RAM + PostgreSQL; official Docker mature4GB RAM minimum (8GB recommended) — 3-8x Odoo’s
Major-version upgradesOfficial upgrade service closed to Community; OCA OpenUpgrade grind, medium-hardOne major version yearly, patch migrations can fail; needs downtime + rollback plan
Customization curveStudio low-code entry; ORM/inheritance/module-conflict deep waterDocType stack steeper (full Python+Jinja+JS), but rule-shaped tasks like bookkeeping become predictable once learned
LicenseLGPL-3, own modules can stay closed, lighter commercial obligationsGPL-3, whole system must open-source if distributed
China community ecosystemOCA l10n-china branches 12.0-19.0 are all empty shells (effectively dormant); GoodERP dead since 2020saoxia fork (81★) is CRM/HR localization, stalled; the financially-fullest NolanZONG is 1 person, 11 commits

Piecing both pictures together, the interesting finding isn’t “which is better”: the China compliance layer is broken in both ecosystems — they just break in different shapes. Odoo ships “half a foundation from the vendor (COA + taxes + vouchers) with everything above ground missing”; ERPNext has “the strongest financial kernel (double-entry, multi-company, native multi-ledger) but even the foundation must be salvaged from a one-person fork.”

The decision rules fall out cleanly:

  • Special-VAT invoices, fundraising due diligence, or external audits within 2 years → Odoo Community + l10n_cn: the vendor-maintained COA and voucher printing are the only “backed” pieces, and accounting firms can read them
  • One person managing several micro-businesses with fully isolated ledgers → ERPNext’s multi-site/multi-company is native and plugin-free; but you must accept forking and maintaining the NolanZONG one-person fork yourself
  • Purely managing your own money, tiny invoice volume → the Beancount main plan still wins (a fraction of the resource footprint, git-native audit trail)

E-invoice ingestion is zero on both sides — self-build either way, but the shared part already exists: erma0/fapiao-print (160★, MIT, active) parses e-invoice XML <EInvoice> and OFD, and that layer is base-agnostic. The deeper base comparison (jshERP’s 35 CVEs, Odoo’s marketing modules) is in my other post, “Open-Source Accounting Bases” — the two pieces complement each other.

Migration in Four Steps (switch at a period boundary; year-end is best)

  1. Handover (1 week): formally request closing trial balance, general ledger, past filings, backups, unresolved items; sign a handover confirmation
  2. Initialization (1-2 weekends): convert balances into Beancount opening assertions; park discrepancies in a “pending investigation” account and clear them one by one; archive historical ledgers in git
  3. Parallel run (one quarter): downgrade the agency to filing-only while you cross-check their filings against your own books
  4. Steady state: terminate the contract, reclaim tax-officer access; calendar the filing deadlines — after leaving the agency, nobody catches your misses, and even zero-filing must be filed

When to Give Up on Self-Building

Six deal-breaker signals, any one of which means go back to outsourcing: upgrading to a general taxpayer (mandatory above 5M RMB in rolling 12-month sales); more than 50 invoices/month; external audit or due diligence needed; hiring employees (IIT withholding + social insurance become monthly hard flows); a tax warning or audit; your hourly value exceeding the agency fee.

Two red lines regardless of build-vs-outsource: under Golden Tax IV, dual books, private-account revenue concealment, and filing/invoicing/bank-flow divergence all trigger automatic alerts (case: an auto reviewer fined 2.47M RMB for concealing 10M+ income); and LLM “compiles but wrong” entries must pass three deterministic gates — balance check, tax-rate legality, invoice verification — with human sign-off recorded.

The Cost Math

Agency market rates (secondary sources, directional only): small-scale 150-300 RMB/month, general taxpayer 400-600. Self-build: software cost ≈ 0; the real cost is labor — 2-4 hours/month steady state, 2-3x in year one, plus 0.5-1 day for annual settlement. Pure economics: if your hour is worth more than 300 RMB, outsourcing still wins. What self-build buys isn’t just savings but data sovereignty — a ledger you can query anytime, git-auditable, instead of asking permission every time.

The hybrid model is the safe start: downgrade the agency to filing-only, run the open-source stack for internal books and the invoice pool, keep the books yourself while the filing liability stays outsourced.

Methodology and the Claims That Died

Honest disclosure: five parallel tracks plus adversarial verification. These claims were refuted 3-0 and removed from the conclusions — “there are only three official filing channels” (LeQi is a fourth); “LeQi is the only direct channel with unified national thresholds” (provincial guidance, not national); “Company Bao’s 2,400 RMB/year is the market baseline” (unreliable anchor, so rates here are directional only); “jshERP unmaintained for two years” (committed the same day). The 90%+ rate for fixed-quota sole proprietors is a directional estimate without independent research; e-Tax Bureau operating figures are government self-reported.

This isn’t an article telling you to fire your bookkeeper. It’s a map: where the road is already flat (XML parsing, plain-text ledgers), where the walls are (filing APIs, verification endpoints), and the one door in the wall that opens for large enterprises (LeQi). The walls won’t stand forever — LeQi thresholds are falling, e-invoices are spreading, and LLM accounting reasoning is climbing up from 2.3%.

2-4 hours a month for a ledger that lives in my own hands. For me, the math works.


Method: 134 parallel AI agents (grok-deep-research + four specialist tracks + 18 three-lens adversarial verifications). Open-source data verified via gh CLI on 2026-09-24; the 12366 agency registry figure is a same-day live API query. Refuted-claim details in the methodology section.