Autor: Satish Bhattrai, Senior SAP Consultant (B2G)
E-Rechnungsstellung hängt von mehr ab als nur der Technologie, die zum Übertragen einer Rechnung verwendet wird. USt-IDs, Adressen, Teilnehmer-IDs, Steuerdaten und andere Informationen müssen zuverlässig sein, bevor sie den Compliance-Prozess erreichen.
Wenn eine Rechnung zu einem strukturierten elektronischen Dokument wird, müssen die dahinterstehenden Informationen ausreichend genau sein, damit ein anderes System, ein Geschäftsnetzwerk oder eine Steuerbehörde sie verarbeiten kann.
Eine fehlende USt-ID, eine veraltete Kundenadresse, ein falsches Steuerfeld oder inkonsistente Geschäftspartnerdatensätze bleiben möglicherweise nicht nur ein internes Datenqualitätsproblem. Es kann das aus diesen Informationen generierte elektronische Dokument beeinflussen und je nach Compliance-Szenario zu Validierungsfehlern, Ablehnungen, Korrekturen oder zusätzlichen manuellen Arbeiten führen.
Deshalb muss Datenqualität als Teil eines SAP E-Rechnungsstellungsprogramms behandelt werden, nicht als separate Aufräumaktion.
SAP Document and Reporting Compliance unterstützt die Erstellung, Verarbeitung und Überwachung elektronischer Dokumente und gesetzlicher Berichte. SAP beschreibt diese als Kernfunktionen für Document and Reporting Compliance, während SAP Document and Reporting Compliance, cloud edition den Austausch elektronischer Dokumente mit externen Kommunikationspartnern und die Übermittlung von Berichten in anwendbaren Szenarien unterstützt.
Beide hängen weiterhin von der Qualität der Informationen ab, die den Compliance-Prozess speisen.
Warum E-Rechnungsstellung Datenqualität wichtiger macht
Die traditionelle Rechnungsstellung lässt oft Raum für menschliche Interpretation.
Eine Person, die eine Rechnung erhält, erkennt möglicherweise einen leicht inkonsistenten Kundennamen, versteht eine abgekürzte Adresse oder löst manuell eine Referenz auf, die nicht perfekt mit einem anderen System übereinstimmt.
Die strukturierte elektronische Rechnungsstellung ist weniger nachsichtig.
Informationen werden über vordefinierte Felder und Formate ausgetauscht. Je nach Gerichtsbarkeit und Szenario können diese Felder Steuerkennungen, Geschäftspartnerdetails, Adressen, Rechnungsreferenzen, Steuerinformationen, Belegdaten und andere Informationen enthalten, die zur Verarbeitung der Rechnung erforderlich sind.
Die SAP-Dokumentation für die elektronische Rechnungsstellung zeigt, wie eine Quellrechnung verwendet werden kann, um ein elektronisches Dokument zur Übermittlung über den eDocument-Prozess zu generieren.
Die Umwandlung von Informationen in ein technisch gültiges elektronisches Format macht die zugrunde liegenden Geschäftsinformationen nicht automatisch korrekt.
Die TJC Group hat dasselbe Problem in ihrer Anleitung zur SAP DRC-Integration hervorgehoben. E-Rechnungen und gesetzliche Berichte hängen von Transaktions- und Stammdaten in der gesamten Geschäftslandschaft ab, wodurch Datenqualität und Governance ein wichtiger Bestandteil der SAP DRC-Bereitschaft sind.
Woher stammen die SAP E-Rechnungsstellungsdaten?
Eine elektronische Rechnung beginnt nicht, wenn das Dokument an eine externe Plattform übermittelt wird. Sie beginnt viel früher im Geschäftsprozess.
In vielen SAP DRC-Szenarien existieren Kundeninformationen, Unternehmensdaten, Steuerinformationen, Vertriebs- und Einkaufsdaten, Adressen, Rechnungsdetails und andere relevante Felder bereits in SAP, bevor das elektronische Dokument erstellt wird.
Unterstützte Prozesse können auch elektronische Dokumente umfassen, die außerhalb von SAP-Anwendungen erstellt wurden, sodass die genaue Quelllandschaft von der Organisation und dem Szenario abhängt. Die Dokumentation von SAP zu Document and Reporting Compliance deckt explizit elektronische Dokumente ab, die aus Quelldokumenten in anderen Anwendungen erstellt wurden.
Für die ausgehende Rechnungsstellung sind Kunden- und Unternehmensstammdaten besonders wichtig. Lieferanteninformationen werden in eingehenden Lieferantenrechnungs- und Self-Billing-Szenarien, die SAP separat dokumentiert, direkter relevant.
Die involvierten Informationen können grob in mehrere Bereiche gruppiert werden:
| Datenbereich | Beispiele |
|---|---|
| Unternehmen und Rechtsträger | USt-ID des Unternehmens, rechtliche Kennungen, registrierte Details |
| Geschäftspartner | Kunden- oder Lieferantenkennungen, Steuerregistrierungen, Adressen |
| Transaktion | Rechnungsnummer, Daten, Beträge, Positionen, Belegreferenzen |
| Steuerdaten und Bestimmungseingaben | Steuercodes, Kategorien, Sätze, Befreiungsinformationen |
| Elektronischer Austausch | Peppol-Teilnehmer-IDs oder andere erforderliche elektronische Kennungen |
Diese Kategorien sind wichtig, da die Korrektur dort erfolgen muss, wo das Problem tatsächlich entsteht. Ein fehlerhafter Geschäftspartnerdatensatz unterscheidet sich von einem falschen Transaktionswert, und beide unterscheiden sich von einem falschen Mapping oder einer Systemkonfiguration.
SAP DRC kann dann Informationen aus der zugrunde liegenden Geschäftstransaktion als Teil des elektronischen Dokumentenprozesses verwenden.
Stammdaten sind gleichermaßen wichtig. SAP dokumentiert beispielsweise, dass Kunden, die im Peppol-Netzwerk durch eine GLN identifiziert werden, diese Informationen in den Kundenstammdaten pflegen müssen.
Wenn ein Dokument das SAP DRC-Monitoring erreicht, kann das zugrunde liegende Problem daher viel früher entstanden sein, als ein Geschäftspartner angelegt, eine Steuernummer eingegeben, eine Adresse geändert oder eine Rechnung gebucht wurde.
Häufige Datenqualitätsprobleme, die die SAP E-Rechnungsstellung beeinflussen können
Nicht jedes Land benötigt exakt dieselben Daten, und die Auswirkung eines falschen Feldes variiert je nach Mandat und SAP-Szenario.
Es gibt jedoch einige wiederkehrende Bereiche, denen Organisationen besondere Aufmerksamkeit schenken sollten. Betrachten wir sie einzeln.
Falsche oder veraltete USt- und Steuernummern
Steuerkennungen gehören zu den offensichtlichsten Beispielen. Ein Kunde oder Lieferant kann eine falsche USt-ID haben, eine Kennung kann sich geändert haben, ohne dass der relevante Stammdatensatz aktualisiert wurde, oder verschiedene Systeme können unterschiedliche Versionen derselben Steuerinformationen enthalten.
Das wird wichtig, wenn die Kennung als Teil einer elektronischen Rechnung erforderlich ist oder zur Identifizierung eines Geschäftspartners im Austauschprozess verwendet wird.
Die SAP-Dokumentation liefert ein konkretes Beispiel für diese Abhängigkeit. Die Peppol-Identifikation kann auf Kennungen basieren, die für den relevanten Kunden oder die Organisation gepflegt werden, abhängig vom Land und dem Identifikationsschema.
Die Korrektur eines einzelnen elektronischen Dokuments löst daher möglicherweise nicht das zugrunde liegende Problem.
Bleibt der Quelldatensatz fehlerhaft, kann dasselbe Problem bei zukünftigen Transaktionen erneut auftreten.
Unvollständige Kunden- oder Lieferantendatensätze
Ein Datensatz muss nicht vollständig falsch sein, um Probleme zu verursachen. Er kann einfach unvollständig sein. Kunden- und Lieferantendatensätze können im Laufe der Zeit Lücken ansammeln, insbesondere wenn Organisationen mehrere SAP-Systeme betreiben, Akquisitionen durchlaufen haben, lokale Prozesse verwenden oder Geschäftspartner in verschiedenen Ländern unterschiedlich gepflegt haben.
Ein Kundendatensatz könnte den korrekten Namen enthalten, aber eine für einen bestimmten elektronischen Austausch erforderliche Kennung fehlen. Ein anderer könnte Steuerinformationen, aber eine unvollständige Adresse enthalten.
Die SAP-Dokumentation zu Peppol enthält länderspezifische Stammdatenanforderungen und Teilnehmerkennungen, was verdeutlicht, warum die benötigten Informationen je nach Szenario variieren können.
Organisationen müssen daher beurteilen, ob ihre vorhandenen Stammdaten die Informationen enthalten, die für die E-Rechnungsstellungsszenarien erforderlich sind, die sie unterstützen möchten.
Fehlende oder falsche elektronische Kennungen
In netzwerkbasierten E-Rechnungsstellungsszenarien muss das System auch die korrekten sendenden und empfangenden Parteien elektronisch identifizieren.
Peppol ist ein gutes Beispiel.
Je nach anwendbarem Schema und Land kann die Teilnehmeridentifikation Kennungen wie USt-IDs, GLNs, Leitweg-IDs oder andere unterstützte Schemata verwenden. Die SAP-Dokumentation listet verschiedene Kennungstypen nach Ländern auf und bietet Mechanismen zur Pflege generischer Peppol-Teilnehmer-IDs, wo erforderlich.
Wenn die erforderliche Kennung fehlt, veraltet ist oder einer falschen Entität zugeordnet ist, kann dies die Identifizierung des Teilnehmers im elektronischen Austauschprozess beeinträchtigen.
Diese Kennungen sollten daher als Teil der Datenbereitschaft für die E-Rechnungsstellung und nicht als rein technisches Integrationsdetail behandelt werden.
Die genaue Kennung und wo sie gepflegt werden muss, hängt vom Szenario ab, daher sollten Organisationen die aktuellen SAP- und regulatorischen Anforderungen für jede Gerichtsbarkeit validieren.
Fehlende oder inkonsistente Steuerfelder
Die elektronische Rechnungsstellung hängt von mehr ab als nur Kundeninformationen. Die zugrunde liegende Transaktion enthält auch steuerbezogene Informationen, die das resultierende elektronische Dokument beeinflussen können. Wenn relevante Steuerinformationen fehlen, inkonsistent gepflegt oder falsch zugeordnet sind, kann das Problem der Transaktion in den Compliance-Prozess folgen.
Dies wird besonders herausfordernd, wenn dieselbe Organisation unterschiedliche Steuerprozesse über Geschäftseinheiten oder Länder hinweg hat. Es ist auch wichtig, Steuerdaten von der Steuerkonfiguration zu unterscheiden. Ein falscher Steuerwert oder eine falsche Kategorie in einer Transaktion ist nicht dasselbe Problem wie ein falsches Mapping oder eine Bestimmungsregel in der SAP-Konfiguration. Das resultierende elektronische Dokument kann beide Arten von Problemen aufzeigen, aber die Korrekturmaßnahme wird unterschiedlich sein.
Je nach Mandat müssen auch Positionsinformationen wie Material- oder Dienstleistungsbeschreibungen bestimmte Dokumentanforderungen erfüllen. Unvollständige oder inkonsistente Transaktionsinformationen können daher nachgelagerte Überprüfungs- oder Korrekturarbeiten verursachen.
Die Antwort besteht nicht einfach darin, mehr Pflichtfelder einzuführen.
Organisationen müssen zunächst verstehen, welche Informationen jedes Compliance-Szenario erfordert, woher diese Informationen stammen, wer sie besitzt und wie ihre Genauigkeit aufrechterhalten wird.
Falsche oder inkonsistente Adressen
Adressen mögen wie ein grundlegendes Stammdatenfeld erscheinen, können aber für die Verarbeitung elektronischer Dokumente wichtig sein.
Das Problem beschränkt sich nicht auf einen fehlenden Straßennamen.
Ein Unternehmen kann doppelte Kundendatensätze mit unterschiedlichen Adressen, eine veraltete registrierte Adresse, inkonsistente Länderinformationen oder lokale Formatierungen haben, die nicht den im relevanten Prozess erwarteten Informationen entsprechen.
Die Anforderungen variieren je nach Szenario.
Für multinationale Organisationen muss die Adressqualität daher zusammen mit Steuerkennungen und anderen Geschäftspartnerinformationen bei der Vorbereitung auf die E-Rechnungsstellung berücksichtigt werden.
Inkonsistente Rechnungsreferenzen und Dokumentbeziehungen
Eine Rechnung existiert nicht immer isoliert.
Je nach Mandat, Dokumenttyp und Geschäftsprozess muss sie möglicherweise mit einer Bestellung, einer früheren Rechnung, einer Gutschrift, einer Korrektur, einem Vertrag oder einer anderen Transaktionsreferenz verknüpft werden.
Probleme entstehen, wenn diese Beziehungen inkonsistent gepflegt werden.
Eine Geschäftseinheit verwendet möglicherweise ein bestimmtes Referenzfeld konsistent, während eine andere ähnliche Informationen als Freitext eingibt. Akquirierte Unternehmen verwenden möglicherweise andere Konventionen. Ältere Integrationen füllen Referenzen möglicherweise anders als neuere Systeme.
Selbst wenn eine Referenz keine sofortige technische Ablehnung verursacht, kann eine schlechte Konsistenz die Abstimmung, die Ausnahmebehandlung und spätere Untersuchungen erschweren.
Datenqualität sollte daher Kontext und Beziehungen umfassen, nicht nur, ob einzelne Felder ausgefüllt wurden.
Nicht jede fehlgeschlagene E-Rechnung ist ein Datenqualitätsproblem
Datenqualität ist wichtig, sollte aber nicht zur Standarderklärung für jedes fehlgeschlagene Dokument werden.
Eine E-Rechnung kann auch aufgrund von Konfiguration, Mapping, Konnektivität, Kommunikation mit einer externen Plattform, Änderungen an einem erforderlichen Schema oder einer länderspezifischen Verarbeitungsregel fehlschlagen.
Die praktische Herausforderung besteht darin, zu bestimmen, wo das Problem seinen Ursprung hat.
Eine fehlende Kundenkennung erfordert möglicherweise eine Stammdatenkorrektur. Ein Mapping-Problem erfordert möglicherweise eine technische Untersuchung. Ein Kommunikationsfehler hat möglicherweise nichts mit den Rechnungsdaten selbst zu tun.
Diese Unterscheidung ist wichtig, wenn Teams wiederkehrende Fehler analysieren.
Jeden Fehler als DRC-Problem zu behandeln, kann Schwachstellen im Quellprozess verbergen. Jeden Fehler als Datenproblem zu behandeln, kann gleichermaßen irreführend sein.
Ziel ist es, Quelldatenprobleme von Konfigurations-, Integrations- und externen Verarbeitungsproblemen zu trennen und jedes Problem dem richtigen Verantwortlichen zuzuweisen.
Eine technisch akzeptierte Rechnung ist nicht unbedingt eine korrekte Rechnung
Die Validierung kann viele technische oder regelbasierte Probleme identifizieren, aber das Bestehen einer Validierungsprüfung beweist nicht, dass jede zugrunde liegende Geschäftsfakt korrekt ist.
Eine Rechnung könnte eine Steuerkennung im richtigen Format enthalten, die aber der falschen Entität gehört.
Eine Adresse könnte technische Anforderungen erfüllen, während sie veraltet ist.
Eine Transaktion könnte ein akzeptiertes Steuerkennzeichen enthalten, während die ursprüngliche Geschäftsklassifizierung falsch war.
Organisationen benötigen daher weiterhin Kontrollen darüber, wie Quellinformationen erstellt und gepflegt werden.
Die E-Rechnungsstellung eliminiert die traditionelle Daten-Governance nicht. Sie macht diese Kontrollen wichtiger, da Geschäftsinformationen durch zunehmend automatisierte Compliance-Prozesse fließen.
Warum Stammdaten-Governance wichtig ist
Individuelle Korrekturen können individuelle Fehler beheben.
Sie lösen keine wiederkehrenden Datenqualitätsprobleme.
Wenn immer wieder dieselbe Art von falscher USt-ID, fehlender Adresse, doppeltem Kunden oder unvollständigen Steuerinformationen auftaucht, hat die Organisation wahrscheinlich ein Governance-Problem und kein isoliertes Rechnungsproblem.
Stammdaten-Governance legt die Verantwortung dafür fest, wie wichtige Geschäftsinformationen erstellt, geändert, validiert und gepflegt werden.
Für die E-Rechnungsstellung müssen Organisationen wissen, wer Kunden-, Lieferanten- und Rechtsträgerinformationen besitzt, wie Änderungen an Steuerkennungen oder Adressen validiert werden, wie doppelte Datensätze verwaltet werden und welche Teams für die Pflege länderspezifischer Informationen verantwortlich sind.
Dasselbe gilt, wenn neue Entitäten oder akquirierte Unternehmen in die Landschaft eingeführt werden. Unterschiedliche Standards zwischen Teams oder Systemen können sich schließlich in der elektronischen Dokumentenverarbeitung zeigen.
Der umfassendere Leitfaden der TJC Group zum Datenmanagement behandelt Stammdatenmanagement, Daten-Governance und Datenintegration als Teile einer umfassenderen Datenmanagementstrategie.
Für die E-Rechnungsstellung verwandelt Governance die Datenqualität von einer einmaligen Bereinigungsaktion in einen fortlaufenden Betriebsprozess.
Datenqualitätsprobleme treten oft während der Implementierung auf, sollten aber früher angegangen werden
Eine SAP DRC-Implementierung kann Schwachstellen aufdecken, die bereits in der Geschäftslandschaft vorhanden waren.
Das E-Rechnungsstellungsprojekt hat sie nicht unbedingt geschaffen.
Ein Kundendatensatz mag jahrelang unvollständig geblieben sein, ohne ein sichtbares operatives Problem zu verursachen. Sobald diese Informationen Teil eines strukturierten elektronischen Dokuments werden und von einem anderen System, Netzwerk oder einer Behörde überprüft werden, wird die Lücke schwerer zu ignorieren.
Deshalb empfiehlt die TJC Group, Stammdaten und die bestehende Rechnungslandschaft als Teil der Vorbereitung auf SAP DRC zu bewerten. Ihr Leitfaden zur E-Rechnungsstellung und E-Berichterstattung betrachtet die umfassendere Vorbereitung, die rund um SAP-Systeme und Compliance-Prozesse erforderlich ist.
Wesentliche Lücken vor dem Go-Live zu finden, ist einfacher, als sie durch eine wachsende Warteschlange von Ausnahmen zu entdecken, nachdem der Prozess operativ geworden ist.
Was sollten SAP-Teams vor dem Go-Live der E-Rechnungsstellung überprüfen?
Es gibt keine universelle Checkliste für Datenqualität, da jedes Mandat seine eigenen Anforderungen hat.
Eine praktische Überprüfung kann dennoch um einige Kernbereiche herum organisiert werden.
| Bereich | Was zu überprüfen ist |
|---|---|
| Unternehmen und Rechtsträger | Rechtliche Namen, Umsatzsteuerregistrierungen, Unternehmensidentifikatoren und erforderliche elektronische IDs |
| Geschäftspartner | Kunden- und Lieferantendatensätze, Duplikate, Kennungen und Eigentum |
| Steuerdaten | USt-IDs, relevante Steuerfelder, Kategorien und Konsistenz |
| Adressen | Registrierte Adressen, Länderinformationen und Vollständigkeit |
| Transaktionen | Rechnungsdaten, Beträge, Daten, Positionsinformationen und steuerliche Behandlung |
| Referenzen | Bestellungen, Korrekturen, Gutschriften und andere erforderliche Beziehungen |
| Elektronischer Austausch | Peppol-Teilnehmer-IDs oder andere vom Szenario verwendete Netzwerk-IDs |
| Länderanforderungen | Felder und Kennungen, die von jedem unterstützten E-Rechnungsstellungsprozess benötigt werden |
| Governance | Wer wichtige Daten erstellt, ändert, validiert und genehmigt |
| Überwachung | Wie wiederkehrende Fehler auf Daten, Konfiguration, Integration oder externe Verarbeitung zurückgeführt werden |
Ziel ist es nicht, jedes Feld im ERP perfekt zu machen.
Es geht darum, zu identifizieren, welche Informationen für den Compliance-Prozess kritisch sind, und ausreichend Qualität und Governance um diese Informationen herum zu etablieren, um eine zuverlässige elektronische Dokumentenverarbeitung zu unterstützen.
Datenqualität sollte nach dem Go-Live fortgesetzt werden
Die Datenbereinigung vor der Implementierung ist nützlich, aber nicht ausreichend.
Geschäftsinformationen ändern sich ständig. Neue Kunden und Lieferanten werden angelegt, Adressen ändern sich, Steuerregistrierungen werden aktualisiert, Unternehmen werden akquiriert, und neue Anforderungen können zusätzliche Datenbedürfnisse mit sich bringen.
Wiederkehrende Fehler und Ausnahmen können daher als Feedback genutzt werden.
Wenn dasselbe Stammdatenproblem wiederholt zu fehlgeschlagenen Dokumenten führt, behebt die Korrektur jeder einzelnen Rechnung nicht die Ursache des Problems. Teams sollten identifizieren, wo die Informationen in den Prozess gelangen, und feststellen, ob die vorgelagerte Kontrolle geändert werden muss.
Im Laufe der Zeit kann dies wiederholte manuelle Korrekturen reduzieren und den E-Rechnungsstellungsprozess stabiler machen.
Wie die TJC Group die Datenbereitschaft für SAP DRC unterstützt
Die SAP DRC-Implementierung liegt an der Schnittstelle von SAP-Technologie, Geschäftsdaten und regulatorischen Anforderungen.
Die TJC Group ist ein offizieller SAP DRC-Partner für Beratung und Implementierung mit langjähriger Erfahrung im SAP-Datenmanagement und in der Compliance.
Die bestehende SAP DRC-Integrationsanleitung deckt Bereiche wie Systembereitschaft, Stammdatenqualität, Länderanforderungen, Tests und Validierung ab.
Das ist wichtig, denn ein E-Rechnungsstellungsprojekt kann nicht rein als Verbindung zwischen SAP und einer externen Plattform behandelt werden.
Teams müssen zunächst die zu digitalisierenden Transaktionen verstehen, die für diese Szenarien erforderlichen Informationen identifizieren, bestimmen, woher diese Informationen stammen, und wesentliche Lücken schließen, bevor sie zu operativen Compliance-Problemen werden.
Für Organisationen, die die umfassendere Compliance-Landschaft betrachten, verbindet das globale E-Rechnungsstellungs- und E-Berichterstattungsangebot der TJC Group diese Anforderungen mit den SAP-Systemen und Geschäftsprozessen, die sie unterstützen.
Ziel ist es nicht einfach, ein technisch gültiges elektronisches Dokument zu erstellen.
Es geht darum, einen E-Rechnungsstellungsprozess aufzubauen, der durch Geschäftsinformationen unterstützt wird, auf die während der gesamten Verarbeitung, Überwachung, Korrektur und Berichterstattung vertraut werden kann.
Fazit
Die E-Rechnungsstellung macht die Qualität von Geschäftsdaten viel sichtbarer.
Informationen, die einst in einem ERP oder einem anderen Quellsystem verblieben, können nun in strukturierte Dokumente fließen, die mit Kunden, Geschäftsnetzwerken und Steuerbehörden ausgetauscht werden. Wenn USt-IDs, Adressen, Rechtsträgerinformationen, Teilnehmerkennungen, Steuerdaten oder Rechnungsreferenzen falsch sind, können diese Probleme mit der Transaktion mitreisen.
SAP DRC bietet die Technologie zur Verwaltung unterstützter elektronischer Dokumenten- und Berichtsprozesse. Es kann ungenaue Quellinformationen nicht einfach durch Umwandlung in ein elektronisches Format zuverlässig machen.
Für Organisationen, die sich auf die SAP E-Rechnungsstellung vorbereiten, muss die Datenqualität daher neben Integration, regulatorischen Anforderungen und Prozessdesign angegangen werden.
Das stärkste Fundament für die E-Rechnungsstellung ist nicht einfach ein System, das konforme Dokumente übertragen kann. Es ist eine Geschäftslandschaft, in der die Informationen hinter diesen Dokumenten genau, verwaltet und über die Zeit gepflegt werden.
Quellen für Informationen
- SAP Help: Document and Reporting Compliance
- SAP Help: SAP Document and Reporting Compliance, cloud edition
- SAP Help: Party ID types for Peppol receivers
- SAP Help: Maintaining Generic Peppol Participant IDs
- SAP Help: Electronic document processing
