The category approval workflow
How adding or editing a finance category needs a Finance Manager then CEO sign-off, and why deactivating a category requires an empty vault.
Adding a sub-category to your category register, or changing an existing one, is never a one-click edit. Because a category decides which fund the money lands in, whether the admin fee applies, and how it is reported for Shari'a, every add and edit goes through a two-step sign-off: someone proposes the change, a Finance Manager gives the first approval, and the CEO signs it off. Only when both approvals land does the live register actually change. This article explains who acts at each step, how the chain moves, and the two safety rules that protect your funds — the empty-vault rule and the locked Shari'a class.
Who can do this. Proposing a new category needs a finance role that grants create — typically the Accountant or Finance Manager. Proposing an edit needs update (again Accountant or Finance Manager). Approving or rejecting either step needs approve — the Finance Manager or the CEO. Anyone with a finance read role can see the pending-approvals list. If you don't see the button you expect, your role doesn't include that permission; see Members & roles.
Where to find it. Finance → Categories — the category register. New proposals, the edit dialogs, and the pending-approvals panel all live on this one page.
How the chain works
Every proposed change moves through the same fixed sequence. Proposing does not touch the live register — it files a request that waits for sign-off.
- Anyone with the create or update permission proposes the change (a new sub-category, a new main category, or an edit). The request opens at the Awaiting Finance step.
- The Finance Manager gives the first approval. The request advances to Awaiting CEO. Nothing has changed in the live register yet.
- The CEO signs off — and the change is applied in the same moment, in one database transaction. Only now does the new category appear, or the edit take effect.
A reject at either step ends the chain: the request is marked Rejected and the live register is untouched.
Only one open request per category code is allowed at a time. If a request for that code is already pending, a new proposal is turned away — resolve or wait for the open one first.
Proposing a change
Add a new sub-category
Open the add form
On Finance → Categories, click New category. (You'll only see this if your role grants the create permission.)
Fill in the category
Pick the parent main category. The code is suggested for you as the next free
number under that parent (for example 03.10 under parent 03) — you can override it,
but it must sit under its parent. Enter the Arabic name and English name, and tick
Exempt from admin fee if the 10% deduction should not apply. Optionally restrict
who may spend from this category to specific roles; leave it empty to allow any role
with spending permission.
Give a reason and submit
Enter a Reason for adding — at least nine characters. It is logged for audit. Click Create & send for review. You'll get a Submitted for approval confirmation. The new category does not appear in any picker yet — it is created only once both sign-offs land.
The form checks everything up front: the code must match its parent, the parent must exist, the code and the names must be unique, and the accounting must be set up (a fund and the income account must resolve). If any check fails you are told before the request is even created.
Edit an existing category
Open the edit dialog
In the register, expand the parent and click Edit on the sub-category you want to change. (The Edit button only shows if your role grants the update permission.)
Change what you need
You can change the Arabic name, English name, scope (income / expense / both), the Exempt from admin fee flag, the Active flag, and who may spend from it. Only the fields you actually change are recorded as part of the request.
Give a reason and save
Enter a Reason for the change (at least nine characters) and click Save. You'll get a Submitted for approval confirmation, and the sub-category shows a Pending change badge in the register until the chain resolves.
Approving or rejecting
Approvals happen in the Pending approvals panel near the top of the category register — not inside the edit dialog. Each open request shows its kind (New or Edit), its level (Main category or Sub-category), the code, the proposed values, who proposed it, the reason, and a status badge of either Awaiting Finance or Awaiting CEO.
The Finance Manager step
Review the request
In Pending approvals, find a request marked Awaiting Finance. Check the proposed values, who proposed it, and the reason.
Approve
Click Approve. The request advances to Awaiting CEO and your approval (who and when) is recorded. Nothing in the live register has changed yet.
The CEO step
Open the request
Find the request now marked Awaiting CEO.
Sign off — and it applies
If you are the CEO, click Approve. The request is signed off and the change is applied immediately, in the same transaction: a new category goes live (active, mapped to its fund), or an edit is patched onto the existing one.
Approving on the CEO's behalf
If you are a Finance Manager and the CEO is unavailable, tick Approve on behalf of the CEO. This reveals a justification box, and a non-empty note is required — the approval is blocked without it. The note is saved alongside the approval and flagged as an on-behalf sign-off, so it stays auditable.
There is no separate-person rule here. One Finance Manager may propose a change, give the Finance Manager approval, and then take the CEO step on the CEO's behalf — provided they supply the justification note. This mirrors how expense approvals work: maximum flexibility, with the on-behalf note as the audit trail.
Rejecting
Click Reject on any open request, from either step. The request is marked Rejected with the reason recorded, the proposer is notified, and the live register does not change.
Two safety rules to know
Deactivating a category needs an empty vault
If your edit switches a currently-active category to inactive, its vault — the money settled in it — must be exactly zero first. This stops restricted Waqf or Zakat money from being orphaned in a switched-off category.
- The edit dialog warns you upfront: Deactivation needs an empty vault and FM + CEO approval.
- If your role can't read balances, you are not shown the figure — only that the vault is not empty. (Balances are restricted to the Finance Manager, CEO, and Auditor.)
- The check runs twice: once when you propose, and again — authoritatively — at the moment the CEO approves. If money lands in the vault during the approval window, the change is blocked at apply time and the request is rejected, so the register is never left in a broken state.
The same empty-vault rule applies to a main category: changing its type or deactivating it is allowed only when the combined vault of all its sub-categories is zero, because that operation re-points where the funds sit.
The Waqf / Zakat classification stays locked for sub-categories
A sub-category's Shari'a class — Waqf, Zakat, Sadaqah, and so on — is inherited from its parent main category. You do not set it when you add a sub-category, and you should treat it as fixed for everyday use: it controls hard money rules (which fund donations post to, and whether the admin fee applies).
The edit dialog does expose a Shariah class field, but it exists only to correct a mis-coding, not to reclassify money at will. If you change it, two things happen on approval: the sub-category is re-pointed to the matching fund, and any balance it already holds is moved to the new fund with an audited transfer entry in the ledger — never by quietly editing history. Moving a category out of Waqf carries an explicit warning, because Waqf endowment principal must be preserved; do it only to fix a genuine error.
The fixed main categories (the seeded 01–15 parents) are the backbone of the
register. They can be edited through the same FM → CEO chain, but their type change is
gated by the combined-vault rule above. See
Managing categories for the day-to-day editing
of names, scope, and the fee-exempt flag.
What you'll be notified about
Each transition sends an org-branded email (best-effort — a mail failure never rolls back an approval):
- When a change is proposed, the Finance Managers are notified.
- When the Finance Manager approves, the CEO is notified that it awaits their sign-off.
- When the change goes live (approved) or is rejected (including a blocked deactivation), the person who proposed it is notified, with the reason.
See also
Managing categories
The day-to-day of the category register: adding, editing, names, scope, and the fee-exempt flag.
Ledger accounts
The chart of accounts behind the register and how categories map onto it.
The expense approval workflow
The Accountant → Finance Manager → CEO chain for payment vouchers, including approving on the CEO's behalf.
Members & roles
Which finance roles can propose, approve, or only read changes to the register.