Open-source, agent-friendly accounting platform

I'll pull the repo page for concrete product and architecture details so the paragraphs stay factual and don't invent numbers.**getmithril/ledger** landed on Hacker News as an open-source, agent-friendly accounting platform: double-entry bookkeeping exposed as an API, aimed at callers that drive the books rather than people clicking through a UI. The project lives at https://github.com/getmithril/ledger and is licensed AGPL-3.0. It targets a QuickBooks-like surface area—chart of accounts, invoices, bills, payments, credit notes, expenses, bank reconciliation, financial statements, and tax returns—while choosing conventions for machine clients. The HN thread had 2 points and 0 comments at listing time.

Technically, the engine runs on **Convex**. Self-host needs **Node 20+** and `npm run setup`: local backend, org bootstrap with a bearer key (`lk_live_…`), and a Next.js UI under `web/` that talks only to the public API. The first call is meant to be unauthenticated **GET /v1/discover**, which describes the whole API (and carries setup hints). Every document posts through one ledger path; reports are built from journal lines only so the trial balance can tie out regardless of which endpoint wrote the entry. Money is integers in minor units, tax rates are parts per million, and FX rates are scaled integers—no floats. Writes support `?dry_run=true`, **Idempotency-Key** (and often `external_id`) inside the same transaction as the write, structured errors with code/message/hint/field, and accounts addressable by role (e.g. `role:accounts_receivable`) so the same posting logic works across charts. Jurisdiction packs for the US and Switzerland live under `convex/jurisdictions/`; unit tests cover pure arithmetic and packs, and the e2e suite runs full US and Swiss bookkeeping cycles over real HTTP.

For engineers building agent workflows, the design treats the API as both product and documentation: dry runs, safe retries, role-based account resolution, and audit-friendly voids/unmatches reduce the failure modes that show up when an LLM posts books without a human in the loop. Session state is first-class via entity **status**, **entity-doc**, and **overview** endpoints so an agent that forgets between runs still has a carry-over briefing, client todos, and durable narrative context. Evidence can be uploaded as PDFs or attached on the same call that books a bill; extraction is deliberately left to the caller so the engine does not invent vendors or amounts.

In market terms, this sits against closed SaaS ledgers (QuickBooks and peers) that expose partial APIs and UI-first product surfaces, and against ad-hoc “agent books” scripts that skip double-entry, tax packs, and period close. Positioning is self-host first (data stays local under AGPL), with an operator-run EU instance in `eu-west-1` not open to the public yet. The UI is a consumer of the same public API—read-only for writes so far—so integrators and agents share one contract rather than a private back door.

Practical takeaway: clone and run the local path if you need agent-driven books without a vendor account; start every integration at `/v1/discover` and bootstrap, then exercise dry-run and idempotent creates before live postings. Watch for the planned **MCP** surface generated from the route table, bank/Stripe connectors (lines are caller-imported today), document extraction as an optional tool, and more jurisdiction packs—adding a country is the contribution path the maintainers call out as most self-contained.