[Bug]: [DE] E-Documents for Germany - Missing Mapping for Payment Means

[pri-kise]

Describe the issue

The payment means code in a XRechnung can be different.

It should be possible to setup a mapping for this.

Expected behavior

If a payment mean is e.g. sepa then another value than 68 should be used.

Steps to reproduce

Create a sales invoice with differnt payment method.
Create a XRechnung.

Additional context

See: https://docs.peppol.eu/poacc/billing/3.0/codelist/UNCL4461/

I will provide a fix for a bug

• I will provide a fix for a bug

[pri-kise]

@Groenbech96 I could need your input to this issue.
I'm not sure where it would be useful to add a new field in "Payment Method".

Maybe this should be added to BaseApp? (Similar to the already existing field "Tax Category" that exists in the "VAT Posting Setup")

[miljance]

SEPA is actually 58 right?
Anyway, good question. I am not sure where to put this. I am personally not sure if this belongs to "Payment Method" as the data is currently being fetched from Company Information (IBAN and SWIFT). If feels like it should be possible to setup multiple bank accounts and not always use the one from a Company Information. In this case it probably makes sense to put it in the "Payment Method" but along with Bank Account data.

[github-actions]

This issue has been approved for contribution ✅ Thanks for contributing.

[marschmar]

We got feedback from our customers:
Today the Payment Code 58 is hardcoded, it needs to be mapped from the Payment Methods.
Depending on the code selected, additional elements must also be added to the XRechnung, for example Code 58 and 59:

1. Code 58 SEPA Credit Transfer:

• Element "PayeeFinancialAccount" with at least the ID (IBAN) is necessary:
  cac:PaymentMeans
  cbc:PaymentMeansCode58</cbc:PaymentMeansCode>
  cac:PayeeFinancialAccount
  cbc:IDDE44500105175407324931</cbc:ID>
  </cac:PayeeFinancialAccount>
  </cac:PaymentMeans>

2. Code 59 SEPA Direct Debit:

• Additional PartyIdentification for the AccountSupplierParty with schemeID=SEPA:
  cac:AccountingSupplierParty
  cac:Party
  ...
  cac:PartyIdentification
  <cbc:ID schemeID="SEPA">DE98ZZZ09999999999</cbc:ID> // Bank assigned creditor identifier
  </cac:PartyIdentification>
• PaymentMandate with ID and PayerFinancialAccount is nessary:
  cac:PaymentMeans
  cbc:PaymentMeansCode59</cbc:PaymentMeansCode>
  cac:PaymentMandate
  cbc:IDMANDATE-12345</cbc:ID> // Mandate reference identifier
  cac:PayerFinancialAccount
  cbc:IDDE44500105175407324931</cbc:ID> // Debited account identifier
  </cac:PayerFinancialAccount>
  </cac:PaymentMandate>
  </cac:PaymentMeans>

For Credit Memos and Code 58 the IBAN of the customer (= Payee) must be used.

Source: https://xeinkauf.de/app/uploads/2024/07/302-XRechnung-2024-06-20.pdf

[pri-kise]

I did some research with the help of AI, too:
This was my result:

The content is strictly aligned to XRechnung 3.0.2 CIUS**, including BR‑DE‑23 / 24 / 25 and PEPPOL‑EN16931‑R061.

---

XRechnung 3.0.2 — Payment Means (BT‑81)

Complete implementation & validation guide

---

1. Core model overview

Semantic → XML mapping (important!)

Semantic element	EN 16931 ID	UBL XML
Payment means type code	BT‑81	cbc:PaymentMeansCode
Payment instructions	BG‑16	cac:PaymentMeans
Credit transfer	BG‑17	cac:PayeeFinancialAccount
Payment card info	BG‑18	cac:PaymentCard
Direct debit	BG‑19	cac:PaymentMandate
Mandate reference	BT‑89	cbc:ID (inside BG‑19)

---

2. Decision matrix (canonical)

This table is the single source of truth

BT‑81 code	Payment type	BG‑17 (Credit Transfer)	BG‑18 (Card Info)	BG‑19 (Direct Debit)	Mandate required	Rule
30	Credit transfer (non‑SEPA)	✅ MUST	❌ MUST NOT	❌ MUST NOT	—	BR‑DE‑23
58	SEPA credit transfer	✅ MUST	❌ MUST NOT	❌ MUST NOT	—	BR‑DE‑23
48	Credit card	❌ MUST NOT	✅ MUST	❌ MUST NOT	—	BR‑DE‑24
54	Debit card	❌ MUST NOT	✅ MUST	❌ MUST NOT	—	BR‑DE‑24
55	Payment card	❌ MUST NOT	✅ MUST	❌ MUST NOT	—	BR‑DE‑24
70	Card payment	❌ MUST NOT	✅ MUST	❌ MUST NOT	—	BR‑DE‑24
49	SEPA direct debit	❌ MUST NOT	❌ MUST NOT	✅ MUST	✅ BT‑89 mandatory	BR‑DE‑25 + R061
59	SEPA direct debit (alt)	❌ MUST NOT	❌ MUST NOT	✅ MUST	✅ BT‑89 mandatory	BR‑DE‑25 + R061
1	Cash	optional	optional	optional	—	—
10	In kind	optional	optional	optional	—	—
20	Cheque	optional	optional	optional	—	—
31	Credit transfer (alt)	optional	optional	optional	—	—
42	Bank account	optional	optional	optional	—	—
97	Clearing / compensation	optional	optional	optional	—	—

---

3. Business rules (plain English)

BR‑DE‑23 — Credit transfers

IF BT‑81 ∈ {30, 58}
THEN
  BG‑17 MUST exist
  BG‑18 MUST NOT exist
  BG‑19 MUST NOT exist

---

BR‑DE‑24 — Card payments

IF BT‑81 ∈ {48, 54, 55, 70}
THEN
  BG‑18 MUST exist
  BG‑17 MUST NOT exist
  BG‑19 MUST NOT exist

---

BR‑DE‑25 — Direct debit

IF BT‑81 ∈ {49, 59}
THEN
  BG‑19 MUST exist
  BG‑17 MUST NOT exist
  BG‑18 MUST NOT exist

---

PEPPOL‑EN16931‑R061 — Mandate reference

IF BT‑81 ∈ {49, 59}
THEN
  BT‑89 (Mandate reference) is mandatory

---

4. UBL‑level XML paths

Semantic	XML path
Payment means	/Invoice/cac:PaymentMeans
Payment means code	cbc:PaymentMeansCode
Credit transfer	cac:PayeeFinancialAccount
Payment card	cac:PaymentCard
Direct debit	cac:PaymentMandate
Mandate reference	cac:PaymentMandate/cbc:ID

---

5. XML examples (copy‑ready)

---

✅ SEPA Credit Transfer (BT‑81 = 58)

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

✔ valid
✘ do not add PaymentCard or PaymentMandate

---

✅ Card payment (BT‑81 = 48, 54, 55, 70)

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>48</cbc:PaymentMeansCode>
  <cac:PaymentCard>
    <cbc:PrimaryAccountNumberID>1234********5678</cbc:PrimaryAccountNumberID>
    <cbc:HolderName>MAX MUSTERMANN</cbc:HolderName>
  </cac:PaymentCard>
</cac:PaymentMeans>

✔ valid
✘ do not add IBAN
✘ do not add mandate

---

✅ SEPA Direct Debit (BT‑81 = 49 or 59)

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>49</cbc:PaymentMeansCode>
  <cac:PaymentMandate>
    <cbc:ID>MANDATE-REF-12345</cbc:ID>
    <cbc:PayerFinancialAccountID>DE44500105175407324931</cbc:PayerFinancialAccountID>
    <cbc:ID schemeID="SEPA Creditor ID">DE98ZZZ09999999999</cbc:ID>
  </cac:PaymentMandate>
</cac:PaymentMeans>

✔ valid
❗ Without BT‑89 this MUST be rejected

---

✅ Cash (BT‑81 = 1)

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>1</cbc:PaymentMeansCode>
</cac:PaymentMeans>

✔ no dependent groups required

---

6. Validation / schematron checklist

Absolute MUSTs

• cac:PaymentMeans exactly once
• cbc:PaymentMeansCode exactly once
• All nodes MUST match BT‑81 dependency rules

---

Common fatal errors

Error	Why
Card payment + IBAN	BR‑DE‑24 violation
Credit transfer + mandate	BR‑DE‑23 violation
Direct debit without mandate reference	EN16931‑R061 violation
Mixing BG‑17 + BG‑18	Illegal combination
Multiple PaymentMeans	XRechnung disallows
Empty payment group	PEPPOL‑R008

---

7. Developer implementation checklist ✅

• Map BT‑81 early (business logic)
• Instantiate only the allowed BG group
• Block all forbidden combinations
• Enforce BT‑89 mandatory for 49 / 59
• Validate using Schematron XRechnung 3.0.2
• Add regression tests per BT‑81 value

---

8. Quick mnemonic

IBAN     → 30 / 58 → BG‑17
CARD     → 48 / 54 / 55 / 70 → BG‑18
MANDATE  → 49 / 59 → BG‑19 + BT‑89

Conclusion

We don't have some of the data in Business Central by default.
Therefore I thought about adding events for partners

[miljance]

Yes, that sounds correct. I guess we have to go with the payment means. From my side I would like to see this implemented ASAP. Our customers reported is as well.

[miljance]

Would be great to do that for ZUGFeRD as well.

[marschmar]

For the most commonly used payment means, data is available in Business Central via Bank Account, Customer Bank Account, and SEPA Direct Debit Mandates.

The examples from the AI research are incorrect, for example:

✅ SEPA Direct Debit (BT‑81 = 49 or 59)

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>49</cbc:PaymentMeansCode>
  <cac:PaymentMandate>
    <cbc:ID>MANDATE-REF-12345</cbc:ID>
    <cbc:PayerFinancialAccountID>DE44500105175407324931</cbc:PayerFinancialAccountID>
    <cbc:ID schemeID="SEPA Creditor ID">DE98ZZZ09999999999</cbc:ID>
  </cac:PaymentMandate>
</cac:PaymentMeans>

This results in validation errors.

Until these payment methods are supported, our customers will not be able to take full advantage of the e-documents. An asap implemention would be great.