DATEV E-Rechnungsplattform anbinden: Das Dokument reist, die Plattform leitet

Sie ist DATEVs Plattform, um elektronische Rechnungen in einem konformen Format zu senden und zu empfangen, und ihre Rolle innerhalb der DATEV-Landschaft ist Transport. Sie ist kein Buchhaltungssystem und kein Ersatz dafür: sie verbindet einen Rechnungsprozess mit einem Netz, und sie verbindet dieses Netz mit den Anwendungen, in denen die Rechnung geprüft und gebucht wird.

Die Formate, die sie trägt, sind die deutschen Standards XRechnung und ZUGFeRD, und das Netz, über das sie sie trägt, ist PEPPOL. Für einen Softwareanbieter bedeutet das weniger, als die Produktseite vermuten lässt: die Plattform steckt tief in DATEV, sie ist für Sie also dann relevant, wenn Ihr Produkt Ausgangsrechnungen für Kunden erzeugt, die in DATEV arbeiten.

Wo sie zwischen den Teilen steht, die eine Schnittstelle haben, gehört früh geklärt. Die DATEV-Übersicht nennt die Datenservices und ihre zwei Zielprodukte, und diese Plattform ist der eine DATEV-Baustein in diesem Bild ohne eigenes Zielsystem.

PEPPOL ist ein Netz, um Rechnungen und andere Geschäftsdokumente standardisiert auszutauschen, ursprünglich eine EU-Initiative für die grenzüberschreitende Beschaffung. Für eine Anbindung zählt seine Form: Dokumente reisen nicht direkt vom Absender zum Empfänger.

Sie reisen durch das Vier-Ecken-Modell. Der Absender gibt das Dokument an seinen eigenen Access Point, dieser Access Point stellt es dem Access Point des Empfängers zu, und der Empfänger erhält es von seinem. Zwei Vermittler, beide zertifiziert, und keiner von beiden gehört dem Absender oder dem Empfänger.

Die DATEV E-Rechnungsplattform ist der Access Point für ein Unternehmen, das in DATEV arbeitet. Die Frage für Ihr Produkt ist also nicht, wie man PEPPOL spricht. Sie lautet, ob Sie Ihren eigenen Access Point mitbringen oder den Ihres Kunden nutzen.

Beide Antworten sind legitim und führen zu unterschiedlicher Arbeit. Mit einem eigenen Access Point oder einem Dienstleister senden und empfangen Sie unabhängig davon, welches Buchhaltungsprodukt der Kunde fährt. Ohne einen ist die Plattform, die Ihr Kunde ohnehin hat, der Weg, und Ihre Aufgabe endet bei der Übergabe des Dokuments.

Zwei Richtungen, und sie sind auf eine Weise ungleich, die darüber entscheidet, ob Ihr Produkt überhaupt beteiligt ist.

Eingehend. Ein Lieferant sendet eine Rechnung über PEPPOL, die Plattform nimmt sie in ihren E-Rechnungs-Eingang auf, und sie wandert weiter nach DATEV Unternehmen Online. Dort gibt ein Mensch sie frei und eine Zahlung kann angestoßen werden, und die strukturierten Daten erreichen DATEV Rechnungswesen für die Buchführung, im Haus oder in der Kanzlei.

Ausgehend. Eine Rechnung entsteht in einer Rechnungsanwendung, und das kann Ihre sein. Sie geht an die Plattform, die Plattform sendet sie über PEPPOL, und im selben Schritt wird sie Unternehmen Online bereitgestellt, damit die Buchhaltungsseite sie ebenfalls hat.

Liest man beide zusammen, ist die Ungleichheit der Punkt: der eingehende Weg läuft von einem DATEV-Baustein zum nächsten und verlässt das Ökosystem nie. Externe Software hat darin nichts zu tun. Der ausgehende Weg beginnt dort, wo die Rechnung entsteht, und dort lebt ein Produkt wie Ihres.

DATEV führt die Schnittstelle der Plattform unter ihren Datenservices als TRAFFIQX Invoice API, beschrieben als bidirektionaler Datenaustausch mit der DATEV E-Rechnungsplattform und mit weiteren Anbietern im TRAFFIQX-Netzwerk. Sie läuft auf der Online-API traffiqx:invoice und bringt eigene Schnittstellenvorgaben mit, dieselbe Form von Freigabeprozess wie jeder andere DATEV-Datenservice.

Wie die Endpunkte aussehen und welche Formate sie nehmen, steht hinter diesem eigenen Vorgabendokument. Planen Sie eine Funktion deshalb mit DATEV dagegen und nicht gegen diesen Absatz. Rechnungen, die aus externer Software versendet werden, kosten auf DATEVs Seite je Ausgangsrechnung, und das gehört früh ins Gespräch.

Was von dieser Antwort nicht abhängt, ist eine E-Rechnungs-Funktion, denn die Rechnung selbst ist ein Dokument, und der Dokumentweg nach DATEV ist dokumentiert und offen. Diesen Weg beschreibt der Rest dieses Artikels.

Die ehrliche Architektur hat heute also zwei Hälften. Der Transport über PEPPOL ist die Plattform Ihres Kunden oder Ihr eigener Access Point. Die Buchhaltungsseite, also das Dokument und der strukturierte Datensatz, die dort ankommen, wo die Kanzlei arbeitet, ist der bestehende Weg über Unternehmen Online.

Liefern Sie die Rechnung als Dokument, und liefern Sie die Daten dazu als Datensatz. Das ist derselbe zweiteilige Schreibvorgang, den jedes andere Dokument nach DATEV Unternehmen Online nimmt, und eine elektronische Rechnung ist davon kein Sonderfall.

Ein Detail entscheidet, ob Ihr Upload angenommen wird, und es ist eine Eigenschaft des DATEV Ihres Kunden und nicht Ihres Codes. Welche Dateiendungen ein Mandant hochladen darf, hängt am DATEV-Status dieses Mandanten, und DATEV stellt diese Liste je Mandant bereit. Die robuste Umsetzung liest sie beim Verbinden, statt einen festen Satz anzunehmen.

Über maesn ist jede der beiden Hälften ein Aufruf gegen das Common Data Model, und der Leitfaden zu DATEV Unternehmen Online hat die Mechanik: jeder Schreibvorgang ist asynchron, die Task-ID ist die einzige Bestätigung, und das Dokument und der Datensatz reisen über zwei verschiedene DATEV-Datenservices.

Zu welchem der beiden DATEV-Produkte eine Nutzlast gehört, ist eine eigene Entscheidung, und der Vergleich der beiden Produkte beantwortet sie von der Objektseite her. Für die strukturierte Hälfte entscheidet das Ziel über das Format und nicht die Vorliebe, und das legt der Leitfaden zu den DATEV-Formaten dar.

Vier Bedingungen, und es braucht alle vier:

• Ihr Produkt erzeugt Ausgangsrechnungen, die in einem konformen elektronischen Format hinausgehen müssen.
• Sie sind nicht für eingehende Lieferantenrechnungen zuständig, was der Normalfall ist, weil dieser Weg innerhalb von DATEV bleibt.
• Ihre Kunden arbeiten im DATEV-Ökosystem, entweder mit Buchführung im Haus oder mit einer Kanzlei.
• Sie bringen keine eigene PEPPOL-Anbindung mit, der Transport muss also über den Access Point eines anderen laufen.

Gilt die vierte nicht, steht diese Plattform gar nicht auf Ihrem kritischen Pfad: Sie senden über Ihren eigenen Access Point und nutzen den DATEV-Weg nur für die Buchhaltungskopie. Gelten alle vier, ist Ihre Arbeit heute die Übergabe des Dokuments, und der Transport ist eine Einstellung auf der Seite Ihres Kunden.

Zwei Dinge nimmt maesn ab, und beide betreffen die Buchhaltungsseite:

• Das Dokument und den Datensatz. Ein Datenmodell, ein Account-Key, und die Übersetzung in die DATEV-Datenservices und ihre Formate passiert hier.
• Den Zugang zu DATEV ohne vorherigen Partnerprozess. Sie bauen auf dem maesn-Client, es muss also nichts beantragt, bezahlt oder abgewartet werden, bevor Sie Ihren ersten Aufruf machen. Offizieller DATEV Schnittstellenanbieter im eigenen Namen zu werden ist später ein Prozess, den wir mit Ihnen gehen, und die DATEV-Gebühren dafür sind Ihre.

Drei Dinge bewegen sich nicht:

• Der PEPPOL-Transport. Ein Access Point ist ein Vertrag und ein Dienst, kein Feld in einer Schnittstelle. Ihrer oder der Ihres Kunden, und diese Wahl ist eine Produktentscheidung.
• Der Rechnungsinhalt und seine Gültigkeit. XRechnung und ZUGFeRD haben Regeln, und die Rechnung, die Ihr Produkt erzeugt, muss sie erfüllen, bevor sie irgendetwas transportiert.
• Was Sie zum Zeitplan zusagen. DATEV veröffentlicht nicht, was die TRAFFIQX Invoice API abdeckt, eine Roadmap, die an einer bestimmten Fähigkeit davon hängt, ist deshalb ein Risiko, das man offen trägt.