Attestwire › Rule reference › BR-DE-TMP-32

BR-DE-TMP-32 Add the delivery date or service period

noun · XRechnung · information · BT-72 / BG-14

a reminder, not a rejection.

Your invoice check has reported BR-DE-TMP-32, and it may have done so even though the invoice passed. The invoice does not say when the goods were delivered or the service was performed. This is the least severe kind of finding, and the invoice is not refused for it. It is still worth fixing, and it is usually one field.

Diese Regel auf Deutsch: BR-DE-TMP-32 — auf Deutsch erklärt.

Business term

BT-72 / BG-14 — Delivery date or invoicing period

Severity

information

Applies to

xrechnung-ubl, xrechnung-cii

The fix

For a one-day supply, add the delivery date to your invoice data. In this library the field is deliveryDate. That is one field, not a complete invoice, so replace the fictional date with the real one, regenerate the document from your source data, and check the complete invoice again.

For a service over a period, use the invoicing period instead: invoicingPeriod with startDate and endDate, or a period on each line. In our local example valid stayed true before and after the change, and adding the date removed the information finding. Clearing it does not confirm that the date is right or that a portal will accept the invoice. Check the invoice XML in your browser · Coverage and limits

What the rule requires

The one idea: a German invoice is expected to state the time of supply, and the standard gives you three places to put it. Every field in a European e-invoice has a number, so these are the delivery date (BT-72), the invoicing period for the whole invoice (BG-14, a group of two dates), and a period on each invoice line (BG-26).

XRechnung, Germany’s version of the European e-invoice standard, checks that at least one of them is present, and BR-DE-TMP-32 is the name of that check.

Choose the one that matches what happened. A delivery or one-day service gets the delivery date. A service over a period gets the invoicing period. Lines that cover different periods each get their own. These are alternatives, not a ranking, and you do not have to remove one that applies to add another. Never invent a date to make the finding go away.

A finding is one rule result, and each one has a severity. Fatal findings make the invoice invalid; warnings and information findings are reported and the invoice is still accepted. This one is information, so Attestwire returns it in result.information rather than result.errors. An application that only reads errors will never see it, which is why all three lists are worth inspecting.

Failing and passing

validateInput({
  profile: "xrechnung-ubl",
  invoiceNumber: "2026-000142",
  issueDate: "2026-08-09",
  // no deliveryDate, no invoicingPeriod, no line periods   <- BR-DE-TMP-32
  currency: "EUR",
  buyerReference: "04011000-1234512345-06",
  seller: { /* ... */ },
  buyer:  { /* ... */ },
  lines:  [ /* ... */ ],
});
// -> { valid: true, errors: [], information: [ { rule: "BR-DE-TMP-32", ... } ] }

validateInput({
  profile: "xrechnung-ubl",
  invoiceNumber: "2026-000142",
  issueDate: "2026-08-09",
  deliveryDate: "2026-08-05",
  currency: "EUR",
  buyerReference: "04011000-1234512345-06",
  seller: { /* ... */ },
  buyer:  { /* ... */ },
  lines:  [ /* ... */ ],
});
// -> { valid: true, errors: [], information: [] }

Why it exists

KoSIT, the German office that publishes the official XRechnung checker, raises this rule at severity information. The technical check reports it and accepts the document. The time of supply is still something a German invoice is expected to carry, and its absence tends to be noticed later, by the buyer’s bookkeeping or tax review, rather than by the portal.

Reporting it here brings that discovery forward to a point where you can still correct the source data.

The payload below is the engine message, printed exactly. Its wording that the document is accepted and no validator will stop you describes this one finding at severity information; it does not guarantee that a portal or receiver accepts the invoice.

What the library returns

The full error returned by @attestwire/en16931. It includes the rule ID, affected field and suggested correction. Developers can use this object in their application:

{
  "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 is always a UBL path. On a CII invoice, look for the matching CII field instead.

How our check differs

See also: BR-DE-15 — the other one-field XRechnung fix, with a worked guide.