> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hyperline.co/llms.txt
> Use this file to discover all available pages before exploring further.
# Contract-based revenue recognition
> Recognize the revenue of a committed contract evenly over its whole term, from the contract rather than from each invoice.
By default, Hyperline creates a [recognition schedule](./revenue-recognition) for each invoice line, so revenue follows what you invoice. For subscriptions under a committed contract with a fixed end, Hyperline instead recognizes revenue from the **contract**. Hyperline spreads the value of the committed term evenly up to the contract end, whatever the invoicing pattern.
This matters when billing and delivery don't line up. A multi-year contract paid upfront for its first year, or one with free or ramped periods, delivers the same service every month. Recognizing it invoice by invoice would put all its revenue in the paid months.
## Setup
The **Revenue recognition** [rule](./rules) matched by each product must recognize revenue **over time** and use distinct **Revenue**, **Deferred revenue** and **Unbilled revenue** accounts. A product whose rule doesn't meet these conditions stays invoice-based. Rules are resolved for each ledger, so a product can be contract-based on one ledger and invoice-based on another.
Hyperline's default recurring revenue recognition rules already carry an unbilled revenue account, so there is nothing to set up for them. A recurring rule you customized or narrowed may have none, and its products then stay invoice-based.
## Which subscriptions are contract-based
A subscription is contract-based when **all** of the following hold:
* It has a [contract](../subscriptions/contracts) attached: the toggle in the **Contract** section is on.
* The contract end is set to a duration or to an end date, not **Forever**.
* The contract status is `active`, and the subscription is active or pending.
* The customer is invoiced on its own invoices, not through consolidated invoicing or on a parent organization's invoice.
* Hyperline can project the contract to its end. For example, a subscription whose next phase you start manually stays invoice-based.
Scheduling a cancellation gives the contract a fixed end, so a **Forever** contract becomes contract-based for its remaining periods.
## How it works
* **One schedule per product for the committed term.** It covers the periods already invoiced and the ones still to invoice. Invoices don't create a second schedule for a period the contract already covers.
* **Revenue is spread evenly**, by day, up to the contract end, free periods included. It is posted at the end of each period of the rule's **Schedule** (monthly by default).
* **Nothing is posted when the contract is signed.** Revenue recognized before it is invoiced accrues to **Unbilled revenue**. When the invoice is issued, it clears Unbilled revenue, and any part invoiced ahead of recognition goes to **Deferred revenue**.
* **Booked in the term-start month.** In the [revenue waterfall](./revenue-recognition#revenue-waterfall), the contract's value appears in the month its current term started. A renewed term is booked in the month it starts, never ahead. **Remaining** includes the part of the contract not invoiced yet.
* **Amounts are net of discounts**, whatever the **Discount method** of the rule.
See [how entries are computed](./entry-mechanics#contract-based-revenue) for the debits and credits behind each step.
A customer signs a 4-year contract from 1 January 2027 to 31 December 2030. Year 1 is invoiced upfront at €14,610 (net), and years 2 to 4 are free.
The term runs for 1,461 days, so Hyperline recognizes €10 per day over the 4 years. January 2027 recognizes 31/1,461 of the total, or €310, and so does January 2030. The invoice parks €14,610 in deferred revenue, which drains to zero on 31 December 2030.
With invoice-based recognition, the same €14,610 would be recognized over 2027 only.
### What stays invoice-based
Only flat fees and seats follow the contract. These lines keep their own invoice schedule, even on a contract-based subscription:
* Usage-based and metered charges, since revenue follows consumption. See [usage-based recognition](./revenue-recognition#usage-based).
* Credits, one-off charges, bundles and minimum fees.
* A period running past the contract end, when the subscription continues after it. If the subscription stops at the contract end, that last period stays in the contract.
## When the contract changes
Only a change to the subscription changes the contract: a cancellation, a shortened or extended end, a price or quantity change, or a product added or removed. Credit notes you create by hand and voids don't.
* Revenue already recognized stays as it is.
* What is left of the new contract value is spread evenly from the day the change is recorded to the new contract end. This also applies to a change dated in the future, such as a cancellation at a later date.
* The booked amount is restated to the new contract value, in the term-start month.
* An immediate or backdated cancellation recognizes the rest of the contract on the day it is recorded.
Continuing the 4-year contract above: on 1 July 2027, you schedule a cancellation for 31 December 2027, and no refund is issued.
By 30 June 2027, Hyperline has recognized €1,810 (181 days at €10). The contract value stays €14,610, since years 2 to 4 were free. The remaining €12,800 is spread evenly from 1 July to 31 December 2027, and deferred revenue drains to zero on the new end date.
## Credit notes, voids and write-offs
* A **credit note** on a line covered by the contract reduces deferred revenue, then increases unbilled revenue for the rest. It never debits revenue directly. Only a refund credit note issued by a subscription change (a cancellation, an update or a transition) lowers the contract value.
* **Voiding an invoice** doesn't change the contract. Revenue for the voided period accrues to unbilled revenue until the period is invoiced again.
* **Writing off an invoice** (marking it `uncollectible`) expenses the unpaid amount of its contract lines as bad debt. The contract keeps recognizing what the invoice billed, since the service is still delivered.
## Where you see it in the app
In **Accounting** > **Settings** > **Accounting rules**, a callout at the top of the **Revenue recognition** section reminds you that committed contracts recognize revenue from the contract.
In an invoice's **Accounting** section, a callout says which lines are recognized from the contract. Those lines show no schedule of their own. The same callout shows on a credit note that touched a contract schedule.
In the schedule detail panel opened from a waterfall cell, a contract schedule shows a **Source** row tagged **Contract**. **Adjust revenue recognition** is not offered there. To change what is recognized, update the subscription.
## Edge cases and limitations
A credit note you create by hand never changes the contract value. A discount given this way leaves revenue too high until you correct it with a [manual journal entry](./manual-entries). To give a real discount or price concession, update the subscription instead.
The part of a written-off invoice not yet recognized on the write-off date is still recognized by the contract end, although it will never be paid. Revenue and bad debt are then both too high by that amount. Correct it with a [manual journal entry](./manual-entries) in the month of the write-off: debit Revenue, credit your bad debt account. When a single invoice billed the schedule (a payment upfront), that amount is the schedule's remaining amount on the write-off date.
An invoice that bills a period at a different amount from what the contract planned doesn't change the schedule. The difference stays in deferred or unbilled revenue and isn't shown in the app. The next change to the subscription spreads it from that day. If no change comes, clear it at the contract end with a [manual journal entry](./manual-entries).
If a change leaves the contract below what was already recognized, the difference is taken back from revenue against unbilled revenue. This happens on the day the change is recorded, or when its refund is issued if later. The contract then ends with nothing left in deferred or unbilled revenue.
The contract's value is converted to the ledger's currency at the rate of the term's start date, or today's rate for a term that starts in the future. Revenue recognized from deferred revenue is measured at the rate it was invoiced at, so deferred revenue drains to exactly zero. Revenue that accrues to unbilled revenue is measured at the contract's rate, but each invoice clears it at the invoice's rate. Hyperline doesn't post an FX gain or loss for the difference, so a small balance can stay on unbilled revenue in the ledger currency.
A subscription can stop qualifying for a reason other than ending, for example when it is paused or its contract end becomes **Forever**. In that case, Hyperline removes schedules with nothing billed or recognized yet. Future invoices are then recognized invoice by invoice again. Schedules already billed or partly recognized run to completion on the contract basis, up to the former contract end.
Is something still unclear? Don't hesitate to reach out to our team via the in-app chat if you need additional support.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.