> ## 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.

# How entries are computed

> Understand the debits and credits Hyperline posts for each billing event: invoice posting, revenue recognition, usage, settlement, refunds, and credit notes.

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](./rules) (which decide *which* accounts are used) and the [journal entries view](./entries) (where you browse the posted result).

<Note>
  The exact account each line lands on is decided by your [accounting rules](./rules). The tables below use account **names** (Accounts receivable, Revenue, Output tax…); the **codes** depend on the [chart of accounts](./accounts) attached to your ledger.
</Note>

## 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](#credit-notes)), 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](#multi-currency-and-fx).

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

| Account           | Debit | Credit |
| ----------------- | ----- | ------ |
| Example account A | 100   |        |
| Example account B |       | 100    |

## 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](./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.

<Card title="Example 💡">
  A €120 invoice line — €100 net + €20 tax — for a product recognised immediately:

  | Account             | Debit | Credit |
  | ------------------- | ----- | ------ |
  | Accounts receivable | 120   |        |
  | Revenue             |       | 100    |
  | Output tax          |       | 20     |
</Card>

### 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](#revenue-recognition)).

| Account             | Debit | Credit |
| ------------------- | ----- | ------ |
| Accounts receivable | 120   |        |
| Deferred revenue    |       | 100    |
| Output tax          |       | 20     |

### Discounts

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

| Mode           | Effect on the entry                                                                     |
| -------------- | --------------------------------------------------------------------------------------- |
| Immediate      | A contra-revenue (or discount) account is debited for the discount amount at issue      |
| Deferred       | A deferred discount account is debited and released on the same schedule as the revenue |
| Use net amount | No separate discount line — revenue is booked net of the discount                       |

## 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:

| Account          | Debit | Credit |
| ---------------- | ----- | ------ |
| Deferred revenue | 100   |        |
| Revenue          |       | 100    |

The timing of these slices is driven by the recognition method (over-time granularity, point-in-time basis, or usage). See [revenue recognition](./revenue-recognition) for how each method spreads the amount.

<Note>
  Tax is **not** touched at recognition time — it was already posted in full to output tax when the invoice was issued.
</Note>

## 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:

| Account          | Debit                 | Credit                |
| ---------------- | --------------------- | --------------------- |
| Deferred revenue | *(daily usage share)* |                       |
| Revenue          |                       | *(daily usage share)* |

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](./revenue-recognition#usage-based) 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:

| Account                             | Debit                 | Credit                |
| ----------------------------------- | --------------------- | --------------------- |
| Unbilled revenue *(contract asset)* | *(daily usage share)* |                       |
| Revenue                             |                       | *(daily usage share)* |

**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:

| Account             | Debit         | Credit                  |
| ------------------- | ------------- | ----------------------- |
| Accounts receivable | *(net + tax)* |                         |
| Unbilled revenue    |               | *(net already accrued)* |
| Output tax          |               | *(tax)*                 |

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**.

<Card title="Example 💡">
  A customer consumes a metered product through May and is invoiced €300 + €60 tax on 31 May. Across May, Hyperline accrues the €300 day by day (debit Unbilled revenue / credit Revenue). On 31 May the invoice reclassifies it:

  | Account             | Debit | Credit |
  | ------------------- | ----- | ------ |
  | Accounts receivable | 360   |        |
  | Unbilled revenue    |       | 300    |
  | Output tax          |       | 60     |

  Revenue was recognised across May as it was earned — not in a lump on 31 May.
</Card>

<Note>
  See [revenue recognition → usage billed in arrears](./revenue-recognition#usage-billed-in-arrears) for the daily timing, the late-usage grace window, and per-product behaviour.
</Note>

## 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).

| Account                      | Debit | Credit |
| ---------------------------- | ----- | ------ |
| Cash *(or payment clearing)* | 120   |        |
| Accounts receivable          |       | 120    |

### 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:

| Account                      | Debit | Credit |
| ---------------------------- | ----- | ------ |
| Cash *(or payment clearing)* | 117   |        |
| Payment processing fees      | 3     |        |
| Accounts receivable          |       | 120    |

### 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:

| Account             | Debit | Credit |
| ------------------- | ----- | ------ |
| Customer credits    | 120   |        |
| Accounts receivable |       | 120    |

## 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.

| Account                      | Debit | Credit |
| ---------------------------- | ----- | ------ |
| Accounts receivable          | 120   |        |
| Cash *(or payment clearing)* |       | 120    |

## 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.

<Card title="Example 💡">
  A €120 credit note (€100 net + €20 tax) against an **unpaid** invoice whose revenue was recognised immediately:

  | Account             | Debit | Credit |
  | ------------------- | ----- | ------ |
  | Revenue             | 100   |        |
  | Output tax          | 20    |        |
  | Accounts receivable |       | 120    |

  Had the invoice been **paid**, the €120 credit would land on **Customer credits** instead of Accounts receivable.
</Card>

<Note>
  If the original line still had **deferred** revenue (not yet fully recognised), the credit note reverses the remaining balance from the deferred revenue account rather than from revenue, so it only claws back what was actually recognised.
</Note>

## 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](./rules) so that, when a receivable is deemed uncollectible, the outstanding amount is written off the books instead of remaining in Accounts receivable.

<Info>
  Is something still unclear? Don't hesitate to reach out to our team via the in-app chat if you need additional support.
</Info>