---
title: "Approval Workflow"
description: "Draft, review, approve, post: how every invoice, bill and journal is checked by someone other than its preparer before it reaches the ledger, on every plan."
url: "https://bareledger.app/guides/approval-workflow"
category: "Team, roles & approvals"
updated: "2026-11-06"
publisher: "BareLedger (Syneria Technologies OPC)"
---

# Approval Workflow

> How a record travels from Draft to Posted, who does what at each stage, and how reversals work.

Journal entries, invoices, credit/debit notes, bills, vendor credits, expenses, payments, payroll runs, customer-credit applications and refunds — and **employee onboardings** — all move through the **same** approval sequence: **Create → Review → Approve → Post**. Nothing reaches the ledger until it has been created by one person, reviewed by a second person, and approved by a third.

```
Draft ──Submit──► Submitted ──Review──► Reviewed ──Approve──► Posted
           │                     │
           └────────Reject───────┴──► back to Draft (with a comment)
```

## What each stage means

| Stage | Meaning | Who can perform the action |
|---|---|---|
| **Draft** | Being written; not part of the books. | Anyone with **Preparer** access (or higher) on that page creates drafts. Most documents — invoices, bills, credit/debit notes — can be reopened and edited while still a draft; journal entries, expenses, and payments can't be edited after saving (see those pages). |
| **Submitted** | Handed over for checking; no longer editable. Submitting requires the entry to balance (and documents to have a valid total). | The preparer submits; everyone who can review is notified. |
| **Reviewed** | A first checker has looked it over and passed it on for final approval. | Anyone with **Reviewer** access or higher — except whoever prepared it. |
| **Posted** | Approved and written to the ledger in the same instant — approval and posting are one action, so you'll never catch a record sitting at "approved". | Anyone with **Approver** access or higher — except whoever prepared it **and** whoever reviewed it. The accounting period must be open. |
| **Rejected** (action, not a stage) | Sends a Submitted or Reviewed item back to Draft. A comment explaining why is **required** — it is what tells the preparer what to fix and what an auditor reads later — and the full history is kept. | From Submitted: anyone with review access or higher; preparers can also reject their own submission to pull it back. From Reviewed: only someone with **Approver** access or higher — once a record has passed review, a reviewer can no longer bounce it. |

Stages can't be skipped — trying to approve something that hasn't been reviewed yet fails with *"This action is not allowed while the entry is 'submitted'."*

## The rules around the flow

- **Three different people: the three-person rule.** The person who creates a record, the person who reviews it, and the person who approves it must all be different people.
  - **You can never check your own work.** Whoever prepared a record cannot review it or approve it. Attempting it fails with *"You prepared this entry and cannot review it."*
  - **The reviewer can't also approve.** Whoever reviewed a record cannot be the one who approves it — a different approver must. Attempting it fails with *"You reviewed this … and cannot also approve it."* The review screen hides the buttons you're not allowed to use and shows a short note explaining why.
  - This applies to everyone, including the organization owner and administrators, and no combination of roles or permissions gets around it.
  - **Practical consequence: you need at least three active team members** to get anything posted. A one- or two-person organization can create and review records but can't complete approvals until a third person joins (the Free plan includes 5 users; every sign-in counts, employees included).
- **This applies on every plan**, including Free — there is no setting that turns the approval flow off and no one-step shortcut. Even entries the system prepares for you (month-end currency revaluation, the year-end closing entry) wait for a reviewer and a different approver.
- **Extra security codes**: by default, the review step and the approve step each require a fresh 6-digit authenticator (2FA) code. Reversals require one too — the same code step also protects completing or reopening a bank reconciliation. These are three separate organization settings (review / approve / reverse), all **on** by default. A user who hasn't enrolled 2FA is blocked with a message telling them to enable it in Security first.
- **Notifications**: submitting notifies everyone who can review; a completed review notifies everyone who can approve; posting or rejection notifies the preparer. If something's been waiting a while, the preparer can send an immediate nudge with **Notify reviewers**/**Notify approvers** on the record itself, instead of waiting for the automatic reminder your administrator may have configured (Settings → Workflow reminders).
- **Comments are permanent.** Any comment left while reviewing or approving is appended to the record's workflow history — it can never be edited or deleted, survives rejection and resubmission, and appears alongside the approval trail in the record's History panel and in the workflow emails.
- **Employee onboardings follow the same flow with two twists**: the "preparer" is whoever sent the invitation (so the inviter can't review or approve), and rejecting doesn't go back to a draft — it *returns the form to the invited person* with your comment and a fresh link so they can fix and resubmit. Approval creates the employee record and their sign-in, or adds the Employee role to an existing member's sign-in. See [Employees & Onboarding](https://bareledger.app/guides/employees-onboarding).
- **Plan limits are checked at approval.** If your organization has used up its monthly transaction allowance, approval is refused and the record stays at Reviewed until the limit frees up or the plan is upgraded.

## Amount-based approval thresholds (optional)

Administrators can define **approval thresholds** per module — journal entries, invoices, bills, expenses, and payments — where amounts at or above a boundary must be checked by holders of specific roles. For example: under 50,000 the regular review roles apply, but 50,000 and above must be reviewed by the Senior Accountant role and approved by a Director. When a threshold applies, review/approval additionally requires holding the specific role named in the threshold; having review/approve access alone is not enough, and **administrators are not exempt** (only the organization owner is). Failing the check shows *"Amounts of this size require the '…' role to approve."* Amounts are compared in your organization's base currency. With no thresholds configured, nothing changes — the ordinary flow above applies. Quotations and sales orders have no review/approve step, so thresholds never apply to them.

## Reversing something that's already posted

Posted records aren't edited or deleted — they're **reversed**. Only a **maker** — a Staff (Preparer-level) user or an Accountant (Full access) — can request a reversal; the Reverse action is not offered to reviewers, approvers, administrators or the organization owner, whose job is strictly oversight. Requesting a reversal creates a mirror-image entry that goes through the same Draft → Submit → Review → Approve flow as everything else; the original stays Posted until the reversal itself posts, at which point the original is marked **Reversed**. As with any record, the requester, the reviewer and the approver must be three different people. A reversal draft is deliberately not editable — it mirrors the original by design, so if it needs changing, delete the draft and request the reversal again.

## Quotations and sales orders are different

Pre-sale documents never touch the ledger, so they don't use this workflow. They follow their own lifecycle — Draft → Sent → Accepted (or Declined/Expired) → Converted — and only the invoice created from them enters the approval flow above.


## Employee profile changes

When an employee edits their own profile, it becomes a request that follows the same review → approve chain (with the same authenticator step-ups). It's applied only once approved, and a request whose fields changed on the record in the meantime can't be approved — return it instead. See [Employee Profile](https://bareledger.app/guides/employee-profile).