Jakob WennbergandClaude Opus 5
4a38fa30ed
PR #1295 (144cc514) fixed computeVatCloseCheck on main while this branch was
fixing it a second, different way. This rebuilds the branch on top of that
merge instead of re-landing the duplicate: main's local
getScopedReconciliationStatus stays as the MCP entry point, its lookup body
moves into lib/reconciliation/cash-account-scope.ts, and the pieces main does
not have are added on top.
Why the lookup has to live in lib/: the bokslut readiness aggregator has the
same defect and is core code, which must never import from @/extensions/. It
called getReconciliationStatus with 4 positional args, so cashAccountId stayed
undefined and scopeTransactionsToAccount fell through to its currency-only
filter: the bank side summed every SEK cash account while the GL side stayed on
1930, and the wizard reported "Bankavstamningen visar en differens" with zero
unmatched transactions and zero unmatched GL lines to point at. Same shape as
the MCP blocker in #1290, different surface.
Decisions taken deliberately, not by taking 'ours':
1. Lookup errors fail CLOSED, everywhere. resolveCashAccountScope throws
"Kunde inte hamta kassakonto <n>" instead of returning the unscoped
fallback. The earlier version on this branch logged and fell back, which
turned a transient DB error or an RLS denial straight back into the #1290
pooling path. Main's contract wins; its merged test asserting exactly that
still passes untouched.
2. The default resolution no longer hard-codes 1930. With no account_number
argument the resolver tries 1930 and, only if the company has no such row,
falls back to its primary cash account. Measured read-only on prod
2026-07-30: 2 companies have no 1930 cash_accounts row while running two SEK
cash accounts each and zero journal_entry_lines on 1930, so the check
compared their entire SEK bank volume against an empty GL side, i.e. a
high-severity bank_unreconciled blocker with count 0 that no user action
could clear. Roughly 20x the difference the issue reported. A caller that
NAMES an account gets no fallback, so gnubok_get_reconciliation_status still
rejects "Okant kassakonto 9999" rather than silently answering about a
different account. 1367 companies have a 1930 row and are unaffected,
including the 5 whose 1930 row is not the primary one.
3. The blocker message names the resolved account instead of a literal 1930:
pointing a user at 1930 when the reconciliation ran on 1935 sends them to an
account with no lines on it.
4. warnIfUnscopedAcrossCashAccounts logs a warning when a run left
cashAccountId undefined AND the rows it fetched really do span more than one
cash account. Kept on the write path too: an unscoped runReconciliation can
persist a wrong journal_entry_id, which does not clear itself later.
Duplicate regression suite collapsed: the branch's
vat-close-check-bank-scope.test.ts overlapped main's
vat-close-check-reconciliation-scope.test.ts case for case, so only the cases
main lacked were merged into main's file (the primary-account fallback, the
message naming the resolved account, the blocker still firing on a genuine
scoped difference, and the tool handler's own scope resolution).
Residuals are now tracked issues, not code comments:
- #1298: the post-sync runReconciliation sweeps in
app/api/extensions/enable-banking/sync/cron/route.ts and
extensions/general/enable-banking/index.ts still run unscoped. They are write
paths.
- #1299: booked transactions with a NULL cash_account_id whose verifikat has no
line on the primary account still inflate the bank total. Measured all-time
on prod: 294 booked NULL rows, 22 of them on verifikat with no 1930 line,
4 companies, net -4170.31 kr with monthly swings from -18055.82 kr to
+38086.00 kr. Fixing it means finishing the cash_account_id backfill.
Also: the file-global logger mock in bank-reconciliation.test.ts now wraps the
real module and swaps only warn, instead of substituting a four-method stub
whose child() returned undefined for the entire module graph of that suite.
Verified: npx vitest run over lib/reconciliation, lib/bokslut,
extensions/general/mcp-server, app/api/reconciliation, app/api/extensions,
app/api/v1, app/api/bookkeeping, app/api/transactions, lib/pending-operations,
lib/bookkeeping, lib/invoices, lib/transactions, lib/reports: all green.
eslint on the 8 changed files: 0 errors (18 pre-existing unused-import
warnings in server.ts). tsc --noEmit: 405 errors, byte-identical to the
origin/main baseline. check:guards passes. No migration, so no pg-real test.
Fixes #1290
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Accounted
Open-source Swedish accounting software for sole traders (enskild firma) and limited companies (aktiebolag). Double-entry bookkeeping that complies with Swedish accounting law, built to be operated by you or by your AI agent.
Website · Hosted app · Documentation
Why Accounted?
Compliant by construction. Accounted implements double-entry bookkeeping under Swedish accounting law (Bokföringslagen). Voucher immutability, sequential voucher numbering, period locks, and 7-year document retention are enforced by database triggers, not by convention. Corrections are made the legal way, with reversal entries (storno), never by editing history. See ARCHITECTURE.md for how.
Agent-native. The full bookkeeping engine is exposed as 100+ MCP (Model Context Protocol) tools with scoped API keys, so an AI agent can do the books in Accounted: categorize transactions, draft vouchers, reconcile periods, and prepare declarations. Posting is staged for human approval, so the agent proposes and you decide.
Yours to run. AGPL-3.0 licensed and fully self-hostable with Docker and Supabase. Use the hosted version at app.gnubok.se or run your own.
Features
- Double-entry bookkeeping -- BAS 2026 chart of accounts, draft/commit workflow, sequential voucher numbering
- Invoicing -- Create, send, and track invoices with mixed VAT rates and PDF generation
- Bank reconciliation -- PSD2 bank connection via Enable Banking, 4-pass automatic matching
- VAT declaration -- SKV 4700 form mapping, per-rate breakdown, EU/export handling
- Tax reports -- NE-bilaga, INK2, SRU export for Skatteverket
- Payroll -- Salary runs, payslips, and AGI (arbetsgivardeklaration) employer declarations
- Supplier invoices -- Registration, payment tracking, input VAT deduction
- Document archive -- SHA-256 integrity, 7-year retention enforcement, full archive ZIP export
- SIE import/export -- Standard Swedish accounting interchange format
- Agent access (MCP) -- 100+ bookkeeping tools over the Model Context Protocol, with scoped API keys and staged approvals
- Extension system -- Opt-in plugins for AI categorization, receipt OCR, email, calendar, and more
Self-Hosting
git clone https://github.com/erp-mafia/accounted.git
cd accounted
./setup.sh # Prompts for Supabase credentials, generates .env
docker compose up -d
You need a Supabase project and must apply the database migrations before first use. See docs/SELF-HOSTING.md for the full step-by-step guide, including Supabase setup, auth configuration, optional features (AI, email, push notifications), and troubleshooting.
Development Setup
Prerequisites: Node.js 20+, a Supabase project.
npm install
npm run dev # Start dev server (auto-generates extension registry)
npm test # Run tests
npm run build # Production build
npm run lint # ESLint
See CONTRIBUTING.md for the full development workflow.
Tech Stack
- Framework: Next.js 16 (App Router), React 19, TypeScript (strict)
- Database: Supabase (PostgreSQL + Row Level Security + email/password auth + TOTP MFA)
- Styling: Tailwind CSS 4 + shadcn/ui
- Integrations: Enable Banking (PSD2), Anthropic SDK, LangChain, OpenAI, Resend, JSZip
Documentation
- User and API documentation -- Guides for using the product and the public API
- ARCHITECTURE.md -- How the system is built: bookkeeping engine, legal enforcement, tenancy, extensions, agent surface
- docs/SELF-HOSTING.md -- Full self-hosting guide (Docker, Supabase setup, migrations, optional features)
- docs/EXTENSIONS.md -- Extension development guide
- docs/DOCKER.md -- Docker deployment reference
- CONTRIBUTING.md -- Development workflow, code style, pull request process
- SECURITY.md -- Vulnerability reporting policy
Community
- Found a bug or have an idea? Open an issue
- Security vulnerabilities: see SECURITY.md, never a public issue
- Everyone interacting in the project is expected to follow the Code of Conduct
Contributing
Contributions are welcome. See CONTRIBUTING.md for the full guide.
All commits require a DCO sign-off (git commit -s).
License
AGPL-3.0-or-later with an extension exception: third-party extensions that interact solely through the documented Extension API may be licensed under any terms, including proprietary. See LICENSE for details and NOTICE for third-party attributions.