Fehler in der ebi 6.1 Doku

[phax]

ebInterface 6.1 — Inconsistencies between the specification (.docx) and the XML schema (Invoice.xsd)

• Specification: ebInvoice_6p1.docx (ebInterface 6.1, publication date 29 June 2022).
• Schema: Invoice.xsd (annotation: Schema version 6.1, last update 2022-06-25).

Authority: the XSD is machine-validated and enforced by every conformant tool, so it is treated as authoritative wherever the two disagree.

Summary

#	Category	Element / location	Impact
1	Data type	ListLineItem/TaxItem/TaxableAmount	Spec understates precision (string vs decimal)
2	Cardinality	ListLineItem/TaxItem/TaxAmount	Spec says mandatory, schema says optional
3	Cardinality	ListLineItem/AdditionalInformation	Spec says single, schema allows many
4	Cardinality	ReductionAndSurchargeDetails/OtherVATableTax/TaxPercent	Spec says optional, schema says mandatory
5	Cardinality	ReductionAndSurchargeDetails/OtherVATableTax/TaxAmount	Spec says mandatory, schema says optional
6	Element order	ReductionAndSurchargeDetails/Surcharge	Spec lists children in an order the schema forbids
7	Non-existent element	TaxExemption (referenced in prose)	Spec references an element that does not exist
8	Data type	Tax/TaxItem/AccountingCurrencyAmount/@Currency	Spec type wrong (xs:string vs CurrencyType)
9	Data type	OtherTax/TaxPercent	Spec type understated (Decimal2Type vs TaxPercentType)
10	Data type	SEPADirectDebit/Type	Spec type understated (xs:string vs enum)
11	Table labelling	Tax section (§4.11)	Several rows mislabel Element vs Attribut
12	Doc cross-reference	ListLineItem/Delivery note	Points to the wrong section
13	Schema-only artefact	ConsolidatorsBillerID	Declared in XSD, unused, absent from spec

---

A. Data-type deviations

1. ListLineItem/TaxItem/TaxableAmount — xs:string vs Decimal2Type

• Spec: §4.9.1.2 gives the type as xs:string.
• Schema: TaxableAmount is a single global element type="Decimal2Type" (Invoice.xsd:115), referenced by TaxItemType (Invoice.xsd:635). All other occurrences of TaxableAmount in the spec correctly show Decimal2Type.
• Verdict: specification typo. Correct type is Decimal2Type (2 fraction digits). A validator would reject a non-decimal value regardless of the prose.

8. Tax/TaxItem/AccountingCurrencyAmount/@Currency — xs:string vs CurrencyType

• Spec: §4.11 gives the type as xs:string.
• Schema: AccountingCurrencyAmountType/@Currency is type="CurrencyType" use="required" (Invoice.xsd:248); CurrencyType is a 3-character ISO-4217 token (Invoice.xsd:172).
• Verdict: specification error. Correct type is CurrencyType.

9. Tax/OtherTax/TaxPercent — Decimal2Type vs TaxPercentType

• Spec: §4.11 gives the type as Decimal2Type.
• Schema: the TaxPercent element is globally type="TaxPercentType" (Invoice.xsd:119); TaxPercentType extends Decimal2Type and adds the required attribute @TaxCategoryCode (Invoice.xsd:643-649). OtherTaxType refs this element (Invoice.xsd:506).
• Verdict: specification understates the type. Correct type is TaxPercentType, i.e. OtherTax/TaxPercent must carry a @TaxCategoryCode. (The spec's own row for @TaxCategoryCode under OtherTax confirms the attribute exists — the type cell is simply wrong.)

10. SEPADirectDebit/Type — xs:string vs SEPADirectDebitTypeType

• Spec: §4.12.2 gives the type as xs:string (with the note "Standard ist 'B2C'").
• Schema: Type is type="SEPADirectDebitTypeType" (Invoice.xsd:124), a closed enumeration of B2C and B2B (Invoice.xsd:229-234).
• Verdict: specification understates the type. Only B2C / B2B are valid; an arbitrary string is rejected.

---

B. Cardinality deviations

2. ListLineItem/TaxItem/TaxAmount — 1..1 vs 0..1

• Spec: §4.9.1.2 marks TaxAmount as 1..1 (mandatory) at line level.
• Schema: all TaxItem occurrences use the one TaxItemType, where TaxAmount is minOccurs="0" → 0..1 (Invoice.xsd:637). The spec's own VAT-summary table correctly shows 0..1, so the spec is internally inconsistent too.
• Verdict: correct cardinality is 0..1. A line TaxItem without TaxAmount is schema-valid.

3. ListLineItem/AdditionalInformation — 0..1 vs 0..*

• Spec: §4.9.1 marks line-level AdditionalInformation as 0..1.
• Schema: ListLineItemType refs it with minOccurs="0" maxOccurs="unbounded" → 0..* (Invoice.xsd:465).
• Verdict: correct cardinality is 0..*; multiple AdditionalInformation entries per line are allowed.

4. ReductionAndSurchargeDetails/OtherVATableTax/TaxPercent — 0..1 vs 1..1

• Spec: §4.10 marks the document-level OtherVATableTax/TaxPercent as 0..1.
• Schema: OtherVATableTaxType extends TaxItemType (Invoice.xsd:512-519); in TaxItemType, TaxPercent has no minOccurs → 1..1 (Invoice.xsd:636). The line-level counterpart in the spec correctly shows 1..1.
• Verdict: correct cardinality is 1..1.

5. ReductionAndSurchargeDetails/OtherVATableTax/TaxAmount — 1..1 vs 0..1

• Spec: §4.10 marks the document-level OtherVATableTax/TaxAmount as 1..1.
• Schema: via TaxItemType, TaxAmount is minOccurs="0" → 0..1 (Invoice.xsd:637). The line-level counterpart in the spec correctly shows 0..1.
• Verdict: correct cardinality is 0..1. (Together with Integrate signature validation service of RTR #4 the spec has the two cardinalities of the root OtherVATableTax reversed relative to the schema and relative to its own line-level table.)

---

C. Element-order deviation

6. ReductionAndSurchargeDetails/Surcharge — Classification before Comment

• Spec: §4.10 lists the Surcharge children as … Amount, Classification, Comment, TaxItem. The sibling Reduction table lists Comment before Classification.
• Schema: both Reduction and Surcharge are ReductionAndSurchargeType, which extends ReductionAndSurchargeBaseType. That base type fixes the order as BaseAmount, Percentage, Amount, Comment, Classification, Extension (Invoice.xsd:594-603) — i.e. Comment precedes Classification.
• Verdict: the spec's Surcharge ordering is wrong (and inconsistent with its own Reduction table). A document following the spec's Surcharge order literally would fail schema validation. Correct order: Comment then Classification.

---

D. Reference to a non-existent element

7. TaxExemption

• Spec: §4.9.2 states that tax-exempt entries should not use BelowTheLineItem but rather "the element TaxExemption at invoice-line level".
• Schema: there is no TaxExemption element anywhere in Invoice.xsd (verified against the complete element-declaration block, Invoice.xsd:17-128). VAT exemption is expressed exclusively through TaxItem/TaxPercent/@TaxCategoryCode (D, E, F, G, I, J, K; see appendix §A.2 of the extraction and the TaxCategoryCode code list).
• Verdict: specification error — the referenced element does not exist. This is likely a leftover from an earlier ebInterface version. The prose should point to the @TaxCategoryCode mechanism instead.

---

E. Table-labelling errors in the specification (Element vs Attribut)

In the Tax section (§4.11) the "Typ" column is scrambled for several rows. These are presentation errors only — the @-prefix and the schema make the true nature unambiguous — but they are recorded for completeness.

Row	Spec "Typ"	Correct	Evidence (Invoice.xsd)
Tax/TaxItem/TaxPercent/@TaxCategoryCode	Element	Attribut	TaxPercentType/@TaxCategoryCode (:646)
Tax/TaxItem/AccountingCurrencyAmount	Attribut	Element	element AccountingCurrencyAmount (:19, :638)
Tax/TaxItem/AccountingCurrencyAmount/@Currency	Element	Attribut	AccountingCurrencyAmountType/@Currency (:248)
Tax/OtherTax	Attribut	Element	element OtherTax (:83, :653)

Additionally, the line-level OtherVATableTaxListLineItem/TaxPercent/@TaxCategoryCode row spells the type "Attribute" (English) instead of "Attribut" (German) — a minor typo.

---

F. Internal documentation cross-reference error

12. ListLineItem/Delivery points to the wrong section

• Spec: §4.9.1 says the line-level Delivery element has "the same structure as shown in section 4.4". Section 4.4 is CurrencyExchangeInformation; the Delivery structure is defined in section 4.5.
• Schema: ListLineItemType/Delivery is type="DeliveryType" (Invoice.xsd:461, :360-372), i.e. the header Delivery structure — confirming the intended reference is §4.5.
• Verdict: documentation cross-reference typo (4.4 should read 4.5). No schema impact.

---

G. Schema-only artefact (not in the specification)

13. ConsolidatorsBillerID declared but unused

• Schema: a global element ConsolidatorsBillerID of type="IDType" is declared (Invoice.xsd:41) but is not referenced by any complex type. BillerType uses InvoiceRecipientsBillerID (Invoice.xsd:316), not this element.
• Spec: the element is not documented anywhere in ebInvoice_6p1.docx.
• Verdict: dead/orphan declaration in the schema. It cannot appear in a valid instance (nothing references it), so it has no functional effect, but it is a schema hygiene issue worth cleaning up. Confirm intent with the schema maintainer.