> 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.md). # Revenue recognition Apply a recognition policy to an invoice, payment, or manual amount, and post the schedule on the Accrual ledger. Kick revenue recognition keeps recognition running from the original source, through the holding account (deferred revenue when the client bills before the work is earned), and into revenue. It is available for clients on Advanced or Enterprise, with the Accrual ledger on. The revenue cycle in Kick stays connected across the invoice, the payment, and the recognition schedule. Invoicing and accounts receivable reconciliation track what was billed and collected. The policy controls how the contract amount is recognized. * **Bill the customer**. [Invoicing](/accountants/bookkeeping-workflows/invoicing.md) records what the customer owes. * **Collect the payment**. Accounts receivable reconciliation clears the receivable. * **Apply the policy**. The policy sets the method, recognition start, holding account, and revenue account for the contract amount. * **Post the schedule**. Kick posts the recognition entries when you apply the policy, including future periods. See [What posts](/accountants/schedules/revenue-recognition/start-a-recognition-schedule.md#what-posts). *** ### Policy-led recognition Kick revenue recognition is policy-led. A policy is the recognition model behind a reusable sale type or a one-time customer contract. Apply that policy to the source for the contract: an invoice line, a payment, or a manual amount. That applied policy becomes the recognition schedule, where review, mid-life changes, and reporting happen. This keeps the setup reusable and the accounting contract-specific: one policy for the pattern, one schedule for each contract's amount, changes, and postings. The term can move, the work can pause, or it can stop, and the schedule changes with it. The rollforward and the waterfall show deferred revenue, what has posted, and what is still ahead. *** ### The revenue recognition workspace Go to **Accounting** → **Revenue recognition**. * **Policies**. Create and manage the reusable recognition models: method, recognition start, holding account, and revenue account. * **Recognition schedules**. Review the applied schedules on invoices, payments, and manual sources. This is where you see status, source amount, remaining balance, posted periods, and schedule actions. A schedule shows no status while it is recognizing, shows **Paused**, **Stopped**, or **Completed** when it is not, and stays a draft with no journal entries when **Auto confirm** is off until you confirm it. *** ### In this section


Create a policy	Set the method, holding account, and revenue account	Create a policy
Milestone-based method	Coming soon. Recognize each share when that milestone is confirmed	Milestone-based method
Start a recognition schedule	Apply a policy to an invoice, payment, or manual amount	Start a recognition schedule
Reporting	Tie the holding account and see what is still ahead	Reporting
Change a schedule	Change the term, or pause, stop, or remove the schedule	Change, pause, stop, or remove a schedule
Run close with MCP	Compare contracts and spreadsheets to Kick before close	Run revenue recognition close with MCP
ASC 606	What you decide, and what Kick posts	How recognition relates to ASC 606

--- # 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.md?ask=&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.