Files
accounted/packs
Mattsson 436cbf5304 fix(skattekonto): route AGI draw back to 2731 to match salary module (#1905)
* fix(skattekonto): route AGI draw back to 2731 to match salary module (#1870)

Migration 20260519160000 moved the skattekonto AGI seed to 2730 while the
salary module kept crediting 2731, splitting the employer-contribution
liability across two accounts that never net at account level (both carry
SRU 7231, so only huvudbok reconciliation exposes the drift). Revert the
system seed to 2731: BAS 2026 defines 2731 as the reported-but-unpaid
arbetsgivaravgift liability (the accrual account is 2940), and the salary
ore-residual logic is built around 2731.

Historical 2730 debits since 2026-05-19 are left for per-company reclass
verifikat; the migration touches the system seed only.

Fixes #1870

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(skattekonto): bump migration version to avoid collision with 20260825120000_create_company_for_user

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(payroll): align remaining 2730 guidance surfaces on 2731 (#1870)

Skeptic regression finding: companies booking salary manually were taught
7510/2730 by in-product guidance, so the seed revert alone would re-create
the #1870 split mirrored for them. Align every guidance surface on 2731:

- packs/loneutbetalning.yaml legal_note
- MCP payroll-monthly skill (booking recipe and rate notes)
- swedish-payroll SKILL.md + references/bas-7xxx.md (2731 convention, 2730
  group-account alternative, never mixed; accrual is 2940) + regenerated
  agent atom seed (skills:generate -> 20260825180001)
- public/docs/systemdokumentation-mall.md

Also addresses the compliance review finding that the swedish-payroll skill
contradicted the migration.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
2026-08-25 19:30:39 +02:00
..

Konteringspaket

Reusable bookkeeping patterns, as data. One YAML file per pattern.

These are the templates a user picks in the app when booking something common: representation, EU-handel, periodiseringsfond, löneutbetalning. They used to be rows frozen inside a database migration. They are files now, so correcting one is a one-line edit and a green CI run instead of a new migration.

Anatomy

meta:
  slug: representation-avdragsgill-25-moms   # filename must match, this is the public key
  order: 13                                  # display order, unique across the catalogue
  name: 'Representation (avdragsgill, 25% moms)'
  category: representation                   # eu_trade | tax_account | private_transfer |
                                             # salary | representation | year_end | vat |
                                             # financial | other
  entity_type: all                           # all | enskild_firma | aktiebolag
  description: >-
    Extern representation med avdragsgill moms. Max 300 kr/person exkl. moms.
lines:
  - account: '6072'                          # BAS account, ALWAYS quoted (it is a string)
    label: 'Representation avdragsgill'
    side: debit
    type: business
    ratio: 0.8
  - account: '2641'
    label: 'Ingående moms'
    side: debit
    type: vat
    vat_rate: 0.25
  - account: '1930'
    label: 'Företagskonto'
    side: credit
    type: settlement
    ratio: 1.0

The three line types

The user types one total amount. The type decides how each line's amount is derived from it (applyTemplate() in lib/bookkeeping/template-library.ts):

Type Amount Carries
vat total * vat_rate / (1 + vat_rate); on fiktiv-moms accounts (reverse charge/import, e.g. 2614/2645) total * vat_rate on top of the base vat_rate, never ratio
business total * ratio ratio, never vat_rate
settlement total * ratio ratio, never vat_rate

settlement is the money leg (the bank account, the reskontra). business is the cost or revenue. Putting a ratio on a vat line silently computes the wrong amount, so the schema rejects it rather than trusting you to remember.

Rules the CI gate enforces

Run npm run validate:packs before pushing. It checks:

  1. The schema, including the vat_rate / ratio split above.
  2. Filename equals meta.slug.
  3. meta.slug and meta.order are unique across the catalogue.
  4. Every account exists in the BAS 2026 chart. A pack may only reference standard accounts, because a non-standard one cannot be seeded into a company's chart and the template will fail to apply.
  5. The pack balances at five probe amounts, applied through the real applyTemplate(). Debits must equal credits or the verifikat cannot post.
  6. Both a debit and a credit line are present.

Account numbers are strings

account: '1930', never account: 1930. YAML would read the unquoted form as a number, and a BAS account is an identifier, not a quantity. The schema rejects it, but quote it anyway so the file reads correctly.

Swedish stays Swedish

name, description and legal_note are user-facing Swedish and are not translated, in either locale. They are statutory content, per .claude/rules/i18n.md.

Known-broken templates

Four packs ported out of the original migration have pre-existing problems (an unbalanced salary template, and accounts that no longer exist in BAS 2026). They are listed in KNOWN_BROKEN in scripts/validate-packs.ts with the reason for each. They are quarantined, not accepted: the list may only shrink, and fixing one means deleting its entry. Each needs a Swedish accounting decision rather than a code change, which is why they were not fixed during the port.

Adding a pack

  1. Copy the closest existing file, rename it to your slug.
  2. Set meta.order to one past the current highest.
  3. Run npm run validate:packs.
  4. New user-facing strings go in the YAML, not in messages/*.json: a pack carries its own Swedish.