> 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/billing.md). # Billing *** ## 1. Overview Billing turns what a customer owes into invoices. It reads the charges on their [orders](/platform/orders.md) and [subscriptions](/platform/subscriptions.md), works out what is billable up to a given date, and produces invoices you can review before anything reaches the customer. That review step is the shape of the whole domain. Younium generates invoices as **drafts**, in a **batch**, so a billing run can be checked, corrected and re-run before it is committed. **Posting** is the point of no return: the invoice takes its number, the accounting entries are made, revenue recognition is updated, and the document goes to the customer. After that a mistake is corrected with a credit invoice rather than an edit. Everything an invoice contains traces back to a charge defined in [Products & Pricing](/platform/products-pricing.md) and sold on an order. Posting feeds [revenue recognition](/platform/revenue-recognition.md), and the resulting balance is settled through [payments](/platform/payments.md). *** ## 2. Core Concepts ### Invoice An invoice belongs to an account, sits in a batch, and holds one or more lines. | Field | Description | | --------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | **Invoice number** | Assigned when the invoice is posted. A draft has none | | **Invoice type** | **Invoice** (a debit invoice), **Credit**, or **On account** | | **Status** | Where the invoice has reached (see below) | | **Account** | The account being invoiced | | **Invoice date** | The date on the document, and the date checked against the accounting period | | **Due date** / **Payment term days** / **Payment term** | When payment is due, and the term it was derived from | | **Days past due** | How far overdue the invoice is | | **Subtotal Amount**, **Tax Amount**, **Total Amount**, **Total Rounding Amount** | The invoice totals | | **Settled amount** / **Balance amount** | How much has been paid and how much is outstanding, each also available in base currency | | **Currency** / **Exchange rate** | The invoice currency and the rate to base currency | | **Tax included** | Whether the amounts are inclusive of tax | | **Date of posting** | When the invoice was posted | | **Settled Date** / **Last Payment Date** | When the invoice was settled, and when it last received a payment | | **Your reference**, **Our reference**, **Buyer reference**, **Your order number** | References carried from the order onto the document | | **Notes** | Free text on the invoice | | **OCR number** | The payment reference, where OCR numbers are enabled | | **Payment method** | **Invoice**, **Stripe** or **GoCardless** | | **Online payment link** / **Online payment status** | The link a customer can pay through, and where that payment has reached | | **Electronic invoice status** | Where the invoice has reached in e-invoicing, where that is configured | | **Invoice delivery method** / **Sent** | How the invoice is delivered, and whether it has been sent | | **Last Reminder Date** / **No. of Reminders** / **Disable invoice reminder** | Reminder history, and a switch to exclude this invoice from reminders | | **Accounts receivable** | The receivable account the invoice posts to | | **External ERP Id** / **External CRM Id** | Identifiers used when matching the invoice in a connected system | Alongside these, Younium derives a set of flags you can filter and report on — whether an invoice is a draft, cancelled, overdue, awaiting payment, partially paid, paid, overpaid, refunded, awaiting refund, or credited. An invoice also carries its credit and debit linkage, so either side of a credit note can be traced from the other. **Is Credited** is true once any credit note has been issued against the invoice — this is the field to filter on to keep credited invoices out of an ageing or collections report. **Credit invoices** lists the credit notes issued against the invoice, and **Debit invoices**, on a credit note, lists the invoice it credits. An invoice can be credited by more than one credit note, so both are lists of linked invoices rather than a single reference. > **Note on filtering by Days past due:** Days past due is worked out from Due date and Status at the moment you read it, rather than stored on the invoice, so it cannot itself be used as a filter condition when querying invoices. Filter on Status and Due date instead — for invoices at least 30 days overdue, that means Status equal to Posted and Due date on or before the date 30 days ago. The direction runs opposite to the day count: more days overdue means an *earlier* due date. > **Note on credited invoices and ageing:** A credit note does not change the status of the invoice it credits — the original stays Posted or Settled. Days-overdue, ageing, and payment-speed reporting should filter on **Is Credited** to exclude credited invoices from the population, rather than relying on status alone. ### Invoice status | Status | Meaning | | ------------- | ----------------------------------------------------------------------------------------------------------- | | **Draft** | Generated but not final. Can be edited, re-run or cancelled. Has no invoice number and no accounting effect | | **Posted** | Final. Numbered, accounted for, sent, and open for payment | | **Settled** | Paid in full — see [Payments](/platform/payments.md) | | **Cancelled** | A draft that was discarded. Any usage or measurement it had claimed is released for billing again | > **Note on correcting a posted invoice:** Only a draft can be cancelled. Once an invoice is posted it stays posted, because its number, its accounting entries and the customer's copy all exist. A posted invoice is corrected with a **credit invoice**, which leaves both documents in the record — which is what an audit expects. ### Invoice line Each line is a billable portion of one charge on an order: its quantity, the service period it covers, its discounts and its tax. Lines can be linked to the usage or measurement data they were billed from. Once a usage record has been billed onto a line, Younium marks it **Processed** and locks it: a processed usage record can no longer be edited or deleted, and processed status is never something you set directly — Younium sets it automatically once the usage is billed. On a draft invoice, notes and custom fields can be updated across many lines at once. Whether lines that come to zero appear on the finished document is controlled by the invoice settings below. ### Invoice batch A batch is one billing run. Every invoice generated together shares the batch's invoice date and its target dates, which is what makes a run reviewable as a unit rather than invoice by invoice. | Field | Description | | --------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | | **Batch number** | Assigned when the batch is created | | **Target date** | The date billed up to, when it is the same for every charge type | | **Target date oneoff**, **Target date recurring in advance**, **Target date recurring in arrears**, **Target date usage**, **Target date measured** | Separate target dates per charge type, when they differ | | **Invoice date** | The date on every invoice in the batch | | **Invoices** / **Open drafts** | How many invoices the batch holds, and how many are still drafts | | **Error messages** | Problems encountered while generating or posting, recorded per account | Posting a batch posts every draft in it, after checking that the accounting period for the invoice date is open. A batch can only be cancelled while none of its invoices is posted; cancelling it cancels the drafts inside. > **Note on target dates versus the invoice date:** The **target date** decides *what* is billed — everything billable up to that date. The **invoice date** is the date on the document and the one that determines which accounting period the invoice falls into. They are set separately because you often bill a period that has already ended. ### Invoice proposal Proposals are a planning step before a batch. Younium scans the billable charges for accounts or orders and proposes what would be invoiced, so you can see the shape of a run before creating any drafts. You then convert the proposals you want into a batch of draft invoices. Proposals can be regenerated for all active accounts, for selected accounts, or for selected orders, replacing what was there before. Where the underlying orders have changed since a proposal was made, the out-of-date proposals can be regenerated on their own. A proposal is not an invoice and has no accounting effect. *** ## 3. Generating Invoices You can bill in three ways: a **batch across accounts**, a **single order**, or a **selection of charges**. All three produce draft invoices in a batch. Before generating, Younium checks that target dates are supplied for every charge type in scope, and that the accounting period for the requested invoice date is open. Only one billing run per legal entity proceeds at a time, so two people cannot bill the same charges twice. Problems found while generating do not stop the run. They are recorded against the account they affect and shown with the batch's progress, so one account with a missing tax template does not block everyone else's invoices. ### Credit invoices A credit invoice corrects a posted one. You select the lines to credit from the posted invoice and, optionally, give the credit its own date. Younium warns where a selection of lines is likely to produce an unintended result. ### On-account invoices An on-account invoice bills an amount that is not tied to charges on an order — a prepayment or an amount held against the account. ### Previewing invoices An order's future invoices can be previewed without creating anything, optionally with the revenue they would generate. This is what quoting and cash-flow reporting use to show what an agreement will bill over its life. For a charge that is aligned to the subscription and has already been billed up to the end of its current term, the preview keeps projecting it into future periods only while the order is **Active** — an active order is assumed to keep renewing for this purpose, whatever its **Auto-renewal** setting is set to. Once an order is no longer Active, for example after it has been cancelled, the preview stops projecting that charge beyond the term it has already billed, even if **Auto-renewal** was left switched on before cancellation. > **Note on forecast renewal vs. automatic renewal:** Assuming an active order will keep renewing is specific to previewing and cash-flow reporting. It does not change whether Younium renews the subscription itself — that still depends on the **Auto-renewal** setting, described under [Automatic renewal](/platform/subscriptions.md#automatic-renewal). *** ## 4. Posting Invoices Posting finalises a draft. Younium assigns the invoice number, creates the accounting entries, updates revenue schedules, generates the document and any e-invoicing attachments, sends it according to the delivery method, and publishes the events integrations act on. You can post one invoice, a selection, or a whole batch. Before each is posted, Younium confirms the accounting period is open and the invoice is still a draft, and prevents the same invoice being posted twice from two places at once. A large batch posts in the background, so a run of thousands of invoices does not hold up the interface. Progress is reported on the batch, and an event is published when the batch completes. A batch can also be left for a scheduled run rather than posted immediately. When the background run finishes, it reports how many invoices it posted and how many it could not. An invoice that fails to post stays a draft, with the reason recorded in the batch's error messages, so a run can complete without posting everything. Read the two counts rather than the run's completion alone to see whether the whole batch posted. The counts are also returned where the public API reports the status of a posting run, and are left blank when a run is still posting after the wait for it has timed out. An invoice posted by someone else while the run is under way is counted as posted by the run. After posting, the invoice appears in [Payments](/platform/payments.md) as outstanding until it is settled. Where the invoice's payment method is **Stripe** or **GoCardless**, collection can start automatically. *** ## 5. Working with Draft Invoices While an invoice is a draft you can change its header fields and addresses, remove lines from it, or cancel it entirely. Cancelling releases any usage or measurement the invoice had claimed, so it can be billed on a later run. A posted invoice's email can be resent, with attachments, without posting anything again. Where a draft contains lines that come to zero — usage with no consumption, or a recurring charge that prices to nothing — Younium can warn you before you post, according to the zero-line settings below. *** ## 6. Invoice Settings These are tenant-wide and control how invoices are numbered, presented, delivered and chased. ### Totals and minimums | Setting | Description | | --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | **Use total rounding** / **Total rounding account** | Rounds the invoice total, and the account the rounding difference posts to | | **Minimum Invoicing Amount** | Invoices below this total are not raised, so you are not sending documents that cost more to process than they collect | ### Zero-amount lines Four settings decide whether a line that prices to zero appears on the finished invoice. The distinction between them is whether a quantity was recorded, which is what separates "nothing was used" from "usage was recorded and priced to nothing". | Setting | Description | | ------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------- | | **Include zero amount lines for usage charges without any linked quantity** | Shows usage lines where no consumption was recorded at all | | **Include zero amount lines for usage and measurement charges with linked quantity** | Shows usage and measurement lines where a quantity was recorded but priced to zero | | **Hide usage and measurement lines with zero amount** | Hides zero usage and measurement lines from the document | | **Hide recurring lines with zero amount** | Hides zero recurring lines from the document | ### Payment references and QR codes | Setting | Description | | ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | **Create OCR number** | Generates a structured payment reference when the invoice is posted, so incoming payments can be matched automatically | | **OCR checksum method** | The reference format: **No checksum**, **Modulus 10**, **Modulus 11**, **FIK**, **Finnish reference number** or **Swiss reference** | | **Swiss bank reference** | The bank reference used on Swiss payment slips | | **Enable Swiss QR Code** / **Enable EPC QR Code** | Adds a scannable payment slip to the invoice | > **Note on OCR numbers:** Generating them requires the invoice number sequence to have no prefix, because the reference has to be numeric. Finnish reference numbers additionally require the current invoice number to be at least 100. ### Documents and delivery | Setting | Description | | ------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | **Invoice template** | The template used for the invoice document | | **Attach pdf to invoice** | Attaches the PDF when the invoice is posted | | **Attach UBL to invoice** / **Attach Zugferd XML to invoice** | Attaches the electronic invoice formats | | **Map only Order Product Charge Name to Electronic Invoice** | Sends only the charge name as the line description on electronic invoices | | **Subject** / **Message** | The email text used when an invoice is sent, with separate wording available for manual sends | ### Credits | Setting | Description | | ------------------------------------------------------ | ------------------------------------------------------------------------------------------- | | **Re-open one-off charges for invoicing after credit** | Makes a credited one-off charge billable again, rather than treating it as already invoiced | | **Reverse usage at credit** | Releases the usage behind a credited line so it can be billed again | | **Allow manual credits in older service periods** | Permits crediting a service period that has already passed | ### Reminders Younium chases overdue invoices in two ways, and you can use either. A **global reminder sequence** of up to five steps applies to every account. Each step has its own template, subject and message, and is timed either by days after the due date or by days since the previous reminder. | Setting | Description | | ------------------------------------------------------------------------- | ----------------------------------------------------------- | | **Days after due date for first invoice reminder** … **fifth** | When each reminder is sent, counted from the due date | | **Number of days from first reminder** … **fourth** | When each reminder is sent, counted from the previous one | | **Use number of days since last reminder** | Chooses which of the two timings applies | | **First invoice reminder template** … **Fifth invoice reminder template** | The document for each step | | **Include credit invoice in reminders** | Counts credit invoices when working out what is outstanding | | **Include cc when sending invoice reminders** | Copies the account's cc addresses on reminders | An **invoice setting group** is a reminder sequence assigned to particular accounts, for customers who need different treatment from the default. Each step in a group has: | Field | Description | | ------------------------------------------------------------------- | --------------------------------------------------------------------------- | | **Reminder order** | Where the step falls in the sequence. Each order is unique within the group | | **Days after due date** / **Number of days from previous reminder** | When the step is sent | | **Template**, **Subject**, **Message** | The document and email wording for the step | The first step in a group cannot be deleted or reordered, so a group always has a starting point. A group cannot be deleted while accounts still use it. Groups can also carry their own subject and message for sending the invoice itself, not just its reminders. An individual invoice can be excluded from all of this with **Disable invoice reminder**. *** ## 7. How Billing Runs Are Started | Flow | Started by | Produces | | --------------------- | ------------------------------------------------------------- | --------------------------------------------------------------------- | | Batch across accounts | Selecting accounts and target dates | A batch of draft debit invoices | | Single order | Invoicing one order | A batch, usually of one invoice | | From proposals | Generating proposals, then converting the ones you want | A batch of drafts | | Credit invoice | Crediting lines on a posted invoice | A credit invoice in a batch | | On-account invoice | Creating one against an account | An on-account draft | | Posting a batch | Posting from the interface, or leaving it for a scheduled run | Posted invoices, accounting entries, documents sent, events published | | Cancelling | Cancelling a draft or a batch | Cancelled drafts, with usage released | --- # 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/billing.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.