Zum Inhalt springen

EBPP

aus Wikipedia, der freien Enzyklopädie
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 31. Mai 2010 um 08:47 Uhr durch Bloodhound sf (Diskussion | Beiträge). Sie kann sich erheblich von der aktuellen Version unterscheiden.

EBPP ist die Abkürzung für electronic bill presentment and payment ("elektronische Rechnungsstellung und -bezahlung"). Hierbei kann es sich um eine auf E-Mail basierende Lösung bis hin zu einem kompletten, elektronischen Zahlungssystem handeln.

Man unterscheidet bei EBPP-Systemen folgende Kriterien und Funktionalitäten:

  • Format der Rechnungsdaten
    • strukturiert: XML, WebInterface, EDIFACT, etc.
    • nicht strukturiert (nicht automatisiert weiterverarbeitbar): PDF, TIFF, JPEG, etc.
  • Bill presentment - Präsentation der Rechnung
  • Bill payment - Bezahlungsmöglichkeit

Weiterhin lassen sich zwei verschiedene Modelle des EBPP unterscheiden:

  • Das Direct Billing Modell
  • Das Consolidator Modell

Direct Billing Modell

Das rechnungsstellende Unternehmen bietet bei diesem Modell den eigenen Kunden den Service, Rechnungen elektronisch entweder per E-Mail oder über einen geschützten Bereich der eigenen Homepage unter Anmeldung mit Benutzername und Passwort zu betrachten.

Direct Billing bezieht sich hier auf die direkte Beziehung zwischen Unternehmen und Kunde.

Vorteile:

  • Die Kunden können innerhalb des eigenen Systems jegliche technisch möglichen Aktionen durchführen (z.B. Anmeldung zu weiteren Services, Zugriff auf Detaildaten, etc.)
  • Zugriff auf Rechnungsdaten in Echtzeit möglich (Hot Billing)
  • Größtmögliche Flexibilität

Nachteile:

  • Hohe Implementierungskosten
  • Hoher Wartungsaufwand
  • Generell geringe Akzeptanz bei Endkunden, bedingt durch Zugangsdaten (mindestens URL, Username, Passwort)

Viele Unternehmen aus den Branchen Telekom, ISP (Internet Service Prodiver) und Utility Provider (Strom- und Gasversorger) haben in den letzten Jahren eigene Direct Billing Lösungen für ihre Kunden entwickelt. Durch die generell schwache Akzeptanz der Endkunden von durchschnittlich 3-8% je Branche wird der direkte Zugang zu den Endkunden zunehmend in Frage gestellt.

Consolidator Modell

Anstelle der direkten Verbindung von Rechnungssteller und Rechnungsempfänger werden die Rechnungen auf einer neutralen Plattform zusammengefasst, konsolidiert. Der Rechnungsempfänger kann diese Plattform somit für alle an diesem Consolidator teilnehmenden Rechnungssteller nutzen und über einen Zugang abrufen.

Ist der Consolidator in eine bestehende Infrastruktur, wie beispielsweise das Internet Banking einer Großbank, integriert, so können die Rechnungsempfänger dieses Service zumeist ohne zusätzliche Zugangsdaten nutzen.

Vorteile:

  • Neue Teilnehmer, Rechnungsempfänger sowie Rechnungssteller, können den schon bestehenden Kundenstamm des Consolidators nutzen
  • Service als ASP nutzbar, zumeist keine hohen Einstiegskosten
  • Weiterentwicklung übernimmt der Betreiber der Consolidator Plattform
  • Haftung für rechtliche Aspekte, wie z.B. Vorsteuerabzugsfähigkeit, übernimmt der Betreiber der Consolidator Plattform
  • Multiplikatoreffekt: Werbemassnahmen von Rechnungsstellern zur Teilnahme von deren Kunden schlagen auf alle anderen Rechnungssteller über

Nachteile:

  • Geringere Flexibilität da Standardformate des Consolidators unterstützt werden müssen
  • Hot Billing zumeist nicht möglich

Gesetzliche Rahmenbedingungen

Damit eine elektronische Rechnung im gleichen Sinne wie eine papierhafte Rechnung zum Abzug der Vorsteuer berechtigt (§ 14 Abs. 3 UStG), muss diese über eine qualifizierte elektronische Signatur im Sinne des Signaturgesetzes verfügen. Hierzu existiert eine entsprechende EU-Richtlinie (RICHTLINIE 2001/115/EG DES RATES), die jeweils in nationales Recht umgesetzt wurde, in Deutschland durch das mehrfach geänderte Signaturgesetz.

Per normalen Papier-Telefax übermittelte Rechnungen werden in Deutschland zum Vorsteuerabzug anerkannt.

Praxis

In der Praxis werden Rechnungen zunehmend als PDF-Datei im Anhang einer E-Mail übermittelt. Der Rechnungsempfänger druckt sie aus und legt sie wie jede andere papiergebundenen Rechnung ab. Da Rechnungen in Deutschland (anders als in anderen europäischen Ländern üblich) in der Regel nicht unterschrieben werden, kann der ausgedruckten Rechnung dann nicht mehr angesehen werden, dass sie einmal eine elektronische Rechnung war. Steuerrechtlich ist ein solches Vorgehen jedoch unzulässig.

Das Risiko bei der Umsatzsteueraußenprüfung ist jedoch nicht, dass der Prüfer die Belege daraufhin überprüft ob diese Ausgedruckt wurde oder evtl. doch elektronisch übermittelt worden sind. Die Prüfung geht immer vom versendenden Unternehmen aus. D.h. bei einem Außenprüfung im versendenden Unternehmen wird festgestellt, dass elektronische Rechnungen erstellt werden ohne mit einer qualifizierten Signatur im Sinne des § 2 Nr. 3 SigG die, den Anforderungen des § 14 Abs. 3 Nr. 1 oder 2 UStG entspricht, versehen worden zu sein. Dies ist leicht feststellbar, da jedes Unternehmen eine Dokumentationspflicht nach GoBS triff. Daraufhin macht das Finanzamt eine Quermitteilung an alle betroffenen Veranlagungsfinanzämter, dass formungültige Belege an den Empfänger versendet wurden. Im Ergebnis führt dies dazu, dass der Außenprüfer beim Empfänger ins Haus kommt und die elektronisch übermittelten Belege schon kennt! Er überprüft dann nur noch ob der Empfänger seiner Verpflichtung aus § 15 UStG nachgekommen ist und die ohne Signatur übermittelten Rechnungen ausgesondert hat. Hat der Empfänger jedoch aus diesen elektronischen Rechnungen die enthaltene Vorsteuer zum Abzug gebracht ohne dass die Voraussetzungen des § 15 UStG vorgelegen haben, werden diese Vorsteuerbeträge zurückgefordert. Die weiteren Sanktionen und wie man die Vorsteuer dann doch noch bekommen kann wird in folgendem Beitrag erläutert: Rechtsfolgen der Erstellung und Verwendung nicht formgerechter elektronischer Rechnungen

Praxisbeispiel eines Industrieunternehmens

Ausgangssituation

Architektur der elektronischen Rechnung

Als Fallstudie dient ein reales Industrieunternehmen. Dieses ist ein Großunternehmen der Versorgungswirtschaft und agiert im Raum Berlin / Brandenburg. Es hat ca. 4000 Mitarbeiter und verschickt pro Jahr ca. 275.000 Rechnungen aus dem Kerngeschäft heraus. Im Jahr 2009 wurde das Projekt elektronische Rechnung gestartet, welche den Versand von Rechnungen an Großkunden innovativer gestalten sollte. Im Januar 2010 wurde das Projekt erfolgreich abgeschlossen. Seit diesem Zeitpunkt ist es möglich, Rechnungen elektronisch an Großkunden zu verschicken. Auf die technische Umsetzung wird in den folgenden Punkten eingegangen und dabei wird zwischen Rechnungserstellung, Rechnungsversand und Rechnungsempfang unter-schieden. Vorweg ist es notwendig, die verwendete Architektur aufzuzeigen.

In der Abbildung Architektur der elektronischen Rechnung ist die Grobstruktur der verwendeten Systeme ersichtlich. Zum einen sind das Industrieunternehmen (als Rechnungssteller) und der Kunde (als Rechnungsempfänger) vorhanden. Als Mittler der beiden Geschäftspartner fungiert die SmartPath-Plattform, bei der beide regist-riert sind. Durch diesen Mittler ist es möglich, dass die Rechnung standardisiert auch an mehrere andere Empfänger zu versenden.

Erstellung

Erstellungsprozess

Bei der Erstellung arbeiten verschiedene Systeme zusammen um die Rechnung elektronisch zu stellen. Im Folgenden wird der Prozess der Erstellung in den einzelnen Schritten anhand der Abbildung Erstellungsprozess erläutert.

In Schritt 1 schickt SAP IS-U einen Simple-RDI Datenstrom an das Output Management System (OMS) in einem standardisierten Format zur externen Druckaufbereitung. Danach wird im OMS dieser Datenstrom verarbeitet (2). Wenn eine Papierrechnung gebraucht wird, kann diese nun ausgedruckt werden, andernfalls wird hier über verschiedene Scripte eine XML-Datei und eine PDF/A-Datei generiert. Im nächsten Schritt 3 verteilt ein Script die Dateien in unterschiedliche Ordner auf einen Server, auf dem der Service Manager läuft. Der Service Manager „überwacht“ diese Ordner und Dateien anhand von MetaDaten. Rechnungen welche signiert werden sollen, in diesem Fall die PDF/A-Dateien, werden in Schritt 4 durch den Signaturserver signiert, anschließend an den Server Manager zurückgeschickt (5) und im Anschluss archiviert (6). Nicht zu signierende XML-Dateien werden sofort archiviert (6). Im letzten Schritt meldet der Service Manager den aktuellen Status an SAP IS-U mit Rechnungsnummer, Dokumentenart, Archivierungszeitstempel, Signaturkennzeichen, GUID zurück.

Versand

Versandprozess

Nachdem die Rechnung erstellt und archiviert wurde folgt der Versand zum Kunden. Auch dieser Schritt wird prozessual anhand der Abbildung Versandprozess beschrieben.

In Schritt 1 prüft ein Job in SAP IS-U ob alle notwendigen Rechnungsdateien archiviert sind, ein weiterer selektiert diese und „holt dich Rechnungen aus dem Archiv ab“ (2). Danach werden die Rechnungsdateien durch SAP IS-U an SAP PI weiter-geleitet. Dies wird sofort an IS-U zurückgemeldet (4). Im nächsten Schritt baut SAP PI eine Verbindung mit SmartPath auf, vergibt eindeutigen Identifier und verschickt die Rechnungsdateien (5). Auch dieser Schritt wird zurückgemeldet (6) (7). Die komplette Rückmeldung wird zum Schluss als XML-Datei archiviert. Im letzten Schritt versendet die externe SmartPath-Plattform die Rechnung an den Kunden.

Empfang

Die Verarbeitung der empfangenen Rechnung hängt stark von dem Kunden, dessen Ansprüche und technischen Systemen ab. Er könnte beispielsweise die XML-Datei in SAP einlesen lassen und diese dann elektronisch weiterverarbeiten, was dem eigentlichen Sinn der elektronischen Rechnungsverarbeitung entspricht.

Abgerufen von „https://de.wikipedia.org/w/index.php?title=EBPP&oldid=74990056“