How entries are computed

This page explains the journal entries Hyperline posts behind the scenes for each billing event — the actual debits and credits, and why. It complements the accounting rules (which decide which accounts are used) and the journal entries view (where you browse the posted result).

​

Double-entry basics

Every Hyperline journal entry follows standard double-entry bookkeeping:

• Each entry balances — total debits always equal total credits.
• Amounts are net of tax on revenue lines. Tax is always posted separately to the output tax account when the invoice is issued, regardless of how the revenue itself is recognised.
• Entries are immutable once posted. Corrections are made with reversing entries (for example a credit note), never by editing or deleting a posted entry.
• One functional currency per ledger. When an invoice is in a different currency, each line stores both the original-currency amount and the converted ledger amount — see multi-currency.

Throughout this page, each event is shown as a small ledger table:

​

Invoice posted

When an invoice is finalised and emitted, Hyperline posts one entry that recognises the receivable and the tax liability, and books the revenue either immediately or as deferred revenue, depending on the line item’s revenue recognition method.

​

Immediate revenue

For a line with no deferral (no recognition rule, or point-in-time recognised on the invoice date), revenue is booked straight away.

​

Deferred revenue

For a line recognised over time, by usage (billed in advance), or point-in-time on a future date, the revenue is parked in deferred revenue at issue and released later (see revenue recognition).

​

Discounts

How a discount appears depends on the discount recognition mode on the rule:

​

Revenue recognition

Deferred revenue is released to revenue over the service period by a recognition schedule. Each recognition entry — called a slice — moves the earned portion out of the liability: The timing of these slices is driven by the recognition method (over-time granularity, point-in-time basis, or usage). See revenue recognition for how each method spreads the amount.

​

Usage-based revenue

Metered products and credit packs are recognised in line with actual consumption. There are two timings, depending on whether the usage is billed in advance or in arrears — and they post differently.

​

Billed in advance

The customer is invoiced up front (or buys a credit pack), so the amount sits in deferred revenue at issue. Each day, Hyperline releases the share matching that day’s consumption: Any amount left deferred when a credit pack expires is recognised as breakage in a single entry on the expiry date. See usage-based recognition for the consumption and breakage rules.

​

Billed in arrears

When usage is billed after the period (the invoice is issued at period end for what was already consumed), the revenue is earned before it is invoiced. Recognising it only at invoicing would understate revenue during the period, so Hyperline accrues it daily against a contract asset — unbilled revenue — instead of deferred revenue. During the period, each day’s consumption is accrued: When the invoice is issued, the already-earned amount is reclassified from the contract asset to the receivable — it is not re-recognised as revenue: If the final invoiced amount differs from what was accrued (late usage, corrections), the difference is trued up against revenue at issue so the contract asset nets to zero and recognised revenue equals the invoiced net. Accrual runs per product and per ledger.

​

Invoice settled

When a payment transaction settles, Hyperline clears the receivable against cash. The debit side depends on the payment method:

• Bank transfer / direct cash → a cash account is debited.
• Payment provider (card, etc.) → a payment clearing account is debited (the funds are in transit until the provider pays out).

​

Provider fees

When the provider deducts a processing fee, the cash received is net of the fee and the fee is booked as an expense:

​

Paying with customer credits

When an invoice is settled using a customer’s credit balance rather than cash, the credit liability is drawn down instead of debiting cash:

​

Refunds

A refund reverses a settlement — cash goes back to the customer and the receivable (or a credit) is restored. The legs mirror the settlement entry, debit and credit swapped.

​

Credit notes

A credit note reverses an invoice, posting to the same accounts that were used when the invoice was issued. The revenue (or remaining deferred revenue) and the output tax are reversed; the offsetting side depends on whether the invoice was paid:

• Unpaid invoice → the receivable is reduced (the customer simply owes less).
• Paid invoice → a customer credit liability is created (the value is owed back to the customer).
• Partially paid → the receivable is cleared first, any excess goes to customer credits.

​

Multi-currency and FX

Each ledger keeps its books in a single functional currency. When an invoice or payment is in another currency, every journal entry line stores:

• the original-currency amount (as billed), and
• the ledger-currency amount (converted), plus the exchange rate and rate date used.

The rate is captured at the time of the event (invoice emission date, payment date) and frozen on the entry, so historical entries are never re-translated when rates later move. The same rate is used across an event’s related entries — for example, accrued usage is accrued, reclassified, and trued up at one consistent per-ledger rate so the contract asset nets cleanly.

​

Bad debt

The default chart of accounts includes an allowance for doubtful accounts (a contra-asset that offsets receivables) and a bad debt expense account. These roles can be mapped on your accounting rules so that, when a receivable is deemed uncollectible, the outstanding amount is written off the books instead of remaining in Accounts receivable.