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

# Understand payment allocations

> Learn how Hyperline allocates payments, refunds, chargebacks, credit notes, and wallet funds to invoices, and how to reassign unallocated amounts.

An allocation tells Hyperline how much of a financial movement applies to a specific invoice or credit note.

The financial movement and its allocation are separate:

* A **transaction** records money collected or returned, such as a card payment, bank transfer, refund, or chargeback.
* An **allocation** assigns all or part of that transaction to a document.
* An **unallocated amount** is the part of a transaction that has not yet been assigned to any document.

<Note>
  Creating or removing an allocation does not move money. It changes how an existing movement is applied to invoices and credit notes.
</Note>

```mermaid theme={null}
flowchart LR
  T["Transaction<br/>€350"] --> A1["Allocation<br/>€200"]
  T --> A2["Allocation<br/>€100"]
  T --> U["Unallocated<br/>€50"]
  A1 --> I1["Invoice A"]
  A2 --> I2["Invoice B"]
```

## Why allocations matter

Allocations let Hyperline represent payment situations that are more complex than one payment for one invoice.

You can use them when:

* One bank transfer pays several invoices
* One invoice is paid using several transactions or payment sources
* A transaction is only partially applied and keeps an unallocated remainder
* A payment is matched to an invoice after it was received
* A credit note is partly applied, partly refunded, and partly added to a wallet
* A refund or chargeback must remain traceable to its original payment
* Wallet funds from several top-ups are used to pay one invoice

## How an allocation affects an invoice

An allocation determines which invoice a transaction contributes to. The transaction status determines when that contribution becomes effective.

For example, a pending payment can already be assigned to an invoice so that the same invoice amount is not collected twice. The invoice is considered paid only according to the payment and invoice status rules that apply to that movement.

Hyperline limits allocations to the amounts that can actually be assigned:

* The sum allocated cannot exceed the transaction amount
* An invoice cannot receive more than its remaining payable amount
* The transaction and invoice must belong to the same customer, currency, and invoicing entity
* A standard payment cannot be used to settle a credit note
* Only eligible, active documents can receive new allocations

If you try to assign more than an invoice can receive, Hyperline allocates the maximum valid amount and leaves the rest of the transaction unallocated.

<Card title="Example 💡">
  You receive a €300 bank transfer and select an invoice with €200 left to pay. Hyperline allocates €200 to the invoice and keeps €100 unallocated. You can later allocate that €100 to another eligible invoice for the same customer.
</Card>

## One transaction can pay several invoices

A transaction can have several active allocations. Each allocation has its own amount.

<Card title="Example 💡">
  A customer sends one €500 bank transfer for two invoices. You allocate €300 to the first invoice and €200 to the second. Both invoices refer to the same transaction, while each displays only the amount assigned to it.
</Card>

The reverse is also possible: one invoice can combine several payment sources, such as a wallet balance, a bank transfer, and a card payment.

## Allocate a payment after receiving it

Some transactions exist before they are matched to an invoice. This is common for bank transfers imported through Open Banking or payments recorded manually.

Until the transaction is allocated:

* The money movement remains recorded in Hyperline
* Its unallocated amount is available for a future match
* It does not settle an invoice by itself

Once you allocate it, Hyperline recalculates the affected invoice balances and statuses.

## Remove or change an allocation

Removing an allocation separates the transaction from the invoice, but it does not delete or refund the transaction.

After an allocation is removed:

* The amount becomes available to allocate again
* The previous invoice balance and status are recalculated
* The transaction remains visible in Hyperline
* The previous allocation remains in the allocation history

To move a payment from one invoice to another, remove the current allocation and create the new one. Hyperline keeps both the past relationship and the new active relationship.

<Warning>
  Unallocating a settled payment can make a previously paid invoice payable again. It does not reverse the external payment.
</Warning>

## Current allocations and allocation history

Hyperline distinguishes between current and past allocations:

| View                    | Meaning                                                 | Effect on balances                                    |
| ----------------------- | ------------------------------------------------------- | ----------------------------------------------------- |
| **Current allocations** | The transaction amounts currently assigned to documents | Included in current invoice calculations              |
| **Past allocations**    | Previous assignments that were removed or replaced      | Kept for traceability, with no current balance effect |

The transaction details show the documents currently receiving the transaction. When a transaction was previously assigned elsewhere, the **Past allocations** section shows the document, amount, and date on which the allocation ended.

Voiding or deleting a document can end its active allocations. Hyperline keeps the past relationships so that you can still understand the transaction's history.

## Refunds

Hyperline supports two refund situations with different effects.

### Refund a payment directly

A direct refund returns money from the original payment without cancelling the invoice amount. The refund remains linked to the original payment and reverses the corresponding payment allocations. The invoice can therefore become payable again.

Use this when the customer should receive the money back but still owes the invoice amount.

### Refund through a credit note

A credit note reduces or cancels the amount the customer owes. When the credit note is refunded, the refund transaction settles the credit note rather than the original invoice.

The complete relationship remains visible:

* The credit note is linked to the invoice it reduces
* The refund is linked to the original payment
* The refund is assigned to the credit note it settles

This separation prevents the invoice amount from being reduced twice.

See [Credit notes & refunds](/docs/invoices/refunds) for the workflows available in Hyperline.

## Credit note allocations

A credit note has its own available amount. You can use that amount in several ways:

* Apply it to one or more invoices
* Refund it through the original payment method
* Record a refund made outside Hyperline
* Add it to the customer's wallet for future use
* Keep the remaining amount available

Hyperline tracks the total used across all these destinations. The same part of a credit note cannot be both applied to an invoice and refunded or credited to a wallet.

<Card title="Example 💡">
  A €300 credit note can be split into €100 applied to an invoice, €120 refunded to the customer, and €50 added to their wallet. The remaining €30 stays available.
</Card>

Credit notes can only be applied to compatible invoices for the same customer, currency, and invoicing entity. Hyperline limits each application to both the credit note's available amount and the invoice's remaining amount due.

## Chargebacks

A chargeback is a separate transaction linked to the disputed payment. It is allocated only to the part of the payment that still contributes to an invoice.

If part of the payment has already been refunded, Hyperline does not apply a chargeback to that same part again. This avoids reducing the invoice balance twice.

<Card title="Example 💡">
  A €100 payment is fully refunded, then the provider reports a €100 chargeback. The chargeback remains linked to the original payment and appears in its transaction history, but it has no current invoice allocation: the refund has already removed the full payment effect from the invoice.
</Card>

For this reason, a refund or chargeback can appear in an invoice's transaction history even when it has no active allocation to that invoice. Its relationship comes from the original payment, while allocations continue to represent the current financial effect.

```mermaid theme={null}
flowchart LR
  P["Original payment"] -->|"Current allocation"| I["Invoice"]
  P -->|"Related movement"| R["Refund"]
  P -->|"Related movement"| C["Chargeback"]
  R -. "Reverses the payment effect" .-> I
  C -. "Applies only to the remaining effect" .-> I
```

See [Chargebacks](/docs/payments/chargebacks) for dispute-specific behavior.

## Wallet allocations

A wallet keeps both a balance and the origin of its funds. Wallet credits can come from paid top-ups, offline payments, free funds, or credit notes.

When wallet funds pay an invoice, Hyperline uses the oldest available eligible funds first. This is a first-in, first-out allocation.

<Card title="Example 💡">
  A wallet contains a first top-up of €150 and a second top-up of €200. A €250 invoice payment consumes the remaining €150 from the first top-up and €100 from the second. The wallet keeps €100 from the second top-up.
</Card>

```mermaid theme={null}
flowchart LR
  F1["First top-up<br/>€150"] -->|"€150"| C["Wallet consumption<br/>€250"]
  F2["Second top-up<br/>€200"] -->|"€100"| C
  F2 -->|"€100"| R["Remaining wallet funds"]
```

This history lets you identify which top-up funded each wallet consumption, including when one consumption uses several top-ups. If a wallet credit is reverted, Hyperline reallocates affected consumptions to other available funds where possible.

See [Manage wallet balance](/docs/wallets/balance) for wallet top-up and consumption workflows.

## Accounting and reporting

Current allocations are the source used to understand which documents a transaction settles. Hyperline uses them for invoice calculations, payment reporting, and supported accounting synchronization flows.

Past allocations remain available for audit purposes but no longer affect current balances. Related refunds and chargebacks can still be displayed with the original invoice even when they have no current allocation, so the full money-movement history remains understandable without counting an amount twice.

## How to read transaction relationships

Use the following questions when investigating a payment:

1. **What money moved?** Review the payment, refund, or chargeback transaction.
2. **Where is it currently applied?** Review its current allocations and amounts.
3. **Was it applied somewhere else before?** Review its past allocations.
4. **Is it an adjustment?** Follow the link to its original payment.
5. **Did a credit note or wallet participate?** Review the related credit note applications or wallet funding sources.

<Note>
  Do not interpret a missing active allocation as a missing transaction. A transaction can be unallocated, or it can be a refund or chargeback whose invoice effect has already been represented elsewhere.
</Note>

## Related documentation

* [Credit notes & refunds](/docs/invoices/refunds)
* [Chargebacks](/docs/payments/chargebacks)
* [Manage wallet balance](/docs/wallets/balance)
* [How the customer balance is calculated](/docs/customers/balance)