> For the complete documentation index, see [llms.txt](https://help.modelreef.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.modelreef.io/help/drivers-variables-and-timing/delay-rules.md).

# Delay Rules

This article explains **delay rules** in Model Reef in more depth.

You will learn:

* How numeric delays are interpreted by the timing engine.
* How delays interact with model periodicity.
* How delays create and unwind receivables and payables.

Delay rules are the link between accrual timing and cash timing.

***

{% stepper %}
{% step %}

### Delay field basics

Each variable has a **delay** setting that tells Model Reef:

* How long after the accrual date cash is received or paid.
* Whether a receivable or payable should be created in the meantime.

Delays can be expressed as:

* A number of days, for example `30 days`, `45 days`, `75 days`.
* A number of weeks, for example `2 weeks`, `4 weeks`.
* A number of months, for example `1 month`, `2 months`.

The timing engine uses these to schedule cash movements in calendar time, then aggregates them into model periods.
{% endstep %}

{% step %}

### Mapping delays to model periods

Model Reef is aware of dates, even if the model uses monthly or quarterly periods.

When you specify a delay:

* The engine calculates the **exact date** by adding the delay to the accrual date.
* It then determines which model period that date falls into.
* Cash is allocated to that period, not necessarily the immediately following one.

Example for a monthly model:

* Revenue accrues on 1 March.
* Delay is 75 days.
* 75 days after 1 March falls in mid May.
* Cash from that accrual appears in the May period.
* Accounts Receivable holds the value between March and May.

This allows you to use real world payment terms without guessing period boundaries.
{% endstep %}

{% step %}

### Zero delay vs positive delay

Two important cases:

* **Zero delay**
  * Cash and accrual occur in the same period.
  * No receivable or payable is created.
  * Useful for cash sales, immediate card payments, and many small expenses.
* **Positive delay**
  * Accrual happens first, cash later.
  * Receivables or payables bridge the gap.
  * Useful for credit sales, supplier terms, tax instalments and many project based arrangements.

You can mix zero and positive delay variables in the same model to reflect different payment behaviours.
{% endstep %}

{% step %}

### Delay rules for different variable types

Delay behaviour by type:

* **Revenue**
  * Delay creates **Accounts Receivable**.
  * Receivable decreases when the delay expires and cash is collected.
* **COGS, Opex and Staff**
  * Delay creates **Accounts Payable**.
  * Payable decreases when the delay expires and cash is paid.
* **Tax**
  * Payment frequency and lag create **Tax Payable** between expense and payment.
* **Interest**
  * Lag between interest expense and interest paid creates **Interest Payable**.
* **Assets, Liabilities, Equity and Dividends**
  * Typically use explicit capex, drawdown, repayment or distribution schedules rather than generic delays.

The same accrual first, cash second principle applies throughout.
{% endstep %}

{% step %}

### Changing delays and their effect

If you change a delay:

* The model recalculates which periods receive cash.
* Receivable or payable balances are recomputed.
* Working capital and cashflow lines update.
* P\&L accruals are **not** changed (timing of performance remains the same).

This lets you test scenarios such as tighter collections or extended supplier terms by editing a single field.
{% endstep %}
{% endstepper %}

***

## Related articles

* [Portfolio, Funds, VC/PE & Family Offices](/use-cases/portfolio-funds-vc-pe-and-family-offices.md)
* [Build a Central Assumption Library](/how-tos/data-workflows-and-automation/build-a-central-assumption-library.md)
* [Building Your Model](/help/building-your-model.md)
* [Selecting Driver Type](/syntax/drivers-syntax/selecting-driver-type.md)