What it means
Each ram:PayerTradeParty under ram:ApplicableHeaderTradeSettlement may contain zero or one direct ram:SpecifiedTaxRegistration child. This rule does not decide which tax registration you should use.
Why it matters
The Extended profile allows only one tax registration block within each payer block.
How to fix it
Check which payer tax registration belongs in this invoice. Keep that registration in one ram:SpecifiedTaxRegistration under ram:ApplicableHeaderTradeSettlement/ram:PayerTradeParty and remove additional blocks from the export. Do not delete valid tax details from your payer records just to correct the XML. Check the corrected file again.
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:SpecifiedTaxRegistration' 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-000931 still fails, and which other rules do.
Related rules
- 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
- FX-SCH-A-000937 Give the payer's postal address one country element