CII (Cross Industry Invoice): Aufbau und Einsatz der UN/CEFACT-Syntax

Herkunft und Rolle

CII stammt von UN/CEFACT, dem Gremium der Vereinten Nationen für Handels- erleichterung und elektronischen Geschäftsverkehr — derselben Organisation, die auch EDIFACT hervorgebracht hat. Die Syntax ist damit älter als EN 16931 und wurde von der Norm übernommen, nicht für sie erfunden.

In der europäischen Formatlandschaft besetzt CII eine klare Position: Überall dort, wo ein Hybridformat im Spiel ist, ist die eingebettete Rechnung eine CII-Datei. ZUGFeRD und Factur-X kennen keine Alternative.

Der Aufbau

CII teilt ein Rechnungsdokument in zwei große Blöcke, und der zweite zerfällt noch einmal in drei:

1rsm:CrossIndustryInvoice
2├── rsm:ExchangedDocumentContext     Kontext: welches Regelwerk gilt (BT-24)
3├── rsm:ExchangedDocument            Kopf: Nummer, Datum, Typ, Bemerkungen
4└── rsm:SupplyChainTradeTransaction
5    ├── ram:IncludedSupplyChainTradeLineItem   die Positionen
6    ├── ram:ApplicableHeaderTradeAgreement     Verkäufer, Käufer, Bestellbezug
7    ├── ram:ApplicableHeaderTradeDelivery      Lieferung, Leistungsdatum
8    └── ram:ApplicableHeaderTradeSettlement    Währung, Steuern, Summen, Zahlung

Diese Dreiteilung — Vereinbarung, Lieferung, Abrechnung — ist der auffälligste Unterschied zu UBL, das die Gruppen flacher nebeneinanderlegt. Sie folgt der Logik eines Handelsvorgangs: was vereinbart wurde, was geliefert wurde, was abgerechnet wird.

Die Namensräume

Drei Präfixe begegnen einem ständig:

Ein Feld an seinem Platz

Die Umsatzsteuer-Identifikationsnummer des Verkäufers (BT-31) liegt in CII hier:

1<ram:ApplicableHeaderTradeAgreement>
2  <ram:SellerTradeParty>
3    <ram:Name>Muster GmbH</ram:Name>
4    <ram:SpecifiedTaxRegistration>
5      <ram:ID schemeID="VA">DE811128135</ram:ID>
6    </ram:SpecifiedTaxRegistration>
7  </ram:SellerTradeParty>
8</ram:ApplicableHeaderTradeAgreement>

Auffällig ist das Attribut schemeID="VA": CII unterscheidet Steuernummer und Umsatzsteuer-ID nicht über verschiedene Elemente, sondern über einen Code am selben Element. VA steht für die Umsatzsteuer-ID, FC für die Steuernummer.

🔴 Das ist eine klassische Fehlerquelle: Wer beide Nummern in dasselbe Element schreibt, ohne den Code zu setzen, erzeugt ein Dokument, in dem der Empfänger die Steuernummer für eine Umsatzsteuer-ID hält.

Beträge tragen ihre Währung mit

Ein zweites Merkmal, das beim Erzeugen auffällt: Geldbeträge stehen in CII nicht nackt da, sondern führen die Währung als Attribut mit — jedenfalls dort, wo die Norm es verlangt.

1<ram:SpecifiedTradeSettlementHeaderMonetarySummation>
2  <ram:LineTotalAmount>1000.00</ram:LineTotalAmount>
3  <ram:TaxBasisTotalAmount>1000.00</ram:TaxBasisTotalAmount>
4  <ram:TaxTotalAmount currencyID="EUR">190.00</ram:TaxTotalAmount>
5  <ram:GrandTotalAmount>1190.00</ram:GrandTotalAmount>
6</ram:SpecifiedTradeSettlementHeaderMonetarySummation>

Dass ausgerechnet TaxTotalAmount das Währungsattribut braucht und die anderen Summen nicht, wirkt willkürlich und ist eine der Regeln, an denen selbst gebaute Erzeuger regelmäßig scheitern.

Wann Sie es mit CII zu tun bekommen

Beim Erzeugen immer dann, wenn das Zielformat ZUGFeRD oder Factur-X ist — dort haben Sie keine Wahl. Bei der XRechnung haben Sie eine, und die Praxis wählt dort meist UBL.

Beim Empfangen immer. Sobald ein Lieferant ein ZUGFeRD schickt, liegt CII auf dem Tisch, unabhängig davon, welche Syntax Sie selbst erzeugen.

💡 Der Rat, der sich daraus ergibt, ist derselbe wie bei UBL: Behandeln Sie die Syntax als Transportdetail. Intern arbeiten Sie mit den BT-Feldern der Norm; CII und UBL existieren nur an der Außengrenze. Dann kostet ein Formatwechsel Konfiguration statt Umbau.