LedgerLou Periods

The Periods module governs when postings are allowed and when they are not. It is the operational guardrail for clean monthly and annual closings.

API Reference

Monthly periodsIntervals in YYYY-MM format, created automatically

Status controlOpen → Soft-Lock → Lock — clearly defined transitions

Write protectionLocked periods block new postings

Closing qualityStable reports through immutable periods

ReopeningSoft-Lock can be lifted selectively for exceptions

Adjustment periods P13/P14Additional periods for year-end adjustments after the regular period

Non-calendar fiscal yearPeriods are created starting from the configured start month

API & MCPFully controllable via API and MCP

Status model

Every period has a clearly defined status that determines whether and how postings are allowed.

openYesNormal operation — postings are possible without restriction.

soft_lockedRestrictedPreliminary close — late postings only as exceptions.

lockedNoFinal close — no more postings possible.

Workflow

Period is openThe current month is open. Postings run normally. Status can be queried via API or dashboard.

Soft-Lock at month-endAfter the monthly close, the period is set to soft_locked. New postings require explicit clearance — prevents accidental late postings.

Exception: reopeningNecessary late postings can be selectively allowed. Scope perioden:write required. Every exception is documented in the audit log.

Lock request (four-eyes principle)A user creates a lock request (POST …/lock). The request is valid for 48 hours and can be aborted at any time.

Approval & final lockA second user approves the request (POST …/approve). Only then is the period finally set to locked — irreversible and GoBD-compliant. For tenants with only one user, self-approval is allowed.

Adjustment periods (P13/P14)

Many companies need one or two additional posting periods after the regular year-end month for audit and closing corrections. LedgerLou supports these as P13 and P14 — also known as year-end adjustment periods or supplementary periods.

Concept

P13 and P14 are additional periods that use the same calendar month as the fiscal year-end (e.g. December for a January–December fiscal year), but can be locked independently of the regular December period:

Period identifier	`period_number`	Purpose
`2025-12`	`0`	Regular December postings
`2025-P13`	`13`	First adjustment period (e.g. year-end adjustments)
`2025-P14`	`14`	Second adjustment period (e.g. after auditor clearance)

This way the regular December period can already be soft_locked while year-end adjustments are still being made in P13 — and P14 serves for a second correction pass if needed.

Assigning postings to P13/P14

A manual posting is assigned to the corresponding adjustment period via the optional adjustment_period parameter:

POST /v1/bookings
Content-Type: application/json

{
  "booking_date": "2025-12-31",
  "description": "Jahresabschlussbuchung AfA",
  "adjustment_period": 13,
  "lines": [
    { "account_number": "6220", "account_name": "AfA Sachanlagen", "debit": 5000, "credit": 0 },
    { "account_number": "0820", "account_name": "Maschinen", "debit": 0, "credit": 5000 }
  ]
}

If adjustment_period is omitted, the posting lands in the regular monthly period (period_number = 0).

Write protection in P13/P14

The database trigger check_period_lock() has been extended: for a posting with adjustment_period = 13, it only checks the lock status of the P13 period — not that of the regular December period. Regular postings (without adjustment_period) remain entirely unaffected by adjustment periods.

This enables the following typical closing flow:

Close December regularly (2025-12 → soft_locked)
Make year-end adjustments in P13 (P13 is created automatically)
Lock P13 after the tax advisor’s review (2025-P13 → locked)
If needed, use P14 for final auditor corrections (P14 is also available automatically)

P13/P14 available automatically

Adjustment periods are created automatically — once regular periods exist for a fiscal year, GET /v1/periods provides P13 and P14 for that year. A manual creation step is not required.

Non-calendar fiscal year

LedgerLou supports fiscal years that do not start in January. The tenant’s fiscal_year_start value (1–12) controls two behaviors:

Period seeding during onboarding: When creating a new tenant, 24 months from the configured start month are created — no longer a blanket January through December. For a tenant with fiscal_year_start = 5 (May), for example, 2025-05 through 2027-04 are created.

DATEV export: The fiscal year start field in the DATEV posting-batch header is set from fiscal_year_start. A tenant with start month May receives 0501 in the header, not a hardcoded 0101.

fiscal_year_start is requested during onboarding and can be adjusted later via PATCH /v1/tenant.

Access methods

Dashboard (UI)View period status, set or lift soft-lock and lock directly in the dashboard. P13/P14 are provided automatically.

REST APIRead periods and drive status transitions programmatically — e.g. automated monthly close via script or service.

MCP (AI agents)AI agents can query periods, set and lift soft-locks. Hard-lock is only available via API/dashboard for security reasons.

MCP tools

Via MCP, AI agents have access to the following period tools:

Tool	Scope	Description
`get_periods`	`perioden:read`	List all periods with status, posting count, and P13/P14
`soft_lock_period`	`perioden:write`	Set a soft-lock (reversible)
`reopen_period`	`perioden:write`	Lift a soft-lock

Period identifier format

Format	Example	Meaning
`YYYY-MM`	`2025-12`	Regular monthly period (`period_number = 0`)
`YYYY-P13`	`2025-P13`	First adjustment period (`period_number = 13`)
`YYYY-P14`	`2025-P14`	Second adjustment period (`period_number = 14`)

Scopes

Reading requires perioden:read; write operations require perioden:write.