instellix Document Creation turns your billing data into finalized, correctly numbered billing documents — invoices, credit notes, deposit and self-billing documents — with billing runs, draft review, and document management.

Whether the platform calculates your charges for you or you bring fully billed data from your own systems, the outcome is the same: a correct billing document for every business transaction.

Two ways to create billing documents

Billing run — instellix bills for you. You maintain customers, plans, contracts, and billing-relevant data on the platform, and instellix processes all due billable items into billing documents. On this path, the platform also calculates the applicable taxes. Learn how it works in Start a billing run.

Document API — you have already billed. Your own system has already determined the amounts, and instellix creates the compliant billing document: it assigns the document number and takes care of the downstream document process. On this path, you deliver the tax details with every line item. See the Documents API reference.

What you can configure in Document Creation

Billing groups — billing settings and splitting for groups of customers
Billable items — the billing units that become document line items when due
Billing runs — process due billable items into documents
Document types — invoices, credit notes, deposit and self-billing documents
Document numbers — how document numbers are built and assigned
Draft documents — hold selected documents for review before finalization
Customer aggregations — consolidate usage into billable line items before invoicing
Document aggregations — how positions are grouped on the final document
Partner logos — show a partner logo on documents for a contract
Manage documents — browse, filter, open, and act on documents in the webportal
Document attachments — upload files on contracts/orders and open them on documents

PDF layout, translations, and delivery are configured under Document Provisioning — see File Creation.

The section below explains the full process from billable items to final documents, stage by stage.

End-to-end process: from billable items to final documents

This section gives you two views of the same process:

Overview diagram — the full chain at a glance, showing only the stages (readable, top-down).
Stage diagrams and descriptions — one diagram per stage, plus a detailed explanation of every sub-process within that stage.

Read the overview first to orient yourself, then jump to the stage that matters for your question. Each stage is written so you can understand what happens even without opening the linked guides — the links take you deeper when you need configuration details or step-by-step instructions.

Overview diagram

flowchart TB
    START(["Billing data available"])

    START --> PA["Path A · Billing run"]
    START --> PB["Path B · Document API"]

    PA --> S1["Stage 1 · Billable item creation"]
    S1 --> S2["Stage 2 · Eligibility · billing run · tax"]

    PB --> S3["Stage 3 · Document API"]

    S2 --> S4["Stage 4 · Document creation"]
    S3 --> S4

    S4 --> S5["Stage 5 · Draft review"]
    S5 --> S6["Stage 6 · Document rendering"]
    S6 --> S7["Stage 7 · Document management"]
    S7 --> END(["Final billing documents"])

Path A runs Stages 1 → 2 → 4 → 5 → 6 → 7. Path B replaces Stages 1 and 2 with Stage 3, then joins the same path from Stage 4 onward.

Stage 1 — Billable item creation

Before instellix can create a billing document on Path A, charges must exist as billable items — the platform's internal billing units. This stage covers everything that happens before a billing run can pick items up: the commercial setup, the creation of charges, and (for usage-based models) the consolidation of individual usage records into billable line items.

A billable item is not yet a document and not yet something the customer sees. It is the billing-relevant result of upstream business logic — ready to be processed once it becomes due.

flowchart TB
    FOUND["Commercial foundation<br/>customers · plans · contracts"]
    OT["One-time · orders"]
    REC["Recurring · contract intervals"]
    USG["Rated usages received"]
    AGG["Usage aggregation"]
    BI["Billable items created"]

    FOUND --> OT
    FOUND --> REC
    FOUND --> USG
    USG --> AGG
    OT --> BI
    REC --> BI
    AGG --> BI

Commercial foundation

Every billable item is tied to a billing context: a customer, a plan that defines commercial terms, and usually a contract that assigns that plan to the customer for a specific period. This foundation determines billing intervals, which options apply, and how charges are attributed. Without this setup, usages and orders cannot be matched to the correct billing relationship.

One-time business (orders)

When a customer makes a one-time purchase, instellix creates billable items from the order. The timing depends on the billing strategy: with immediate billing, the processing date is set to the time of purchase and the item becomes eligible quickly. With on-demand billing, the item is created but only processed when billing is actively triggered — for example through a billing run or the "Process billable items" action in the webportal. This distinction is important: an order can exist and even produce a billable item without a document appearing automatically.

Recurring business (contract intervals)

For subscription-style business, billable items are created according to the billing intervals defined in the plan and contract — for example monthly, quarterly, or annually, billed at the beginning or end of each interval. Additional rules such as synchronization can affect the first and subsequent processing dates when a contract starts mid-interval. Recurring billable items often exist in the platform before they are due; they become eligible for a billing run only when their processing date is reached.

Rated usages

In usage-based models where you provide pre-priced usage data, individual rated usages are sent to instellix. Each record represents a priced consumption event (excluding taxes) for a contract and product reference. Rated usages are assigned to the matching aggregation for their period. Their status reflects whether aggregation succeeded — for example pending, aggregated, or unprocessed if matching failed.

Usage aggregation

Individual usages are typically not invoiced one by one. Instead, instellix aggregates them per customer and period into consolidated line items. An aggregation closes automatically after the end of the aggregation period plus any configured aggregation delay (to allow late-arriving usages). When it closes, a billable line item is created. If additional usages arrive after closure — or existing ones are cancelled — the aggregation reopens and must be closed again (manually if needed) before the corrected amount can be billed.

Billable items created

The output of Stage 1 is one or more billable items visible under Billing > Billable Items in the webportal. They represent charges that are ready to be processed, but they are not automatically billed. Each item carries a processing date that controls when it becomes eligible for the billing run in Stage 2.

What to remember: Seeing billable items means Stage 1 succeeded. It does not mean a document exists or will appear immediately.

Learn more: Billable items · Rated usages · Customer aggregations · Rated usage aggregations · Start a billing run

Stage 2 — Eligibility, billing run, and tax (Path A)

Stage 2 is where billable items that are due are collected and processed toward document creation. This stage applies only to Path A — the instellix billing run path. It answers the questions most customers struggle with: Why do billable items exist but no document appears yet? and What triggers billing?

flowchart LR
    BI["Billable items exist"]
    DUE{"Processing date<br/>reached?"}
    WAIT["Not yet eligible"]
    ELIG["Eligible for billing run"]
    BR["Billing run"]
    TAX["Tax calculation"]

    BI --> DUE
    DUE -->|No| WAIT
    DUE -->|Yes| ELIG
    ELIG --> BR --> TAX

Items become due

Each billable item stores an individual processing date — the point from which it is allowed to enter document creation. A billing run processes all items whose processing date is on or before the run's processing date. Items with a future processing date remain in the platform but are not included. This is deliberate: billing follows the commercial timing defined by orders, contracts, and plans — not simply "everything that exists."

Billing run

The billing run is the execution step that collects eligible billable items and begins turning them into documents. instellix monitors continuously whether due items exist and processes them in billing runs. A run can cover all customers or be triggered for a single customer (for example via Process billable items on the customer details page). The run does not create charges — it processes charges that already exist as billable items.

Depending on billing group settings and splitting configuration, one run may produce one or several documents. A single document can also carry only a limited number of items (configurable, up to 1,000); if more items are due than fit, instellix automatically creates additional documents so no eligible item is left unprocessed.

Tax calculation

On Path A, instellix calculates applicable taxes as part of the billing run, before the document structure is finalized. Tax rules depend on the billing context — customer, contract, service location, and your tax configuration. On Path B, by contrast, tax details are provided with the incoming data.

What to remember: Billable items without a matching document usually mean the items are not yet due — not that the billing run failed. Check processing dates before assuming an error.

Learn more: Start a billing run · Taxation

Stage 3 — Document API (Path B)

Path B is for organizations that calculate amounts in their own systems and use instellix primarily for compliant document creation, numbering, and downstream processing. This path replaces Stages 1 and 2 — there is no billable-item selection or platform-side tax calculation in the same way as a billing run.

flowchart LR
    EXT["External system<br/>amounts · tax details"]
    API["Document API"]
    DOC["Documents created"]

    EXT --> API --> DOC

External amounts and tax details provided

Your system sends billing data to instellix with already calculated line amounts and tax details. This includes the information needed to create a compliant billing document — customer context, line items, tax breakdowns, and document type. instellix validates and processes this data rather than deriving amounts from billable items and contract logic.

Documents created via Document API

instellix creates billing documents from the provided payload, assigns document numbers according to your configuration, and hands off to the same downstream process as Path A from Stage 4 onward — including optional draft review, rendering, and portal management. Corrections and reissues on this path also reference original documents.

What to remember: Path A and Path B converge at Stage 4. The difference is entirely in where the amounts come from — instellix billing logic versus your external system.

Learn more: Documents API reference

Stage 4 — Document creation

Both paths converge here. instellix transforms billing data — whether from a billing run or the Document API — into structured billing documents in the platform. This stage applies the configuration that determines document type, numbering, grouping, and position layout. The result is one or more documents that exist in the system but may not yet be the final PDF the customer sees (that happens in Stage 6).

flowchart TB
    IN["Billing data from Stage 2 or 3"]
    TYPES["Document types"]
    NUM["Document numbers"]
    SPLIT["Billing groups · splitting"]
    AGG["Aggregations"]
    DOC["Documents created"]

    IN --> DOC
    TYPES --> DOC
    NUM --> DOC
    SPLIT --> DOC
    AGG --> DOC

Document types

instellix supports multiple document types for different business cases: invoices, credit notes (regular, goodwill, or warranty), deposit invoices for advance payments, and self-billing invoices — each with dedicated correction types. The document type determines the legal and process character of the output. Corrections and reissues always reference the original document, so finalized documents remain unchanged and audit trails stay intact.

Document numbers

Each document receives a unique number according to your numbering configuration: counters with prefix, suffix, and mask, plus matching strategies per document type, billing group, or service country — with a fallback counter when no specific rule matches. Number assignment happens during document creation and is part of what makes the output compliant and traceable.

Billing groups and splitting

A billing group bundles the billing settings that apply to a set of customers — you manage them under Billing > Billing Groups. Splitting configuration determines whether billable items are combined into one document or separated across several. This matters commercially and operationally: not every charge belongs on the same invoice. Combined with the item limit per document (up to 1,000), splitting ensures all eligible items are processed even when a single document would become too large.

Aggregations

Two aggregation concepts apply at different points. Customer aggregations consolidate rated usage data into billable line items before a document exists — so a month of usage becomes a handful of clean invoice lines instead of hundreds of individual records. Document aggregations control how line items are grouped and displayed on the final document — for example summarizing by tax rate. Do not confuse the two: customer aggregations shape billing input; document aggregations shape presentation.

Documents created

The output of Stage 4 is one or more billing documents in the platform. They contain the structured billing result — customer and contract context, line items, tax positions, and assigned document numbers. Depending on draft rules, they may proceed directly to rendering or be held in Stage 5 first.

What to remember: The number and shape of documents is driven by configuration, not only by how many billable items you have.

Learn more: Document types · Document numbers · Document aggregations · Customer aggregations

Stage 5 — Control before finalization

Not every document proceeds immediately to the customer. Where configured, instellix holds selected documents as drafts for review before they become final. This stage adds an operational checkpoint — useful for high-value invoices, specific currencies, or sensitive billing groups.

flowchart LR
    DOC["Documents created"]
    RULES{"Draft rules<br/>match?"}
    DRAFT["Held as draft"]
    REV["Review · release"]
    FINAL["Proceeds to rendering"]

    DOC --> RULES
    RULES -->|Yes| DRAFT --> REV --> FINAL
    RULES -->|No| FINAL

Draft rules evaluated

After document creation, instellix evaluates draft rules based on JSONata expressions. Typical criteria include document amount, currency, billing group, or other attributes you define. Documents that match a rule are created as drafts rather than finalized immediately. Documents that do not match any rule skip this stage and proceed directly to rendering.

Review and release

Draft documents appear in the webportal for operator review. An authorized user inspects the document and releases it when approved, which triggers finalization and allows the document to proceed to Stage 6. Until release, the document exists in the platform but is not treated as a finalized billing output.

What to remember: A document may exist without a final PDF yet because it is held as a draft — not because rendering failed.

Learn more: Draft documents

Stage 6 — Document rendering

Stage 6 is where the internal billing document becomes the customer-facing output — typically the PDF you open in the webportal. Rendering applies your visual and language configuration on top of the structured billing data created in Stage 4.

flowchart LR
    DOC["Billing document"]
    TPL["Template selection"]
    TR["Translations"]
    PDF["PDF output"]
    OUT["Customer-facing document"]

    DOC --> TPL --> TR --> PDF --> OUT

Template selection

Every document is rendered with a document template that defines layout and branding. By default, instellix provides a standard template; tenants can also use customized templates that reflect their corporate design. Template selection can depend on provisioning configuration — for example whether the default template is used or a tenant-specific layout applies.

Translations applied

Headlines, labels, and text blocks on the document come from translation management, maintained per language. One template serves all document languages: the template defines structure, translations provide the language-specific text. This means a German and an English invoice can be produced from the same template with different label sets.

PDF output generated

The final file is produced according to your PDF output settings — including variant and accessibility options configured in provisioning. This is the artefact operators and customers typically interact with. It reflects both the billing data from Stage 4 and the presentation layer configured here.

What to remember: The PDF is not a raw printout of billable items. It is the result of billing data + document configuration + template + translations.

Learn more: File Creation · Document templates · Translation management · PDF output

Stage 7 — Document management

Once documents are final and rendered, operators manage them in the webportal — reviewing output, organizing documents, and triggering business follow-up. This stage is where you confirm that the end-to-end process produced the expected result.

flowchart LR
    DOC["Final documents"]
    VIEW["Document overviews"]
    LABEL["Labels"]
    ACT["Follow-up actions"]

    DOC --> VIEW
    DOC --> LABEL
    DOC --> ACT

Document overviews

Billing document overviews let you browse, filter, sort, and open documents across the platform or in a customer-specific context. You can adjust columns, search for specific documents, and open the PDF to verify content. This is the primary place to confirm what Stages 1–6 produced.

Labels

Labels are free-text tags you assign to documents for operational organization — for example marking documents for a specific review cycle, business unit, or internal process. Labels do not change document content; they help teams filter and report on document sets.

Follow-up actions

Depending on document type and your process setup, operators can trigger follow-up actions from the document context — such as corrections, reissues, or payment intents. Corrections always create a new document that references the original, preserving the audit trail established in Stage 4.

What to remember: Stage 7 is for verification and downstream business process — not for re-running billing. If the wrong items were billed, trace back to Stages 1–4.

Learn more: Manage documents · Document attachments · Document labeling

Where to verify

Stage	What to check	Where to look
1	Billable items exist	Billing > Billable Items
2	Items were eligible; run processed them	Billable items · processing date · customer billing data
3	Documents created from external data	Document overviews after API call
4–6	Documents exist and PDF renders correctly	Billing document overviews · open PDF
7	Final result and follow-up	Document overviews · labels · customer context

Common questions

Why do I see billable items but no document?
Stage 1 succeeded, but Stage 2 has not yet applied — the items are not yet due or no billing run has processed them.

Why were multiple documents created?
Stage 4: billing-group splitting rules or the document item limit divided eligible items across several documents.

Why does the PDF not match my billable items one-to-one?
Stages 4 and 6 apply document configuration, aggregations, templates, and translations before producing the final output.

Which path applies to us?
Path A if instellix calculates and processes due billable items via billing runs. Path B if your system already calculated amounts and you use the Document API.