> For the complete documentation index, see [llms.txt](https://docs.kick.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kick.co/accountants/schedules/revenue-recognition/create-a-policy.md).

# Create a policy

Set the recognition method, holding account, and revenue account for a reusable sale type or a one-time contract.

A policy sets the recognition pattern and the accounts before the schedule exists. Use one policy for a repeatable sale type, or create one for a customer contract that needs its own recognition setup.

{% hint style="info" %}
**Set repeated models first**. For repeated business plans or sales models, set the policy before you apply it. Then each invoice line, payment, or manual source can use the same setup.
{% endhint %}

***

### Create the policy

Go to **Accounting** → **Revenue recognition** and click **Create policy**.

* Enter a **Name**.
* Add a **Description** when the name is not enough for the next reviewer.
* Choose a **Group**, or add one. Groups organize the policy list and do not change the journal entry.

***

### Revenue recognition types

Set **Type** to **Deferred revenue** or **Accrued revenue**. The type controls which holding account the policy uses and how the source enters the recognition flow.

<table><thead><tr><th width="220"></th><th>Deferred revenue</th><th>Accrued revenue</th></tr></thead><tbody><tr><td><strong>Use when</strong></td><td>The client bills or collects before the revenue is earned.</td><td>The client earns revenue before the invoice or payment catches up.</td></tr><tr><td><strong>Recommended holding GL</strong></td><td>Deferred revenue liability.</td><td>Accrued revenue asset.</td></tr><tr><td><strong>Recommended recognition GL</strong></td><td>The revenue account for the earned product or service.</td><td>The revenue account for the earned product or service.</td></tr><tr><td><strong>On apply</strong></td><td>The source moves to the holding account and recognition stays on the schedule.</td><td>No opening entry. The schedule is the recognition plan.</td></tr><tr><td><strong>Holding balance means</strong></td><td>Amount still deferred.</td><td>Amount recognized before the receivable or payment clears it.</td></tr></tbody></table>

{% hint style="info" %}
Changing **Type** clears the holding account. Set the type before you choose accounts.
{% endhint %}

***

### Set up your General Ledger accounts

* **Holding account**. The temporary balance sheet account for the schedule. Deferred policies use a liability. Accrued policies use an asset.
* **Recognition account**. The income account Kick credits when a period is recognized. On a Kick chart of accounts, template policies may fill these accounts for you. When the books have more than one income account, choose the right revenue account before you save.

{% hint style="info" %}
**Multi-entity policy**. One policy can cover multiple entities while using different GL accounts for each entity. Use this when the recognition pattern is the same, but the entities post to different holding or revenue accounts.
{% endhint %}

***

### Build the recognition pattern

#### Recognition methods

* **Straight-line**. Spreads the amount evenly over the interval and number of periods you set.
* **Daily pro rata**. Recognizes by the exact days in the term, based on the start and end dates on the schedule.
* **Point-in-time**. Recognizes the full component amount on one date.
* **By milestone**. Coming soon. Recognizes each milestone allocation when that milestone is confirmed. Set the rows on [Milestone-based method](/accountants/schedules/revenue-recognition/milestones.md).

#### Recognition factors

Each recognition row sets the share, the method, when recognition starts, and, for straight-line, the interval and number of periods.

* **Source date**. Uses the date on the source the policy is applied to: the transaction date, invoice date, or manual source date.
* **Specific date**. Uses a date entered when the policy is applied, independent of the source date.

#### Policy components

A policy can use more than one method. Add a component for each slice and set its percent. The percents must total 100%. Each component can have its own method and term, such as 20% at a point in time and 80% straight-line over the year.

For straight-line components, set the interval as **Daily**, **Weekly**, **Monthly**, or **Yearly**, then set the number of periods. Daily pro rata uses a daily interval across the term.

{% hint style="info" %}
**Why components use percents**. The policy is reusable across different source amounts, so components are set as percents. The actual amount comes from the source when the policy is applied, and you can confirm that amount on the source.
{% endhint %}

***

### Preview and save

**Recognition preview** updates as you set the policy. Enter an **Example amount**, and a source date or specific date when you want to preview a specific contract example.

{% hint style="info" %}
The preview appears when the component percents total 100% and the term is valid.
{% endhint %}

Click **Create policy** to save it. On an existing policy, click **Confirm edit**.

Editing the policy changes it for the next schedule you apply. Schedules already applied stay as they are. To change one contract, change that schedule.

Apply the policy from an invoice line, a payment, or a manual amount.

→ [Start a recognition schedule](/accountants/schedules/revenue-recognition/start-a-recognition-schedule.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.kick.co/accountants/schedules/revenue-recognition/create-a-policy.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.