Journals, Allocations, and Recurring Transactions
This domain tests how journals are created, generated and posted, with emphasis on recurring templates and allocation runs rather than manual entry.
Journal lifecycle
Journals come from manual entry, import, or generated processes such as recurring, allocation, revaluation and consolidation. A journal sits in a batch and moves from Entered to Posted. When journal approval is enabled on the ledger, entries above an approver's limit must be approved before posting.
Recurring journals
A template stores lines plus three settings: Repeat (None, a set number of times, or indefinitely), Change (Absolute, Relative, No change) and Generate. The Generate Recurring Journals process creates entries in Entered status, so posting is a separate step.
Allocations
An allocation pairs a pool (cost pool with amount and offset account) with a basis (prorata or percentage, driven by a statistical or account balance) and a target. Allocation rules link pool and basis; a run produces a batch. Percentage bases must total 100 so the pool is fully consumed.
Worked example
Rent of 12,000 sits in cost center 100 and must be spread over 200, 300 and 400 by headcount 30/50/20. Reasoning: define the pool as 12,000 on 7100-100, the basis as prorata headcount, and the targets as 7100 in each receiving cost center; the pool account acts as the offset. Because 30/50/20 sums to 100, the pool clears exactly.
Traps
Expecting generated recurring journals to post automatically; using a basis that leaves a residual pool balance; running allocations into a Never Opened or closed period; forgetting approval limits block posting, not entry.