GL Posting Approval

GL Posting Approval controls when a prepared GL batch can post immediately and when it must stop for review first.

Navigation: Accounting -> Setup -> GL Posting Approval

Workspace Reference

Workspace	How Users Reach It	What Users Usually Do There
GL Posting Approval	Accounting -> Setup -> GL Posting Approval	Configure approval chains, approval policies, authority limits, and pending GL approval review.
Back-Office Posting	Accounting -> Operations -> Back-Office Posting	Submit manual postings that may route through GL approval.
GL Journals	Accounting -> Operations -> GL Journals	Review approved, rejected, failed, posted, or pending accounting batches.
Roles And Users	Administration -> Access	Confirm approvers have the required roles, permissions, and business unit scope.
Fiscal Periods And Posting Rules	Administration -> Financial Setup and Accounting -> Setup	Confirm approval does not mask invalid periods, accounts, sub-ledgers, or rule details.

What This Workspace Controls

Use GL Posting Approval to define:

• Who can approve GL batches.
• Which postings require approval.
• Which preparer roles can post directly up to a limit.
• What happens to batches waiting for approval.

Approval does not replace accounting validation. A batch must still pass posting-date, period, rule, account, amount, and sub-ledger validation before it can be posted.

Workspace Areas

Area	Purpose
Approval Chains	Define who approves and in what order.
Approval Policies	Define which posting situations require a chain.
Authority Limits	Define how much a preparer role may post directly.
Pending Approvals	Review, approve, reject, or return submitted GL batches.

Approval Chains

An approval chain defines the approver path.

Common patterns:

• One senior finance approver.
• Branch accountant then branch manager.
• Finance reviewer then controller.
• Any one person from a senior approval role.
• Multiple approvers in parallel for high-risk batches.

Chain Fields

Field	Meaning	User Impact
Chain Name	Business name of the chain.	Shown in setup and approval traces.
Chain Type	Sequential, parallel, or any-one approval.	Controls whether approvers act one after another, together, or only one approver is enough.
SLA Hours	Expected turnaround time.	Helps teams monitor stale approvals.
Description	Purpose of the chain.	Helps administrators choose the right chain later.
Active	Whether the chain can be used.	Inactive chains should not be selected by live policies.

Chain Step Fields

Field	Meaning	User Impact
Step Order	Position of the step.	Important for sequential chains.
Role	Approver role.	Users with that role can approve the step.
Specific User	Optional named approver.	Restricts approval to one user where needed.
Business Unit Scope	Same, any, or specific business unit.	Controls whether approval must come from the same branch/unit.
Specific Business Unit	Chosen unit when scope is specific.	Limits approval to that unit.
SLA Hours	Step-level turnaround time.	Overrides the chain default for that step.
Can Delegate	Whether delegation is allowed.	Useful when approvers may be absent.
Mandatory	Whether the step must complete.	Non-mandatory steps may not block completion in supported chain designs.

Approval Policies

An approval policy decides when a GL batch should route to an approval chain.

Examples:

• High-value manual journals.
• Backdated postings.
• Future-dated postings.
• Reversal batches.
• Cross-business-unit batches.
• Batches affecting sensitive accounts.
• Batches that could create abnormal account balances.

Policy Fields

Field	Meaning	User Impact
Policy Name	Business name of the policy.	Helps administrators identify why a batch routed.
Priority	Evaluation order.	The first matching high-priority policy normally controls routing.
Approval Chain	Chain used when the policy matches.	Determines who must approve.
Business Unit Scope	Optional unit filter.	Limits the policy to a branch, service, or unit where configured.
Description	Purpose of the policy.	Helps future administrators maintain it.
Active	Whether the policy is live.	Inactive policies do not route batches.

Policy Conditions

Conditions describe when a policy applies.

Common condition examples:

• Total amount is greater than a threshold.
• Currency is a specific currency.
• Source is manual posting.
• Journal date is backdated.
• Posting touches a selected account.
• Posting touches an asset, liability, income, expense, or equity category.
• Posting has a sub-ledger.
• Posting is cross-business-unit.

Condition Groups

Use condition groups when a policy needs multiple checks.

Examples:

• Amount is above UGX 10,000,000 and source is manual.
• Posting is backdated or future-dated.
• Account category is cash and preparer role is teller.

Use AND when all conditions must be true. Use OR when any condition can trigger the policy.

Condition Fields

Field	Meaning
Condition #	Visual reference used inside the form.
Attribute	The posting attribute to check, such as amount, currency, source, account category, or date behavior.
Comparison Operator	How to compare the attribute, such as equals, greater than, between, in list, or is empty.
Group Operator	AND or OR for grouping conditions.
Parent Group / Condition	Places a condition under a group.
Value	The comparison value. The form may show text, number, lookup, select, or multi-select depending on the attribute.
Sort Order	Display and evaluation order for clarity.

The UI should guide the value field. For example, amount conditions use numbers, currency conditions use currency choices, and account conditions use account lookup choices.

Authority Limits

Authority limits define how much a preparer role can post directly when no approval policy has already routed the batch.

Use authority limits for simple ceilings, such as:

• Tellers can post up to a small amount.
• Branch accountants can post up to a medium amount.
• Finance managers can post larger batches without extra review.

Use approval policies when routing depends on context, not just amount.

Authority Limit Fields

Field	Meaning
Role Type / Role	Which preparer group the limit applies to.
Maximum Amount	Largest amount that can post directly.
Currency	Currency for the limit where applicable.
Business Unit Scope	Whether the limit is global or unit-specific.
Active	Whether the limit is currently enforced.

If a user exceeds their direct-posting limit and no policy routes the batch, the batch should stop with an authority-limit message.

Pending Approvals

Use Pending Approvals to review GL batches waiting for action.

Typical actions:

• Approve: allows the batch to continue posting.
• Reject: stops the posting and records the reason.
• Return: sends the batch back for correction or clarification.
• View History: reviews the approval timeline.

Approvers should review:

• Source and narration.
• Amount and currency.
• Posting date.
• Business unit.
• Journal lines.
• Accounts and sub-ledgers.
• Rule or policy that caused approval.
• Any warnings or validation notes.

Policy Priority

Priority matters. If multiple policies could match, the highest-priority matching policy should be the one that routes the batch.

Good practice:

• Put narrow, high-risk policies first.
• Put broad fallback policies later.
• Avoid duplicate policies that match the same scenario with different chains.
• Test policies with realistic batches before relying on them.

Common Mistakes To Avoid

• Do not create approval chains without linking them to active policies.
• Do not leave sensitive policies inactive after setup.
• Do not create broad policies that accidentally route every posting.
• Do not rely only on amount limits when date, source, account, or abnormal-balance risk also matters.
• Do not allow the same maker-checker user to both prepare and approve where policy requires separation.
• Do not approve a batch without reviewing failed warnings or abnormal-balance indicators.

Troubleshooting

Problem	What To Check
Batch did not require approval	Policy inactive, condition did not match, priority routed elsewhere, or authority limit allowed direct posting.
Batch routed to the wrong chain	Policy priority or condition overlap is wrong.
Approver cannot see the batch	Role, business-unit scope, or user assignment does not match the chain step.
Batch cannot post after approval	Accounting validation still fails, often due to account, sub-ledger, period, or rule setup.
Too many batches require approval	Policy conditions are too broad or authority limits are too low.

Related Pages

• GL Posting Rule Details
• Posting Dates and Periods
• Back-Office Posting
• GL Journals