Revenue recognition

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.

​

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:

​

Point in time

All revenue is recognised at a single date. You configure the recognition date basis:

​

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 extra 7 days before being closed at zero, so a slow-starting customer or a delayed ingestion pipeline doesn’t permanently zero out an early slice. Two carve-outs to that gate:

• Catching up on old periods. A day whose period closed more than 7 days ago is recognised on the first pass, without waiting for a second observation — the late-event window has already elapsed.
• Credit-pack drawdown has no grace period. Drawdown is recognised as soon as it is read. If a drawdown lands late, Hyperline trues the schedule up with an additional slice rather than dropping the amount.

​

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.

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-10-55-46 through 55-49). Any pending future slices on the schedule are cancelled, and the schedule is closed.

​

Usage billed in arrears

Some metered products are billed in arrears — the invoice is issued at the end of the period for usage that already happened, so the revenue is earned before it is invoiced. Deferring it (as for prepaid usage) would understate revenue during the period, so Hyperline recognises it as it is consumed and holds it as a contract asset — unbilled revenue — until the invoice is issued. Each day during the period, Hyperline recognises that day’s consumption against unbilled revenue (rather than releasing it from deferred revenue). When the invoice is issued at period end, the accrued amount is reclassified from unbilled revenue to accounts receivable — it is not recognised again. If the final invoiced amount differs from what was accrued (late usage, corrections), the difference is trued up at issue so unbilled revenue nets to zero and recognised revenue equals the invoiced net. Accrual runs per product and per ledger, and uses the same daily stability gate as prepaid usage — a day’s revenue is released once its usage total has been seen unchanged on two consecutive runs, giving a ≥24 hour grace period for late events.

​

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 on the Revenue recognition rule:

​

Recognition schedule statuses

Each invoice line item gets a recognition schedule. The schedule can have the following statuses:

​

Revenue waterfall

Go to Accounting > Revenue recognition. The tab is a single matrix — the revenue waterfall — showing, for each booking month (the month invoices were issued), how the booked revenue unwinds into recognised revenue across the following months, and how much is still deferred. Read it left to right, under three band labels: Filter the matrix by year, All customers, All products, or free-text search.

​

Drill into a cell

To see what makes up a figure, double-click any non-zero cell — or select it and click Explore in the floating bar that appears. The drill-down lists the line items behind that cell: Select a line item to open its full recognition schedule in a sidebar.

​

Recognition schedules

The sidebar is where a single line item’s schedule lives. It shows:

• The customer, subscription, invoice, and product the schedule belongs to
• An Overview with the recognised amount against the booked amount, and a progress bar
• The amounts excluding and including tax
• The recognition method in plain words (e.g. Over time - Monthly)
• The service period
• The Slices table — one row per recognition slice, with its Period and Amount, each tagged Recognized, Pending, Reversed, or Cancelled

​

Adjust remaining recognition

Sometimes the schedule Hyperline computed no longer reflects reality: the obligation was satisfied earlier than planned, delivery was renegotiated, or the service period was set up wrong. Click Adjust remaining recognition on a schedule to reshape what is left, without touching what has already been recognised.

​

The two moves

An adjustment combines two moves in a single operation — you can use either or both:

• Recognize now — release part or all of the remaining deferred balance immediately. Hyperline posts one entry in the current open period, debiting deferred revenue and crediting revenue.
• Spread the remaining — re-plan whatever is still deferred over a new From → To window.

If anything has already been recognised on the schedule, From is locked to the day after the last recognised slice. Adjustments only ever look forward. Three things never change, whatever you do:

• The booked total stays the same — an adjustment moves revenue in time, it never creates or destroys any.
• Already-recognised amounts are never touched.
• A quarterly or yearly schedule keeps its periodicity when re-spread — it is not silently converted to monthly.

​

Preview before applying

The editor previews the result before you commit. Each resulting slice is listed with its new amount, and where an amount changed, the old one is struck through next to it. Slices covering the already-recognised span are tagged Settled, and any amount you chose to recognise immediately is tagged Now.

​

Reason

A Reason is mandatory — it is what makes the adjustment auditable:

​

Audit trail

Every adjustment is recorded on the schedule under Manual adjustments: who made it, when, how much was recognised early, the new recognition window, the reason, and a link to the journal entry that was posted. Each slice the adjustment produced also carries a Manual badge in the Slices table, so an automated slice is never mistaken for a hand-made one. The recognized summary export carries the same auto / manual distinction.

​

When a schedule can be adjusted

The Adjust remaining recognition button is available when all of the following hold:

• The schedule is pending or in_progress — a completed or cancelled schedule has nothing left to move
• It still has a remaining deferred balance
• It is not a point-in-time schedule — there is no spread to reshape
• It does not use deferred discount recognition

​

Export

The Export dropdown on the Revenue recognition tab produces two XLSX reports. Export waterfall — the matrix as displayed, for the selected year: Export recognized summary — recognised revenue only, cut three ways: Every amount in the recognized summary carries an Origin column marking it auto (posted by the recognition engine) or manual (produced by an adjustment).