Accounts execution
Read the exact action guide for prerequisites, identifier discovery, supported input, effects, captured successful and refused responses, verification and recovery. Synthetic fixture results do not authorize a live mutation or establish a provider outcome.
- List accounts: List the chart of accounts. Filter by type or archived state, search across code, name and description, and sort by code, name, type, subtype or status.
- Create account: Add an account to the chart. Codes are unique per workspace; a sub-account must share its parent's type.
- Get account: Read one account with its type, code and current balance, so a journal line can name it correctly.
- Update account: Change an account's code, name, type, parent, currency or description. Type cannot change once the account has postings; system accounts keep their type.
- Import chart of accounts: Import accounts from a Xero or QuickBooks Online chart-of-accounts CSV export (or a generic code,name,type file). Previews by default (dryRun true): every row is reported as create, skip_existing or error with a reason. Pass dryRun false to create the new accounts; existing accounts are never changed, and codes are generated for rows without one.
- Archive account: Archive an account so nothing new posts to it. Accounts are never deleted; system accounts cannot be archived.
- Restore an account: Bring an archived account back into use, provided no live account holds its code.
- Empty the chart of accounts: Delete every account nothing has been posted to, after literal CLEAR confirmation. Accounts the ledger has touched are kept and named in the response. Use this before a migration: the other system's chart should come across as it stands, because a template applied first collides with it — the same code means different accounts in two charts.
Evidence
Actual Books route handlers and the exported Worker were exercised against five local SQLite D1 concern databases with all committed migrations, the real posting Durable Object and local R2. Route captures use synthetic verified Auth; Worker captures use synthetic Auth transports. Nexus, Brand, Notify, Pay, Mercury and Xero responses are explicitly simulated at the provider transport boundary. Captures prove local request/response behavior and canonical SDK projection, not live bank access, payment movement, email delivery, provider eligibility, tax compliance, encrypted custody, scheduled execution, deployment or production completion. Fixture identities, credentials, addresses and records authorize no live operation.