Standing orders

Standing orders enable the automated creation of recurring transactions. They are particularly useful for regular deposits or withdrawals to accounts, as well as for periodic securities purchases as part of a savings plan. Instead of manually entering each transaction, you define the parameters of the standing order once, and GT automatically creates the transactions at the scheduled time.

Access in the frontend

Standing orders are located under the tenant view in the Standing orders tab. This tab contains two sub-tabs:

  • Standing order cash: For recurring account transactions such as deposits and withdrawals.
  • Standing order security: For recurring securities transactions such as buys and sells.

Repeat configuration

Each standing order contains a repeat configuration that determines when the next transaction is created.

Repeat unit and interval

The repeat unit determines the time measure of the repetition. Together with the repeat interval, this defines the spacing between executions:

  • Days: Execution every n days, where n is the repeat interval. The day position, execution day and execution month fields are disabled since they are not relevant for day-based intervals.
  • Months: Execution every n months. The day position determines the exact day within the month. The execution month field is disabled since it is only relevant for yearly repetition.
  • Years: Execution every n years. The execution month (1–12) and day position determine the exact timing.

Day position

For monthly or yearly repetition, the day position determines the day within the month:

  • Specific day: Execution on the specified execution day (1–28). This is the only day position where the execution day field is enabled.
  • First day: Execution on the 1st of the month. The execution day field is disabled since the day is implicit.
  • Last day: Execution on the last day of the month. The execution day field is disabled. This option is particularly convenient for varying month lengths (28, 29, 30, 31 days).

Weekend adjustment

If an execution date falls on a weekend, it is automatically shifted:

  • Shift before (Friday): Execution takes place on the preceding Friday.
  • Shift after (Monday): Execution takes place on the following Monday.

Examples

ConfigurationDescription
Months, interval 1, specific day 15On the 15th of every month
Months, interval 3, first dayOn the 1st of every quarter
Months, interval 1, last dayOn the last day of every month
Years, interval 1, month 6, specific day 1On June 1st every year
Days, interval 14Every 14 days

Validity and deactivation

Each standing order has a valid from and a valid to date. The first execution occurs at the earliest on the valid-from date. As soon as the next calculated execution date lies after the valid-to date, the standing order is automatically deactivated. Whether a standing order is still active can be determined from the Next execution date column: if a date is shown, the next execution is still pending. If the column is empty, the standing order has been deactivated.

Catch-up mechanism

If the background process has not been executed for several days, for example due to a server outage, missed execution dates are caught up on the next run. A separate transaction is created for each due date. This ensures no scheduled executions are lost.

Limit

The number of standing orders per tenant is limited. The default value is 50 and can be adjusted by the administrator via the global settings.

Editing and deletion restrictions

Once a standing order has been executed at least once and has created transactions, the following restrictions apply:

  • Deletion is not possible: The standing order cannot be deleted because the created transactions reference it. The delete option is hidden from the context menu.
  • Transaction fields are read-only: Only the scheduling fields (repeat configuration, validity period, note) can still be edited. The transaction-specific fields (account, amount, security, costs, etc.) are locked to maintain consistency with the already created transactions.

Showing inactive standing orders

By default, inactive standing orders (those that have been automatically deactivated after reaching their valid-to date) are hidden from the table. To display them, use the Show inactive standing orders option in the show menu. The toggle switches between showing and hiding inactive entries.

Creating a standing order

A new standing order can be created via the context menu in the respective standing order table. Additionally, a standing order can be created directly from an existing transaction. To do this, select the desired transaction in a transaction view and call the Create standing order function via the context menu. The transaction data such as account, amount and transaction type are used as a template.

Execution failures

When the execution of a standing order fails, the error is recorded in a failure log. Typical causes for failures with securities standing orders are a missing price on the execution date or a calculated unit count of zero. In any case, the standing order advances to the next scheduled date, so a single failure does not block the entire processing. In the standing order table, the Failures column shows the number of execution failures that have occurred. Standing orders with failures can be expanded using the row expander. The failure table shows the Execution date and the Business error for each failed date. If an unexpected technical error occurred, the respective failure row can be expanded once more to view the full error text.

Failures are cleaned up on deletion

When a standing order is deleted, all associated failure logs are automatically removed as well.

Background processing

The execution of standing orders is carried out by a daily background process. This process checks which standing orders are due and creates the corresponding transactions. The default execution time is after the daily price update, so that current price data is available for securities standing orders. The following simplified flow shows how the background process handles a single standing order:

graph TD
    A[Check next execution date] --> B{Execution date due?}
    B -- No --> C[No action]
    B -- Yes --> D[Apply weekend adjustment]
    D --> E{Type of standing order?}
    E -- Cash --> F[Create cash transaction]
    E -- Security --> G[Look up price and calculate transaction]
    F --> H[Compute next execution date]
    G --> H
    G -- Error --> K[Save failure to log]
    K --> H
    H --> I{Next date within validity?}
    I -- Yes --> B
    I -- No --> J[Deactivate standing order]