PHP-Entwickler in Wien

#Wer in Österreich E-Rechnungen stellen muss

Die Pflicht trifft nicht jedes Unternehmen, sondern jeden, der an den Bund liefert. Nach § 5 Abs. 2 des IKT-Konsolidierungsgesetzes sind im Waren- und Dienstleistungsverkehr mit Bundesdienststellen alle Vertragspartner verpflichtet, E-Rechnungen auszustellen und zu übermitteln. Die Portalseite e-Rechnung.gv.at nennt als Rechnungsempfänger im Bund alle Bundesministerien mit ihren nachgeordneten Dienststellen, das Parlament, die Präsidentschaftskanzlei, den Verwaltungsgerichtshof, den Verfassungsgerichtshof, die Volksanwaltschaft und den Rechnungshof.

Für alle anderen Empfänger gilt laut derselben Seite derzeit keine gesetzliche Pflicht. Wer also eine Software für Rechnungsstellung baut oder betreibt, entscheidet pro Kunde, ob das Verfahren gebraucht wird: Ein Auftragnehmer, der auch Bundesstellen beliefert, braucht es zwingend, ein reiner Geschäftskundenbetrieb nicht. Die EU-Richtlinie 2014/55/EU verpflichtet die öffentliche Verwaltung in allen Mitgliedsländern seit dem 18. April 2019, E-Rechnungen anzunehmen. Das Verfahren des Bundes steht nach der Rechtsgrundlagenseite auch anderen Empfängern offen, ohne dass dadurch eine Übermittlungspflicht entsteht.

Eine E-Rechnung ist nach § 5 Abs. 1 IKTKonG eine Rechnung, die in einem elektronischen Format ausgestellt, gesendet, empfangen und verarbeitet wird. Das Portal nimmt strukturierte E-Rechnungen entgegen, also XML, und genau dort beginnt die Arbeit für Ihre Anwendung.

#ebInterface: das österreichische XML-Format

ebInterface ist nach Angabe der Wirtschaftskammer der österreichische XML-Standard für die E-Rechnung. Er wird seit 2009 im AUSTRIAPRO-Arbeitskreis E-Billing entwickelt und steht Softwareherstellern kostenlos zur Verfügung. Version 6.1 gibt es seit dem 25. August 2022 und berücksichtigt die Europäische Norm EN 16931-1. Die WKO kündigt auf derselben Seite ebInterface 7.0 mit einem Syntax-Binding zur EN 16931 für das vierte Quartal 2026 an. Welche Versionen der Bund annimmt, führt er auf der Seite der geplanten Änderungen.

Der Bund nimmt nicht jede Version an. Nach e-Rechnung.gv.at gelten die Versionen 4.3, 5.0, 6.0 und 6.1, empfohlen wird 6.1. Die Versionen 4.0 bis 4.2 werden seit dem 6. April 2022 nicht mehr akzeptiert. Neben ebInterface kann der Bund auch UBL einlesen.

Für Rechnungen an die öffentliche Verwaltung gelten nach der Formatseite zusätzliche Befüllregeln, die in keiner allgemeinen ebInterface-Bibliothek von selbst stecken. Die wichtigsten:

• Eine Rechnung darf sich nicht auf mehrere Bestellungen gleichzeitig beziehen.
• InvoiceRecipient/OrderReference/OrderID ist Pflicht und enthält die Auftragsreferenz.
• Ist der Empfänger der Bund und die Auftragsreferenz eine zehnstellige Bestellnummer, braucht jede Rechnungszeile die passende Bestellpositionsnummer.
• Beim Rechnungssteller (Biller) ist mindestens eine E-Mail-Adresse Pflicht, und Biller/InvoiceRecipientsBillerID trägt die Lieferantennummer.
• Es sind höchstens 999 Rechnungs- und Below-the-Line-Zeilen erlaubt.
• Als Zahlungsart sind PaymentCard und OtherPayment nicht zulässig.

Das sind Daten, die Ihre Anwendung beim Kunden oder im Auftrag erfassen muss, bevor die Rechnung entsteht. Fehlt die Auftragsreferenz im Auftragsstamm, lässt sich daran im Rechnungsmodul nichts mehr reparieren. Deshalb gehört die Frage nach den Pflichtfeldern an den Anfang des Projekts und nicht ans Ende.

#So kommt die Rechnung zum Bund: USP oder Peppol

Es gibt zwei Wege. Beide sind auf der Seite zu den Einbringungsarten beschrieben.

Der erste läuft über das Unternehmensserviceportal (USP). Nach der Anmeldung stehen drei Varianten zur Wahl: Online-Formular, händischer Upload einer fertigen E-Rechnung und die automatische Übermittlung per Webservice. Eine Rechnung kann auch ein Dritter, etwa ein Serviceprovider oder ein Wirtschaftsprüfer, im Namen des Rechnungsstellers einbringen. Dann muss der Rechnungssteller selbst nicht am USP registriert sein.

Für eine Anwendung, die Rechnungen ohne Handarbeit verschickt, kommt vor allem das Webservice in Betracht. Nach der Webservice-Seite gilt:

• Der Aufrufer muss USP-Teilnehmer sein und in der Benutzerverwaltung einen Benutzer für Webservices anlegen.
• Empfohlen ist Version 2.0 der Schnittstelle. Die Seite nennt als Endpunkt https://txm.portal.at/at.gv.bmf.erb/V2, verlangt mindestens TLS 1.2 und beschreibt die Schnittstelle als WSDL-Datei.
• Jede Rechnung braucht einen eigenen Aufruf.
• Die Verarbeitung läuft zweistufig: Eine synchrone Antwort meldet, ob das Dokument technisch angenommen wurde. Die endgültige Annahme oder Ablehnung kommt später, standardmäßig per E-Mail, optional an eine Callback-URL, die Sie im Aufruf mitgeben.

Der zweite Weg ist Peppol. Dort melden sich Sender über einen Access Point an, die Authentifizierung läuft über Peppol-Zertifikate, und weder eine USP-Anmeldung noch eine PVP-Anbindung ist nötig. Alle Rechnungsempfänger des Bundes haben dieselbe Peppol-Teilnehmer-ID (9915:b); der eigentliche Empfänger wird aus der Auftragsreferenz in der Rechnung ermittelt. Das Format ist hier UBL nach Peppol BIS Billing 3.0, nicht ebInterface.

Der Unterschied für die Architektur: Beim Webservice hält Ihre Anwendung Zugangsdaten und spricht selbst mit dem Portal. Bei Peppol sitzt dazwischen ein Access Point, etwa bei einem Dienstleister, und Ihre Anwendung übergibt ihm eine UBL-Datei. Welcher Weg besser passt, hängt davon ab, ob der Kunde schon einen Peppol-Anbieter hat und ob er auch Rechnungen an Unternehmen im Ausland stellt.

#Die Rechnung in PHP prüfen, bevor sie das Portal sieht

Das Portal prüft jede eingebrachte Rechnung formal und übernimmt sie erst, wenn sie fehlerfrei ist. Diese Prüfung lohnt sich im eigenen Code vorwegzunehmen, denn die Rückmeldung per E-Mail ist ein schlechter Ort, um Fehler zu finden.

Die Schemaprüfung übernimmt PHP selbst. DOMDocument::schemaValidate() prüft ein Dokument gegen eine XSD-Datei, unterstützt nach der Dokumentation nur XML Schema 1.0 und gibt true oder false zurück. Die Fehlermeldungen holen Sie mit libxml_use_internal_errors() und libxml_get_errors() ab, sonst landen sie als Warnungen im Log. Eine kleine Funktion dafür, die ich auf PHP 8.4 gegen ein Testschema laufen ließ:

<?php
declare(strict_types=1);

function pruefeRechnung(string $xmlPfad, string $xsdPfad): array
{
    $vorher = libxml_use_internal_errors(true);
    $doc = new DOMDocument();
    $fehler = [];

    if (!$doc->load($xmlPfad) || !$doc->schemaValidate($xsdPfad)) {
        foreach (libxml_get_errors() as $e) {
            $fehler[] = sprintf('Zeile %d: %s', $e->line, trim($e->message));
        }
    }

    libxml_clear_errors();
    libxml_use_internal_errors($vorher);

    return $fehler;
}

Zwei Stolpersteine aus den Quellen. Erstens bietet e-Rechnung.gv.at für die Version-Schemas mit den Sonderregeln der öffentlichen Verwaltung nur die geänderte Haupt-XSD an. Die weiteren Schemadateien müssen Sie von der offiziellen ebInterface-Seite laden und daneben ablegen, sonst fehlen der Prüfung die importierten Definitionen. Zweitens fängt ein Schema nur den Aufbau ab, nicht die Fachregeln: Ob OrderID befüllt ist, ob Bestellpositionsnummern vorliegen und ob die Zeilenzahl unter 999 bleibt, prüfen Sie zusätzlich im eigenen Code oder beim Aufbau der Rechnung.

Zum Gegentest bietet das Portal einen Testbereich mit Test-Upload, Test-Formular und einem Werkzeug, das ein ebInterface-Dokument mit Erläuterungen anzeigt. Eine Rechnungsstrecke gehört dort durchgespielt, bevor sie an echte Beschaffer geht.

Im Betrieb zahlt es sich aus, die Übermittlung nicht im Webrequest auszuführen. In Laravel oder Symfony läuft sie als Job in einer Queue, mit gespeicherter Annahmebestätigung, einem Status je Rechnung und einem Wiederholungsversuch bei Ausfall des Portals. Das Portal führt eine eigene Seite zu Wartungsfenstern (Wartungsfenster).

Foto: Diego Delso, CC BY-SA 4.0, Wikimedia Commons.

#Checkliste vor dem ersten Rechnungslauf

#So arbeite ich an einem PHP-Projekt für Wien

Ich bin ein einzelner Entwickler und arbeite ausschließlich remote und schriftlich. Ein Projekt beginnt mit Ihrer schriftlichen Beschreibung: Stack, Version, Ziel, Termin. Offene Fragen stelle ich schriftlich, den Umfang und die Annahmen halte ich ebenso fest, bevor Code entsteht. Die Arbeit läuft auf einer Testumgebung, in kleinen Schritten hinter PHPUnit-Tests und mit statischer Analyse über PHPStan. Sie nehmen Stände dort ab, bevor etwas live geht.

Laravel und Symfony setze ich für neue Anwendungen ein, bestehenden Code ohne Framework baue ich schrittweise um. Layout, Gestaltung und Mockups bringen Sie mit; ich setze sie um und entwerfe sie nicht.

Für die E-Rechnung brauche ich von Ihnen: einen Beispielauftrag mit Auftragsreferenz, Ihre Lieferantennummer, den Zugang zum Test-USP oder die Angabe Ihres Peppol-Anbieters und Beispieldatensätze aus der bestehenden Rechnungsstellung. Den Rest kläre ich schriftlich mit Ihnen.

#Häufige Fragen

#Muss meine Firma in Österreich E-Rechnungen stellen?

Nur gegenüber dem Bund. § 5 Abs. 2 IKTKonG verpflichtet Vertragspartner von Bundesdienststellen. Für andere Empfänger besteht laut e-Rechnung.gv.at derzeit keine gesetzliche Pflicht.

#Welche ebInterface-Version soll ich verwenden?

Der Bund nimmt 4.3, 5.0, 6.0 und 6.1 an und empfiehlt 6.1. Die WKO kündigte im August 2026 ebInterface 7.0 für das vierte Quartal 2026 an. Ob der Bund diese Version annimmt, hängt von seiner Ankündigung ab.

#Kann ich auch Peppol statt des USP-Webservice nutzen?

Ja. Peppol ist ein zweiter Einbringungsweg für den Bund. Er nutzt UBL, einen Access Point und Peppol-Zertifikate statt einer USP-Anmeldung.

#Reicht die Prüfung gegen die XSD-Datei?

Sie fängt Aufbaufehler ab, nicht Fachregeln. Pflichtfelder wie die Auftragsreferenz und die Regeln des Bundes (etwa höchstens 999 Zeilen) prüfe ich zusätzlich im Code. Den Abschluss bildet der Testbereich des Portals.

#Kann das Portal meine Rechnung später ablehnen, obwohl sie angenommen wurde?

Das Webservice meldet zuerst synchron, ob das Dokument technisch in Ordnung ist. Die endgültige Annahme oder Ablehnung kommt danach asynchron, standardmäßig per E-Mail, auf Wunsch an eine Callback-URL. Ihre Anwendung sollte beide Stufen speichern.

#Kommen Sie für die Abstimmung nach Wien?

Nein. Ich arbeite remote, in Schriftform und ohne Termine. Die Abstimmung läuft über E-Mail und Dokumente.

#Schreiben Sie mir

Schicken Sie mir den Stand Ihrer Anwendung (PHP-Version, Framework oder eigener Code), das Ziel, den Termin und die Angabe, ob Rechnungen an den Bund gehen. Meine erste schriftliche Einschätzung bekommen Sie ohne Berechnung, am einfachsten über die Kontaktseite.