> For the complete documentation index, see [llms.txt](https://docs.younium.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.younium.com/platform/payments.md). # Payments *** ## 1. Overview Payments is the part of Younium that records money received from customers, matches those receipts to posted invoices, and updates invoice balances when payments are posted. It supports manual entry, structured bank file import, and CSV import, as well as payment collection through external providers documented separately. A **payment** always belongs to a **payment batch**. Batches group related incoming transactions (for example one bank file or one manual session). Each payment can have **settlements** that allocate amounts to invoices, and **write-offs** that account for small residual differences within configured tolerance. Until a payment is **posted**, it does not finalise invoice settlement status or the associated accounting entries. Payment **methods** and **terms** configure how receipts are classified and how due dates are calculated on commercial documents; they are distinct from payment provider integrations such as Stripe or GoCardless. *** ## 2. Core Concepts ### Payment A payment represents an incoming amount on a given date, linked to a payment method and financial account. It carries payer details, an optional bank reference, optional bank fee amounts, and currency information including exchange rate when the payment currency differs from the legal entity base currency. The payment tracks how much of its amount is allocated through settlements and write-offs. Any unallocated amount is treated as **remaining** until matched, written off within tolerance, or handled manually. Payments created by online collection providers can store provider identifiers on the payment record for reconciliation with external systems. ### Payment batch A payment batch groups one or more payments that were imported or created together. The batch stores a batch number, descriptions, a total batch amount, and posting state. When posting a batch, the platform compares the sum of payments in the batch to the batch total amount. Batches can be partially posted: some payments in a batch may be posted while others remain open until they are fully matched and have no remaining amount. ### Payment settlement A settlement links part of a payment to a **posted** invoice. Each settlement has an amount in invoice currency and can include **invoice write-offs** when tolerance rules apply to close a small invoice balance. Settlements can be created automatically during reference matching or added manually against selected invoices. ### Write-off Younium distinguishes two write-off types: | Type | Attached to | Purpose | | ---------------------------------- | -------------------- | -------------------------------------------------------------------------------------- | | **Settlement (invoice) write-off** | A payment settlement | Closes a small remaining balance on the matched invoice when within tolerance | | **Payment write-off** | The payment itself | Closes a small remaining amount on the payment after settlements when within tolerance | Write-offs created by tolerance rules are marked as automatically created and use the financial account configured in payment settings. ### Payment method A payment method defines how incoming payments are categorised for posting. It links to financial accounts used for the payment itself, and optionally separate accounts for exchange rate gains, exchange rate losses, and bank fees. One method can be marked as the default. ### Payment term Payment terms describe when payment is due relative to invoice or order dates. Terms support net-days style calculations, including variants that anchor to end-of-month. Orders and accounts can reference a payment term; the term type and day count drive due date behaviour on commercial documents. ### Payment reference and payer information The **payment reference** is the primary input for automatic invoice matching. The platform parses references into one or more numeric tokens (split on common separators) and attempts to match each token to invoices. **Payer name** and **payer information** support identification when references are missing or ambiguous, and are populated from bank file imports where available. *** ## 3. Recording Payments ### Manual payments Users can record a payment manually with amount, date, method, account, payer fields, and reference. When **automatic matching by reference** is enabled for the operation, the platform treats the payment like a single-entry import: it builds a one-payment batch, runs the same matching rules as bank import, and persists the matched payment. When matching by reference is disabled, the platform creates a manual batch and stores the payment without running automatic matching. Users can add settlements manually before posting. ### CSV import Payments can be imported from CSV using a configurable field mapping. The import requires mapped fields for payment amount, currency code, and payment date. Imports can exclude negative amounts when configured. Imported rows are grouped by currency; each currency group becomes a section that is processed into batches through the same batch-generation and matching pipeline as bank files. Import templates can be saved and reused as data import configurations for the payment entity. ### Bank file import (CAMT) CAMT XML files (ISO 20022 bank-to-customer statement and debit/credit notification formats) are parsed into incoming payments. Supported schema variants include CAMT.053 (multiple versions) and CAMT.054. The import requires at least one payment entry in the file. Amounts may be taken from structured remittance, transaction amount, or entry amount. Debit entries are treated as negative amounts. Payments are grouped by currency into sections before batch generation. The user selects the target financial account and payment method applied to all payments in the import. ### Bank file import (BGMAX) BGMAX files (Swedish bankgiro format) are parsed section by section. Only **SEK** currency sections are supported; other currencies are rejected. Valid sections produce batches with deposit metadata as the source description. Payment and deduction records map to incoming amounts; payer name and information text are taken from name and information records when present. Invoice references are extracted from payment information for matching. *** ## 4. Matching Payments to Invoices Automatic matching runs when batches are generated from imports or when a manual payment is created with reference search enabled. Only **posted** invoices are considered. ### Reference extraction The platform splits the payment reference on spaces, commas, periods, colons, and tabs, keeps numeric tokens, and trims leading zeros. Special handling applies to Danish OCR-style references beginning with `IK71 0000`. ### Matching priority For each reference token, matching is attempted in order: | Order | Rule | Behaviour | | ----- | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | 1 | OCR number | Match token to invoice OCR reference (including structured OCR formats with `+` segments) | | 2 | Invoice number | Match token to invoice number (numeric comparison, leading zeros ignored) | | 3 | Payer name and amount | If the token is empty but payer name is present, match a single posted invoice with the same account name and identical total amount | If multiple invoices match payer name and amount, no automatic match is made for that rule. ### Currency and amount allocation A settlement is only created when the invoice currency matches the payment currency. The platform allocates up to the invoice balance or remaining payment amount per token. When the payment is split across multiple invoice references, amounts count down from the payment total across tokens. If the payment amount is exhausted but further reference tokens exist, the platform can still attach invoices with **zero-amount settlements** to reflect balancing scenarios (for example offsetting credit and debit invoices on one payment). ### Duplicate detection If an incoming payment carries an **external bank id**, the platform skips creating a payment when that id already exists on another payment. Empty external ids do not trigger duplicate detection. *** ## 5. Payment Tolerance and Write-offs Payment tolerance is optional. When configured, a positive tolerance amount and a tolerance financial account must both be set. | Situation | Condition | Result | | ----------------------------------- | ------------------------------------------------------------------------------- | ------------------------------------------------- | | Invoice remainder after settlement | Remaining invoice balance greater than zero and less than or equal to tolerance | Automatic **invoice write-off** on the settlement | | Payment remainder after settlements | Remaining payment amount greater than zero and less than or equal to tolerance | Automatic **payment write-off** on the payment | If the remainder exceeds the tolerance amount, no automatic write-off is created for that case. ### Settings | Setting | Description | Default | | ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | ------- | | **Payment Tolerance Amount** | The largest remainder Younium will write off automatically, so a payment a few cents short still settles the invoice. Zero turns tolerance off | `0` | | **Payment Tolerance Account** | The account automatic write-offs post to | Not set | *** ## 6. Settlements and Remaining Amounts ### Manual settlements Users can create settlements by linking one or more posted invoices to a payment. Settlement amounts are calculated from invoice balance and payment context. ### Remaining amount A payment’s remaining amount equals the payment amount minus the sum of settlement amounts minus the sum of payment-level write-offs. Posting behaviour depends on whether remaining amount is zero. *** ## 7. Posting Payments and Batches **Posting** finalises payments: it creates accounting transactions, sets the payment posted date, updates invoice status from settlements, and can update related sales order status for the batch. ### Posting a batch When a whole batch is posted without filtering to specific payments, the platform posts payments that: * Belong to the batch * Are not already posted * Have settlements, and every settlement is linked to an invoice * Have **no remaining amount** If no payments meet these criteria, posting fails. The batch records when it was posted, and is marked **Is fully posted** once no unposted payments remain in it. The same batch cannot be posted from two places at once. ### Posting selected payments Users can post a subset of payments in a batch by id. Filtered posting does not require the “no remaining amount” rule that applies to whole-batch posting in the same way; selected payments are posted individually through the posting pipeline. ### Invoice status after posting For invoices affected by posted payments in the batch, the platform recalculates balance from settlements and write-offs: | Invoice balance after allocations | Invoice status | Payment date on invoice | | --------------------------------- | -------------------- | ------------------------------------- | | Zero | Settled | Set to latest settlement payment date | | Non-zero | Posted (not settled) | Payment date cleared | The invoice **last payment date** is updated to the latest settlement payment date in both cases. ### Reverting a posted payment A posted payment can be reverted when validation allows. Revert is blocked if accounting transactions for the payment are already on a **posted journal**. Revert removes accounting transactions for the payment, clears the payment posted date, marks the batch as not fully posted, and recalculates invoice statuses for linked invoices. ### Credit invoice balancing When a posted credit invoice can be balanced against its debited invoice (debit invoice posted, no payments linked), the platform can create and post a balancing payment automatically using a selected method and account. This closes the credit through the standard payment and posting flow. *** ## 8. Manual vs Automatic Flows | Flow | How it is triggered | Matching | Typical source description on batch | | ------------------------------- | ------------------------------------------------------ | ----------------------------------------------------- | ----------------------------------- | | Manual with reference search | User creates payment | Automatic on reference | Manually created | | Manual without reference search | User creates payment | None at creation | Manually created | | CAMT / BGMAX import | User uploads bank file | Automatic per section | Bank file name | | CSV import | User imports mapped file | Automatic per currency section | Import configuration | | Online provider | Provider webhook / checkout (see payment integrations) | Provider-specific; payment record stores provider ids | Provider-driven | Payment provider integrations (Stripe, GoCardless, Aiia) handle collection and reconciliation with external systems; they are documented under **Integrations → Payments**. This article covers core payment, batch, matching, settlement, and posting behaviour inside Younium. *** ## 9. Payment Methods and Terms Configuration ### Payment method fields Payment methods are configured per legal entity. Each method ties receipt posting to chart-of-accounts mappings. | Field | Description | | -------------------------------------------------- | ----------------------------------------------------------------------- | | **Name** | What the method is called when you pick it | | **Description** | Optional description | | **Financial Account** | The account payments received this way post to | | **Exchange rate gains** / **Exchange rate losses** | Where exchange differences post when the payment is in another currency | | **Bank fees** | Where a bank fee deducted from the payment posts | | **Default** | Whether this is the method proposed for new payments | ### Payment term types | Term type | Meaning | | -------------------------- | ---------------------------------------------------------------------------------------------- | | **Net days** | The due date is the invoice date plus the number of days | | **End of month, net days** | The due date is the end of the invoice month, plus the number of days | | **Net days, end of month** | The due date is the number of days after the invoice date, then moved to the end of that month | | Field | Description | | --------------- | ------------------------------------------ | | **Name** | What the term is called when you pick it | | **Description** | Optional description | | **Term Value** | One of the types above | | **Days** | The number of days used in the calculation | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.younium.com/platform/payments.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.