White Paper (Rechnungsbearbeitung - Dr.

Transcrição

Dr.-Ing. Rolf Meyer
Informa
ations- und
Prozessm anagement Consulting
W
White Paper
P
Elekttroniscche Be
earbeittung vo
on
Eingangsrec
chnung
gen
Informationss- und Prozesssmanageme
ent Consultin
ng Dr.-Ing. R
R. Meyer
Thom
mas Richter
Rolf M
Meyer
Frohmestraße 29
9
224
457 Hamburg
g
info@ip
pc-meyer.de
e
Hamb
burg, den 14
4.04.2014
www.ip
pc-meyer.de
e
White Paper
Dr.-Ing. Rolf Meyer
Rechnungsbearbeitung
Informations- und
Prozessmanagement Consulting
Inhalt
1 Einleitung ...................................................................................................... 3 2 Hintergrund ................................................................................................... 4 2.1 Gesetzliche Grundlagen ..................................................................................... 4 2.2 Unstrukturierte Dateiformate .............................................................................. 5 2.3 Strukturierte Dateiformate ................................................................................. 6 2.4 Verfahren für den Austausch von Rechnungsdaten ..................................................... 7 3 Prozess der elektronischen Rechnungsbearbeitung ..................................................... 9 3.1 Modellprozess der Rechnungsbearbeitung................................................................ 9 3.2 Arbeitsschritte .............................................................................................. 11 3.3 Ablaufvarianten ............................................................................................ 15 3.4 Sonderfälle .................................................................................................. 18 4 5 Komponenten der technischen Lösung .................................................................. 21 4.1 Scannen ...................................................................................................... 21 4.2 Datenextraktion (REB-Komponente) .................................................................... 21 4.3 Elektronischer Datenaustausch (EDI) .................................................................... 23 4.4 Webservice .................................................................................................. 24 4.5 ASP- oder Cloud-Lösung ................................................................................... 24 4.6 Workflow .................................................................................................... 25 4.7 Authentifizierung........................................................................................... 26 4.8 Elektronisches Archiv ...................................................................................... 26 Bewertung der Varianten ................................................................................. 27 Prozessmanagement
Rechnungsbearbeitung.docx
Seite 2 von 28
White Paper
Dr.-Ing. Rolf Meyer
Informations- und
1 Einleitung
Die elektronische Bearbeitung von Eingangsrechnungen steht beispielhaft für die Kombination unterschiedlicher Softwareprodukte zu integrierten IT-Lösungen. Die Technologie des Scannens von konventionellen Rechnungen mit Datenextraktion, elektronischer Prüfung und revisionssicherer Archivierung wird vielfach erfolgreich genutzt. Das Verfahren optimiert aber nur den Medienbruch (Digitalisierung der konventionellen Rechnungen) und ist gegenüber der Vermeidung des Medienbruchs
(elektronische Übermittlung der Rechnungen) die zweitbeste Lösung.
Für den elektronischen Austausch von Rechnungen hat sich die englische Bezeichnung „E-Invoicing“
durchgesetzt. Nach der Verabschiedung des UN/EDIFACT-Standards (1988) wurden bereits in den
90er Jahren EDI-Lösungen (Electronic Data Interchange) für Rechnungen implementiert. Heute gibt
es innovative Techniken, mit denen Rechnungen wahlweise per




E-Mail
EDI-Verfahren (Elektronischem Datenaustausch)
service-orientierter Web-Lösung im Eigenbetrieb
ASP- oder Cloud-Lösung durch einen Service-Anbieter
übermittelt werden.
Bei der Bearbeitung von Eingangsrechnungen sind konventionelle Medien (Postweg) und digitale
Medien (elektronische Kanäle) als komplementäre Elemente einer Gesamtlösung zu betrachten.
Deshalb wird auch die Umwandlung von Papierrechnungen in elektronische Rechnungsdaten im Vergleich zum echten E-Invoicing behandelt.
Ein Investitionsvorhaben für eine elektronische Rechnungsbearbeitung lässt sich für die meisten
Unternehmen über die Kosteneinsparung begründen. Es kann daneben auch strategische (bessere
Prozesssteuerung und Liquiditätsplanung) und ökologische (Einsparung von Papier und Energie)
Gründe für ein E-Invoicing geben.
Eine auf dem Medienbruch basierende Lösung ist nur für den Debitor (Rechnungsempfänger) vorteilhaft und der Kreditor (Rechnungssteller) bleibt davon weitgehend unberührt. Eine E-InvoicingLösung setzt dagegen ein Zusammenwirken zwischen Kreditor und Debitor voraus und bietet beiden
Seiten Nutzenpotenziale. Insbesondere für den Kreditor ergeben sich dann neben den betrieblichen
Motiven auch marktstrategische Gründe (Kundenbindung, Sicherung der Marktposition).
Diese Firmenschrift stellt die verschiedenen Verfahren vor und bewertet sie. Im Abschnitt 2 werden
zunächst die Randbedingungen der elektronischen Rechnungsbearbeitung beschrieben. Alle Varianten und Lösungsansätze müssen die gesetzlichen Grundlagen erfüllen und unterliegen den Möglichkeiten und Grenzen der verfügbaren Dateiformate.
Dabei kann eine technische Lösung je nach Prozessablauf mehr oder weniger zweckmäßig sein. Deshalb wird im Abschnitt 3 ein Modellprozess definiert, der als Referenz für die spätere Bewertung der
Lösungsoptionen dient. Der Abschnitt 4 enthält die Beschreibung der technischen Komponenten mit
ihren spezifischen Leistungsmerkmalen. Im Abschnitt 5 werden die Lösungsoptionen bewertet und
die Auswirkungen von Ablaufvarianten auf die Bewertung erläutert.
Prozessmanagement
Seite 3 von 28
White Paper
Dr.-Ing. Rolf Meyer
Informations- und
2 Hintergrund
2.1 Gesetzliche Grundlagen
Die gesetzlichen Grundlagen der Rechnungsbearbeitung ergeben sich aus



dem Handelsgesetzbuch (insbesondere HGB §257 und §261)
der Abgabenordnung (insbesondere AO §147) und
dem Umsatzsteuergesetz (insbesondere UStG §14).
Die Vorschriften der Zivilprozessordnung über die Beweiskraft von elektronischen Dokumenten und
privaten Urkunden (z.B. ZPO §371a und ZPO §416) sind für Rechnungen weniger wichtig, weil Rechnungen üblicherweise nicht unterschrieben werden1. Für rechnungsbegründende Unterlagen wie
Verträge, Bestellungen, Lieferscheine, Leistungsnachweise etc. können andere Voraussetzungen
gelten und eine Prüfung der ZPO ist durchaus sinnvoll.
Der bisherige Einsatz von E-Invoicing-Verfahren beim Versand von elektronischen Rechnungen verlangte bei Bilanzprüfungen oder Jahresabschlüssen nach UStG §14 zusätzlich die Dokumentation und
Beweisführung in Papierform. Der Gesetzgeber hat die Vorteile der elektronischen Übermittlung von
Rechnungen erkannt und mit dem Steuervereinfachungsgesetz rückwirkend ab 1.7.2011 die Anforderungen deutlich reduziert und auf eine elektronische Signatur verzichtet.
Wenn der Kreditor keine qualifizierte elektronische Signatur verwendet, kann der Debitor durch ein
innerbetriebliches Kontrollverfahren sicherstellen, dass Echtheit der Herkunft, Unversehrtheit des
Inhalts sowie Lesbarkeit der Rechnung gewährleistet sind. Dabei ist kein bestimmtes Kontrollverfahren vorgeschrieben, sondern die Beweisführung muss einer kritischen Prüfung standhalten.
Nachdem die elektronische Signatur für die Rechnungsbearbeitung an Bedeutung verloren hat, bleiben vor allem die Aufzeichnungs- und Aufbewahrungspflichten nach HGB und AO als bestimmende
Vorschriften. Sie verlangen insbesondere die bildliche Übereinstimmung der gespeicherten Daten
mit dem Original. Es bleibt abzuwarten, wie Gerichte im Streitfall die „bildliche Übereinstimmung“
interpretieren und bewerten, wenn der empfangene Buchungsbeleg eine CSV- oder XML-Datei ist.
IPC empfiehlt regelmäßig mindestens folgende Grundsätze anzuwenden:
1. Es sollte immer eine für den Menschen lesbare Darstellung der Rechnung in einem standardisierten Dateiformat (z.B. XML oder PDF/A) geben bzw. beim Eingang der Rechnung erzeugt
werden, die als Grundlage für manuelle Prüfungen (durch Sachbearbeiter) oder zur Vorlage
im Streitfall dienen kann.
2. Die Darstellung nach 1. sollte so früh wie möglich nach dem Rechnungseingang beim Debitor
manipulationssicher archiviert werden.
3. Für das Scannen von Papierrechnungen sollten die Hinweise und Empfehlungen des BMWi für
das ersetzende Scannen (Handlungsleitfaden zum Scannen von Papierdokumenten, Dokumentation Nr. 571, 2008) beachtet werden.
4. Die Authentizität (Herkunft) der Rechnung kann durch Validierung der elektronischen Signa-
1
Eine Unterschrift des Kreditors könnte auch wenig bewirken. Die in Rechnung gestellte Forderung ist durch andere Dokumente (z.B. Vertrag, Bestellung o.ä.) begründet und wird durch die Zahlung des Debitors anerkannt oder eben nicht.
Prozessmanagement
Seite 4 von 28
White Paper
Dr.-Ing. Rolf Meyer
Informations- und
tur (soweit vorhanden) des Kreditors oder durch Prüfung der Übereinstimmung mit der bestellten und ausgeführten Lieferung oder Leistung geprüft werden. Das Prüfungsergebnis
sollte protokolliert und das Protokoll ebenfalls manipulationssicher archiviert werden.
5. Der Prozessablauf der Rechnungsbearbeitung sollte beschrieben und dokumentiert sein. Dieser Prozessablauf kann soweit wie möglich durch definierte Workflows gesichert werden.
Schon die Befassung mit den gesetzlichen Grundlagen erweist die elektronische Rechnungsbearbeitung – gleichgültig welche Verfahrensweise genutzt wird – als ein durchaus komplexes Zusammenwirken von verschiedenen organisatorischen Maßnahmen und technischen Komponenten. Bei der
konkreten Ausgestaltung des Prozesses sind die Eigenschaften und Leistungsmerkmale der verwendeten Dateiformate wesentlich:
-
bildliche, für den Menschen lesbare Rechnungen in „unstrukturierten“ Formaten wie PDF,
TIFF oder JPG und
für die maschinelle Verarbeitung geeignete Rechnungsdaten in strukturierten Formaten
wie EDIFACT oder XML.
2.2 Unstrukturierte Dateiformate
Natürlich sind weder die Dateiformate noch die Dateien „unstrukturiert“. Die Struktur des Dateiinhalts ist nur nicht definiert, d.h. bei der Erstellung (manuell oder automatisch) kann eine beliebige
Struktur aufgebaut werden. Für einen Datenaustausch sind solche Dateien eigentlich ungeeignet,
weil der Empfänger nicht weiß, welche Struktur der Sender produziert hat und wie die Daten maschinell zu verarbeiten sind. Die Verbreitung unstrukturierter Dateiformate im Datenaustausch2 ist
die Folge ihrer Flexibilität, denn sie sind für alle möglichen Informationen nutzbar. Für die Rechnungsbearbeitung sind vor allem die Dateiformate TIFF, JPEG, PDF und PDF/A relevant.
TIFF (Tagged Image File Format) ist der verbreitete ISO-Standard für digitale Bilder in Rastergrafik.
Eine Rastergrafik besteht aus Pixeln (Bildpunkten), die in einem Raster angeordnet sind und deren
Dichte als Auflösung in dpi (digits per inch) angegeben wird. Je höher die Pixeldichte gewählt wird,
desto größer wird das Dateivolumen. Um das Dateivolumen zu reduzieren, kann das Bild mit unterschiedlichen Algorithmen komprimiert werden. Eine Software muss Datenstruktur und Kompression
verarbeiten können, um das Bild anzuzeigen.
Die traditionelle Kompression für TIFF-Bilder ist der G4-Standard aus der Fax-Technologie. Da diese
Kompression nur für Schwarz-Weiß-Bilder geeignet ist, hat sich für Farbbilder der JPEG-Algorithmus
(Joint Photographic Experts Group) weitgehend durchgesetzt. JPEG ist eigentlich kein eigenes Dateiformat sondern nur ein anderes Kompressionsverfahren für Rasterbilder.
Anders als TIFF ist PDF (Portable Document Format) kein öffentlicher Standard, sondern ein proprietäres Dateiformat, das erst durch die Verbreitung des Acrobat Readers zum „De-Facto-Standard“
wurde. PDF ermöglicht eine identische Darstellung beliebiger Dokumente auf unterschiedlichen
Plattformen. Formatierungen und Layout-Anweisungen sind in der PDF-Datei enthalten und daher
2
Unabhängig vom Datenaustausch sind die Dateiformate für die Speicherung und Darstellung von Informationen durchaus
geeignet, deshalb gibt es sie und sie werden umfassend genutzt.
Prozessmanagement
Seite 5 von 28
White Paper
Dr.-Ing. Rolf Meyer
Informations- und
nicht anwendungsneutral, aber der Acrobat Reader ist als Freeware für jedermann zugänglich.
Eine PDF-Datei kann wie TIFF oder JPEG Rastergrafik mit Bildpunkten enthalten, aber auch auswertbare Zeichenketten wie in XML. Die Angaben zur Bedeutung der Zeichenketten sind jedoch
nicht genormt, d.h. die Struktur ist für den Empfänger einer PDF-Datei nicht erkennbar und nicht
mit einer beliebigen Anwendungssoftware auswertbar. Deshalb wird PDF in dieser Firmenschrift als
unstrukturiertes Dateiformat behandelt.
Mit der Verbreitung von PDF entstand das Bestreben, dieses Dateiformat auch für die elektronische
Archivierung zu nutzen. Um die Risiken des proprietären Firmenstandards zu eliminieren, wurde
PDF/A (Portable Document Format / Archiving) als öffentlicher Standard in der ISO 19005 genormt.
Für PDF/A-Dateien ist die Anzeige mit verschiedenen Softwareprodukten gesichert und sie sind für
eine Archivierung geeignet.
PDF/A enthält nur eine Untermenge (Subset) der Strukturelemente von PDF. Für den Austausch von
strukturierten Rechnungsdaten ist weder PDF noch PDF/A geeignet. PDF/A ist inzwischen jedoch das
dominierende Dateiformat für die elektronische Archivierung und IPC empfiehlt, jede Rechnung
auch als PDF/A-Dokument im elektronischen Archiv zu speichern3.
2.3 Strukturierte Dateiformate
Bereits 1988 wurde mit dem UN-Standard ISO 9735 „EDIFACT“ (Electronic Data Interchange For Administration, Commerce and Transport) ein strukturierter Datenaustausch ermöglicht. EDIFACT
definiert Zeichensätze und Dateistrukturen für kommerzielle Nachrichten (z.B. Rechnungen). Für
die Rechtssicherheit waren bilaterale Datenaustausch-Vereinbarungen erforderlich.
EDIFACT entstammt der „Vor-Internet-Ära“ und überlässt es den Partnern, die technischen Modalitäten (Codierungen, Übertragungswege, Protokolle usw.) zu vereinbaren. Natürlich können EDIFACTNachrichten auch per E-Mail oder Internet (Upload, Download) transportiert werden. Aber immer
muss das Nachrichtenformat beim Sender und beim Empfänger bekannt sein und beide Seiten benötigen die Software für dessen Verarbeitung.
Schon in einer von Individualsoftware dominierten Anwendungslandschaft (1988!) war die Bindung
von EDIFACT an bilaterale Vereinbarungen und spezifische Algorithmen ein Hindernis für die breite
Anwendung. Das nötige Investitionsvolumen ist nur bei sehr großem Rechnungsaufkommen zwischen
einem Kreditor und einem Debitor vertretbar. Eine allgemeine E-Invoicing-Nutzung setzt standardisierte Dateien sowie kostengünstige Kommunikationsverfahren für deren Übertragung und eine verbreitete Anwendungssoftware für die Verarbeitung voraus.
Ein sehr verbreitetes Dateiformat sind ASCII-Zeichenketten in CSV-Dateien (Character Separated
Values), die auch mit gängigen Office-Anwendungen (z.B. MS Excel) erzeugt werden können. Die
Verarbeitung ist also nicht an spezifische Softwarekomponenten gebunden. Die Zeichenketten können beliebige Informationen enthalten und werden durch definierte Sonderzeichen („,“ oder „;“)
3
Der Anwender sollte sorgfältig zwischen der gesetzlichen Anforderung (jederzeit anzeigbar) und seinem Eigeninteresse
(automatisch auswertbar) unterscheiden. PDF/A-Dateien können jederzeit auf dem Bildschirm angezeigt und ausgedruckt
werden. Automatisch auswertbar sind PDF/A-Dateien nur bedingt.
Prozessmanagement
Seite 6 von 28
White Paper
Dr.-Ing. Rolf Meyer
Informations- und
getrennt. Die CSV-Datei wird tabellarisch aufgebaut und kann Überschriftenzeilen enthalten.
Im Unterschied zu EDIFACT ist jedoch die Datenstruktur in CSV-Dateien nicht standardisiert. Jeder
Rechnungssteller kann die Daten und ihre Reihenfolge nach eigenem Ermessen auswählen. Informationen für die Interpretation und Verarbeitung der CSV-Daten muss der Empfänger auf anderen Wegen erhalten, um die Daten zuverlässig und korrekt verarbeiten zu können. Bekannte Anwendungen
für CSV-Dateien sind elektronische Kontoauszüge oder Rechnungen der Telekom.
EDIFACT und CSV-Dateien bzw. ihre Unzulänglichkeiten zeigen beispielhaft die Anforderungen an
allgemein nutzbare Dateiformate für den Austausch von Rechnungsdaten:
1. Das Dateiformat muss in einem offenen und verbreiteten Standard definiert sein, so dass
alle Hersteller von Anwendungssoftware die notwendigen Verarbeitungsfunktionen implementieren können und dies auch umsetzen.
2. Das Dateiformat muss flexible Datenstrukturen unterstützen, so dass beliebige Anwendungssysteme miteinander kommunizieren können.
3. Die Dateien müssen alle Informationen für die Interpretation und Verarbeitung der Daten
enthalten, so dass möglichst keine bilateralen Abstimmungen zwischen Kreditoren und Debitoren erforderlich sind.
Das erste Dateiformat mit verbreiteter Anwendung und expliziter Angabe zur Bedeutung der Zeichenketten war HTML (Hyper Text Markup Language) für den Aufbau von Web-Seiten im Internet.
XML (eXtended Markup Language) ist eine Erweiterung und Weiterentwicklung von HTML und damit
Teil der Web-Technologie. XML-Dateien enthalten nicht nur Zeichenketten sondern auch Angaben zu
deren Bedeutung. Das Anwendungssystem kann der XML-Datei nicht nur Rechnungsdaten zuverlässig
entnehmen, sondern sie nach Bedarf des Buchhaltungssystems formatieren und verarbeiten.
Der Aufbau einer XML-Datei kann in einer DTD (Document Type Definition) oder einem XML-Schema
definiert werden. DTDs und XML-Schemata sind Dateien mit standardisiertem Aufbau, sie können
transferiert und vom Empfänger ausgewertet werden. Deshalb verwendet u.a. die Finanzverwaltung
XML für die Beschreibung von Datenstrukturen im GDPdU-Kontext (Grundsätze für den Datenzugriff
und die Prüfbarkeit digitaler Unterlagen).
Der Nachteil von XML ist das Datenvolumen – die Übertragung einer simplen Rechnungsnummer erfordert mehrere Zeilen Programmcode oder mehr als 100 Zeichen für eine 8-stellige Nummer. Zu
Zeiten von Kupferkabeln und knappen Speicherkapazitäten war XML nicht effektiv nutzbar. Heute ist
es das verbreitete und geeignete Dateiformat für den Austausch von kommerziellen Daten.
2.4 Verfahren für den Austausch von Rechnungsdaten
Die Dateiformate für den Austausch von Rechnungsdaten müssen für Kreditoren und Debitoren
gleichermaßen nutzbar sein. Dazwischen liegt die Übertragung der Rechnungsdaten vom Kreditor
zum Debitor. Die verschiedenen Verfahren der Übertragung bieten unterschiedliche Möglichkeiten
der Integration in den Prozess der Rechnungsbearbeitung, d.h. sie stellen unterschiedliche Anforderungen an den Umfang dieses Prozesses.
Die Papierrechnung wird durch Scannen in eine Imagedatei umgewandelt, bevor aus der Imagedatei
Prozessmanagement
Seite 7 von 28
White Paper
Dr.-Ing. Rolf Meyer
Informations- und
durch eine intelligente Datenextraktion die Rechnungsdaten ausgelesen und für die weitere Bearbeitung in das gewünschte Dateiformat konvertiert werden. Für alle elektronischen Formen der Kommunikation entfällt das Scannen oder sollte entfallen können4.
Abbildung 1: Verfahren für den Austausch von Rechnungsdaten
Das E-Mail-Verfahren beschränkt sich auf die Zustellung der Rechnung und in der Regel werden mit
diesem Verfahren auch lediglich unstrukturierte Daten übermittelt, die zunächst ausgelesen werden
müssen. Einige Unternehmen bieten auch strukturierte Formate wie *.csv oder *.xml an (z.B. die
Deutsche Telekom), die sich in der Konfiguration des Kundenkontos einstellen lassen. Letztlich eignet sich die Zustellung per E-Mail jedoch nur bedingt für eine automatisierte Verarbeitung.
EDI- und service-orientierte Web-Verfahren sehen den transaktionsorientierten Austausch von strukturierten Rechnungsdaten vor, wobei der Sender für eine Übermittlung eine entsprechende Rückantwort erhält. Während EDI das EDIFACT-Format (Standardformat INVOIC) bevorzugt, wird bei ser-
4
Es gibt Ausnahmefälle, in denen elektronische Rechnungen gescannt werden, um die Daten aus der Datei extrahieren zu
können (vgl. 4.2).
Prozessmanagement
Seite 8 von 28
White Paper
Dr.-Ing. Rolf Meyer
Informations- und
vice-orientierten Web-Lösungen der Austausch via XML-Datenformat favorisiert. ASP- oder CloudLösungen sind in der Regel ebenfalls service-orientierte Web-Lösungen, die jedoch von einem Service-Dienstleister auf seiner Plattform zur Nutzung zur Verfügung gestellt werden.
Ob EDI-, ASP- oder Cloud-Service – die Lösung muss für beide Seiten sicherstellen, dass



der Rechnungsempfänger nur Zugriff auf seine Rechnungen erhält,
diese Rechnungen aber auch tatsächlich vollständig und korrekt erhalten hat und
die erhaltenen Rechnungen vom ausgewiesenen Kreditor stammen.
Sinnvollerweise wird die Lösung auch garantieren, dass jede Rechnung nur einmal übertragen wird.
Sicherungen gegen Doppelbuchungen sind aus verschiedenen Gründen jedoch auch im Buchhaltungssystem erforderlich, so dass auch eine mehrfach übertragene Rechnung nicht zu Doppelbuchungen
führen sollte.
Die verschiedenen Verfahren (vgl. Abbildung 1) stehen nicht nur alternativ zur Wahl, sondern eignen
sich auch für einen kombinierten Einsatz. Dabei sollte der Prozess so gestaltet sein, dass ab einem
bestimmten Punkt die Rechnungen aus unterschiedlichen Quellen gemeinsam verarbeitet werden.
3 Prozess der elektronischen Rechnungsbearbeitung
3.1 Modellprozess der Rechnungsbearbeitung
Für den Prozessablauf der Rechnungsbearbeitung gibt es bei detaillierter Betrachtung etwa so viele
Varianten, wie es Unternehmen und Organisationen gibt. Bei vereinfachter Betrachtung sind es
deutlich weniger Varianten aber immer noch so viele, so dass eine Bewertung technischer Lösungen
extrem schwierig wird. Zur besseren Übersicht und Nachvollziehbarkeit soll die spätere Bewertung
auf einem Modellprozess beruhen, der in diesem Abschnitt skizziert und erläutert wird.
Einkauf
Bestellung
m:n
Bestellnummer
Artikelnummer
Menge
Preis
...
Zahlung
Lieferung
Lieferschein
Datum
Artikelnummer
Menge
...
m:n
Rechnung
Referenzdaten
Rechnungsnummer
Kreditor
Rechnungsbetrag
...
1:n
Buchung
Kontonummer
Betrag
Kostenstelle
Steuerschlüssel
...
n:1
Zahlung
Bankverbindung
Empfänger
Datum
Verwendungszweck
Abbildung 2: Prozesskontext der Rechnungsbearbeitung
Prozessmanagement
Seite 9 von 28
White Paper
Dr.-Ing. Rolf Meyer
Informations- und
Die Umsicht gebietet es, zunächst auf den Prozesskontext der Rechnungsbearbeitung hinzuweisen.
Die Rechnungsbearbeitung selbst umfasst die Arbeitsschritte vom Rechnungseingang bis zur Buchung
(vgl. Abbildung 2). Gegenstand dieser Arbeitsschritte sind die Datenobjekte „Rechnung“ (als Dokument und Datensatz) und „Buchung“ (mit Verknüpfung zum Rechnungsdokument).
In einer Zahlung können mehrere Rechnungsbeträge eines Kreditors zusammengefasst werden und
Zahlungen können auch aus wiederkehrenden Buchungen hervorgehen. Wegen der komplexen Beziehungen zwischen Rechnungen und Zahlungen ist ein durchgängiger Vorgang kaum noch darstellbar
und die Zahlung sollte nicht als Teil der Rechnungsbearbeitung betrachtet werden.
Nach dem Verständnis von IPC ist der Arbeitsablauf „Rechnungsbearbeitung“ kein echter „Prozess“,
weil er keinen Mehrwert im Sinne des Empfängers erzeugt5. Der Abfluss von Geld wird jedenfalls nur
selten als „Mehrwert“ verstanden. Der eigentliche Prozess ist die Beschaffung (vgl. Abbildung 2), die
dem Rechnungsempfänger Produkte oder Leistungen zuführt und dadurch zur Wertschöpfung beiträgt. Diese Sichtweise des Prozessmanagements ist jedoch sehr theoretisch und die Rechnungsbearbeitung wird in dieser Firmenschrift als Prozess bezeichnet.
Digitalisieren
Scanner
Archivieren
Imagedatei
Imagedatei
Konvertieren
Kontieren
Prüfen
Buchen
Vorgang
Vorgang
Vorgang
Datenextraktion
Workflow
InvoiceDaten
Buchung
Buchung
Buchung
Finanzmanagement
Archiv
ohne automatische Datenextraktion
mit automatischer Datenextraktion
Abbildung 3: Modellprozess der Rechnungsbearbeitung
Inzwischen gehen auch Systemanbieter vermehrt dazu über, in ihren Lösungsansätzen den Beschaffungsprozess abzubilden. In der betrieblichen Praxis dominieren allerdings Lösungen, die die vorgelagerten Teilprozesse (Bestellung und Lieferung / Leistung) ausblenden und nur die Arbeitsschritte
5
Nähere Erläuterungen zu den Begriffen „Prozess“ und „Geschäftsprozess“ sind im White Paper „Workflowmanagement“ zu
finden.
Prozessmanagement
Seite 10 von 28
White Paper
Dr.-Ing. Rolf Meyer
Informations- und
der Rechnungsbearbeitung enthalten. Für die Funktion solcher Lösungen sind jedoch die Referenzdaten zu den vorgelagerten Vorgängen unverzichtbar (vgl. 4.2).
Die Rechnungsbearbeitung im Modellprozess umfasst die Einzelschritte






Digitalisieren (der konventionell eingehenden Rechnungen)
Archivieren (der eingegangenen oder digitalisierten Daten)
Konvertieren (ggf. mit Extraktion strukturierter Daten aus den Imagedateien)
Kontieren
Prüfen (formelle, sachliche und rechnerische Korrektheit sowie Freigabe zur Zahlung)
Buchen (im Buchhaltungssystem)
Diese Schritte und ihre Reihenfolge bedürfen einer Erläuterung.
3.2 Arbeitsschritte
3.2.1 Digitalisieren
Das Scannen von Dokumenten ist nur für Papierrechnungen erforderlich und erzeugt ein unstrukturiertes Imagedateiformat. Obwohl Rechnungen meist in separaten Stapeln gescannt werden, kann
eine universelle Scan-Infrastruktur genutzt werden (vgl. 4.1).
Nach dem Scannen können die Papieroriginale entweder entsorgt oder zur Archivierung eingelagert
werden. Für die weitere elektronische Bearbeitung werden sie nicht mehr benötigt. Das übliche
Verfahren ist eine temporäre Aufbewahrung der Originale für etwa 4 bis 8 Wochen. Der Zeitraum
sollte so dimensioniert sein, dass die digitalen Rechnungsdaten in jedem Fall gesichtet und bearbeitet worden sind. Scanfehler werden dadurch rechtzeitig erkannt und bei Bedarf kann ein erneuter
Scan angefordert werden.
Damit die Entsorgung der Papieroriginale rechtssicher möglich ist, sollten beim Scannen unbedingt
die einschlägigen Empfehlungen beachtet werden. Leider gibt es dafür diverse Quellen mit unterschiedlichen Empfehlungen. Neben dem Bundesministerium für Wirtschaft und Technologie (BMWi,
Dokument Nr. 571 „Hinweise zum ersetzenden Scannen“) haben auch der Fachverband der ECMAnbieter (VOI, „Grundsätze der revisionssicheren Archivierung“ sowie „Code of Practice - Dokumentenmanagement“) und der Fachverband der Wirtschaftsprüfer (IDW, „Grundsätze ordnungsmäßiger
Buchführung beim Einsatz elektronischer Archivierungsverfahren“) umfassend behandelt.
Daneben gibt es weitere Empfehlungen von mehr oder weniger berufenen Institutionen für spezifische Anwendungsbereiche. In Umsetzungsprojekten führt die Frage nach dem maßgebenden Regelwerk häufig zu umfänglichen Diskussionen zwischen den betroffenen Fachbereichen. IPC empfiehlt
die Nutzung der BMWi-Hinweise – nicht weil sie besonders kompetent oder hilfreich wären, sondern
weil es gegen ein Bundesministerium als maßgebende Instanz wenige Einwände geben dürfte.
3.2.2 Archivieren
Der Rechnungsempfänger muss den „Urzustand“ der Eingangsrechnung belegen können (vgl. 2.1),
deshalb wird die manipulations- und revisionssichere Archivierung im Modellprozess an den Anfang
der Verarbeitungskette gelegt. Die Funktionsweise eines digitalen Archivs sowie die Leistungsmerk-
Prozessmanagement
Seite 11 von 28
White Paper
Dr.-Ing. Rolf Meyer
Informations- und
male der Revisionssicherheit werden hier als bekannt unterstellt. In der Praxis wird die Archivierung
oft aus technischen Gründen am Ende der Verarbeitungskette positioniert. Die Manipulationssicherheit der Dateien kann dabei durch Signaturverfahren oder Zeitstempel erreicht werden. Diese Ablaufvariante wird im Abschnitt 3.3.1 begründet und erläutert.
Die Archivierung ist der erste Arbeitsschritt, der unabhängig vom Eingangskanal für alle Rechnungen
durchgeführt wird. Als Dateiformat hat sich dabei PDF bzw. PDF/A gegen TIFF, JPEG o.a. weitgehend durchgesetzt. Die archivierte Rechnungsdatei muss für mindestens 10 Jahre aufbewahrt werden und darstellbar sein. IPC empfiehlt daher, auch Rechnungen, die als strukturierte Dateien (z.B.
XML oder CSV) eingehen, für die Archivierung zusätzlich in eine PDF-Datei zu konvertieren. Die
strukturierten Originaldaten müssen natürlich in jedem Fall archiviert werden und die PDF-Datei ist
nur eine sinnvolle Ergänzung.
Soweit der Ersteller eine Rechnungsdatei elektronisch signiert hat, wird die Signatur vor der Archivierung validiert. Bei einer positiven Validierung (gültige Signatur) kann deren Ergebnis protokolliert
werden, um die Authentizität der Rechnungsdaten zum Zeitpunkt der Archivierung nachzuweisen.
Rechnungsdaten mit ungültiger Signatur werden reklamiert.
In jedem Fall wird bei der Archivierung eine Archiv-ID erzeugt, die die Rechnung im Archiv identifiziert. Die Archiv-ID kann an die nachgelagerten IT-Systeme übergeben und in den weiteren Arbeitsschritten als Link auf die Rechnungsdaten im Archiv verwendet werden, soweit die jeweiligen Anwendungssysteme das unterstützen (manche Buchhaltungssysteme unterstützen es nicht, vgl. 3.3.1).
3.2.3 Konvertieren
Das Ziel ist die Erzeugung von „buchungsfähigen Daten“, die fehlerfrei in das Buchhaltungssystem
importiert und dort verarbeitet werden können. Die eingehenden oder beim Scannen erzeugten
Daten sind im Normalfall nicht „buchungsfähig“ und bedürfen einer Transformation, Ergänzung und
Aufbereitung. Die dafür erforderlichen Systemfunktionen unterscheiden sich jedoch erheblich, je
nach dem, in welchem Dateiformat die Daten vorliegen.
Die einfachste Variante sind XML-Dateien, weil sie nicht nur die operativen Nutzdaten einer Rechnung enthalten sondern auch die Metadaten (vgl. 2.3) und dadurch einer automatischen Verarbeitung unmittelbar zugänglich sind. Für EDIFACT-Dateien gehen die Verarbeitungsregeln nicht aus der
Datei hervor, sondern sie müssen als Zuordnungstabelle, Schnittstellenkonfiguration oder Verarbeitungslogik in der Konvertierungskomponente gespeichert werden. Gleiches gilt für CSV- oder TXTDateien, wobei der Kreditor bei der Gestaltung seiner Rechnungsdateien an keinen Standard gebunden ist, das Regelwerk für jeden Kreditor anders aussehen kann.
Auch strukturierte Dateiformate benötigen im Normalfall eine Konvertierung, die jedoch wesentlich
einfacher und zuverlässiger ist als die Verarbeitung unstrukturierter Bilddateien. Die dafür benötigte
Technologie wird im Abschnitt 4.2 beschrieben. An dieser Stelle genügt der Hinweis, dass auch die
beste Texterkennung nur jene Angaben verarbeiten kann, die in der Imagedatei der Rechnung vorhanden sind – was nicht in der Rechnung steht, kann auch nicht erkannt und extrahiert werden!
Softwareprodukte für eine Datenextraktion speichern vielfach ihre Output-Daten in XML-Dateien. Im
günstigsten Fall wird dafür ein XML-Schema verwendet, das vom Buchhaltungssystem direkt verar-
Prozessmanagement
Seite 12 von 28
White Paper
Dr.-Ing. Rolf Meyer
Informations- und
beitet werden kann. Das Ergebnis der Konvertierung (die „Invoice-Daten“, vgl. Abbildung 3) wird auf
Vollständigkeit und formale Korrektheit geprüft. Soweit die erforderlichen Daten nicht automatisch
gewonnen werden konnten, müssen sie manuell ergänzt werden.
Achtung:
Da das Regelwerk für die Konvertierung vom Kreditor und seiner spezifischen Rechnungsgestaltung abhängt, muss der Kreditor bereits bei der Konvertierung bestimmt werden. Eine
fehlende Zuordnung zum Kreditor verhindert die nachfolgenden Arbeitsschritte und eine
fehlerhafte Zuordnung kann sie entwerten.
Nach dem Konvertieren sollten – unabhängig vom ursprünglichen Rechnungsformat (Papier, unstrukturierte Bilddatei oder strukturierte Rechnungsdaten) – alle Rechnungen in gleicher Form vorliegen
und in gemeinsamen Arbeitsabläufen verarbeitet werden. Jedenfalls empfiehlt IPC eine Prozessgestaltung, die das ermöglicht und unterstützt.
3.2.4 Kontieren
Die Kontierung umfasst die Zuordnung der Rechnungsbeträge zu Kostenarten (Sachkonten), Kostenstellen und Buchungsperioden. Dabei sind firmenspezifische Buchungsregeln zu beachten, z.B.






Kontenplan, Buchungskreise und Kostenstellenplan
Regeln für den Umgang mit Umsatzsteuer- und Skontobeträgen
Regeln für die Verwendung von CPD-Konten (CPD: conto pro diverse)
Regeln für Zahlungen an eigene Mitarbeiter
Umrechnungskurse für Fremdwährungen
usw.
Zusätzlich werden nicht selten weitere Zuordnungen zu internen Kontroll- und Steuerungssystemen
vorgenommen. Viele dieser Regeln sind als Geschäftslogik im Buchhaltungssystem implementiert.
Dazu gehören auch die Zeichnungsvollmachten (wer darf einen Rechnungsbetrag zur Zahlung freigeben). Neben den firmenspezifischen Buchungsregeln gibt es noch die produktspezifischen Regeln des
Buchhaltungssystems (z.B. Notation von Kostenstellen, Aufbau von Buchungsnummern usw.).
Mithin sollte die Kontierung möglichst im Buchhaltungssystem erfolgen, um dessen Geschäftslogik zu
nutzen. Der Bearbeiter muss Zugang zum Buchhaltungssystem haben, im Umgang damit geschult
sein und auch jene Buchungsregeln kennen, die nicht im Buchhaltungssystem implementiert sind.
Aus diesen Randbedingungen ergibt sich eigentlich eine möglichst späte Kontierung z.B. unmittelbar
vor der Buchung. Nach den IPC-Erfahrungen gibt es allerdings regelmäßig drei Anforderungen, die
eine frühe Kontierung oder zumindest Teilkontierung erzwingen:



Die Zuordnung zur Kostenstelle bestimmt die Zuständigkeit für die weitere Rechnungsprüfung. Wenn diese Information nicht automatisch aus den Rechnungsdaten extrahiert werden
konnte, muss sie manuell eingegeben werden.
Der Bearbeiter möchte bei der Freigabe (vgl. 3.2.6) wissen, welche Kostenstelle mit welchen Beträgen belastet wird und er möchte die Kostenstelle bei Bedarf korrigieren können.
Die Kontierung stellt implizit oder explizit die für eine Rechnungsprüfung erforderlichen Un-
Prozessmanagement
Seite 13 von 28
White Paper
Dr.-Ing. Rolf Meyer
Informations- und
terlagen bereit. Bestellunterlagen und Lieferscheine ergeben sich aus einer Bestell- oder
Auftragsnummer, Informationen zum Lieferanten aus der Kreditorennummer. Die Informationen können auch durch explizite Verknüpfung mit einer Vorgangsakte (z.B. in einer ECMLösung) bereitgestellt werden.
Die Kontierung vor der Prüfung hat demnach Vorschlagscharakter und kann im Zuge der Prüfung
noch geändert werden. Je nach technischen und organisatorischen Gegebenheiten kann der Ablauf
der Kontierung allerdings auch anders gestaltet werden (vgl. 3.3.3).
3.2.5 Prüfen (und Freigeben)
Die klassische Rechnungsprüfung umfasst 4 Elemente:
1. Die formale Prüfung – meist nach Maßgabe des UStG §14 – stellt sicher, dass die Rechnung
alle erforderlichen Angaben enthält. Bei einer elektronischen Rechnungsbearbeitung ist eine
formale Prüfung spätestens bei der Konvertierung (vgl. 3.2.3) üblich, d.h. unvollständige
Rechnungen gelangen gar nicht bis zur Kontierung und Prüfung.
2. Die rechnerische Prüfung stellt sicher, dass die in der Rechnung ausgewiesenen Beträge
und Teilbeträge (z.B. Rabatt-, Skonto- und Steuerbeträge) rechnerisch korrekt sind. Auch
diese Prüfung wird in einer elektronischen Rechnungsbearbeitung automatisiert und bereits
bei der Konvertierung durchgeführt.
3. Die sachliche Prüfung ist das wesentliche Element, weil sie sicherstellt, dass die Rechnung
begründet und authentisch ist, d.h. mit der Bestellung und Lieferung bzw. Leistung übereinstimmt sowie vom beauftragten Kreditor stammt. Diese Prüfung ist an den Empfänger der
Lieferung oder Leistung gebunden, weil nur er die auftragsgemäße Erfüllung bestätigen
kann. In vielen Firmen und Organisationen bewirkt dieser Zusammenhang, dass sehr viele
Mitarbeiterinnen und Mitarbeiter potenziell in die Rechnungsprüfung involviert sein können.
4. Die Freigabe der Zahlung ist an entsprechende Zeichnungsvollmachten gebunden und ist
meist auch das kritische Element bezüglich der Autorisierung (wer darf freigeben) und Authentifizierung (wer hat freigegeben, vgl. 4.7).
In den meisten Fällen ist die sachliche Prüfung der kritische Faktor einer elektronischen Rechnungsbearbeitung, weil sie besonders viele Benutzer berührt und dadurch einen sehr großen Lizenz- und
Schulungsbedarf erzeugen kann. Die Lösung des Problems entscheidet oft über den wirtschaftlichen
Erfolg einer elektronischen Rechnungsbearbeitung, deshalb wird dieses Thema im Abschnitt 5 umfassend behandelt.
Die formale und rechnerische Prüfung werden bei einer elektronischen Rechnungsbearbeitung automatisiert und erfordern nur manuelle Fehlerkorrekturen. Für die sachliche Prüfung und Freigabe
ergeben sich Optimierungsmöglichkeiten, die in Abschnitt 3.3.3 erläutert werden.
3.2.6 Buchen
Soweit eine Rechnung erfolgreich geprüft und freigegeben wurde und die Daten fehlerfrei in das
Buchhaltungssystem importiert wurden, kann die Buchung automatisch erfolgen. Etliche Buchhaltungssysteme enthalten auch entsprechende Funktionen. Sehr viele Anwender sind – zumindest am
Prozessmanagement
Seite 14 von 28
White Paper
Dr.-Ing. Rolf Meyer
Informations- und
Beginn einer elektronischen Rechnungsbearbeitung – misstrauisch und möchten die Ergebnisdaten
vor der Buchung einer zusätzlichen Qualitätskontrolle unterziehen.
Neben der möglichen Qualitätssicherung gibt es zwei Aufgaben, die automatisiert werden können,
aber nicht in jeder technischen Lösung automatisch durchgeführt werden:
1. Es muss geprüft werden, ob alle Rechnungsdatensätze im Buchhaltungssystem „angekommen“ sind. Das betrifft Rechnungen, deren Bearbeitung aus welchen Gründen auch immer
nicht abgeschlossen wurde. Es kann aber auch fehlerhafte Datensätze betreffen, die an den
Prüfroutinen der Importfunktion des Buchhaltungssystems gescheitert sind. Nicht jedes
Buchhaltungssystem generiert entsprechende Fehlermeldungen und die Fehlerfälle müssen
dann aus einem Fehlerprotokoll ermittelt und behoben werden.
2. Bei der Buchung sollten die archivierten Rechnungsdaten (vgl. 3.2.2) aktualisiert werden.
D.h. fehlerhafte Indexdaten werden korrigiert und fehlende Indexdaten oder Bearbeitungsvermerke werden ergänzt. IPC empfiehlt regelmäßig auch ein Vorgangsprotokoll für die Bearbeitung einer Rechnung automatisch erstellen und bei der Buchung archivieren zu lassen.
Die meisten Workflowsysteme (vgl. 4.6) generieren solche Protokolle per Standardfunktion.
3.2.7 Zahlungslauf
Die Zahlung der Rechnung erfolgt abschließend durch das Zahlungsmanagement. Dabei werden u.U.
mehrere Rechnungsbeträge eines Kreditors zu einer Zahlung zusammengefasst. Die einzelne Rechnung ist in der Zahlung dann nicht mehr identifizierbar. Deshalb wird die Zahlung im Modellprozess
nicht als Bestandteil der Rechnungsbearbeitung behandelt.
Die Zahlung kann jedoch zusätzliche Anforderungen an die Rechnungsbearbeitung hervorbringen. Mit
der Konvertierung werden die Rechnungsdaten für die Bedürfnisse des Rechnungsempfängers bzw.
seiner Anwendungssysteme transformiert. Es ist ein Gebot partnerschaftlicher Fairness, die Zahlungs- oder Überweisungsdaten nach den Bedürfnissen des Rechnungserstellers (Zahlungsempfänger)
zu gestalten, damit der Zahlungseingang möglichst unkompliziert verbucht werden kann.
Viele Rechnungsersteller benötigen eigene Kassenzeichen, Kunden- oder Auftragsnummern für ihre
Buchung. Solche Daten müssen dann durch die Prozesskette transportiert und in die Zahlung eingesteuert werden, obwohl sie für den Rechnungsempfänger selbst bedeutungslos sind.
3.3 Ablaufvarianten
3.3.1 Archivierung
Im Abschnitt 3.2.2 wurde die Archivierung an den Beginn der Prozesskette gestellt, um die Manipulationssicherheit zu verbessern bzw. deren Nachweis zu erleichtern. Dabei wurde die Nutzung der
Archiv-ID als Referenz auf die archivierten Daten empfohlen. Es gibt jedoch Buchhaltungssysteme,
die nur eine eigene ID als Referenz auf archivierte Dokumentdateien nutzen können! Im Zweifelsfall
ist der Aufruf der archivierten Daten aus dem Buchhaltungssystem unverzichtbar und ggf. muss eine
Rechnung zuerst im Buchhaltungssystem registriert werden, um eine Archiv-ID (des Buchhaltungssystems) zu erzeugen, unter der die Daten archiviert werden können.
Prozessmanagement
Seite 15 von 28
White Paper
Dr.-Ing. Rolf Meyer
Informations- und
Der zweite mögliche Grund für eine späte Archivierung (nach der Buchung) ist die Verfügbarkeit der
Daten. Es gibt Benutzer, die Rechnungen prüfen, aber zur Vermeidung von Lizenzkosten keinen Zugang zum Buchhaltungssystem erhalten sollen. Diese Benutzer können „ihre“ Rechnungen nur im
Archivsystem finden und einsehen. Dazu benötigen die archivierten Rechnungen eine ausreichende
Indexierung, die jedoch erst nach der Kontierung, Prüfung und ggf. Korrektur der Rechnungsdaten
möglich ist. Eine günstige Lösung ist die frühzeitige Archivierung, bei der fehlende oder korrigierte
Indexdaten später in einer Folgeversion archiviert werden.
Sogar wenn alle Benutzer direkten Zugriff auf das Buchhaltungssystem haben, kann der direkte Zugriff auf das Archiv unverzichtbar sein. Buchhaltungssysteme bzw. ihre Performanz leiden unter
einem wachsenden Datenvolumen. Die Buchungsdaten werden oft nach einigen Jahren ausgelagert
und mit ihnen der Zugriff auf die archivierten Rechnungsdokumente.
Die in Abschnitt 3.2.2 unterstellte frühe Archivierung ist also nur praktikabel, wenn


eine rudimentäre Indexierung der Rechnungsdateien im Archiv ausreicht, weil der Zugriff für
alle Benutzer und für die gesamte Aufbewahrungsdauer aus dem Buchhaltungssystem gesichert ist und das Buchhaltungssystem die Nutzung einer fremden Archiv-ID unterstützt oder
das Archivsystem die Versionierung der archivierten Rechnungsdaten unterstützt, so dass
fehlende oder korrigierte Rechnungsdaten in einer Folgeversion archiviert werden können.
3.3.2 Datenimport im Buchhaltungssystem
Aus einer Kontierung vor der Prüfung und im Buchhaltungssystem (vgl. 3.3.2) folgt implizit, dass die
Rechnungsdaten unmittelbar nach der Konvertierung (vgl. 3.2.3) in das Buchhaltungssystem importiert werden. Zudem sind die Rechnungsdaten im Buchhaltungssystem manipulationssicher gespeichert, während eine temporäre Datenhaltung im Filesystem mit technischen Problemen (Zugriffsschutz) behaftet ist. Die Reihenfolge Konvertierung > Import > Kontierung ist naheliegend und technisch wie organisatorisch sinnvoll, jedoch an Voraussetzungen gebunden:
1. Die Rechnungsdaten sind nach dem Import noch ungeprüft und nicht freigegeben. Das Buchhaltungssystem muss die importierten Rechnungsdaten von verbindlich gebuchten Daten unterscheiden.
2. Für die Prüfung und Freigabe benötigen die Bearbeiter einen Zugriff auf das Buchhaltungssystem und entsprechende Lizenzen. Ein lesender Zugriff ist im Normalfall kostengünstig realisierbar, schreibende Zugriffe (Änderungen der importierten Rechnungsdaten) werden von
vielen Softwareherstellern weniger großzügig angeboten.
Es kann technische oder wirtschaftliche Gründe geben, die einem Import der ungeprüften Rechnungsdaten in das Buchhaltungssystem entgegenstehen. Andererseits gibt es spezielle Anwendungssoftware (vgl. 4.2), die eine vorgelagerte Rechnungsbearbeitung mit geschützter Datenhaltung außerhalb des Buchhaltungssystems ermöglicht. Die Rechnungsdaten bleiben in dieser Anwendung, bis
sie freigegeben sind und werden erst danach in das Buchhaltungssystem importiert. Für solche Lösungen muss die Buchungslogik (vgl. 3.2.4) nicht nur im Buchhaltungssystem sondern auch im Anwendungssystem der Rechnungsbearbeitung implementiert und gepflegt werden.
Prozessmanagement
Seite 16 von 28
White Paper
Dr.-Ing. Rolf Meyer
Informations- und
3.3.3 Kontierung
Im Modellprozess (vgl. 3.1, Abbildung 3) werden Rechnungen kontiert, die bei der sachlichen Prüfung (vgl. 3.2.5) als fehlerhaft erkannt und reklamiert werden können. Abgesehen vom Problem
einer fehlerhaften Rechnung und den möglichen Verwicklungen einer Reklamation wäre das unerheblich, wenn die Rechnungen automatisch verarbeitet werden. Eine vollautomatische Kontierung
ist jedoch eher die Ausnahme, d.h. es wird auch Personalkapazität benötigt. Deshalb wäre eine
Kontierung nach der Prüfung und Freigabe effizienter, weil fehlerhafte Rechnungen frühzeitig erkannt und nicht kontiert werden.
Die kritischen Elemente der Kontierung sind das Kreditorenkonto und die Kostenstelle. Das Kreditorenkonto bestimmt das Regelwerk für die Konvertierung und muss ohnehin schon frühzeitig festgelegt werden. Die Kostenstelle bestimmt die Zuständigkeit für Prüfung und Freigabe der Rechnung
und soll bei der Freigabe explizit ausgewiesen werden. Die übrigen Daten der Kontierung können
ggf. auch erst nach der Prüfung und Freigabe festgelegt werden. Die Aufteilung der Kontierung in
zwei Schritte


Zuordnung zur Kostenstelle vor der Prüfung und Freigabe,
Festlegung der weiteren Kontierungsdaten nach der Prüfung und Freigabe
kann eine zweckmäßige Alternative sein. Der Aufwand für die Kontierung vor der Prüfung wird zwar
nicht beseitigt aber zumindest minimiert.
Das wesentliche Optimierungspotenzial resultiert aus einer sehr viel grundlegenderen Überlegung:
Die Rechnungsbearbeitung ist Teil des Beschaffungsprozesses (vgl. 3.1, Abbildung 2). In einem IT-gestützten Beschaffungsprozess sind fast alle Daten der Kontierung bereits bei der
Bestellung vorhanden. Nur die Buchungsperiode ergibt sich entweder aus dem Rechnungsdatum oder aus dem Zahlungsdatum.
In der konventionellen Rechnungsbearbeitung ist der Zusammenhang mit der Bestellung
praktisch nicht nutzbar, weil zwischen Bestellung, Lieferung und Rechnungseingang mehrere
Wochen oder Monate vergehen können.
In der elektronischen Rechnungsbearbeitung kann die „Zuordnung“ automatisiert werden. In
einem IT-gestützten Beschaffungsprozess wird bereits die Bestellung kontiert, geprüft und
freigegeben. Stimmt eine Rechnung mit den Bestell- und Lieferdaten überein, sind weitere
Kontierungen, Prüfungen und Freigaben entbehrlich!
Die elektronische Rechnungsbearbeitung unterstützt einen durchgängigen Beschaffungsprozess, der
dann seinerseits eine weitgehend automatische Rechnungsbearbeitung ermöglicht. Aus diesem Lösungsansatz ergeben sich fundamentale Vorteile und Verbesserungen:
1. Geprüft und freigegeben wird die Bestellung bevor eine Forderung des Kreditors begründet
wird. Das ist effektiv im Sinne der Unternehmenssteuerung.
2. Die Liquiditätsplanung wird mit den aktuellsten Daten versorgt. In Auswertungen ist jederzeit erkennbar, welches Finanzvolumen mit geplanten Beschaffungen, aktiven Bestellungen,
eingegangenen Lieferungen oder empfangenen Rechnungen bewegt wird.
3. Die Rechnungsbearbeitung kann auf den relevanten Gesichtspunkt reduziert werden –
Prozessmanagement
Seite 17 von 28
White Paper
Dr.-Ing. Rolf Meyer
Informations- und
stimmt die Rechnung mit Bestellung und Lieferung überein. Alle anderen Schritte können
weitgehend automatisiert werden.
Rechnungen
ohne Bestellbezug
Rechnungen
mit Bestellbezug
Bestellung freigeben
Lieferung prüfen
Rechnung erfassen
Rechnung erfassen
Rechnung kontieren
Rechnung prüfen
Rechnung freigeben
Rechnung buchen
Rechnung buchen
Abbildung 4: Rechnungsbearbeitung mit und ohne Bestelldaten
Der Modellprozess mit Kontierung, Prüfung und Freigabe ist mithin kein Optimum, sondern ein Zugeständnis an historisch gewachsene Abläufe und an den Sonderfall der kurzfristigen Beschaffung.
Natürlich gibt es und wird es immer Fälle geben, in denen Lieferungen oder Leistungen „freihändig“
beauftragt werden, d.h. ohne förmliche Bedarfsmeldung, Angebot, Bestellung und Lieferschein.
3.3.4 Buchung
Einige Buchhaltungssysteme können für das Berichtswesen eine vorläufige und eine verbindliche
Buchung nicht unterscheiden. Rechnungen im Prüfungsprozess werden dann in den monatlichen
Standardberichten nicht berücksichtigt und der Liquiditätsbedarf wird zu gering ausgewiesen.
Für ein Unternehmen besteht die regelmäßige Anforderung für die Feststellung eines (monatlichen)
aktuellen Geschäftsergebnisses. Rechnungen im Zulauf, die eine Geschäftsperiode betreffen, sollen
dabei berücksichtigt werden, selbst wenn es nachträglich zu Korrekturen kommen kann. Das Argument der Aktualität schlägt hier das Argument der abschließenden Korrektheit.
In solchen Fällen kann die Rechnung bereits nach dem Eingang kontiert und verbindlich gebucht
werden. Eine Zahlsperre verhindert während einer laufenden Prüfung die Auslösung einer unbeabsichtigten Zahlung. Ergibt die Prüfung der Rechnung eine Abweichung, erfolgt eine Korrekturbuchung. Diese Korrekturbuchung kann vollständig sein (Storno) oder in Verbindung mit einer Stornobuchung eine korrigierte Verbuchung der gleichen Rechnung.
3.4 Sonderfälle
3.4.1 Neuer Kreditor
Prozessmanagement
Seite 18 von 28
White Paper
Dr.-Ing. Rolf Meyer
Informations- und
Die Zuordnung zum Kreditor bestimmt weitgehend die automatische Verarbeitung von elektronischen Rechnungen. Eine Datenextraktion beginnt regelmäßig mit der Erkennung des Kreditors, aber
auch die Konvertierung strukturierter Rechnungsdateien in ein „Inhouse-Dateiformat“ ist auf die
Zuordnung der Rechnung zu einem Kreditor angewiesen. Folglich setzt die Rechnungsbearbeitung
immer voraus, dass ein Kreditorenkonto existiert und die erste Rechnung eines neuen Kreditors bildet den Sonderfall.
In der konventionellen Rechnungsbearbeitung kann die Pflege der Kreditorenstammdaten in die
Rechnungsbearbeitung integriert sein. Die eingegangene Rechnung wird zunächst der Buchhaltung
zugeleitet, wo sie vorerfasst und vorkontiert wird, bevor sie an den zuständigen Fachbereich überstellt wird. Fehlende oder fehlerhafte Kreditorenstammdaten können im Zuge der Vorerfassung
ergänzt bzw. korrigiert werden.
In der elektronischen Rechnungsbearbeitung ist diese formlose Variante der Pflege von Kreditorenstammdaten nur in Ausnahmen praktikabel. Im Normalfall erzeugen die IT-Systeme eine Fehlermeldung wenn die zweifelsfreie Zuordnung zum Kreditor misslingt. Die reguläre Prozesskette wird unterbrochen und erst nach Ergänzung oder Korrektur der Kreditorenstammdaten fortgesetzt.
Die einfachste Lösung für den Sonderfall ist ein Ad-Hoc-Workflow, der gestartet wird und die Imagedatei der Rechnung an die Buchhaltung weiterleitet, wo die Kreditorenstammdaten erfasst werden.
Größere Unternehmen bevorzugen meist die förmlichere Variante eines definierten Workflows „Kreditorenstammdaten“. In beiden Fällen ist die zeitliche Abhängigkeit zu beachten:



Der Kreditorenstamm wird im Buchhaltungssystem gepflegt.
Die Rechnungsdaten befinden sich noch in der Konvertierung, sind also im Buchhaltungssystem noch nicht vorhanden.
Die Konvertierung kann erst abgeschlossen werden, wenn die neuen Kreditorendaten aus
dem Buchhaltungssystem übertragen wurden.
Bei einem Direktzugriff der Konvertierung auf die Kreditorenstämme im Buchhaltungssystem ist das
kein Problem. Das ist jedoch nicht unbedingt der Normalfall, weil


die Performanz der Konvertierung durch die Kommunikation mit dem Buchhaltungssystem
beeinträchtigt wird. Viele „Konvertierungssysteme“ speichern die Referenzdaten (inkl. der
Kreditorendaten) in einer eigenen Datenbank.
das Buchhaltungssystem den Direktzugriff nicht ermöglicht sondern lediglich den Datenexport unterstützt. Dann müssen die exportierten Daten für die Konvertierung in einer separaten Datenbank gespeichert werden.
In beiden Fällen sind die Kreditorendaten erst nach dem Daten-Update in der Konvertierung verfügbar – üblicherweise max. 24 Stunden nach der Datenpflege im Buchhaltungssystem. Das ist unproblematisch, wenn die übrigen Rechnungsdateien ungehindert weiter verarbeitet werden können. Es
gibt allerdings auch Konstruktionen, bei denen die Rechnungen im Stapel konvertiert werden.
3.4.2 Investition
Weniger diffizil als ein neuer Kreditor sind die investiven Ausgaben, d.h. jene Rechnungen, die ne-
Prozessmanagement
Seite 19 von 28
White Paper
Dr.-Ing. Rolf Meyer
Informations- und
ben der Kreditorenbuchhaltung auch die Anlagenbuchhaltung durchlaufen sollen. In kleinen Firmen
sind diese Funktionen vielfach gar nicht getrennt und das Problem existiert nur theoretisch. Aber
auch in großen Organisationen ist die Lösung unkompliziert. Üblicherweise wird die Kontierung für
das Anlagenbuch einfach an die Buchung angehängt, nur wenn die Anlagenbuchung ebenfalls Gegenstand der Prüfung und Freigabe sein soll, muss sie in die Kontierung integriert werden.
Die Erkennung investiver Rechnungen bei der Konvertierung sollte nicht unterstellt werden, d.h.
zwei unterschiedliche Workflow-Definitionen sind ungünstig, weil eben bei der Konvertierung festgelegt wird, welche Art von Workflow zu starten ist. Ein nachträglicher Wechsel der WorkflowDefinition ist ebenso unzweckmäßig wie eine Beendigung des ersten Workflows und der Neustart in
einer Workflow-Definition „investive Rechnung“. Der Workflow für die Rechnungsbearbeitung (vgl.
4.6) sollte besser eine Verzweigung an der gewünschten Stelle vorsehen.
3.4.3 Reklamation
Fällt eine Prüfung negativ aus, ist ein Bearbeiter dazu aufgefordert, die Rechnung zu reklamieren.
Bei der konventionellen Rechnungsbearbeitung wird oft ein formloses Verfahren praktiziert:
Der Bearbeiter beim Rechnungsempfänger telefoniert mit dem Bearbeiter beim Rechnungsersteller und klärt den Sachverhalt. Ggf. werden Änderungen der Rechnung vereinbart und
beim Rechnungsempfänger handschriftlich auf dem Rechnungsdokument vermerkt.
Eine handschriftliche Notiz ist bei der elektronischen Rechnungsbearbeitung schon technisch nicht
einfach, viel gravierender sind jedoch die rechtlichen Folgen im Streitfall:
Änderungen im originären Datenbestand entwerten die Mechanismen der Manipulationssicherheit und sollten daher technisch unterbunden werden!
Die Erstellung und Archivierung einer neuen Version (mit den Bearbeitungsvermerken) ist
technisch möglich und auch zulässig – im Streitfall aber mehr oder weniger wertlos. Gewollte und ungewollte, sichtbare und unsichtbare, autorisierte und nicht autorisierte Veränderungen im Datenbestand sind nicht unterscheidbar! Der Rechnungsempfänger müsste bei
Bedarf nachweisen, dass unterschiedliche Prüfsummen und Versionsnummern ausschließlich
durch gewollte, sichtbare und autorisierte Änderungen entstanden sind.
Die IPC-Empfehlung lautet daher, formlose Reklamationen auf einfache Klärungen zu begrenzen und
jede Änderung der Rechnung beim Rechnungsersteller zu veranlassen. Dieser Reklamationsprozess
ist zwar durch den Bearbeiter zu initiieren, kann aber durch Automatisierung unterstützt werden
(Benachrichtigung des Lieferanten durch eine standardisierte E-Mail).
Für das Workflowmanagement ist es dann einfacher, die Bearbeitung der ersten reklamierten Rechnung zu beenden und mit Eingang der korrigierten Rechnung einen neuen Vorgang zu starten. Die
bereits im Buchhaltungssystem importierten Rechnungsdaten werden storniert.
In Ausnahmefällen wird der Vorgang der reklamierten Rechnung unterbrochen und mit Eingang der
korrigierten Rechnung fortgesetzt. Für solche Fälle sollte die korrigierte Rechnung eine Verknüpfung
mit der ursprünglichen Rechnung enthalten (z.B. gleiche Rechnungsnummer). Die technische Umsetzung solcher Lösungen bleibt in jedem Fall anspruchsvoll und meist fehleranfällig (fehlende Ver-
Prozessmanagement
Seite 20 von 28
White Paper
Dr.-Ing. Rolf Meyer
Informations- und
knüpfung zur ursprünglichen Rechnung, Fehlermeldung wegen gleicher Rechnungsnummer).
4 Komponenten der technischen Lösung
4.1 Scannen
Die Scan-Infrastruktur besteht aus Hardware (Scanner), Software (Scan-Software oder Scan-Client
sowie den Schnittstellen zu nachgelagerten Systemen), einem Zwischenlager für die gescannten
Papieroriginale und Arbeitsanweisungen für das Scannen. Beim Scannen kann eine vorhandene ScanInfrastruktur (z.B. im Rahmen einer ECM-Lösung, vgl. 4.8) auch für die Rechnungsbearbeitung genutzt werden.
Der Scanner erzeugt ein Bild (Foto) der Papierseite, das als Rastergrafik gespeichert wird. Die Rastergrafik kann in eine PDF-Datei eingebettet werden, sie enthält dennoch keine auswertbaren Textzeichen sondern nur Bildpunkte, die durch Texterkennung in Zeichenketten umgewandelt werden
müssen (vgl. 4.2). Der Scan-Output sollte übrigens auch nur Bildpunkte enthalten wie ein Beispiel
aus der Praxis zeigt:
Ein Softwareanbieter präsentierte seine Scan-Lösung mit integrierter Texterkennung. Der
Algorithmus funktionierte nicht nur prächtig, sondern enthielt auch gleich eine Rechtschreibkorrektur. Die Schreibfehler in der Rechnung (z.B. „Muster gmbb“) wurden in der
PDF-Datei korrigiert (>“Muster GmbH“). Leider gingen dabei die bildhafte Übereinstimmung
mit dem Original und der Nachweis der Manipulationssicherheit verloren.
Die üblichen Auflösungen für die elektronische Archivierung liegen bei 200 oder 300 dpi, weil das für
die menschliche Wahrnehmung am Bildschirm ausreicht. In der maschinellen Texterkennung (Datenextraktion, vgl. 4.2) kann die Auflösung jedoch Qualitätsunterschiede verursachen. Deshalb werden
Rechnungen oft mit 600 oder mehr dpi gescannt und erst nach der Datenextraktion werden die Dateien auf die geringere Auflösung reduziert, um das Datenvolumen im Archiv zu begrenzen.
Umgekehrt verhält es sich bei der Frage schwarz-weiß oder farbig. Informationstragende Farbdarstellungen (z.B. farbig unterlegte Rechnungsteile, handschriftliche Notizen oder Stempel) können
ein Farbscannen erzwingen. Für die Texterkennung ist eine farbige Imagedatei eher nachteilig, weil
die Algorithmen mit abnehmender Kontrastschärfe schlechtere Resultate liefern. Deshalb werden
Rechnungen gerne zunächst mit hoher Auflösung und farbig gescannt (Dateivolumen > 1 Mbyte), um
dann eine schwarz-weiß Imagedatei mit hoher Auflösung für die Texterkennung und eine farbige
Imagedatei mit geringer Auflösung für die Archivierung zu erzeugen.
4.2 Datenextraktion (REB-Komponente)
Die Möglichkeiten, mittels Texterkennung strukturierte Daten aus der bildlichen Rechnung zu gewinnen, sind auf die in der Rechnung dargestellten Angaben beschränkt. Meist enthält die Rechnung
nicht alle Angaben, die für eine folgende Rechnungsprüfung benötigt werden. Dazu kommen
Schreibfehler in der Rechnung (s.o.) und die Fehler der Texterkennung. Die einfache Texterkennung
würde mithin kaum nutzbaren Input für die Rechnungsbearbeitung liefern und die marktüblichen
Softwareprodukte leisten wesentlich mehr als nur eine Texterkennung.
Prozessmanagement
Seite 21 von 28
White Paper
Dr.-Ing. Rolf Meyer
Informations- und
Das gängige Verfahren besteht darin, Schlüsseldaten per Texterkennung auszulesen und mit vorhandenen Referenzdaten zu vergleichen. Beispielsweise wird die Rechnung nach Zeichenketten wie
„Konto“ oder „BLZ“ durchsucht und die Bankverbindung (Bankleitzahl und Konto) gelesen. Diese
Daten werden mit den Kreditorenstammdaten aus dem Buchhaltungssystem verglichen, um den Kreditor zu identifizieren. Schreib- oder Erkennungsfehler werden dabei implizit korrigiert. Scheitert
die Identifizierung, wird die Rechnung zur manuellen Prüfung und Bearbeitung ausgesteuert.
Die wichtigsten Referenzen, die in diesem Zusammenhang regelmäßig benötigt werden, sind:




Die Kreditorennummer (Referenz auf die Stammdaten des Rechnungsstellers)
Auftrags-, Bestell-, Vertrags- oder Vorgangsnummern (Referenz zu Bestelldaten)
Artikelnummern (Referenz zu Artikelstammdaten)
Preis- oder Tarif-Schlüssel (Referenz auf das Preis- und Tarifmodell)
Je nach Rechnungstyp können weitere Angaben gelesen und auf Plausibilität geprüft werden:





Rechnungsbeträge und Teilbeträge inklusive Währungszeichen
Umsatzsteuersatz und Steuerbeträge
Rabattkennzeichen, Rabattsatz oder andere Sonderkonditionen
Leistungsdatum bzw. Rechnungsdatum und Leistungsort
usw.
Ein häufiges Diskussionsthema sind die Positionsdaten. Einige Softwareprodukte verarbeiten nur den
Rechnungskopf (Rechnungssteller, Rechnungsempfänger, Rechnungsnummer, Datum etc.) und die
Rechnungsbeträge (Gesamtbetrag, Steuer- und ggf. Skontobetrag). Aber auch wenn die Verarbeitung
der Rechnungspositionen funktional vorgesehen ist, vergrößert sie die Menge der zu verarbeitenden
Zeichen und erhöht die Zahl der Erkennungsfehler. Die Leistung der Softwareprodukte ist ohne Positionsverarbeitung in jedem Fall höher. Bei manchen Rechnungstypen (z.B. Sammelrechnungen oder
Baurechnungen) ist eine Prüfung ohne Positionsdaten jedoch nicht praktikabel.
Ein weiteres Leistungsmerkmal der Datenextraktion ist ihre Anwendbarkeit auf „halbstrukturierte“
PDF-Dateien, die vom Rechnungssteller elektronisch erstellt und übermittelt wurden. Die Texterkennung wird hier nicht benötigt, aber die Mechanismen der Datenextraktion (Auffinden von Schlüsseldaten, Abgleich mit Referenzdaten) sind durchaus nützlich. Manche Softwareprodukte lassen nur
Imagedaten als Input zu – es soll vorkommen, dass elektronisch eingehende PDF-Dateien ausgedruckt
und gescannt werden, um sie mit der Datenextraktion zu verarbeiten! Die Auswahl einer Software,
die den elektronischen Rechnungseingang unterstützt, wäre wohl der bessere Lösungsansatz.
Der kritische Erfolgsfaktor für die Datenextraktion sind die Bestelldaten. Das Ergebnis der Datenextraktion ist umso besser, je mehr Referenzdaten verfügbar sind. Mit Bestelldaten kann nicht nur die
Erfolgsquote der automatischen Datenextraktion deutlich verbessert werden, sondern auch die
nachfolgenden Arbeitsschritte sind entbehrlich bzw. automatisierbar (vgl. 3.3.3). Ohne Bestelldaten
bleibt das Nutzenpotenzial begrenzt.
Die Programme benötigen eine kundenspezifische Konfiguration, um Referenzdaten aus den verschiedenen Datenquellen importieren und unterschiedliche Rechnungen vollständig interpretieren
zu können. Die Software läuft zunächst auf Analyse- oder Extraktionsservern im Hintergrund. Damit
fehlende oder fehlerhafte Daten durch manuelle Datenerfassung ergänzt bzw. korrigiert werden
Prozessmanagement
Seite 22 von 28
White Paper
Dr.-Ing. Rolf Meyer
Informations- und
können, gibt es eine Client-Komponente, deren Nutzung häufig Kontroversen erzeugt.
Viele Anwender präferieren eine manuelle Bearbeitung (Validierung) der Daten im Zuge der sachlichen Prüfung (vgl. 3.2.5). Für die Ablauforganisation ist das naheliegend, weil die Rechnungsdaten
bei der sachlichen Prüfung ohnehin gesichtet werden und weil der Prüfer am besten Fehler erkennen und Daten ergänzen kann. Die Validierung im Zuge der sachlichen Prüfung widerspricht jedoch
fundamental der technischen und lizenzrechtlichen Konzeption der Softwareprodukte:



Die Serverkomponenten werden üblicherweise nach Durchsatz (Rechnungen pro Jahr) lizenziert, die Client-Komponenten jedoch nach Arbeitsplätzen.
Zudem sind viele Softwareprodukte – vor allem die Besseren – selbstlernende Systeme. Eine
Fehlbedienung am Client belastet nicht nur die jeweilige Rechnung, sie wird auch als „Lernergebnis“ im System gespeichert und reduziert die Leistung bei weiteren Rechnungen.
Viele Benutzer bearbeiten nur wenige Rechnungen im Monat und können die Handhabung
der Software nicht optimieren. Fehlbedienungen und Supportanfragen sind die Folge.
Eine Validierung der Datenextraktion in Verbindung mit der sachlichen Prüfung ist ablauforganisatorisch naheliegend und oft gewünscht, aber in 9 von 10 Anwendungsfällen ist sie nicht praktikabel (zu
teuer, zu umständlich, zu fehleranfällig).
Die Softwareprodukte für die Datenextraktion lassen sich in drei Kategorien einteilen:
1. Buchhaltungsnahe Systeme sind auf die Verarbeitung von Rechnungen spezialisiert und
werden daher auch als „REB-Komponenten“ bezeichnet (REB: Rechnungseingangsbearbeitung). Sie beinhalten oft vorkonfigurierte Workflows für die Rechnungsprüfung und leistungsstarke Schnittstellen zu einem oder mehreren Buchhaltungssystemen. Die Verarbeitung
von elektronisch eingehenden Rechnungen ist üblich, die Verarbeitung von anderen Dokumentarten (Nicht-Rechnungen) dagegen nicht.
2. REB-Komponenten im Buchhaltungssystem funktionieren wie buchhaltungsnahe REBSysteme, benötigen jedoch keine Schnittstelle. Im Gegenzug sind sie nur mit einem bestimmten Buchhaltungssystem nutzbar und oft auch an dessen Lizenzmodell gebunden.
3. ECM-nahe Systeme werden als Teil von ECM-Lösungen (vgl. 4.8) angeboten. Sie sind nicht
auf Rechnungen spezialisiert, sondern können auch andere Dokumentarten verarbeiten. Die
Implementierung der Workflows und die Konfiguration der Schnittstellen erzeugen Mehraufwand im Projekt, aber die Lizenzkosten sind meist geringer als in den anderen Kategorien.
Die Lösungen haben sich zunehmend verbessert, so dass die Automatisierungsraten auch bei mäßig
günstiger Struktur des Rechnungsaufkommens (viele Rechnungen von vielen Kreditoren) brauchbar
ausfallen. Im Zweifelsfall gilt die Formel „je besser die Referenzdaten, desto besser das Ergebnis“.
4.3 Elektronischer Datenaustausch (EDI)
EDI-Konverter sind Softwareprodukte, die von verschiedenen Herstellern mit unterschiedlichen Leistungsmerkmalen angeboten werden. Ein EDI-Konverter sendet und empfängt elektronische Nachrichten und setzt die Daten in ein gewünschtes Zielformat um. Der EDI-Konverter protokolliert den
Datenverkehr und verwaltet Fehlerprotokolle.
Prozessmanagement
Seite 23 von 28
White Paper
Dr.-Ing. Rolf Meyer
Informations- und
Es ist eine Batch-Verarbeitung, die nicht an die Reaktionszeiten einer service-orientierten Variante
herankommt. Der Rechnungssteller muss seine Daten exakt entsprechend der Protokoll-Vorgaben
bereitstellen, sonst wird die Verarbeitung der Rechnung verweigert.
Das Grundformat wird zwar durch den EDIFACT-Standard für Rechnungen (Format INVOIC) vorgegeben, aber die Vorgaben bedürfen der Ergänzung durch zusätzliche Regelungen und Vereinbarungen
zur Datenübermittlung. Um alle Rechnungen verarbeiten zu können, sind umfangreiche Vorbereitungen und Abstimmungen zwischen Ersteller und Empfänger erforderlich.
EDI ist für große Datenmengen optimiert, weil das kompakte Format der Rechnungsdaten einen großen Datendurchsatz ermöglicht. Nach wirtschaftlichen Gesichtspunkten lohnt sich EDI-Technik in der
Rechnungsverarbeitung nur bei einem großen Nachrichtenvolumen mit wenigen Partnern. Dann lassen sich die Projektkosten für Vorbereitung, Abstimmung und Programmierung amortisieren.
4.4 Webservice
EDI-Verfahren sind eine bilaterale Lösung zwischen einem Rechnungsersteller und einem Empfänger.
Web-Services können auf verschiedenen Plattformen betrieben werden und sind universell einsetzbar. Die Web-Technologie bietet die Möglichkeit, einer breiten Nutzung durch viele Ersteller oder
Empfänger von Rechnungen. Die Webservices können



vom Rechnungsersteller (Download aus einem gesicherten Internet-Portal)
vom Rechnungsempfänger (Upload der Rechnungsdaten in ein geschütztes Portal) oder
einer neutralen Instanz (vor allem als Cloud-Lösung, vgl. 4.5)
angeboten werden.
Häufig wird zusätzlich zu einer Schnittstelle eine Web-Front-Anwendung zur Verfügung gestellt,
über die das Einstellen von Rechnungen geführt wird. Dabei werden Fehler in den Daten durch Prüfroutinen schon vor dem Sendevorgang abgefangen. Direkt nach Dem Sendevorgang erstellt die WebAnwendung eine Verarbeitungsquittung, die entweder die Annahme bestätigt und oder über die
verweigerte Annahme der Bearbeitung informiert. Es können lizenzpflichtige und lizenzfreie Applikationsserver eingesetzt werden.
Die Rechnungen werden fast in Echtzeit ausgetauscht und verarbeitet. Dabei können existierende
Internet-Verbindungen genutzt werden und erst bei durchgängig hohem Datenaufkommen müssen
zusätzliche Leitungskapazitäten geschaffen werden.
Die Webservices lassen sich über Programmaufrufe relativ einfach in die bestehende Geschäftslogik
einbinden, was frühzeitige automatisierte Prüfungen erleichtert. Dadurch wird nicht nur die Häufigkeit von Fehlern reduziert sondern auch der Aufwand für ihre Korrektur.
4.5 ASP- oder Cloud-Lösung
Ein E-Invoicing-Verfahren kann auch mittels einer ASP-Lösung implementiert werden. Der Unterschied zwischen ASP- (Application Service Providing) und Cloud-Lösungen (ASP in Web-Technologie)
löst sich zunehmend auf und viele ASP-Anbieter stellen auf Cloud-Computing um. Die verwendete
Prozessmanagement
Seite 24 von 28
White Paper
Dr.-Ing. Rolf Meyer
Informations- und
Technik und die Funktionalität der Lösung unterscheiden sich daher nicht nennenswert von eigenen
service-orientierten Web-Anwendungen. Der wesentliche Unterschied ist die Art der Einführung und
die Art der anfallenden Kosten:


Webservices des Erstellers oder des Empfängers von Rechnungen sind mit eigenem Projektaufwand, zeitlichem Vorlauf und hohen Investitionen verbunden.
ASP- oder Cloud-Lösungen werden von einem Service-Anbieter implementiert, d.h. Ersteller
und Empfänger von Rechnungen können sie mit minimalem Projektaufwand, geringem Vorlauf und ohne große Investitionen nutzen. Die Abrechnung kann als „pay per use“ erfolgen.
Neben den E-Invoicing-Verfahren gibt es auch Scan- und Datenextraktionsverfahren als ASPLeistung. Dabei wird der Rechnungseingang zum Dienstleister umgeleitet, der die konventionellen
Rechnungen scannt und in strukturierte Daten konvertiert. Der Output wird dann entweder als
Download im Internet-Portal oder (immer seltener) auf Datenträgern (z.B. DVD) bereitgestellt.
ASP-Lösungen können nicht nur das gesamte Spektrum des Rechnungseingangs bedienen, sie sind
auch „diplomatisch unverfänglich“. Der Daten-Upload in das Portal des Rechnungsempfängers bedient naturgemäß dessen Systemlandschaft und der Rechnungsersteller muss seine Rechnung entsprechend anpassen. Das muss der Rechnungsersteller dann u.U. für viele Rechnungsempfänger mit
unterschiedlichen Systemlandschaften bewerkstelligen. Die umgekehrte Konstellation (DatenDownload aus dem Portal des Kreditors) ist nicht einfacher. ASP-Lösungen sind neutral – beide Partner haben gleiche Chancen und gleiche Probleme.
ASP-Lösungen sind vor allem für kleinere und mittlere Firmen geeignet, deren Geschäftsvolumen die
Investition in eigene Lösungen nicht rechtfertigt. Dabei findet die Verarbeitung des Rechnungsverkehrs auf der Plattform des Dienstleisters statt, es werden aber auch Lösungen zur Installation auf
eigenen Plattformen angeboten.
4.6 Workflow
Die elektronische Rechnungsbearbeitung erzeugt keine „sichtbaren Merkposten auf dem Schreibtisch“. Alle erforderlichen Aktivitäten von Benutzern sind nur in den jeweiligen Anwendungssystemen erkennbar und an der Rechnungsbearbeitung sind mehrere Anwendungssysteme (Datenextraktion, Konvertierung, Archiv, Buchhaltung) beteiligt. Eine Vorgangssteuerung durch einen Workflow ist
daher für jede Form der elektronischen Rechnungsbearbeitung dringend zu empfehlen.
Der Workflow muss



jeden Benutzer identifizieren, erkennen und erreichen können, der an der Rechnungsbearbeitung beteiligt ist,
ermitteln können, welcher Benutzer für eine bestimmte Aufgabe zuständig ist sowie
die Verknüpfungen zu den Rechnungsdaten in den verschiedenen IT-Systemen verwalten und
dem Benutzer zur Verfügung stellen.
Wegen der Vielzahl möglicher Ablaufvarianten und Sonderfälle sowie der „Anwendungsbreite“ (viele
potenzielle Benutzer in vielen Organisationseinheiten) mit Außenwirkung (auf die Kreditoren) ist die
Rechnungsbearbeitung als Einstieg in die Workflow-Technologie nicht zu empfehlen. Vor der Rech-
Prozessmanagement
Seite 25 von 28
White Paper
Dr.-Ing. Rolf Meyer
Informations- und
nungsbearbeitung sollten bereits Erfahrungen mit der Workflownutzung vorliegen.
Die Anforderungen und Randbedingungen gelten nicht spezifisch für die Rechnungsbearbeitung oder
den Beschaffungsprozess. Deshalb wird in dieser Firmenschrift das Workflowmanagement nicht ausführlich behandelt6.
4.7 Authentifizierung
In der konventionellen Rechnungsbearbeitung werden Bearbeitungs-, Prüfungs- und Freigabevermerke handschriftlich auf der Rechnung oder einem Kontierungsblatt und eingetragen und mit Unterschrift oder Handzeichen bestätigt. Dieses Verfahren muss bei der elektronischen Rechnungsbearbeitung durch eine elektronische Lösung ersetzt werden. Rechtlich ist das unproblematisch, weil die
gesetzlichen Grundlagen existieren (vgl. 2.1).
Im einfachsten Fall genügt die Anmeldung mit Benutzername und Kennwort im Betriebssystem. Bei
einem Single-Sign-On wird die Benutzeridentität an die beteiligten IT-Systeme übermittelt und in
Datensätze und Protokolle eingetragen. Diese Lösung ist technisch einfach, sollte jedoch mit der
Geschäftsleitung und Innenrevision bzw. Wirtschaftsprüfer oder Steuerberater abgestimmt sein.
Die nächste Stufe ist die Bestätigung der einzelnen Transaktion (Prüfung, Freigabe oder Reklamation
einer bestimmten Rechnung) durch erneute Eingabe der Benutzerkennung. Das ist immer noch einfach umsetzbar und kann für die neuen gesetzlichen Anforderungen ausreichen.
Eine fortschrittliche Lösung ist die Verwendung von Mitarbeiter-Chipkarten7, die beispielsweise auch
den Zugang zu den Betriebsräumen ermöglichen, die Abrechnung von Kantinenessen unterstützen
und Druckprozesse auf Etagendruckern starten. Die Transaktionen werden nur ausgeführt, wenn die
Chipkarte sich im Lesegerät befindet und der Karteninhaber für die Transaktionen berechtigt ist.
Für Unternehmen, die eine erhöhte Anforderung stellen, bieten verschiedene Anbieter OutsourcingLösungen für die Signierung und Validierung von Rechnungen an. Der Aufbau einer eigenen Infrastruktur für die Erzeugung und Validierung digitaler Signaturen ist nur für die Rechnungsbearbeitung
nicht zu begründen. Soweit solche Infrastrukturen bereits für andere Anwendungen vorhanden sind,
bietet sich ihre Nutzung natürlich an.
4.8 Elektronisches Archiv
Ein elektronisches Archiv ist die etablierte Lösung für eine revisionssichere Speicherung der anfallenden Daten, allerdings kann die Manipulationssicherheit auch mit anderen Mitteln (z.B. Zeitstempeln, Signaturen, restriktiven Zugriffsrechten usw.) erreicht werden. Solche Lösungen sind nicht
ausgeschlossen, aber sie generieren Mehraufwand.
Im Normalfall ist das Archiv Bestandteil einer umfassenderen ECM-Lösung (ECM: Enterprise Content
6
Einzelheiten und ausführliche Erläuterungen zur Auswahl, Einführung und Nutzung von Workflowsystemen sind in der IPCFirmenschrift „Workflowmanagement“ zu finden.
7
Die Chipkarte bietet zusätzliche Sicherheit, weil ein ausgespähtes Passwort nicht unbedingt umgehend geändert wird,
während die unverzügliche Sperrung nach Verlust der Chipkarte unterstellt werden darf.
Prozessmanagement
Seite 26 von 28
White Paper
Dr.-Ing. Rolf Meyer
Informations- und
Management) und erlangt sogar für die Rechnungsbearbeitung eine tragende Rolle. Im Unterschied
zu Buchhaltungssystemen sind die ECM-Lizenzen relativ günstig und das ECM-System ist unternehmensweit verfügbar. Für einen unternehmensweiten Prozess „Rechnungsbearbeitung“ ist das ECMSystem daher eine naheliegende Plattform. Viele Anwender entscheiden sich dann auch, eine integrierte Workflowkomponente im ECM-System zu nutzen.
Sofern eine umfassende ECM-Lösung bereits vorhanden ist, sollte sie auch eine Scan-Infrastruktur
beinhalten, deren Nutzung für die Digitalisierung von Rechnungen sich ebenfalls anbietet (vgl. 4.1).
Gleiches gilt für die Datenextraktion (vgl. 4.2), deren Anwendung nicht auf Rechnungen begrenzt
sein muss. Vor allem leistungsstarke Softwarekomponenten für die Datenextraktion sind oft teuer
und benötigen eine funktionale Integration in die Systemlandschaft. Es wäre wirtschaftlich wenig
sinnvoll, ihre Nutzung dann auf die Rechnungsbearbeitung zu reduzieren.
Die technischen Details einer ECM-Lösung bzw. der revisionssicheren elektronischen Archivierung
werden hier als bekannt vorausgesetzt und nicht weiter behandelt8.
5 Bewertung der Varianten
Die Aufbereitung von Papierrechnungen durch Scannen und Datenextraktion für eine elektronische
Rechnungsbearbeitung ist eine erprobte und etablierte Technologie, deren Nutzung jedoch keinesfalls trivial ist. Vor allem der Einfluss der Referenzdaten auf die Qualität des Daten-Outputs wird oft
unterschätzt. Fehlende Bestelldaten und fehlerhafte Kreditorenstämme können die Erkennungsrate
und damit die Wirtschaftlichkeit der Systemnutzung beeinträchtigen.
Die frühen Ansätze für E-Invoicing-Lösungen mit EDIFACT waren für breite Massenanwendungen
letztlich zu umständlich. Erst mit der Bereitstellung des Internets als Kommunikationsplattform und
der Standardisierung geeigneter Dateiformate wie XML wurden die technischen Grundlagen für allgemein nutzbare E-Invoicing-Lösungen geschaffen. Lange Zeit wurde deren Nutzung jedoch durch
gesetzliche Anforderungen (elektronische Signatur) erschwert.
Erst mit den letzten Vereinfachungen der gesetzlichen Anforderungen ist der Weg für eine verbreitete Nutzung von E-Invoicing frei geworden. Deshalb dominiert bisher die mit dem Medienbruch
behaftete elektronische Rechnungsbearbeitung. Wegen der größeren Nutzenpotenziale erwartet IPC
jedoch mittelfristig eine deutliche Zunahme von E-Invoicing-Lösungen. Wir empfehlen unseren Kunden daher eine sorgfältige Prüfung, ob die Investition in eine Optimierung des Medienbruchs auch
dann noch gerechtfertigt ist, wenn Papierrechnungen zunehmend durch elektronische Rechnungen
ersetzt werden und das Volumen der konventionellen Papierrechnungen deutlich abnimmt.
Bei allen Varianten der elektronischen Rechnungsbearbeitung ist der Kontext mit dem übergeordneten Beschaffungsprozess zu beachten. Die Datenextraktion aus Papierrechnungen liefert nach den
IPC-Erfahrungen erst dann zufriedenstellende Resultate, wenn qualitativ hochwertige Referenzdaten
aus den Bestellungen vorliegen. Aber auch die E-Invoicing-Lösungen sind mit dem Problem der Li-
8
Umfassende Erläuterungen zur elektronischen Archivierung sind der IPC-Firmenschrift „ECM mit SharePoint 2010“ zu entnehmen.
Prozessmanagement
Seite 27 von 28
White Paper
Dr.-Ing. Rolf Meyer
Informations- und
zenzkosten behaftet:
Die Kontierung, Prüfung und Freigabe der Daten im Buchhaltungssystem ist die einfache,
naheliegende und relativ fehlersichere Lösung. Dazu muss das Buchhaltungssystem auf allen
Arbeitsplätzen verfügbar sein, die von der Rechnungsbearbeitung berührt werden.
Das Ausweichen auf andere Anwendungssysteme ist bestenfalls eine Notlösung, weil die Client-Komponenten von Datenextraktions- oder REB-Systemen im Normalfall ebenfalls nach
Arbeitsplätzen lizenziert werden müssen. Die kostengünstigste Variante ist meist die Nutzung einer ECM-Lösung, wenn diese Querschnittsanwendung betriebsweit genutzt wird. Die
Einführung einer ECM-Lösung nur für Zwecke der Rechnungsbearbeitung ist nicht sinnvoll,
weil die Kosten eines ECM-Arbeitsplatzes mit wenigen Rechnungen pro Monat nicht zu erwirtschaften sind.
Alle Ausweichlösungen sind zudem mit dem Nachteil behaftet, dass fehlerhafte Rechnungsdaten erst beim Import in das Buchhaltungssystem erkannt werden, weil die Daten erst hier
gegen die Geschäftslogik des Debitors geprüft werden. Die Implementierung der Geschäftslogik in einem vorgelagerten System ist eine eher theoretische Option. Letztlich entscheidet
immer das Buchhaltungssystem, ob Rechnungsdaten „buchungsfähig“ sind oder nicht.
Wie immer einzelne Varianten der elektronischen Rechnungsbearbeitung bewertet werden – das
nachhaltige und umfassende Nutzenpotenzial liegt in der Reorganisation des Beschaffungsprozesses.
Die Umstellung auf einen elektronischen Beschaffungsprozess ermöglicht nicht nur die zuverlässige
Bereitstellung und Verknüpfung der Bestelldaten mit eingehenden Rechnungen, sie macht Arbeitsschritte wie die Kontierung, Prüfung und Freigabe nach dem Rechnungseingang weitgehend entbehrlich. Auf die Ausnahmen wurde in Abschnitt 3.3.3 hingewiesen.
Viele Anbieter von REB-Lösungen haben die Unzulänglichkeit einer isolierten Rechnungsbearbeitung
erkannt und begonnen, ihre Softwaresysteme für einen integrierten Beschaffungsprozesses zu erweitern. Verbreitet sind solche Lösungen bisher nicht und können es auch nicht sein. Ein elektronischer
Beschaffungsprozess setzt nicht nur technische Funktionalität in den Systemen voraus, sondern auch
und vor allem eine entsprechende Prozessorganisation in den betroffenen Fachbereichen. Tatsächlich ist bereits die Umstellung auf die Arbeitsweisen der viel einfacheren Rechnungsbearbeitung für
viele Anwender eine erhebliche Belastung.
Der Prozessablauf der elektronischen Rechnungsbearbeitung ist das Resultat vielschichtiger organisatorischer und technischer Überlegungen. Die digitale Prozesskette umfasst mehrere IT-Systeme
und der Ablauf muss der Funktionalität und den Lizenzmodellen dieser Systeme angepasst werden.
Jede Form der elektronischen Rechnungsbearbeitung ermöglicht die Integration in einen ITgestützten Beschaffungsprozess und damit die nachhaltige und gewichtige Verbesserung. Ohne diese
Integration bleibt das Optimierungspotenzial begrenzt.
Diese Firmenschrift soll nicht für das Warten auf eine perfekte Lösung plädieren. Bei den meisten
IT-Lösungen haben sich schrittweise Einführungen und Teillösungen bewährt. Die Firmenschrift soll
jedoch deutlich aufzeigen, dass die aktuellen Lösungsangebote nicht als Endzustand einer Entwicklung zu betrachten sind. Deshalb sollten die technischen und organisatorischen Lösungen unter dem
Aspekt ihrer funktionalen Erweiterbarkeit konzipiert und ausgewählt werden.
Prozessmanagement
Seite 28 von 28

White Paper (Rechnungsbearbeitung - Dr.

Transcrição

Documentos relacionados

Jede Rechnung stets im Blick

Leitfaden Elektronische Rechnungsbearbeitung

Stellenanzeige Bürokauffrau

Weniger Aufwand in der SAP®- Rechnungsbearbeitung. Weniger

Automatische Rechnungsbearbeitung für internationale Rechnungen

sap invoice management by opentext vermessung

Elektronische Rechnungsstellung wird Teil der gemeinsamen

R+V Standard Word97 Dokumentvorlage

Das Rennen um die Industrialisierung

Antworten Auf häufig gestellte frAgen zum themA e-invoicing