> For the complete documentation index, see [llms.txt](https://docs.younium.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.younium.com/platform/revenue-recognition.md). # Revenue Recognition *** ## 1. Overview Invoicing a customer and earning the revenue are two different events, and in subscription businesses they rarely happen at the same time. Bill a year upfront and you have the cash but not the revenue; you earn it a month at a time. Revenue recognition in Younium is what keeps those two apart: it holds what you have billed but not yet earned as **deferred revenue**, and moves it to **recognised revenue** in the period you earn it. The unit of that work is the **revenue schedule item** — one accounting period's worth of deferred and recognised revenue for a charge. Younium builds these when you post an invoice or when an order changes, and converts deferred to recognised when you close the period. Every charge carries a **revenue recognition rule** that decides how its revenue is spread and what triggers the schedule. The rules are yours to define, because how you recognise revenue is an accounting policy rather than something a billing system should assume. *** ## 2. Core Concepts ### Revenue schedule item A schedule item is one accounting period for one charge. It holds two amounts, and only ever one of them at a time: | Amount | Meaning | | ---------------------- | ------------------------------------- | | **Deferred revenue** | Billed, not yet earned in this period | | **Recognised revenue** | Earned, and posted to the ledger | An item cannot hold both at once, which is what makes the total across all items equal to what has been billed: every amount is either still deferred or has been recognised, never counted twice. Items are typed as **default**, **balance** or **upfront**. The distinction matters for the mixed upfront method, where an upfront portion is held separately from the amount spread over time. ### Recognition type: what triggers the schedule This is the first decision on a rule, and it determines when Younium builds the schedule at all. | Type | Schedule is built | Driven by | | ----------------- | ---------------------------------------------------------- | --------------------------------------------------------- | | **Invoice-based** | When an invoice line is posted | The posted line's amount and the service period it covers | | **Order-based** | When the order is activated, changed, renewed or cancelled | The charge's total contract value and its dates | **Invoice-based** recognition follows what you have actually billed, so nothing is deferred until an invoice exists. **Order-based** recognition follows the contract, so the full value of an agreement is scheduled the moment it is signed, before any of it is invoiced. Which you need is an accounting decision, not a preference. Changing a charge's recognition type after invoicing has begun is refused where it would move between the two models, because the schedule already built follows the old one. ### Recognition method: how revenue is spread | Method | What it does | | ----------------------------------- | -------------------------------------------------------------------------------------------------------------------- | | **Full recognition upon invoicing** | No schedule at all. Revenue is earned when it is invoiced — the right answer for a one-off fee delivered immediately | | **Monthly recognition over time** | Spreads the amount across the periods it covers, according to the distribution below | | **Mixed upfront and over time** | Recognises a set percentage upfront and spreads the rest — for an agreement with a genuine setup component | | **Manual distribution** | No automatic schedule. You allocate the amounts yourself, period by period | The mixed method has several controls over how the upfront portion is taken: | Field | Description | | --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | **Upfront percentage** | How much is recognised upfront, from 0 to 100 | | **Upfront period** | For order-based rules, the period the upfront portion covers — quarterly, biannual, annual, or end of term | | **Base upfront on list price** | Derives the effective percentage from the list price against the price actually billed, so a discount does not inflate the upfront share | | **Upfront only on first invoice** | Takes the upfront portion once, on the charge's first invoice, rather than on every invoice | | **Upfront only on first period** | For order-based rules, takes it only when the charge's schedule is first created | ### Distribution: how the spread is shaped | Distribution | Behaviour | | ------------------------ | ---------------------------------------------------------------------------------------------- | | **Prorated** | By days: each period gets the share of the amount matching its days in the service period | | **Full periods or days** | Whole monthly amounts for complete periods, with day-level proration only at the start and end | | **Front load** | Earlier periods receive more | | **Back load** | Later periods receive more | Order-based rules accept **prorated** and **full periods or days** only. Front load and back load are refused, since they would not reconcile against a contract value. > **Note on closed periods:** A closed accounting period cannot take new deferred revenue. Where a spread would put an amount into a period that is already closed, the amount rolls forward into the next open period — or the first open period, if none in the range is open. Nothing is lost, but the timing shifts, which is worth knowing before closing a period you may still bill into. ### Revenue recognition rule Rules are defined per legal entity and assigned to charges, either through the product catalogue or directly on an order's charge. | Field | Description | | ----------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------- | | **Name** | What the rule is called when you assign it | | **Method** | One of the methods above | | **Distribution** | One of the distributions above, where the method uses one | | **Upfront percentage**, **Upfront period**, **Base upfront on list price**, **Upfront only on first invoice**, **Upfront only on first period** | The mixed method controls above | A rule cannot be edited while it is used on invoice lines that are posted or settled, and cannot be deleted while any charge uses it — in both cases the schedules already built depend on it. Which combinations are valid: | Method | Distribution required | | ------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | Full recognition upon invoicing | None — there is nothing to spread | | Monthly recognition over time | A distribution is required. Order-based rules: prorated or full periods or days | | Mixed upfront and over time | A distribution is required, with an upfront percentage from 0 to 100. Order-based rules also require an upfront period | One-off charges can be spread over time rather than recognised on invoicing, where the rule allows it. ### Settings These apply per legal entity. | Setting | Description | Default | | ------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | ------- | | Enable order-based revenue recognition | Makes the order-based type available on rules in this legal entity | Off | | Book deferred revenue and contract asset on order event | When on, the deferred revenue and contract asset entries are made as soon as the order is activated. When off, they wait for period-close processing | On | | Exchange rate gain account / Exchange rate loss account | Where exchange differences post when an order-based invoice is posted in another currency | Not set | | Adjustment account | Balances unbilled receivables against accounts receivable when the invoice currency differs from base and proration leaves a difference | Not set | Order-based schedules also require an **unbilled accounts receivable** account on the order's invoice account, where booking on order event is enabled. *** ## 3. Invoice-Based Schedules When a debit invoice line is posted, Younium builds the schedule items for it. The same logic runs in invoice preview, which is how forecasting can show future revenue as well as future billing. No schedule is built when the line comes to zero, when the rule recognises fully on invoicing or leaves distribution to you, or when the invoice is a credit — credits follow their own path below. ### What the spread is calculated from The service period on the invoice line, or the charge's effective dates for a one-off; the line's amount both before and after discount; the charge's billing period for usage and measured charges; and any order-level discount covering part of the period. Where prices include tax, that is accounted for before the spread. For mixed upfront rules, the configured percentage is moved out of each period into the upfront portion, and the rounding difference is balanced on either the first or the last period depending on the distribution — so the schedule totals the invoiced amount exactly. ### Credits A credit invoice mirrors the schedule of the line it credits. Where the original amounts sit in periods that are still **open**, the credit reverses them in the same periods. Where they sit in **closed** periods, the amounts are accumulated and posted as a single deferred item in the first open period, since a closed period cannot be reopened to take them. ### Manual distribution Where a rule uses manual distribution, nothing is scheduled automatically and you allocate the revenue yourself. You can: * Add an item against a posted or settled invoice line, choosing its accounting period. * Change the deferred amount on an item that has nothing recognised yet. * Delete an item only where nothing has been recognised on it and the charge still uses manual distribution. Posted lines with an amount not yet allocated appear in the pick lists, so you can see what is left to distribute. *** ## 4. Order-Based Schedules Order-based schedules are built and corrected as the order changes, for charges whose rule uses that type. They follow the contract rather than the invoices, so the whole value of an agreement is scheduled from activation. ### What order-based recognition requires It is deliberately narrower than invoice-based recognition, because a schedule built from a contract value needs that value to be knowable and fixed. It is refused when: | Condition | Why | | ---------------------------------------------------- | ----------------------------------------------------------- | | The subscription is **evergreen** | With no end date there is no total contract value to spread | | A charge starts or ends on a **milestone** | The dates are not known in advance | | The invoice currency differs from the order currency | The scheduled and invoiced amounts could not be reconciled | | The charge is **usage** or **measured** | Consumption is not known in advance | | The distribution is front load, back load or none | These would not reconcile against a contract value | Associated charges are not supported either: a one-off added directly to an order cannot be recognised from the order, and Younium refuses the charge rather than booking it wrongly. See [Orders](/platform/orders.md). ### How the schedule is built and kept correct For each version of an eligible charge, Younium builds the items from the charge's total contract value and its dates, then handles what has changed since: renewals extend the schedule, cancellations shorten it, and balance items reconcile the difference across charge versions. A final check matches the schedule total against the contract value, correcting it where proration has left a difference. Where booking on order event is enabled, the deferred revenue and contract asset entries are made at this point rather than waiting for period close. For mixed upfront rules, the upfront portion follows the **Upfront period** — quarterly, biannual, annual, or end of term — and **Upfront only on first period** restricts it to when the charge's schedule is first created. A schedule is not rebuilt where a renewal has no renewal term, or where the charge has not changed. ### What happens when you invoice Because the revenue was scheduled from the contract, invoicing does not create the revenue — it converts an unbilled receivable into a real one. Younium works out how much of the invoice covers scheduled revenue by overlapping the invoice's service periods with the schedule's recognition dates, and posts the difference against unbilled accounts receivable. Where the invoice is in a different currency from the order, the exchange difference posts to the gain, loss and adjustment accounts configured in the settings above. *** ## 5. Recognising Revenue at Period Close Closing an accounting period is what turns deferred revenue into recognised revenue. Younium: 1. Discards any unposted revenue recognition journal already sitting on the period, so the close works from current data. 2. Selects the schedule items in the period that still hold deferred revenue and are not already on another journal. 3. Builds the balanced accounting entries, using the deferred revenue and recognised revenue accounts on each charge, and any recognised revenue template. 4. Moves the deferred amounts to recognised on each item. The journal can be reviewed before it is posted. See [Platform & Configuration](/platform/platform-configuration.md) for what else period close checks, and for what blocks a period from closing. *** ## 6. How the Order-Based Pieces Fit Together ```mermaid flowchart LR OrderEvent[Order activated, changed, renewed or cancelled] Settings[Revenue recognition settings] Schedule[Order-based schedule items] Journal[Deferred revenue and contract asset entries] Invoice[Invoice posted] UnbilledAR[Unbilled receivable converted] Close[Period close] Recognised[Recognised revenue] OrderEvent --> Schedule Settings -->|Book on order event| Journal Schedule --> Journal Schedule --> Invoice Invoice --> UnbilledAR Settings --> UnbilledAR Schedule --> Close Close --> Recognised ``` --- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.younium.com/platform/revenue-recognition.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.