Indiens B2B-E-Invoicing-Mandat im Überblick

Ist ein Betreiber eines elektronischen Marktplatzes berechtigt, eine IRN für einen Lieferanten zu erzeugen, muss die Rechnung weiterhin die GSTIN des tatsächlichen Lieferanten korrekt ausweisen. Die für den Portalzugang verwendete GSTIN, die Rolle des Betreibers und die Lieferantendaten in der Rechnung müssen im vorgesehenen Zusammenhang übermittelt werden. Andernfalls kann das IRP die Anfrage wegen nicht übereinstimmender Benutzer- und Lieferantenangaben ablehnen.

Daneben ist ein eindeutiger Rückgabeprozess für IRN, signierte Rechnungsdaten, QR-Informationen und Fehlermeldungen erforderlich. Lieferanten sollten die in ihrem Namen erzeugten Dokumente mit den eigenen ERP-Daten und GST-Meldungen abstimmen können, statt die Plattform als getrennte Datenquelle zu behandeln.

Zuordnungen und Prüfregeln sollten nicht unabhängig voneinander in jedem ERP- oder Abrechnungssystem hinterlegt werden. Eine kontrollierte Integrationsschicht erleichtert es, neue Schemaversionen, Pflichtfelder, Codelisten und IRP-Prüfregeln unternehmensweit einheitlich umzusetzen.

Vor der Produktivsetzung sollten Unternehmen repräsentative Fälle testen, darunter innerstaatliche und bundesstaatenübergreifende Lieferungen, Exporte, SEZ-Szenarien, Gutschriften, Rundungsabweichungen und die Verarbeitung hoher Rechnungsvolumen. Die Wiederholungstests sollten sowohl die erfolgreiche Registrierung als auch die korrekte Rückgabe von IRN, Bestätigung, QR-Daten und Fehlermeldungen abdecken.

Unternehmen sollten mehr als nur die lesbare Rechnungsdarstellung aufbewahren. Zu den relevanten Nachweisen gehören die ursprünglich übermittelte JSON-Datei, die signierte JSON-Antwort, IRN, Bestätigungsnummer und -datum, die signierten QR-Daten, die tatsächlich an den Kunden übermittelte Version sowie zugehörige Fehler- oder Stornierungsantworten des IRP.

Diese Informationen sollten über eine gemeinsame interne Dokumentreferenz verknüpft sein. So können Support, Finanzwesen und Steuerfunktion nachvollziehen, was im ERP erstellt, beim IRP registriert, dem Kunden bereitgestellt und später gegebenenfalls storniert oder korrigiert wurde.

Nein. Die Registrierung bestätigt, dass das Dokument die Prüfungen des Portals durchlaufen und eine IRN erhalten hat. Obwohl die registrierten Daten in die GST-Meldeprozesse einfließen können, ersetzt dies nicht die unternehmensseitige Kontrolle von Meldezeiträumen, Korrekturen, Stornierungen und Vollständigkeit.

Ein praxisgerechter Abgleich sollte ausgestellte Rechnungen, erfolgreich erzeugte IRNs, ERP-Buchungen und die für GSTR-1 verfügbaren Daten gegenüberstellen. Dabei sollten auch abgelehnte, stornierte oder verspätet registrierte Dokumente sowie intern gebuchte Rechnungen ohne erfolgreiche IRP-Registrierung sichtbar werden.

Der signierte QR-Code einer indischen B2B-E-Rechnung entsteht im IRP-Prozess. Er enthält wesentliche Rechnungsinformationen und ermöglicht die Prüfung der Registrierung sowie der mit der IRN verbundenen digitalen Signatur.

Ein dynamischer B2C-QR-Code verfolgt einen anderen Zweck und dient im Regelfall dazu, Verbrauchern eine digitale Zahlung zu ermöglichen. Er wird vom Lieferanten und nicht vom IRP erzeugt und macht aus einer B2C-Rechnung keine beim IRP registrierte E-Rechnung. Unternehmen mit beiden Szenarien müssen die QR-Prozesse daher technisch und organisatorisch voneinander trennen.

Der QR-Code muss aus den signierten QR-Daten erzeugt werden, die das IRP zurückgibt. Die Prüfung kann fehlschlagen, wenn der Inhalt manuell rekonstruiert, bei der Übertragung abgeschnitten, im Dokumentlayout verändert oder in unzureichender Qualität dargestellt wird. Auch ein veralteter Prüfschlüssel oder eine ungeeignete Anwendung kann Probleme verursachen.

Der Prozess sollte die signierte Antwort unverändert aufbewahren und den sichtbaren QR-Code unmittelbar daraus erzeugen. Schlägt die Prüfung dennoch fehl, sollte das System die signierten Daten mit der ursprünglichen IRP-Antwort abgleichen, anstatt lediglich die QR-Grafik auszutauschen.

Die dem Kunden bereitgestellte Darstellung muss mit den beim IRP registrierten Daten übereinstimmen. Werden Beträge, GSTINs, Steuerangaben oder Positionen bei der Erzeugung eines PDFs, einer EDI-Nachricht oder einer Portalansicht verändert, können zwei widersprüchliche Versionen derselben Rechnung entstehen.

Unternehmen sollten die Kundenversion deshalb aus den registrierten Daten erzeugen oder ihre wesentlichen Felder automatisch mit der signierten IRP-Antwort abgleichen. Eine fehlerhaft registrierte Rechnung sollte über den vorgesehenen Stornierungs- oder Korrekturprozess behandelt und nicht lediglich im Kundendokument geändert werden.

Beide Prozesse können Daten desselben Geschäftsvorgangs verwenden, erfüllen jedoch unterschiedliche Funktionen. Die registrierte Rechnung liefert die zentralen Dokument- und Steuerdaten, während das E-Way Bill zusätzliche Angaben für den Warentransport enthält, beispielsweise zum Transporteur oder Fahrzeug.

Die Systeme sollten IRN, Rechnungsnummer und E-Way-Bill-Status miteinander verknüpfen, ohne voneinander abweichende Dokumentversionen zu führen. Das ist insbesondere bei Korrekturen und Stornierungen wichtig, weil ein aktives E-Way Bill die Stornierung der zugehörigen IRN verhindern kann, solange das Transportdokument nicht entsprechend bearbeitet wurde.

Typische Ursachen sind ungültige oder inaktive GSTINs, widersprüchliche Angaben zu Bundesstaat und Leistungsort, fehlerhafte HSN- oder Mengeneinheitencodes, unplausible Postleitzahlen, Abweichungen zwischen Positions- und Gesamtsummen sowie eine falsche Zuordnung von IGST beziehungsweise CGST und SGST. Auch Export- und SEZ-Transaktionen müssen korrekt klassifiziert werden.

Viele dieser Fehler lassen sich bereits vor der Übermittlung erkennen. Unternehmen sollten Kunden- und Materialstammdaten prüfen, Summen und Steuern neu berechnen und die Verbindung zwischen GSTIN, Bundesstaatencode und Leistungsort validieren, bevor die endgültige JSON-Datei erzeugt wird.

Die Umsatzschwelle kann auf PAN-Ebene beurteilt werden, die operative Rechnungsregistrierung ist jedoch an die GSTIN der jeweiligen Lieferantenregistrierung gebunden. Ein zentrales ERP muss deshalb ermitteln, welche indische GST-Registrierung die Rechnung ausstellt, und die zugehörigen Zugangsdaten, Rechnungsnummern, Bundesstaatenangaben und Steuerregeln anwenden.

Unternehmen sollten verhindern, dass Dokumente einer GSTIN mit den Zugangsdaten oder Nummernkreisen einer anderen Registrierung übermittelt werden. Eine zentrale Integrationsschicht kann die IRP-Anbindung vereinheitlichen und gleichzeitig Registrierungen, Berechtigungen und Dokumentfolgen sauber voneinander trennen.

In Indien stehen mehrere zugelassene Invoice Registration Portals zur Verfügung. Der Wechsel zu einem anderen IRP eröffnet jedoch keinen unabhängigen Registrierungsweg: Die Portale greifen auf die gemeinsame E-Invoicing-Infrastruktur zu und erkennen eine bereits an anderer Stelle erzeugte IRN.

Ein Ausweichverfahren muss deshalb verhindern, dass dieselbe Rechnung gleichzeitig über mehrere Portale eingereicht wird. Dafür benötigen Unternehmen ein zentrales Statusmanagement, kontrollierte Wiederholungen und eine eindeutige Verbindung zwischen der ERP-Rechnung und einer möglicherweise bereits vergebenen IRN.

Eine Zeitüberschreitung bedeutet nicht automatisch, dass das Invoice Registration Portal die Rechnung abgelehnt oder nicht registriert hat. Möglicherweise wurde bereits eine Invoice Reference Number erzeugt, während lediglich die Antwort das sendende System nicht erreicht hat.

Vor einer erneuten Übermittlung sollte deshalb der Status anhand der betreffenden Dokumentdaten abgefragt werden. Ungeprüfte Wiederholungen können zu Fehlermeldungen wegen einer bereits vorhandenen IRN führen oder unterschiedliche Statusinformationen in ERP und IRP verursachen. Ein belastbarer Prozess protokolliert daher die übermittelten Daten, den Zeitpunkt und die technische Referenz und startet einen erneuten Versuch erst nach der Statusprüfung.