3 · Drei Tore, nicht eines

Die verbreitete Kurzfassung des Engpasses lautet: es fehlt ein Vertrag. Das ist richtig, und es ist die kleinere Hälfte. Wer die Transmitter-Spezifikation der Swissdec vom 06.03.2026 («Technische Spezifikation eBILANZ · Version 20260306 · Anforderungen Transmitter») zusammen mit den 35 mitgelieferten XML-Schemata, der einen WSDL-Datei und den elf SOAP-Beispielen liest, findet nicht eine Zulassungsbedingung, sondern drei — vertraglich, zertifikatsbezogen, identitätsbezogen. Sie sind voneinander unabhängig, jede ist einzeln dokumentiert, und jede müsste einzeln fallen. Die dritte liegt am weitesten vom Steuerrecht entfernt: Die Identität eines Schweizer Unternehmens auf dem nationalen Übermittlungsnetz wird über dessen Versicherer bewiesen.

Tor 1 — der Vertrag

Unmittelbar unter der Kommunikationsmatrix (Tabelle 2.1, Teil 2) steht eine Anmerkung. Sie wird in der Debatte regelmässig halb zitiert. Vollständig lautet sie:

«Aus vertragsrechtlichen und statuarischen Gründen seitens Swissdec können aktuell nur kantonseigene Deklarationslösungen die E-Bilanz via Distributor elektronisch empfangen. Für die Anbindung von privaten Deklarationslösungen an den Distributor müssen zuerst die vertraglichen Grundlagen geschaffen werden.»

— Swissdec, Technische Spezifikation eBILANZ, Ausgabe 06.03.2026, Kap. 2, Anmerkung unmittelbar unter Tabelle 2.1 (statuarischen sic)

Drei Beobachtungen, die nur der Volltext hergibt.

Erstens: «seitens Swissdec». Der Halbsatz benennt den Träger der Schranke. Es ist keine Vorschrift des Bundes, keine der Schweizerischen Steuerkonferenz, keine eines Kantons. Es ist die vertragliche und statutarische Lage des Vereins, der das Netz betreibt — beschrieben von diesem Verein selbst. Wer die Schranke fallen sehen will, weiss damit, an welchen Tisch er sich setzen muss.

Zweitens: die zwei Lesarten. Satz 1 spricht vom Empfangen — «können aktuell nur kantonseigene Deklarationslösungen die E-Bilanz via Distributor elektronisch empfangen». Eng gelesen regelt er, wer Adressat einer DeclareRawBalanceSheet sein darf, also die Zielseite der XBRL-Spur. Satz 2 verallgemeinert: er spricht von «der Anbindung von privaten Deklarationslösungen an den Distributor» als solcher, ohne Richtung. Die beiden Sätze sagen nicht dasselbe. Diese Unschärfe gehört offen benannt, statt in die eine oder andere Richtung aufgelöst zu werden — denn dieselbe Matrix, über der die Anmerkung steht, enthält bereits eine nummerierte Zeile DISTRRIBUTOR[2] (sic, drei R) für den Weg Private Deklarationslösung → SwissdecAdapter, Teil 7, DeclareBalanceSheet, eCH-0276. Und die Prozessbeschreibung in §2.2 führt die «Private Deklarationslösung Transmitter» als drittes von drei beteiligten Systemen auf. Die Architektur kennt diesen Akteur. Ausgesetzt ist er, nicht ausgeschlossen.

Drittens: «zuerst». Das Wort setzt ein «dann» voraus. Es ist vorwärtsgerichtet, nicht abschliessend. Ein Satz, der eine Kategorie dauerhaft ausschliessen wollte, käme ohne dieses Adverb aus. Das ist keine Zusage und keine Frist — aber es ist der Unterschied zwischen einer Wand und einer Tür ohne Schlüssel.

Eine Randnotiz zur Sorgfalt: Wir zitieren diese Stelle strukturell, nicht mit Seitenzahl. Unsere eigene Extraktion legt sie zwischen die Seitenmarke 6 und die Überschrift §2.1; eine eigene frühere Notiz nennt «§2, S. 6». Wo wir die Seite nicht sicher belegen können, nennen wir sie nicht.

Tor 2 — die Zertifizierung

Das zweite Tor steht nicht in der Prosa, sondern in der Schnittstellenbeschreibung. schema/BalanceSheetDeclarationService.wsdl (SHA-256 3ca8a5806b283649b154bb79008fb4bbc6e7ed2f8ca811ce18a0e88af7175879) definiert sieben Operationen. Sechs davon tragen eine wortgleiche wsdl:documentation:

This operation must be signed by: ERP Certificate

Betroffen sind DeclareRawBalanceSheet, SynchronizeDeclareRawBalanceSheet, DeclareBalanceSheet, GetStatusFromDeclareBalanceSheet, SynchronizeDeclareBalanceSheet und CheckInteroperability. Die siebte, Ping, trägt:

This operation must be signed by: None

Das deckt sich mit §8.15 der Richtlinien: «Ausser dem Erreichbarkeitstest muss jede Übermittlung signiert und verschlüsselt werden.» Alles, was Daten trägt, braucht ein Zertifikat; der blosse Anklopf-Aufruf nicht.

Zum Namen dieses Zertifikats: Es gibt in der veröffentlichten Schnittstelle keine eigene Berechtigungsklasse für eine Deklarationslösung. Auch die beiden Operationen, die nach Tabelle 2.1 ausschliesslich von Deklarationslösungen aufgerufen werden — kantonseigenen wie privaten —, verlangen ein «ERP Certificate», also die Berechtigung des Akteurs der anderen Spur. Das ist zunächst eine Beobachtung über Wortlaut, nicht über Absicht. Aber sie hat eine praktische Kante: Ein Anbieter, der heute den Zertifizierungsprozess durchlaufen wollte, fände in der Schnittstelle keinen Ausweis, der auf ihn gemünzt wäre.

Wie dieser Ausweis in der Nachricht erscheint, sagt Tabelle 4.2 beziehungsweise 8.3, UserAgentType, wörtlich:

Certificate — «Zertifikatsnummer, xxxx.yy wie auf dem physischen Zertifikat abgebildet»

Producer — «Name des Softwareherstellers»

Und §8.1.1.1 setzt nach — die Stelle ist im Original mit einem fett gesetzten Warnwort markiert: «Der UserAgent muss im Anschluss an die abgeschlossene Swissdec-Zertifizierung aktualisiert werden und muss sämtliche Informationen zum ERP-System (und nicht zum Endbenutzer) enthalten.»

Damit ist der Befund präzise: Jede Nachricht auf dieser Leitung trägt den Namen des Softwareherstellers und eine physische Zertifikatsnummer. Funktional ist das ein Zulassungsregister pro Hersteller, geführt an der Schnittstelle selbst. Wir schreiben diesen Satz aus einem Haus, das genau so etwas hält: eine deutsche Hersteller-ID, die in jeder von uns übermittelten Erklärung mitläuft und über die die Finanzverwaltung monatlich zählt, wie viele echte Nutzdatenblöcke wir abgesetzt haben. Ein Herstellerregister ist kein Skandal; es ist ein bewährtes Instrument, und es hat einen Preis, den man kennen sollte, bevor man ihn zahlt: Wer nicht drin ist, existiert auf der Leitung nicht.

Wie früh das Programm steht, zeigen die ausgelieferten Beispiele. In allen elf SOAP-Samples des Pakets steht <ep:Producer>Swissdec</ep:Producer>, <ep:StandardVersion>0.0</ep:StandardVersion> und <ep:Certificate>n/a</ep:Certificate>. Die Zertifizierungsstufe für eBILANZ 1.0 ist in den mitgelieferten Artefakten noch nicht nummeriert.

Tor 3 — SUA, und woran ein Unternehmen erkannt wird

Das dritte Tor betrifft nicht die Software, sondern das einreichende Unternehmen. Anhang C beschreibt die «Swissdec Unternehmens-Authentifizierung» (SUA). C.1, wörtlich:

«Grundlage einer SUA Registrierung ist eine bestehende Geschäftsbeziehung des Unternehmens zu einer Versicherung, welche Identität des Unternehmens bereits geprüft hat. Auf diese überprüfte Identität stützt sich Swissdec für die Identifikation des Unternehmens. Der Distributor prüft während der Registrierung die Angaben zum Unternehmen sowie die bestehende Vertragsbeziehung beim Versicherer.»

Die Pflichtangaben, ebenfalls wörtlich aus der Tabelle: Name des Unternehmens «Identisch mit Angaben aus dem UID-Register»; UID-Nummer identisch mit UID-Register und mit den Angaben beim Versicherer; «Bestehende Vertragsverbindung (Vertragsnummer und Kundenummer)» — identisch mit den Angaben beim Versicherer.

Für die Stellvertretung gilt C.2.1.1:

«Als Sicherheitsmassnahme muss der identische Stellvertreter beim Versicherer auch hinterlegt sein, was der Distributor im Rahmen der Registrierung überprüft.»

Wir schreiben diesen Satz flach hin und quellen ihn. Eine Treuhandgesellschaft, die für eine Mandantin auf diesem Weg registrieren will, muss beim Versicherer der Mandantin hinterlegt sein. Was daraus für eine Treuhandgesellschaft folgt, die für mehrere Mandantinnen registrieren will, steht in den Unterlagen nicht; C.2.1.1 regelt den einzelnen Stellvertreter.

Die Zugangsdaten kommen nicht elektronisch. C.2.1: C.2.1:

«Zu diesem Zeitpunkt wird ein Brief an die beim Versicherer hinterlegten Adresse des Unternehmens gesendet. Dieser Brief enthält ein einmaliges Registrierungspasswort sowie das Sperrpasswort. Der physische Versand wird aus Sicherheitsgründen gemacht …»

(im extrahierten Text «Brief and die», sic)

Die Parameter, aus der Tabelle C.3.1: Sicherheitsmerkmal der Registrierung «Brief/ A+», ausdrücklich als «Zweiter, nicht elektronsicher Kanal» (sic); Registrierungspasswort mindestens 12 Zeichen, gültig 1 Jahr; Sperrpasswort mindestens 12 Zeichen, gültig 5 Jahre; Erneuerungsfenster 60 Tage vor Ablauf; «3x (3 Jahre) Anzahl möglicher automatischer Erneuerungen» — danach, C.2.3: «Ist eine Zertifikat abgelaufen, kann die Erneuerung nicht mehr durchgeführt werden. In diesem Fall muss eine neue Registrierung durchgeführt werden.» Das Zertifikat selbst ist X.509v3 nach RFC 5280, Aussteller CN = Verein Swissdec Issuing CA by DigiCert, Subject CN = NTRCH-{UID}@swissdec.ch, O = {Name aus dem UID Register}, Gültigkeit 1 Jahr.

Und dann die Beobachtung, die keine Wertung braucht: Ein Unternehmen ohne swissdec-angebundene Versicherungsbeziehung hat in diesen Unterlagen keinen dokumentierten Zugang. Nicht «einen schwierigen». Keinen beschriebenen. Das steht so nirgends als Ausschluss — es ergibt sich daraus, dass die Registrierung keine zweite Wurzel kennt.

Woher das Fahrgestell stammt

Das erklärt sich, sobald man zählt, worauf dieses Netz gebaut ist. Das Glossar in Anhang B definiert Domäne als: «Im Swissdec-Ökosystem bekannte Domänen sind; AHV, FAK, UVG, UVGZ, KTG, BVG, Lohnausweis, Quellensteuer, Grenzgänger und Statistik.» Die E-Bilanz steht nicht in der Liste der bekannten Domänen ihrer eigenen Spezifikation. Institution heisst dort: «Empfänger, der Daten erhält. Hier handelt es sich um Versicherungen, die den jeweiligen Domänen angehören.» Beträge sind durchgehend vom Typ ep SalaryAmountType — auch die beiden Operanden und die Ergebnisse des Interoperabilitätstests. Und §8.1.1.2, in einer Bilanzspezifikation: «Es wird empfohlen, dass bei der Übermittlung grösserer Datenmengen (>2000 Personen) die Daten bereits vorher gefiltert werden.»

Das ist zitiert, weil das Vokabular den Ursprung des Netzes zeigt. Ein Netz, das seit Jahren Lohndaten an Versicherer verteilt, bekommt eine zweite Fracht aufgeladen, und das Vokabular ist noch das alte. Genau deshalb wird Identität über den Versicherer bewiesen: Für die Fracht, für die dieses Fahrgestell gebaut wurde, ist eine Versicherungsbeziehung keine Voraussetzung, sondern der Geschäftszweck.

Die Adresse, und das vierte Tor

Der Endpunkt steht in derselben WSDL, als das, was er ist:

<soap:address location="https://distributor.swisscom.com/services/ebilanz/BalanceSheet/V1"/>

Wir nennen die URL und behaupten nichts über die Vereinbarung dahinter. Wir haben diesen Endpunkt nie aufgerufen — nicht einmal Ping, die eine Operation, die dafür kein Zertifikat verlangt.

Drei Tore also, und keines davon ist technisch: ein Vertrag, der laut seiner eigenen Trägerin erst zu schaffen ist; ein Ausweis, der nach dem Akteur der anderen Spur benannt ist; eine Identität, die an einem Versicherungsvertrag hängt. Für Zürich kommt ein viertes hinzu, das auf einer ganz anderen Ebene liegt und mit dem nationalen Netz nichts zu tun hat: ein Login, das nach Auskunft des Kantons «immer eine natürliche Person» repräsentiert. Es heisst AGOV, und es wird in Teil 5 aufgelöst.

Alle vier sind Entscheidungen. Entscheidungen haben Urheber, und Urheber können sie ändern.

---