LedgerLou Config

The central place for API keys, tenant master data, user access, and tax codes. Permissions are granted, settings maintained, and the configuration basis for REST and MCP kept clean here.

API Reference

API keysProgrammatic access with scope control

Scope-basedFine-grained permissions per key

Tenant master dataCompany name, address, tax number

Users & rolesInvite, assign roles, remove

Owner-only for writeWrite access requires the owner role

What the Config module covers

API key lifecycle — Create, list, and revoke API keys. Each key receives an individual scope combination across the 5 modules (journal, bank, perioden, auswertungen, config) at creation. The key value is displayed only once and is then stored hashed.

User management — Owners can invite additional users by email and assign them a role (member or admin). Existing users can be removed. All actions are recorded in the audit log.

Tenant master data — Company name, address, tax number, USt ID, and legal form can be maintained here. Write access to tenant master data is only allowed via browser session for owners, not via API key.

Tax codes — Tenant-specific tax keys for lightweight VAT automation are also managed as a Config resource. Reading is via config:read, creating and changing via config:write.

OAuth clients — OAuth 2.0 clients can be registered for third-party integrations. This is an advanced feature for developers and partners.

Access methods

Dashboard (UI)The primary path for Config tasks: create API keys, invite users, and maintain tenant data — all in settings.

REST APIRead Config data; manage API keys and tax codes. Only tenant master data remains deliberately browser-session-only.

Tax codes

Tax codes are the light configuration layer between raw journal lines and everyday VAT logic. They allow posting lines to be tagged with tax_code while LedgerLou adds the required tax lines deterministically.

What a tax code defines

the key itself, e.g. VSt19 or VSt-igE19
the percentage rate
the input-tax or output-tax account
optionally a counter account for self-assessment / reverse charge

When posting with tax_code, the journal line is expanded before validation and pairing:

Standard case: gross is split into net + tax on the same side
Self-assessment: the original line remains net; a balanced tax pair is additionally generated

Supported cases

Case	Supported	Behavior
`VSt19`, `VSt7`, `USt19`, `USt7`	Yes	Standard split on the same posting side
Intra-Community acquisition / §13b with `self_assess_account`	Yes	Net line stays; a balanced tax pair is added
Manual tax lines + `tax_code` in the same booking	No	Request is rejected
`FX + self_assess`	No	Request is rejected

Examples

Purchase with `VSt19`

POST /v1/bookings
{
  "booking_date": "2026-04-09",
  "description": "Bürobedarf",
  "lines": [
    { "account_number": "6815", "account_name": "Bürobedarf", "debit": 119, "credit": 0, "tax_code": "VSt19" },
    { "account_number": "1800", "account_name": "Bank", "debit": 0, "credit": 119 }
  ]
}

Result in the journal:

6815 -> 1800 for 100.00
1406 -> 1800 for 19.00

Both lines carry tax_code = "VST19" in the journal.

Intra-Community acquisition with `VSt-igE19`

POST /v1/bookings
{
  "booking_date": "2026-04-09",
  "description": "Innergemeinschaftlicher Erwerb",
  "lines": [
    { "account_number": "5200", "account_name": "Wareneingang", "debit": 100, "credit": 0, "tax_code": "VSt-igE19" },
    { "account_number": "1800", "account_name": "Bank", "debit": 0, "credit": 100 }
  ]
}

Result in the journal:

5200 -> 1800 for 100.00
1404 -> 3804 for 19.00

What remains deliberately separate

The journal request remains explicit: tax_code is optional; raw manual tax lines are still possible
DATEV BU keys or UStVA derivation are not generated automatically from the code

Scopes

Config endpoints have no review action — only read and write:

config:readconfig:write