Approval Workflows
This course covers multi-level approval (tier validation) workflows in Quickenerp: defining who must approve a journal entry or vendor bill before it posts, how reviewers approve/reject, and requiring a specific per-vendor approver on bills.
| Responsible | System |
|---|---|
| Last Update | 07/21/2026 |
| Completion Time | 1 day 6 hours |
| Members | 1 |
From Draft to Posted
Requesting Validation
- Create the journal entry/vendor bill as normal.
- Click Request Validation — Quickenerp checks every configured tier's domain and creates a pending Review for each tier this record actually matches.
- The record cannot be posted until all required reviews are approved.
Reviewing
A reviewer sees pending reviews assigned to them (and notifications, if enabled). They can:
- Approve – moves to the next tier in sequence, or clears for posting if it was the last.
- Reject – sends it back; the requester must address the issue and request validation again.
Auditability
Every review — who approved/rejected, when, and any comments — is logged on the record's chatter, giving a permanent audit trail of who signed off on every entry that required it. This is exactly the kind of evidence an external auditor or the Journal Audit Trail screen (Finance Insights course) looks for.
Best Practices
- Keep thresholds meaningful — requiring approval on every tiny entry trains people to rubber-stamp without really reviewing.
- Make sure a reviewer group always has at least one active member — a tier pointing at an empty/inactive user blocks posting indefinitely.
- Review your tier definitions periodically as thresholds/organisational structure change — a stale rule set is either too strict (bottlenecking normal work) or too loose (no longer catching what it should).
Approval Workflows Overview
View allFrom Draft to Posted
Requesting Validation
- Create the journal entry/vendor bill as normal.
- Click Request Validation — Quickenerp checks every configured tier's domain and creates a pending Review for each tier this record actually matches.
- The record cannot be posted until all required reviews are approved.
Reviewing
A reviewer sees pending reviews assigned to them (and notifications, if enabled). They can:
- Approve – moves to the next tier in sequence, or clears for posting if it was the last.
- Reject – sends it back; the requester must address the issue and request validation again.
Auditability
Every review — who approved/rejected, when, and any comments — is logged on the record's chatter, giving a permanent audit trail of who signed off on every entry that required it. This is exactly the kind of evidence an external auditor or the Journal Audit Trail screen (Finance Insights course) looks for.
Best Practices
- Keep thresholds meaningful — requiring approval on every tiny entry trains people to rubber-stamp without really reviewing.
- Make sure a reviewer group always has at least one active member — a tier pointing at an empty/inactive user blocks posting indefinitely.
- Review your tier definitions periodically as thresholds/organisational structure change — a stale rule set is either too strict (bottlenecking normal work) or too loose (no longer catching what it should).
Building Your Approval Rules
Go to Settings > Technical > Tier Validation > Tier Definitions (developer mode) → Create.
Defining a Tier
- Model –
account.movefor journal entries/vendor bills. - Definition Domain – a filter deciding which records need this tier (e.g. only vendor bills over a certain amount, or only entries in a specific journal).
- Reviewer – a specific user, or a Reviewer Group (any member of the group can approve).
- Sequence – if a record needs multiple tiers, this sets the required order (e.g. Finance Manager first, then CFO).
- Notify Reviewer – whether the reviewer gets an automatic notification when their review becomes due.
A Typical Setup
- Vendor bills under a threshold: no tier required, posts normally.
- Vendor bills over the threshold: Tier 1 requires the Accounting Manager.
- Vendor bills over a much higher threshold: Tier 2 additionally requires the CFO/Owner.
Per-Vendor Approver
Beyond amount-based tiers, set a specific Approver directly on a vendor's contact record — enabling Require Approver in Vendor Bills (Settings) means every bill from that vendor specifically needs that named person's sign-off, regardless of amount. Useful when one person owns the relationship with a particular supplier and should always see their invoices before payment.
Requiring Sign-Off Before Something Posts
For journal entries and vendor bills above a certain size, or matching other risk criteria, many businesses require one or more people to formally approve before the entry can post — a real internal control, not just a courtesy notification. The Tier Validation framework lets you define exactly which records need review, by whom, and in what order.
Core Concepts
| Concept | Description |
|---|---|
| Tier Definition | A rule: which records need this review step (via a domain/condition), and who the reviewer(s) are. |
| Review | One reviewer's pending or completed approval on a specific record. |
| Sequence | The order tiers must be satisfied — a record can require several tiers, approved one after another. |
This same underlying mechanism can apply to more than journal entries/vendor bills — anywhere it's configured, the pattern (define who reviews what, then request/review/approve) is identical.