Kunden & Artikel

Auto-assigned Kundennummer, e.g. "K-00001". Counted per company and per mode: each company's live customers and its sandbox customers each run their own series from K-00001, so the same number can belong to a different customer in another company or in the other mode. Unique within one company and mode; gaps are possible (a deleted customer's number is not reused).

ISO 3166-1 alpha-2

USt-IdNr

Recipient email for invoice delivery

EN 16931 BT-49 default for this customer — a Leitweg-ID or an email, prefilled onto new invoices and subscriptions. Bare value only: the scheme (0204 / EM) is derived at XRechnung generation time.

The customer's document-target intent (B2B / B2G), snapshotted onto every new invoice/subscription for this customer. Always present (defaults to 'b2b').

Standing copy recipients („Kopie an"): every automatic invoice e-mail to this customer is also sent to these addresses, visibly in the Cc header. The invoice itself and its recipient are not affected. null when there are none, never an empty list.

Standing blind copy recipients („Blindkopie an"): every automatic invoice e-mail to this customer is also delivered to these addresses without naming them in any header. null when there are none, never an empty list.

DERIVED rollup — count of this customer's documents currently DSGVO Art. 18 processing-restricted. Present only on the single-customer detail read (GET /customers/{id}), not the list. The invoice remains the single source of truth.

Set when this customer's e-mail address is on the account's suppression list, because earlier mail to it was permanently refused by the receiving mail system. While it is set, no further mail is sent to that address; the remedy is to record a different address on this customer. Present on the single-customer detail read only — an address is not a list-scan fact and does not belong in a table. null when the address is not suppressed.

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.

Whether ccEmails and bccEmails are accepted on create and replace, and applied to automatic invoice delivery.

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.

ISO 3166-1 alpha-2 (2 letters)

Recipient email for invoice delivery

EN 16931 BT-49 default — a Leitweg-ID or an email, prefilled onto new invoices and subscriptions. Send the bare value; the scheme (0204 / EM) is derived at XRechnung generation time.

Whether this customer is a public authority (b2g) or an ordinary business (b2b). It decides whether their invoices are later produced in the format public authorities require. On a CREATE, omitting it records an ordinary business customer. On the REPLACE it is REQUIRED — see ReplaceCustomer. The same property is KEPT rather than reset on the invoice and recurring-template replaces, which is why it is described here per property.

Standing copy recipients („Kopie an") for every automatic invoice e-mail to this customer. Each entry is one plain address with no display name; the domain is lower-cased and the local part kept as sent. An address equal to email is dropped silently, and an address listed in both ccEmails and bccEmails is kept only here. At most 5 entries, else 400 validation_error naming ccEmails with code: too_many_addresses; an entry that is not one valid address is refused with code: invalid_address. An empty list or null stores none. Copies require email: a list without it is refused at email with code: copies_require_email. Accepted only where capabilities.copyRecipients is true; elsewhere a non-empty list is refused and stored lists are left unchanged.

Standing blind copy recipients („Blindkopie an"), under the same rules as ccEmails. A blind copy appears in no header of the sent message. Each automatic send records its blind copies permanently in the invoice's send history.

ISO 3166-1 alpha-2 (2 letters)

Recipient email for invoice delivery

EN 16931 BT-49 default — a Leitweg-ID or an email, prefilled onto new invoices and subscriptions. Send the bare value; the scheme (0204 / EM) is derived at XRechnung generation time.

Whether this customer is a public authority (b2g) or an ordinary business (b2b). It decides whether their invoices are later produced in the format public authorities require. On a CREATE, omitting it records an ordinary business customer. On the REPLACE it is REQUIRED — see ReplaceCustomer. The same property is KEPT rather than reset on the invoice and recurring-template replaces, which is why it is described here per property.

Standing copy recipients („Kopie an") for every automatic invoice e-mail to this customer. Each entry is one plain address with no display name; the domain is lower-cased and the local part kept as sent. An address equal to email is dropped silently, and an address listed in both ccEmails and bccEmails is kept only here. At most 5 entries, else 400 validation_error naming ccEmails with code: too_many_addresses; an entry that is not one valid address is refused with code: invalid_address. An empty list or null stores none. Copies require email: a list without it is refused at email with code: copies_require_email. Accepted only where capabilities.copyRecipients is true; elsewhere a non-empty list is refused and stored lists are left unchanged.

Standing blind copy recipients („Blindkopie an"), under the same rules as ccEmails. A blind copy appears in no header of the sent message. Each automatic send records its blind copies permanently in the invoice's send history.

null = no override = use the catalog price.

Bezeichnung. Copied verbatim into the line item's description.

EN 16931 BT-130 — the unit of measure this entry carries onto an invoice line, 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: catalogue entries saved before this input boundary existed may carry a value outside the code list, and they are returned exactly as they were saved.

Katalogpreis — the fallback unit price. NUMERIC(15,4), as on the line item.

ISO 4217. The client filters the picker to positions matching the invoice's currency; the api only stores and returns it.

Standardmenge, prefilled as the line's quantity on insert. null = NOT SET — the client falls back to "1".

Customers this position is assigned to. Always present (empty array when unassigned), on both the list and the detail endpoint.

EN 16931 BT-130 — the unit of measure this catalogue entry carries onto an invoice line. 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.

ISO 4217. This price is copied onto invoice lines, so the currency is copied with it. On a CREATE, omitting it records EUR. On the REPLACE it is REQUIRED — see ReplacePosition. Until it became required, omitting it on a replace silently repriced a foreign-currency catalogue entry in euros.

Standardmenge. Omit or send null for "not set" (client falls back to "1").

EN 16931 BT-130 — the unit of measure this catalogue entry carries onto an invoice line. 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.

ISO 4217. This price is copied onto invoice lines, so the currency is copied with it. On a CREATE, omitting it records EUR. On the REPLACE it is REQUIRED — see ReplacePosition. Until it became required, omitting it on a replace silently repriced a foreign-currency catalogue entry in euros.

Standardmenge. Omit or send null for "not set" (client falls back to "1").

Whether the dunning columns (nextAction/currentLevel*) are populated. false (degraded) ⇒ those fields are null on every item.

The position's Bezeichnung.

EN 16931 BT-130 — the unit of measure this entry carries onto an invoice line, 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: catalogue entries saved before this input boundary existed may carry a value outside the code list, and they are returned exactly as they were saved.

Katalogpreis — the position's list price.

ISO 4217, trimmed (the column is CHAR(3), blank-padded).

Standardmenge. null = NOT SET — the client falls back to "1".

Kundenpreis. null = NO override = bill this customer unitPriceNet. Effective price = unitPriceNetOverride ?? unitPriceNet.

Kundennummer, e.g. "K-00001" — counted per company and mode, unique only within them.

Kundenpreis. null = NO override = bill this customer the catalog price (unitPriceNet). Effective price = unitPriceNetOverride ?? unitPriceNet.

COALESCE(due_date, issue_date + 30).

CURRENT_DATE − effectiveDueDate (whole days; NEGATIVE when not yet due).

True iff past the effective due date (daysOverdue > 0).

What is still owed, in minor units: totalGross − amountPaid − the same-currency partial credit notes.

The invoice gross in minor units.

The derived current Mahnstufe label; null when none sent OR dunning is off.

When the current level was sent; null when none OR dunning is off.

The server-computed next-action descriptor; null when dunning is not enabled.

Σ openAmountMinor over every open invoice.

Count of open invoices.

Σ openAmountMinor over the overdue subset only.

Count of open invoices past their effective due date.

The next level's key, or null when all reached levels are sent.

The next level's label (the dynamic kebab item label), or null.

Whether the next level can be sent right now.

Why the next level is not sendable, or null when sendable is true. correction_chain_indeterminate is ranked FIRST of all: one of this invoice's own cancellation documents has itself been cancelled, so the amount still owed cannot be determined automatically. Every other reason implies an amount; this one is the absence of one, so the invoice is withheld from automated dunning and shown to a human instead (it stays on the per-customer open items). It never clears by waiting or by sending. cancelled_by_correction means an issued/paid 384, or a 381 that reverses this invoice IN FULL, settles it — it is ranked next, ahead of every remaining reason, because a cancelled invoice is not merely "not yet due". A 381 that reverses only PART of the invoice does not produce this state: it reduces the open amount instead, and the invoice stays dunnable for the remainder. not_sent is ranked SECOND: the platform has no record of ever sending this invoice, so it may not be dunned. It deliberately outranks all_sent and no_level_due — those read as "wait", and a delivery gap never clears by waiting. The row is still returned by the overdue read (it is still money owed); only the send is blocked, until the seller sends the invoice.

ISO date the next level becomes due, when it is not yet due (no_level_due), else null.