Understanding the Beleg approval workflow and states
This article explains how a Beleg (receipt/expense document) travels through MobilityManager, the states it can hold, and the rules that decide which actions are available at each step. Knowing the state graph lets you predict what you can and cannot do to any given Beleg.
The seven workflow states
A Beleg always holds exactly one state. The states model a governed review-and-payment lifecycle.
| State | Meaning |
|---|---|
| Draft | Created and still fully editable; not yet submitted. |
| Submitted | Sent for review; header and line items have passed submit validation. |
| In Review | A reviewer has taken it up; quality rules have been evaluated. |
| Needs Clarification | Returned to the submitter with a mandatory note. |
| Approved | Signed off; financially locked and awaiting payment. |
| Rejected | Declined; a terminal state. |
| Paid | Payment confirmed; a terminal state. |
How a Beleg moves between states
Only the following transitions are permitted. Any request that is not on this list is refused and written to the audit trail.
- Draft → Submitted
- Submitted → In Review, Needs Clarification, or Rejected
- In Review → Approved, Needs Clarification, or Rejected
- Needs Clarification → Submitted or In Review
- Approved → Paid
Returning a Beleg to Needs Clarification requires a clarification note; the transition is rejected without one.
Terminal and immutable states
Two related concepts govern what happens at the end of the lifecycle:
- Terminal states — Paid and Rejected. No further transitions are possible.
- Immutable states — Approved, Paid, and Rejected. These reject header, financial, and line-item edits. Approved can still move to Paid, but is otherwise read-only.
Note: Because Approved is immutable, correct any financial data before you approve. Once approved, the record is locked and the only remaining step is Paid.
Two approval modes per company
Each tenant (company) runs one of two workflow modes:
- Review — the full governed flow (Draft → Submitted → In Review → Approved → Paid) with segregation-of-duties (maker-checker) and the configurable rule gates.
- None — a small-tenant mode with no approval flow: submitting a Beleg records it directly as Paid. Data-quality Blocking rules are still enforced at submit, but warnings do not block (there is no human approver to override them).
If the company cannot be resolved, the platform fails closed to Review (the most restrictive mode). Self-approval is separately controlled by a company setting.
What submit validation checks
To leave Draft, a Beleg must have a Vendor (Lieferant) and a Currency, and at least one line item whose description is filled in, quantity is greater than zero, and unit price is not negative. Financial tagging requirements (cost center, tax rate) are enforced later by the rules engine, not at submit.
Permissions
The belege:transition permission is required to submit and to move a Beleg through review. The separate belege:mark-paid permission is required to move Approved → Paid. Every successful transition and every denial is recorded in the immutable audit trail.
Related
- Reviewing Belege in the review queue
- Approving a Beleg and how approval locks the record
- Rule warnings, blockers, and override governance
- Marking a Beleg as paid
