Home › Intercompany › Allocations and central payments › Recurring allocations
Allocations and central payments

Recurring allocations

Schedule allocations that come back every few days, each week or each month.

What it does

Recurring templates are executed individually; Intercompany reminds the user when the add-on starts.

When you need it: A monthly rent recharge posted on time.

How it works

  1. Open Financials › Recurring G/L Allocation Postings and enter a "Code" of up to eight characters and a "Description".
  2. Set the "Frequency" (a number of days, a weekday or a day of the month; monthly unless changed), the "Next Execution" date, which must lie after today, and, if the posting should end, a "Valid Until" date.
  3. Fill in the top table as for any allocation (G/L account, currency, a debit for income or a credit for expense), choose "Amount" or "Percentage" as the "Allocation Method", list the receivers below and choose "Add".
  4. When postings fall due, open the "Confirmation List". Each row is one instance of a recurring posting, with its date, value and instance number.
  5. Select rows and choose "Execute": each becomes a G/L branch allocation, posted to the receivers in the usual way, and drops off the list. "Remove" discards instances you do not want; they can no longer be executed.

Set it up

To have the confirmation list open by itself, tick "Display Recurring Postings on Execution" under Administration › System Initialization › General Settings › Services. The postings use the same accounts as every G/L allocation (Branch Accounts Setup and the default accounts in each receiver). With "Percentage" the lower table may not total more than 100; with "Amount" it may not exceed the top line; "Calculate Allocation %" and "Calculate Allocation Amt." turn one into the other.

Since: Version 50 (November 2023): the recurring postings window responds faster.

Good to know

  • Nothing is posted without a user: each due instance is executed from the list, and the list shows only postings whose next execution date has arrived.
  • Allocation accounts and receiver branch codes behave as in a single allocation; the receiver branch code decides where the receiver's voucher or entry is made.
  • From 2.0 PL30 the sender's own branches may be listed as receivers, where it runs multiple branches.