When a customer pays upfront for a service delivered over time, the revenue cannot be recognised immediately — it must be deferred and released as the service is performed. Hyperline manages this automatically by creating recognition schedules on each invoice line item and posting the corresponding journal entries as revenue is earned.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.
All revenue recognition amounts are net of tax. Tax is always posted
separately as a liability (output tax account) at the time the invoice is
issued, regardless of the recognition method applied to the revenue.
Recognition methods
The recognition method is defined in your Revenue recognition accounting rule. It can be set at the rule level and overridden for specific products or customer segments using filters.Over time
Revenue is spread evenly across the service period using a straight-line allocation. You configure the granularity at which Hyperline posts recognition entries:| Granularity | How revenue is spread |
|---|---|
| Daily | Recognised each day over the service period |
| Monthly | Recognised at the end of each calendar month |
| Quarterly | Recognised at the end of each quarter |
| Yearly | Recognised at the end of each year |
Example 💡
A customer pays €12,000 upfront for a 12-month SaaS subscription starting 1
January. With monthly granularity, Hyperline defers the full €12,000 at
invoice time and recognises €1,000 each month from January to December.
Point in time
All revenue is recognised at a single date. You configure the recognition date basis:| Basis | Recognition date |
|---|---|
| Invoice date | The date the invoice was issued |
| Service start date | The first day of the service period |
| Service end date | The last day of the service period |
Example 💡
A one-off implementation fee with “service end date” basis will remain
deferred until the end of the project, at which point the full amount is
recognised.
Usage-based
Revenue is recognised in line with what your customers actually consume. Use this method for metered products and credit packs — the amount you recognise each day reflects that day’s usage, not a flat allocation. When the invoice is issued, the full amount is parked in deferred revenue. Each day, Hyperline releases the share corresponding to that day’s consumption. Days with no usage recognise nothing; busy days recognise more.Recognition timing
A daily job sweeps every day’s slice and only releases revenue once the day’s usage total has been seen unchanged on two consecutive runs — i.e. no late events landed between observations. This stability gate gives a ≥24 hour grace period for late-arriving usage events. In practice, day D’s revenue is recognised at the next-but-one daily run (typically two days after the consumption day). A day with zero observed usage gets an additional grace window before being closed at zero, so a slow-starting customer or a delayed ingestion pipeline doesn’t permanently zero out an early slice.Once a day’s revenue has been recognised, events landing for that day after recognition are not retroactively allocated. If your usage pipeline regularly produces late events older than 48 hours, reach out before relying on usage-based recognition for material amounts.
| Setting required | Where to set it |
|---|---|
| A revenue account | Revenue recognition rule |
| A deferred revenue account | Revenue recognition rule |
| Metered or credit-pack product | Catalog |
Example 💡
A customer is invoiced €600 upfront for a metered product over a 30-day
service period and consumes 1,000 units across that period. Hyperline
defers €600 at invoice time, then recognises each day in proportion to
that day’s consumption — a day with 50 units recognises €30, a day with
no usage recognises nothing.
Credit packs
Credit packs follow the same usage-based engine, with the schedule anchored on the credit topup rather than a metered aggregator:- The service window is the topup’s validity period (
createdAt → expiresAt). Non-expiring topups inherit the line item’s billing period. - Each day, Hyperline reads the credits drawn down that day and releases the proportional share of the topup’s value.
- When a customer holds multiple active topups, drawdown is attributed FIFO — the oldest topup is consumed first, so its schedule recognises ahead of newer ones.
Example 💡
A customer buys a €1,000 / 500-credit pack valid for 90 days. Over that window
they consume 400 credits. Hyperline recognises €800 across the 90 days in
proportion to daily consumption; the remaining €200 stays deferred until
expiry.
Breakage on expiry
When a topup expires with credits unconsumed, the unrecognised remainder is recognised in a single entry on the expiry date as breakage (per ASC 606-340-10). Any pending future slices on the schedule are cancelled, and the schedule is closed.Example 💡
Continuing the example above: on day 90, the topup expires with 100 credits
unused. Hyperline posts a single recognition entry for the remaining €200 on
the expiry date and marks the schedule completed.
Flat fees and seats use over-time or point-in-time recognition — usage-based
doesn’t apply to non-metered, non-credit products.
Discount recognition
When a line item includes a discount, you control how the discount amount is treated at recognition time using the discount recognition mode in the Invoice posted rule:| Mode | Behaviour |
|---|---|
| Immediate | Discount is recognised in full at invoice time (posted as contra-revenue immediately) |
| Deferred | Discount follows the same recognition schedule as the revenue (spread over the service period) |
| Use net amount | Revenue is recognised net of the discount — no separate discount entry is created |
Recognition schedule statuses
Each invoice line item gets a recognition schedule. The schedule can have the following statuses:| Status | Meaning |
|---|---|
pending | The schedule has been created but recognition has not started |
in_progress | Recognition has started; some entries have been posted |
completed | The schedule is fully processed and closed |
cancelled | The schedule was cancelled before recognition began |
Exploring recognition schedules
Go to Accounting > Revenue recognition to browse all recognition schedules for a ledger.
- The total amount to be recognised (net of tax)
- The amount already recognised
- The remaining deferred balance
- The individual recognition entries (slices) with their dates and amounts
Revenue waterfall
The revenue waterfall is a matrix that shows, for each booking cohort (the month invoices were issued), how the booked revenue unwinds into recognised revenue across subsequent periods — and how much is still deferred. The matrix has three sections:| Section | What it shows |
|---|---|
| Booked revenue | One row per booking cohort; the Total column is the gross amount invoiced (net of tax) in that period |
| Recognised revenue | One column per recognition period; each cell is the amount from that cohort recognised in that month |
| Total revenue | Recognised = cumulative sum of all recognition entries posted so far; Remaining = Booked − Recognised = the deferred revenue balance still on the balance sheet |
All waterfall amounts are net of tax and expressed in the ledger’s functional currency.