GL Posting Rule Details

Rule details are the individual debit and credit lines within a GL posting rule. Each detail line specifies which account to hit, how to determine the amount, and how the account is resolved.

Navigation: Administration → Accounting → GL Posting Rules → Select a rule → Details

What Is a Rule Detail?

When a GL posting rule fires, it creates a balanced journal entry. Each detail line in the rule becomes one line in that journal entry — either a debit or a credit.

Example: Loan Disbursement Rule

Line	Type	Account	Amount
1	DEBIT	Loan Receivable (resolved per borrower)	Loan principal
2	CREDIT	Cash/Bank (resolved per payment channel)	Loan principal

The debit and credit totals must always balance.

Detail Line Fields

Each rule detail line has these key properties:

Field	Description
Line Type	DEBIT or CREDIT
Detail Nature	How the COA account is determined (see below)
COA Account	The GL account (for STATIC nature)
Tag Key	The system tag used to resolve the account (for TAG_RESOLVED)
Amount Source	How the amount is calculated
Percentage	For FIXED amount source — the percentage of the reference amount
Fixed Amount	For FIXED amount source — a fixed monetary amount
Dynamic Handlers	Optional resolver bindings for system-calculated details
Resolver Scopes	Optional limits on which accounts may be selected or resolved
Description	What this line represents

Detail Nature Types

The detail nature determines how the system resolves which GL account to use:

STATIC

The COA account is hardcoded on the detail line. The same account is used every time the rule fires.

When to use: Simple rules where the account never changes (e.g., Interest Income always goes to the same COA).

Rule: LOAN.INT.ACCRUE
  DR: STATIC → Interest Receivable (COA 1310-110) — 100%
  CR: STATIC → Interest Income (COA 4110-110)     — 100%

TAG_RESOLVED

The COA account is resolved dynamically using a system tag. The tag maps to different COA accounts depending on the business unit, currency, or configuration.

When to use: Rules that need to be portable across business units or currencies without modification.

Rule: FEE.CHARGE
  DR: TAG_RESOLVED → tag: FEE_RECEIVABLE  → resolves to COA per BU
  CR: TAG_RESOLVED → tag: FEE_INCOME      → resolves to COA per BU

DOMAIN_RESOLVED

Both the COA account and amount are resolved by a handler procedure — a stored procedure registered for the specific domain (loans, deposits, etc.).

When to use: Complex operations where the domain logic determines which accounts and amounts to use (e.g., disbursement routing to cash vs. bank based on payment method).

Rule: LOAN.DISBURSE
  DR: DOMAIN_RESOLVED → handler: hdlr_loan_receivable_resolve
  CR: DOMAIN_RESOLVED → handler: hdlr_cash_bank_resolve

INFO

DOMAIN_RESOLVED is the most powerful but also the most complex nature. It requires handler procedures to be registered in the gl_dynamic_handler_registry and bound to the detail line via gl_detail_handler_binding.

Dynamic Handler Bindings

Dynamic handlers are the bridge between a rule detail and the domain logic that knows how to calculate the final posting lines.

Use handler bindings when:

• The final account depends on the product, payment route, or business event
• The amount is calculated from domain data rather than copied directly from the posting amount
• The detail is meant to be executed in SYSTEM mode

General expectations:

Detail Nature	What You Usually Provide
STATIC	Fixed COA and fixed or manual amount
TAG_RESOLVED	Active system tag and optional resolver scope
DOMAIN_RESOLVED	Approved handler binding and SYSTEM amount source

For manual rules, avoid attaching handler bindings unless the detail is explicitly designed for system resolution.

Amount Sources

The amount source determines how the monetary amount for each line is calculated:

Source	Description	Used With
FIXED	A fixed percentage of the transaction amount	STATIC, TAG_RESOLVED
MANUAL	The user enters the amount during posting	STATIC (manual rules only)
SYSTEM	The handler procedure calculates the amount	DOMAIN_RESOLVED
SUM_OF_OTHERS	Calculated as the sum of other detail lines	Balancing lines

FIXED Amount Source

The most common source. You specify a percentage (typically 100) and the system calculates:

line_amount = transaction_amount × (percentage / 100)

For a 100% fixed line on a $10,000 loan disbursement, the line amount is $10,000.

MANUAL Amount Source

Used only for manual/back-office posting rules. The accountant enters the amount when creating the journal entry.

SYSTEM Amount Source

Used with DOMAIN_RESOLVED nature. The handler procedure determines both the account and the amount based on domain-specific logic.

Creating Rule Details

1. Open a GL posting rule header
2. Click Add Detail Line
3. Fill in the form:

Field	Description	Required
Detail Name	Descriptive name for this line	Yes
Line Type	DEBIT or CREDIT	Yes
Detail Nature	STATIC, TAG_RESOLVED, or DOMAIN_RESOLVED	Yes
COA Account	The GL account (if STATIC)	Conditional
Tag Key	The resolution tag (if TAG_RESOLVED)	Conditional
Amount Source	FIXED, MANUAL, SYSTEM, or SUM_OF_OTHERS	Yes
Percentage	Percentage of reference amount (if FIXED)	Conditional
Dynamic Handlers	One or more handler bindings (if DOMAIN_RESOLVED)	Conditional

4. Submit

Resolver Scopes

For TAG_RESOLVED and DOMAIN_RESOLVED details, you can optionally define resolver scopes that constrain which COA accounts are valid:

Scope	Description
ANY	Any COA account can be resolved
FOUNDATION	Must be within a specific foundation (e.g., Assets only)
MAJOR	Must be within a specific major account header
HEADER	Must be within a specific account header
PARENT	Must be a child of a specific COA account
LIST	Must be from an explicit list of COA accounts
ENTITY	Resolved based on the domain entity

Common Rule Patterns

Interest Accrual (Simple)

LOAN.INT.ACCRUE (SYSTEM mode)
  DR: STATIC → Interest Receivable   — FIXED 100%
  CR: STATIC → Interest Income        — FIXED 100%

Loan Disbursement (Domain)

LOAN.DISBURSE (SYSTEM mode)
  DR: DOMAIN_RESOLVED → hdlr_loan_receivable_resolve  — SYSTEM
  CR: DOMAIN_RESOLVED → hdlr_cash_bank_resolve         — SYSTEM

Share Transfer (Domain)

SHARE.TRANSFER (SYSTEM mode)
  DR: DOMAIN_RESOLVED → share transfer destination logic   — SYSTEM
  CR: DOMAIN_RESOLVED → share transfer source logic        — SYSTEM

This pattern is useful when the system must respect both the sending and receiving member context while keeping the transfer paired operationally.

Share Dividend Credit

SHARE.DIVIDEND_CREDIT (SYSTEM mode)
  DR: DOMAIN_RESOLVED → dividend expense or payable logic   — SYSTEM
  CR: DOMAIN_RESOLVED → savings, cash, or payable logic     — SYSTEM

This is especially important when dividend options vary by member account, because cash payout, savings credit, accrual, and reinvestment do not all resolve to the same target line.

Asset Events

Asset accounting uses the same detail concepts even when configured from the asset GL integration screen instead of the generic GL posting rules page:

ASSET ACQUISITION
  DR: DOMAIN_RESOLVED → asset acquisition resolver   — SYSTEM
  CR: DOMAIN_RESOLVED → offset or settlement logic   — SYSTEM

ASSET DEPRECIATION
  DR: DOMAIN_RESOLVED → depreciation expense logic   — SYSTEM
  CR: DOMAIN_RESOLVED → accumulated depreciation     — SYSTEM

ASSET DISPOSAL
  DR/CR: DOMAIN_RESOLVED → disposal gain, loss, and asset clearing logic

Tag and Handler Expectations

Before approving a dynamic detail, confirm all of the following:

• The rule header itself is approved
• The tag binding points to the right rule header and scope
• Any required handler is active in the dynamic handler registry
• Resolver scopes do not block the account that the handler is expected to return
• Product-level mappings still point to the intended rule

Manual Journal Entry

MANUAL.ENTRY (MANUAL mode)
  DR: STATIC → [User selects COA]  — MANUAL amount
  CR: STATIC → [User selects COA]  — MANUAL amount

Next Steps

• GL Posting Approval — Approval policies for GL postings
• GL Journals — View and create journal entries