This blog explains why certain payment scenarios cannot be represented compliantly in SAF‑T (PT) 1.04_01, how this impacts SAP customers today, and what the SAF‑T XSD schema explicitly enforces when it comes to Payments, Customers, and Suppliers. 

Problem Scope 

The issue under discussion affects a very specific but impactful set of scenarios related with incoming manual payments and clearing transactions. 

Typical business cases:  

• A single payment that settles open items for multiple customers 

• Clearing transactions between customer and vendor accounts 

Technical Deep Dive: What the SAF‑T XSD Actually Allows 

To understand why this happens, we need to look directly at the SAF‑T (PT) 1.04_01 XSD schema, not at business expectations. 

The XSD defines a key reference constraint that binds each to exactly one : 

XML 

refer=”CustomerIDConstraint”> 

 A single SAF‑T Payment cannot represent a settlement covering multiple customers, even if the payment exists as one document in SAP. 

Evidence from the Schema 

The Payment section includes the following constraints: 

• PaymentPaymentRefNoConstraint 

• PaymentPaymentRefNoCustomerIDConstraint 

There is no: 

• Alternative party element 

This design clearly indicates that: 

• Payments are customer‑only constructs 

• Supplier involvement is not supported, neither instead nor in addition to customers 

A SAF‑T Payment cannot reference suppliers, and any clearing between customer and vendor accounts inherently violates the schema. 

Closing Thoughts 

Understanding what the SAF‑T schema allows—not what we wish it allowed—is essential for designing compliant solutions. While SAP can improve validations and guidance, certain business scenarios will always require process alignment or redesign to remain SAF‑T compliant. 

Until preventive checks are introduced, customers should be actively discouraged from using multi‑party payment and clearing scenarios when SAF‑T reporting is required. 

Cheers, Elsa