Belege configuration overview and publishing a version

Belege configuration defines how expense receipts are validated: the thresholds the engine uses and the severity of each rule per Beleg type. Configurations are versioned — you publish a new version to activate it, and you can roll back to a previous one. This article explains the overview and the publishing workflow.

Required permission

Viewing the overview, active version, and version history requires settings:manage. Publishing and rolling back additionally require the SystemAdmin role. Open the area at /admin/belege-configuration.

What a configuration contains

• Thresholds — whether duplicate detection uses the invoice number, plus the mileage deviation tolerance in kilometers and percent.
• Beleg type rules — for each type, the severity of the fuel-type mismatch, missing cost center, missing VAT rate, duplicate detection, and mileage plausibility checks.

Each severity is one of Off (rule disabled), Info, Warning (overrideable with a reason), or Blocking (hard stop). At least one Beleg type must be configured.

Review the active version

1. Open the configuration overview. It shows the currently active version, when it was published, and by whom.
2. Open the version history to see every version, which one is active, and the publishing user and trace identifier for each.

Note: If the overview returns a 503 with "Configuration baseline is not available", the configuration schema has not been provisioned for this environment. Publishing and rollback will also be blocked until the baseline exists.

Publish a new version

1. Prepare the configuration: set the thresholds and the per-type severities.
2. Provide a version label (required).
3. Submit the publish request.
4. On success, the platform deactivates the previously active version, stores the new one as active, and records a publish change event. The response returns the new version identifier and label.

Publishing runs server-side validation first: a version label is required, at least one Beleg type must be present, and every severity must be a recognized value. An invalid severity is rejected with a message listing the allowed values, so a typo can never be persisted.

Tip: Use a clear, incrementing version label (for example a date or a semantic version) so the version history reads as a changelog.

Roll back to a previous version

1. Open the version history and note the identifier of the version you want to restore.
2. Submit a rollback for that version identifier.
3. The platform marks that version active again and records a rollback change event.

A rollback to a non-existent version returns a "Version not found" error.

Warning: Publishing takes effect immediately for all new rule evaluations. Raising a rule to Blocking can stop submitters mid-flow, and lowering to Off disables a check entirely — confirm the impact before you publish.

Related

• Validating configuration before publishing
• Localization and workflow-state label translations
• System configuration overview and access