Attestwire

Rule reference

BR-DE-TMP-32 This invoice states no time of supply: it carries neither an actual delivery date (BT-72), nor an invoicing period (BG-14), nor a period on every invoice line (BG-26)

This invoice states no time of supply: it carries neither an actual delivery date (BT-72), nor an invoicing period (BG-14), nor a period on every invoice line (BG-26). KoSIT raises this at severity `information`, so the document is accepted and no validator will stop you — but §14 Abs. 4 Nr. 6 UStG requires the time of supply on a German invoice, and its absence is a defect the buyer's tax adviser finds long after the portal did not. The three routes are alternatives, not a hierarchy: pick whichever describes the supply.

This rule is implemented and its error payload below is real, but the long-form write-up — normative text, worked example, divergence note — is not written yet. Everything the library knows about this rule is on this page. Ask and we will prioritise it.

Business term
BT-72 / BG-14
Severity
information

What the library returns

The exact object in result.errors when this rule fires. Generated by running @attestwire/en16931, not transcribed:

TeachingError
{
  "rule": "BR-DE-TMP-32",
  "field": [
    "BT-72",
    "BG-14"
  ],
  "severity": "information",
  "message": "This invoice states no time of supply: it carries neither an actual delivery date (BT-72), nor an invoicing period (BG-14), nor a period on every invoice line (BG-26). KoSIT raises this at severity `information`, so the document is accepted and no validator will stop you — but §14 Abs. 4 Nr. 6 UStG requires the time of supply on a German invoice, and its absence is a defect the buyer's tax adviser finds long after the portal did not. The three routes are alternatives, not a hierarchy: pick whichever describes the supply.",
  "fix": "Set deliveryDate for a one-off supply (\"2026-08-05\"), or invoicingPeriod with startDate and endDate for a service billed over a period, or a period on each line when the lines cover different periods. If the supply date is the invoice date, say so explicitly rather than leaving it to be inferred.",
  "example": "\"invoicingPeriod\": { \"startDate\": \"2026-07-01\", \"endDate\": \"2026-07-31\" }",
  "xpath": "/ubl:Invoice/cac:Delivery/cbc:ActualDeliveryDate",
  "docsUrl": "https://attestwire.com/rules/BR-DE-TMP-32"
}

xpath locates the element in the generated UBL document, which is where a KoSIT or Peppol validator will report the same problem.

A passing value

the shape this field expects
"invoicingPeriod": { "startDate": "2026-07-01", "endDate": "2026-07-31" }

The fix

Set deliveryDate for a one-off supply ("2026-08-05"), or invoicingPeriod with startDate and endDate for a service billed over a period, or a period on each line when the lines cover different periods. If the supply date is the invoice date, say so explicitly rather than leaving it to be inferred.

All 292 rules →

Nearby: PEPPOL-COMMON-R040 — The Seller electronic address (BT-34) is "7300010000002" under scheme "0088", which identifies the GS1 Global Location Number; BR-DE-31 — The invoice carries a DIRECT DEBIT group (BG-19), so the debited account identifier (BT-91) must be present; PEPPOL-COMMON-R041 — The Seller electronic address (BT-34) is "991825828" under scheme "0192", which identifies the Norwegian organisation number (Enhetsregisteret).

Check this rule against your invoice via the hosted API → https://api.attestwire.com/docs

Arrived from a stack trace? The docsUrl on every error links straight here. Something wrong on this page — tell us.