Abonnements

ISO 4217 code (3 letters).

true when this company has configured nothing and the shipped defaults answered; false when the values come from a stored row.

ISO 4217

Optional Leistungszeitraum (BT-73/74) anchor, decoupled from startsAt. Null ⇒ the period is anchored to startsAt (legacy behavior). Setup-time only (locked after the first invoice is generated).

Computed at read time; when the next invoice is due.

Total number of records matching the current filter.

Current page (1-indexed, echoes the request).

Records per page (echoes the request).

Total number of pages. Minimum 1, even when total is 0.

The unrecognised parameter NAMES, deduplicated and sorted. Bounded at ten entries, and a name longer than 64 characters is omitted — a parameter name is caller-supplied text, and this response never reflects unbounded caller input. The array may therefore be EMPTY while the refusal still stands: the refusal is decided by the request, not by the length of this list.

Whether the recipient is a public authority. It decides the format every invoice this template generates is produced in. On a CREATE, omitting it takes the linked customer's setting, else an ordinary business. On the REPLACE it is REQUIRED — see ReplaceSubscription. Until it became required there, omitting it re-resolved the linked customer's setting, so re-linking a customer could change the format of every future invoice from this template without the property ever appearing in the request.

ISO 4217

Optional Leistungszeitraum (BT-73/74) anchor, decoupled from startsAt. When set, each generated invoice's service period is anchored to it and rolled by the Turnus; billing timing still governs when the invoice is issued. No proration — an offset first period still bills the full Turnus amount. Not applicable to weekly cadence; must sit within one Turnus of startsAt on either side.

ISO 3166-1 alpha-2; upper-cased server-side.

USt-IdNr (BT-48)

EN 16931 BT-49 — the buyer's ELECTRONIC ROUTING address (a Leitweg-ID for B2G, or an email). Send the bare value: the scheme (0204 for a Leitweg-ID, EM for an email) is derived server-side, so a 0204:-prefixed value is rejected as malformed.

ISO 3166-1 alpha-2; upper-cased server-side.

Document title / Betreff.

Body text rendered above the line items (notes renders below).

ISO 4217

Optional Leistungszeitraum (BT-73/74) anchor, decoupled from startsAt. Null ⇒ the period is anchored to startsAt (legacy behavior). Setup-time only (locked after the first invoice is generated).

Computed at read time; when the next invoice is due.

The document-target snapshotted onto this subscription at creation (override > linked customer > 'b2b'), copied onto every invoice it generates. Always present (defaults to 'b2b').

Whether the recipient is a public authority. It decides the format every invoice this template generates is produced in. On a CREATE, omitting it takes the linked customer's setting, else an ordinary business. On the REPLACE it is REQUIRED — see ReplaceSubscription. Until it became required there, omitting it re-resolved the linked customer's setting, so re-linking a customer could change the format of every future invoice from this template without the property ever appearing in the request.

ISO 4217

Optional Leistungszeitraum (BT-73/74) anchor, decoupled from startsAt. When set, each generated invoice's service period is anchored to it and rolled by the Turnus; billing timing still governs when the invoice is issued. No proration — an offset first period still bills the full Turnus amount. Not applicable to weekly cadence; must sit within one Turnus of startsAt on either side.

ISO 3166-1 alpha-2; upper-cased server-side.

USt-IdNr (BT-48)

EN 16931 BT-49 — the buyer's ELECTRONIC ROUTING address (a Leitweg-ID for B2G, or an email). Send the bare value: the scheme (0204 for a Leitweg-ID, EM for an email) is derived server-side, so a 0204:-prefixed value is rejected as malformed.

ISO 3166-1 alpha-2; upper-cased server-side.

Document title / Betreff.

Body text rendered above the line items (notes renders below).

Null on a freshly created draft unless an explicit invoiceNo was supplied at creation (numbers are no longer auto-assigned at draft creation — only at issue time, sticky thereafter). Use GET /invoices/next-number to preview what will be assigned.

EN 16931 BT-2, the invoice date. It is always the day the invoice is issued (Europe/Berlin): on a draft it is provisional and reads as the day of the latest save; issuing sets it to the issue day, and a scheduled issuance to the day it runs. Frozen at issue.

⚠ void is RESERVED AND NEVER WRITTEN. §14c UStG / GoBD forbid voiding an issued original; a cancellation is a separate 381 document referencing it, so api never writes this status anywhere. It stays in the enum because removing it would be a breaking contract change for no benefit. To detect a cancelled invoice read correctionState, never status.

ISO 4217

Compliance-gate outcome. null until a validation attempt has run. 'legacy' = issued before the gate existed (backfilled when the gate was introduced).

The DERIVED correction state, computed on read from the document chain and never stored. cancelled = an ISSUED/PAID 381 (Storno) that reverses this invoice IN FULL references it; corrected = an ISSUED/PAID 384 (Berichtigung) does and no full 381 does; null = neither, INCLUDING the case where the only correction is still a DRAFT (a half-made Storno has cancelled nothing and must not switch off collection) AND the case where the only correction is a PARTIAL 381 (it reduces the open amount rather than settling the invoice, so the invoice stays in the open items and is still dunned for the remainder). Cancellation wins over correction. Naming + the null-for-none convention follow dauerrechnungState. This — not status: void, which the law forbids the system from ever writing — is what a "Storniert" view keys on. An invoice with a non-null correctionState is excluded from /dunning/overdue, from the per-customer open items, and from payment matching, and POST /invoices/{id}/reminders refuses it with 409 cancelled_by_correction. An invoice reduced by PARTIAL credit notes keeps a null correctionState and stays in all three, at its reduced open amount, until that amount reaches zero.

When we learned the fact transmissionState reports. null when there is no such fact.

Null on a freshly created draft unless an explicit invoiceNo was supplied at creation (numbers are no longer auto-assigned at draft creation — only at issue time, sticky thereafter). Use GET /invoices/next-number to preview what will be assigned.

EN 16931 BT-2, the invoice date. It is always the day the invoice is issued (Europe/Berlin): on a draft it is provisional and reads as the day of the latest save; issuing sets it to the issue day, and a scheduled issuance to the day it runs. Frozen at issue.

⚠ void is RESERVED AND NEVER WRITTEN. §14c UStG / GoBD forbid voiding an issued original; a cancellation is a separate 381 document referencing it, so api never writes this status anywhere. It stays in the enum because removing it would be a breaking contract change for no benefit. To detect a cancelled invoice read correctionState, never status.

ISO 4217

Compliance-gate outcome. null until a validation attempt has run. 'legacy' = issued before the gate existed (backfilled when the gate was introduced).

The DERIVED correction state, computed on read from the document chain and never stored. cancelled = an ISSUED/PAID 381 (Storno) that reverses this invoice IN FULL references it; corrected = an ISSUED/PAID 384 (Berichtigung) does and no full 381 does; null = neither, INCLUDING the case where the only correction is still a DRAFT (a half-made Storno has cancelled nothing and must not switch off collection) AND the case where the only correction is a PARTIAL 381 (it reduces the open amount rather than settling the invoice, so the invoice stays in the open items and is still dunned for the remainder). Cancellation wins over correction. Naming + the null-for-none convention follow dauerrechnungState. This — not status: void, which the law forbids the system from ever writing — is what a "Storniert" view keys on. An invoice with a non-null correctionState is excluded from /dunning/overdue, from the per-customer open items, and from payment matching, and POST /invoices/{id}/reminders refuses it with 409 cancelled_by_correction. An invoice reduced by PARTIAL credit notes keeps a null correctionState and stays in all three, at its reduced open amount, until that amount reaches zero.

When we learned the fact transmissionState reports. null when there is no such fact.

What is on record about this invoice having gone out. Present on this read only.

What the transport reported about the latest system-performed dispatch of this invoice, and the remedies offered for it. Present on this read only; null when there is no system-performed dispatch to report on.

What this deployment currently accepts on this invoice. It rides inside this read so a client can offer only what would be accepted, without a second request.

EN 16931 BT-9 payment due date. Frozen at issue; render clients fall back to issueDate + 30 days when null.

EN 16931 BT-20 payment terms / Zahlungsziel. Frozen at issue.

UNTDID 1001 (BT-3), e.g. "380" (commercial invoice). Write requests are allowlist-checked (INVOICE_TYPE_CODES, default "380,381,384"); anything else is a 400. Frozen after issue — a PUT on a non-draft invoice is always rejected regardless of which fields it tries to change.

Derived, read-only: whether a credit note (invoiceTypeCode="381") reverses its referenced original in full or only in part. A FULL reversal is titled „Stornorechnung" on the rendered document; a PARTIAL one is titled „Rechnungskorrektur". Re-derived on every draft edit and frozen at issue. "full" means all of: the same currency, numerically equal net, tax and gross totals, and the same set of value-bearing line facts (quantity, unit code, unit net price, VAT rate, VAT category). Free text — descriptions and exemption reason texts — is deliberately not part of the comparison, and the comparison is against the referenced original document, not against whatever remains outstanding on it after earlier corrections. null for every other document type, and for a credit note whose original could not be resolved. This field affects the printed title ONLY. It is never a second document type: a partial credit note keeps invoiceTypeCode="381", so how it is booked, whether it is dunned, and which preceding references it may carry are all unchanged.

EN 16931 BG-3 (BT-25 number / BT-26 issue date). Set only on a correction (invoiceTypeCode="384") that references an in-system original; both fields are snapshotted server-side from the resolved original at create/update time — never trusted from client input directly. null for any other invoiceTypeCode.

Derived, read-only: ids of correction invoices (invoiceTypeCode="384") whose precedingInvoice points at THIS invoice. Computed on every read via the preceding-invoice link — never stored, so an original is never mutated by a correction that targets it. Only populated on GET /invoices/{id} (empty on create/update/ finalize responses).

The INTERNAL backlink to the source Angebot this invoice was derived from (POST /offers/{id}/convert-to-invoice). NULL for every non-converted invoice. NOT the EN 16931 preceding-invoice reference — a quote is not a preceding invoice.

The reverse projection of sourceOfferId — the source Angebot's id + number, for the invoice-detail "Entstanden aus Angebot AN-…" reference line. Resolved on every read (no migration) from the offer named by sourceOfferId; null for a non-converted invoice (or an offer no longer visible under scope). Only populated on GET /invoices/{id} (null on create/update/finalize responses).

The reverse-link LABEL projection — the ISSUED/paid corrections (invoiceTypeCode="384") and credit notes / Stornos ("381") whose precedingInvoice points at THIS invoice, enriched with number + type code + issue date so a client can render "storniert durch (381) …" vs "korrigiert durch (384) …" without an N-fetch. The issued subset of the same reverse lookup as correctedBy (which stays the full, unfiltered id list). Computed on every read via the preceding-invoice link — never stored. Only populated on GET /invoices/{id} (empty on create/update/ finalize responses).

Soft link to the source customer; buyer is snapshotted

The document-target (Rechnungsintent) snapshotted onto this invoice at creation (override > linked customer > 'b2b'), re-resolved on draft edit, frozen at issue. 'b2b' renders ZUGFeRD (EN 16931) with the German XRechnung CIUS rules (BR-DE-, e.g. BT-10) advisory; 'b2g' renders XRechnung + ZUGFeRD with BR-DE- as hard requirements.

§19 UStG snapshot: whether the seller was a Kleinunternehmer at this invoice's CREATION, captured from the company profile's Kleinunternehmer setting and frozen on the invoice (like seller.taxNumber). Read-only; the §14 evaluator reads this immutable snapshot, never the live company flag.

The Dauerrechnung marker — an ORTHOGONAL invoice-level flag, NOT a new invoiceTypeCode (a Dauerrechnung stays a "380", or "384" on a reissue-as-Berichtigung). Set at create/draft, frozen at issue. The only consumer that branches on it is the §14 evaluator (Nr. 4 static-Objektnummer exemption; Nr. 6 period-satisfies). DATEV never branches on it — a Dauerrechnung books identically to its underlying 380/384.

DERIVED, read-only standing state. active = a Dauerrechnung chain head (no successor references it); superseded = a later invoice references it via precedingInvoice; null = not a Dauerrechnung (isDauerrechnung=false). Computed from the correctedBy chain, never stored (no anchor table). superseded only ever surfaces on GET /invoices/{id} (where correctedBy is resolved); a Dauerrechnung on a create/update/finalize response reads active.

Snapshot recipient email

Set at issue time. Approximate (from updatedAt) for 'legacy' rows backfilled when the field was introduced; null for drafts.

DSGVO Art. 18 processing restriction. When true, the document is flagged restricted — it is still fully archived, exported, and DATEV-included (restriction limits processing, not existence). Set/cleared via PATCH /invoices/{id}/processing-restriction.

Reason for the restriction; null when not restricted.

When the restriction was set (denormalized render-copy).

users.id that set the restriction (denormalized render-copy).

EN 16931 BT-130 — the unit of measure each generated invoice line will carry. This is a CODED element: the value must come from the UN/ECE Recommendation 20 code list with the Recommendation 21 extension, as enforced by rule BR-CL-23, and NOT from your own vocabulary. Codes are UPPERCASE and are never corrected for you — "hur" is not "HUR". Common values: C62 (piece), HUR (hour), DAY, KGM (kilogram), MTR (metre), LTR (litre), MTK (square metre), KWH. The full accepted set is much wider than these examples; anything matching the published pattern and present in the code list is accepted.

ANNOUNCED NARROWING: this endpoint currently ACCEPTS values outside the code list and records them, so an existing integration keeps working. Refusal is a separate, later change. Send a listed code now; the pattern above is what will be enforced.

Percent as a decimal string, e.g. "19".

EN 16931 BT-154 — optional longer item description, distinct from the item name (description, BT-153). The same field and bound as CreateInvoiceLineItem.itemDescription. Stored on the template and carried onto the matching line of every invoice the template generates (scheduled run and manual generation). Leading and trailing whitespace is trimmed. Omitting it on a replace stores no description for that line.

When we wrote the record down. Null when there is no record.

The date stated by the person who recorded it. Present only for user_asserted, and then always together with recordedAt.

The sender identity the message actually went out under, read from the send record's own snapshot. It is never re-derived from current settings: a sender identity can be changed, and re-reading it would show today's sender beside yesterday's message.

The recipient address is currently on this account's suppression list, so no further mail is sent to it until the address is changed.

The remedies this API offers for this state, in the order they should be presented. The list is decided by the server and a client renders it as offered — a client that decides for itself whether a re-send is possible will eventually offer one the server refuses.

Angebotsnummer (e.g. AN-00042)

UNTDID 1001

The referencing document's own reversal scope, so a client can label this reverse link with the same word that document carries on itself („Stornorechnung" when full, „Rechnungskorrektur" when partial). null for a correction ("384") and for a credit note whose scope was never recorded.

ISO 3166-1 alpha-2

USt-IdNr (EN 16931 BT-31 / BT-48)

Steuernummer (seller snapshot on invoices)

EN 16931 BT-130 — the unit of measure of the invoiced quantity, from the UN/ECE Recommendation 20 code list with the Recommendation 21 extension (rule BR-CL-23). E.g. C62 (piece), HUR (hour), KGM.

NO PATTERN IS PUBLISHED ON THIS READ, deliberately: documents issued before the input boundary existed may carry a value outside the code list, and those documents are immutable and are streamed from the archive rather than re-rendered. Publishing a pattern here would make our own historical responses fail a client's schema validation.

Computed = quantity × unitPriceNet

EN 16931 BT-154 — optional longer item description, distinct from the item name (description, BT-153). Renders as a PDF sub-line and serialises to CII ram:Description.

EN 16931 BT-118 VAT category. O omitted per owner. A Kleinunternehmer seller's lines resolve to E server-side.

EN 16931 BT-121 VATEX exemption reason code (late-binding / StB-gated).

EN 16931 BT-120 exemption reason free-text.