GL Posting Rule Details

GL posting rule details are the debit and credit lines that Pinkapple creates when a posting rule is used. Administrators use this page to define which accounts are affected, how amounts are calculated, and how flexible the account selection should be.

Navigation: Accounting -> Setup -> GL Posting Rules -> Select a rule -> Details

Workspace Reference

Workspace	How Users Reach It	What Users Usually Do There
GL Posting Rule Details	Accounting -> Setup -> GL Posting Rules, then open a rule's details	Define debit and credit lines, account selection behavior, amount sources, resolver scopes, and sub-ledger expectations.
GL Posting Rules	Accounting -> Setup -> GL Posting Rules	Maintain the parent rule header, posting mode, approval state, and business meaning.
Back-Office Posting	Accounting -> Operations -> Back-Office Posting	Test manual or both-mode details by creating controlled manual postings.
GL Journals	Accounting -> Operations -> GL Journals	Review the journal lines produced by the rule after posting.
Service Workspaces	Operational modules that trigger system-mode posting	Confirm automated rules resolve accounts, sub-ledgers, and amounts correctly in real business flows.

What A Rule Detail Does

A posting rule header describes the accounting event. Rule details describe the journal lines that event creates.

Example: a payout rule may create:

Line	Type	Meaning
1	Debit	Reduce the payable or clear the beneficiary obligation.
2	Credit	Reduce the funding account, such as wallet, bank, cash, or clearing account.
3	Debit	Record provider or bank charges where fees apply.
4	Credit	Reduce the wallet, bank, or provider float for those charges.

Every rule must remain balanced. Total debits must equal total credits.

Main Fields

Field	What It Means	User Impact
GL Posting Rule Header	The parent rule this line belongs to.	Links the line to the business event being posted.
Detail Name	Business-readable name for the journal line.	Helps reviewers understand the purpose of the line.
Line Type	Debit or Credit.	Determines which side of the journal the line appears on.
Detail Nature	How Pinkapple selects the GL account.	Controls whether the account is fixed, tag-based, or system-resolved.
COA Account	Specific GL account.	Used when the same account should always be posted.
Sub-Ledger	Optional sub-ledger attached to a control account.	Required where the selected account needs party/account-level tracking.
Tag Key	A named accounting tag.	Lets the system resolve the correct account by business unit, currency, or configuration.
Fallback Tag Key	Backup tag if the main tag does not resolve.	Reduces posting failures, but should not hide poor setup.
Amount Source	How the line amount is determined.	Controls whether the amount is entered, calculated, or derived.
Percentage / Fixed Amount	Amount calculation settings.	Used for fixed-share or fixed-value lines.
Repeating	Whether the line can produce multiple journal lines.	Used when one rule line may split by beneficiary, account, tax component, or other detail.
Resolver Scope	Limits where an account may be resolved from.	Protects rules from posting to the wrong account family.

Detail Nature

Detail nature controls how the GL account is selected.

Static

Use Static when the same account should always be used.

Good examples:

• A fixed fee income account.
• A fixed write-off expense account.
• A fixed clearing account for a narrow internal process.

Be careful with static control accounts. If the account requires a sub-ledger, the rule must also provide the correct sub-ledger or posting will fail.

Tag-Resolved

Use Tag-Resolved when the account should come from configured accounting tags.

Good examples:

• Cash at hand by business unit.
• Cash at bank by currency.
• Wallet float by provider rail.
• Receivable, payable, tax, or revenue accounts that vary by service or business unit.

This is usually the safest pattern for reusable rules because the same rule can work across branches, services, and currencies when tags are maintained correctly.

System-Resolved

Use System-Resolved when the correct line depends on the business record being posted.

Good examples:

• Loan repayment lines that split principal, interest, fees, and penalties.
• Asset disposal lines that split cost, accumulated depreciation, gain, or loss.
• Payment batches where the credit account depends on cash, bank, wallet, or mobile money.
• Tax or fee lines that depend on pricing or product setup.

System-resolved details should be used only for rules designed for automated posting. They require strong setup discipline because the final line is determined at posting time.

Amount Source

Amount source controls how Pinkapple calculates the journal line amount.

Amount Source	Use When
Manual	A user enters the amount during a manual journal or back-office posting.
Fixed	The line uses a fixed amount or a percentage of the posting amount.
System	The amount is determined from the business record being posted.
Sum Of Others	The line balances or totals other lines.

For automated domain rules, System is usually safer than forcing a fixed percentage when the business event can contain multiple components.

Resolver Scope

Resolver scope limits the accounts a rule detail may use.

Use resolver scopes to prevent accidental posting into the wrong account class, major header, account header, parent account, or configured list.

Good examples:

• A cash payout credit line should resolve only to cash or bank style accounts, not revenue.
• A receivable debit line should resolve only to asset receivable accounts.
• A fee income credit line should resolve only to income accounts.

If the resolver scope is too strict, valid postings can fail. If it is too broad, incorrect postings can slip through.

Control Accounts And Sub-Ledgers

Some GL accounts require a sub-ledger. Examples may include:

• Customer receivables.
• Supplier payables.
• Loan control accounts.
• Deposit control accounts.
• Bank accounts configured with account-level tracking.
• Wallet or provider accounts configured with rail-level tracking.

When a rule resolves to a control account, Pinkapple must also know the correct sub-ledger. If not, posting stops with a setup error.

For administrators, the practical checks are:

• Is the selected or resolved account a control account?
• Does the rule line provide or resolve the required sub-ledger?
• Is there a default sub-ledger configured where the business process expects one?
• Does the selected business unit or service have the required account mapping?

Do not fix this by choosing a non-control account just to make posting pass. That can break reconciliation and financial reporting.

Repeating Lines

Use repeating lines when one rule detail can produce multiple journal lines.

Examples:

• One payment batch with many beneficiaries.
• One invoice with multiple tax or revenue components.
• One settlement with multiple provider fee lines.
• One allocation that needs separate entries by account or sub-ledger.

Set minimum and maximum repeat counts carefully. A rule that repeats too broadly can create unexpected journals; a rule that cannot repeat enough can block valid transactions.

Good Setup Practice

• Use clear detail names, not generic names like "Line 1".
• Prefer tag-resolved or system-resolved accounts for reusable service rules.
• Use static accounts only where the account truly never changes.
• Confirm control-account sub-ledger behavior before activating a rule.
• Use resolver scopes to protect account families.
• Validate rules with realistic transactions before relying on them in operations.
• Keep failed posting feedback visible to finance users so setup errors are corrected at the rule or tag level.

Common Posting Failures

Failure	Likely Cause	What To Check
Account cannot be resolved	Missing tag, missing account mapping, or wrong service/business-unit scope.	Review tag setup and rule detail nature.
Control account requires sub-ledger	The resolved account needs sub-ledger tracking but none was supplied.	Review sub-ledger setup, default mappings, and selected account.
Debits and credits do not balance	Missing line, wrong percentage, failed system-resolved component, or bad fee setup.	Review all rule details and amount sources.
Rule works in one branch but not another	Business-unit or currency-specific setup is incomplete.	Compare tag and account mappings across branches.
Wrong account is used	Static account or broad resolver scope is too permissive.	Review detail nature and resolver scope.

Related Pages

• GL Posting Rules
• GL Posting Approval
• GL Journals
• Chart of Accounts