Automation MCP Server Features Blog Pricing Contact
Validation rule Peppol · German national rules

DE-R-001

When both trading parties are German, Peppol BIS activates its German national pack, and the first thing it wants is the same thing XRechnung wants: payment instructions. DE-R-001 fails a domestic German network invoice that does not say how it will be paid.

What DE-R-001 checks

DE-R-001 requires that a domestic German Peppol invoice contain payment instructions, BG-16: cac:PaymentMeans in UBL, with a payment means code and typically an IBAN. Peppol BIS bundles national rule packs that switch on when both parties share the relevant country, and Germany's pack imports the conviction behind BR-DE-1: an invoice a German buyer cannot pay from its own data is incomplete, whichever rail delivered it.

Layer and formats

The finding carries "layer": "cius" and fires when validating against the Peppol BIS profile with both country codes DE. Under options.profile en16931 neither the network overlay nor the national packs apply, which is the correct treatment only for documents that never touch Peppol.

Why it fails in practice

  • The cross-border pipeline meets a domestic pair. The Peppol integration was built for exports, where the pack never fired; the first DE-to-DE invoice surfaces the gap.
  • Payment data lives outside the invoice. Direct debit mandates or standing transfer arrangements exist, so nobody mapped bank details into the document; the rule still requires the group.
  • Credit notes without the payment block. Templates drop payment means for credits; the national pack does not.

How to fix it

Emit the payment means with code and account:

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>58</cbc:PaymentMeansCode>
  <cac:PayeeFinancialAccount>
    <cbc:ID>DE89370400440532013000</cbc:ID>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>

In an InvoiceXML create request the group is invoice.paymentDetails; an IBAN in paymentAccountIdentifier is enough, the means code defaults to 58 (SEPA credit transfer).

The raw rejection vs the InvoiceXML finding

The raw Schematron output does not mention the domestic trigger that activated the rule:

<svrl:failed-assert id="DE-R-001" flag="fatal"
    location="/*:Invoice[namespace-uri()='urn:oasis:names:specification:ubl:schema:xsd:Invoice-2'][1]">
  <svrl:text>An invoice shall contain information on
    "PAYMENT INSTRUCTIONS" (BG-16).</svrl:text>
</svrl:failed-assert>

The InvoiceXML finding does:

{
  "rule": "DE-R-001",
  "layer": "cius",
  "line": null,
  "message": "This is a domestic German invoice (both parties in DE), so Peppol BIS requires payment instructions (BG-16). Add the payment details, e.g. a payment means code and account.",
  "btCodes": ["BG-16"],
  "fields": ["paymentDetails"],
  "raw": "[DE-R-001] CIUS: An invoice shall contain information on \"PAYMENT INSTRUCTIONS\" (BG-16)."
}

The message explains why the rule fired at all, which the raw output never does, and fields names the request object to fill. Your integration keeps no rule-code lookup, and clients localize by the stable rule key.

Check or generate Peppol documents

Validate a domestic German BIS document in the UBL validator to see the national pack fire, or generate with POST /v1/create/ubl, where the current national packs ride along automatically and every document is validated before delivery. The Peppol hub covers the network end to end.

Frequently asked questions

When does DE-R-001 apply?

When the document is validated as Peppol BIS and both the seller's and the buyer's country code are DE. A German seller invoicing into France over Peppol is untouched; a Hamburg company invoicing a Frankfurt one is in scope. The trigger is the country pair, not the access point's location.

What satisfies the rule?

The payment instructions group (BG-16): a payment means type code (BT-81), and in practice an account, for German transfers code 58 with the IBAN in BT-84. It is the same content BR-DE-1 requires on the XRechnung side.

Is DE-R-001 the same as BR-DE-1?

Same requirement, different rulebook. BR-DE-1 comes from KoSIT and fires when validating the XRechnung profile; DE-R-001 comes from OpenPeppol's German national rules and fires on domestic German BIS documents. Which one appears depends on the profile the document was validated under.

Can I make the finding go away without adding payment data?

Only by leaving the Peppol overlay: under options.profile en16931 the national packs do not run. For a document actually travelling the network that is not an option; add the payment details instead.