Subscription invoices: lines, periods, and consolidated billing

Subscription periods and other invoice lines were consolidated into one document for the paying customer. Several subscriptions in the same currency can therefore appear on one invoice, while different currencies produce separate invoices. Each line keeps its period so the customer can see what the amount covers. A card payment can be attached at creation; an invoice paid by bank transfer or manual registration is settled later. Open the invoice and compare its lines with upcoming subscription periods. Created, sent, booked, and paid are separate states. See the current guide ### Practical check

All product updates

Historical retrospective - August–September 2024 This article was written afterwards and describes the feature as it worked during the stated period.

Subscription periods and other invoice lines were consolidated into one document for the paying customer. Several subscriptions in the same currency can therefore appear on one invoice, while different currencies produce separate invoices. Each line keeps its period so the customer can see what the amount covers. A card payment can be attached at creation; an invoice paid by bank transfer or manual registration is settled later. Open the invoice and compare its lines with upcoming subscription periods. Created, sent, booked, and paid are separate states. See the current guide (Markdown file, AI agent-friendly)

Practical check

When a customer asks why a line is missing, compare the paying customer, currency, and period invoice date. Also check whether the period is an installment, a zero-priced period, or waiting for manual invoicing. A consolidated invoice does not mean all subscriptions share an interval.

Questions: Can lines be split? Only when the current invoice flow offers it; a sent or booked invoice cannot be freely changed. Is a consolidated invoice paid? Only when payment status says so.

Workflow for a missing or split invoice

  1. Open the customer’s subscriptions and identify who pays for each one.
  2. Compare currency and period start and end with the invoice lines.
  3. Check whether the period is automatic, manual, trial, pause, installment, or usage based.
  4. Read document, delivery, and payment status separately.

When a customer pays for others, only subscriptions linked to that payer can be consolidated. A planned future period is not an invoice, and an invoice is not automatically a payment. When delivery uses an accounting system, its number or PDF may arrive later.

Questions: Why is a period missing? It may not be invoiceable yet, may be zero priced, or may need manual action. Why are there several documents? Check currency, payer, and whether some periods were already locked or sent. Can an old invoice be consolidated later? Not freely; an already sent or booked document needs the separate credit or correction flow.

FAQ and boundaries

An invoice consolidates only periods ready at the same time for the same paying customer and currency. It does not automatically combine different payers or currencies. A zero-priced line can be absent by design. A period waiting for usage, manual invoicing, or a locked change does not become a line until its prerequisite is met. To correct a sent invoice, use the applicable credit flow and create the correct document; do not alter history by adding a manual payment.

Support scenario

A subscription changing interval, currency, or payer must be assessed on the new period; earlier invoice lines do not change automatically. Use the period’s own dates in support. If a document was already sent, use the document actually delivered and make any correction traceable to the original invoice.

Check after the action

Use this check during follow-up: note what was visible before the action, perform only the selected action, and check the document or mandate afterwards. Read a status again before informing the customer if it changes later. The retrospective describes the documented milestone; the current guide and interface determine today’s steps. Examples use fictional customers, amounts, and dates.

Bo Møller
Bo Møller
Emil Højbjerg
Emil Højbjerg

The people and AI helpers behind the updates

Bo Møller and Emil Højbjerg are the primary developers behind Alunta. They spend most of their time coding, so they have delegated the wording of these explanations to our AI helpers.

The AI helpers write from the updates we have deployed to the product. Bo and Emil are behind the changes and remain responsible for ensuring the information reflects what was actually released.