What it means
The payer (ram:PayerTradeParty), the party that pays the invoice when that is not the buyer, may have one electronic address, such as an email address or a Peppol ID (ram:URIUniversalCommunication). The rule fails when there are two or more such blocks.
Why it matters
The Extended profile allows a single electronic address for the payer. Extra blocks do not fit the structure, so the file fails the check and the recipient can reject it.
How to fix it
In your invoicing software, check the payer's details and keep one electronic address. If you need to give more than one way to reach the payer, use the contact details instead. In the XML, ram:PayerTradeParty may contain one ram:URIUniversalCommunication.
Once the file is corrected, check it again for free: Validate a ZUGFeRD invoice
Or fix the invoice in a form and download the corrected file, for 1 credit: Fix a rejected e-invoice Beta
The rule as published
Element 'ram:URIUniversalCommunication' may occur at maximum 1 times. Where this rule applies
| Rule set | Version |
|---|---|
| Factur-X 1.09 EXTENDED | 1.0.9-2 |
| ZUGFeRD 2.5 EXTENDED | 2.5.2 |
Check your file
Drop your e-invoice to see whether FX-SCH-A-000930 still fails, and which other rules do.
Related rules
- FX-SCH-A-000931 Use at most one payer tax registration block
- FX-SCH-A-000932 Give the payer's contact email block one address element
- FX-SCH-A-000933 Give the payer's fax block one number element
- FX-SCH-A-000934 The payer's telephone block needs exactly one number
- FX-SCH-A-000935 Add the scheme attribute to the payer's global identifier
- FX-SCH-A-000936 Use a permitted scheme for the payer's global identifier