Magento-ZUGFeRD-Testmatrix: Welche Rechnungsfälle müssen vor Go-live getestet werden?
Die ZUGFeRD-Erweiterung ist installiert, die erste XML-Rechnung wurde erzeugt und der Validator meldet keinen Fehler. Kann der Magento-Shop damit produktiv gehen? Eine einzelne erfolgreiche Testrechnung ist ein guter Anfang. Sie zeigt aber noch nicht, ob Rabatte, Versandkosten, Teilrechnungen oder abweichende Kundendaten im eigenen Shop korrekt verarbeitet werden.
Vor dem Go-live sollte deshalb eine überschaubare, zum Geschäftsmodell passende Testmatrix abgearbeitet werden. Sie verbindet typische Rechnungsfälle mit klaren Soll-Ergebnissen. So können Shopbetreiber, Buchhaltung und Magento-Agentur gemeinsam prüfen, ob die erzeugten Belege fachlich stimmen und den richtigen Empfänger erreichen.
Dieser Leitfaden beschreibt eine unserer Meinung nach empfohlene technische und fachliche Abnahme für die Konvis-ZUGFeRD-Erweiterung für Magento 2. Die Testmatrix ist keine gesetzlich vorgeschriebene Prüfliste und keine Zusage, dass jede individuelle Shopkonstellation ohne Anpassung unterstützt wird.
Prüfen/Überlegen Sie auf jeden Fall ob/welche Sonderfälle Sie evtl. haben. Testen Sie mindestens(!) die für Sie relevantesten Rg. Fälle in allen Varianten durch.
Warum eine gültige XML-Datei allein nicht ausreicht
Bei der Prüfung einer E-Rechnung sind drei Ebenen zu unterscheiden:
| Prüfebene | Leitfrage | Beispiel |
|---|---|---|
| Technische Validierung | Entspricht die Datei den ausgewählten Format- und Geschäftsregeln? | Ein erforderliches Feld fehlt oder eine Summenregel wird verletzt. |
| Fachlicher Abgleich | Gibt die Datei den tatsächlichen Rechnungsfall richtig wieder? | Die XML enthält eine formal gültige, aber falsche Rechnungsadresse. |
| Prozessprüfung | Wird der richtige Beleg korrekt bereitgestellt und versendet? | Eine gültige Rechnung geht an die falsche E-Mail-Adresse. |
Ein Validator kennt nicht automatisch Ihre Bestellung, Ihre Kundenvereinbarungen oder die steuerliche Einordnung des Geschäftsfalls. Deshalb gehört zum Test immer der Vergleich mit einem vorher festgelegten Soll-Ergebnis.
Auch eine optisch richtige PDF-Rechnung genügt nicht als Nachweis: Prüfen Sie die XML-Inhalte eigenständig und vergleichen Sie die gemeinsamen Angaben beider Dokumente.
Was bei der Konvis-Erweiterung geprüft werden sollte
Die Konvis-Erweiterung erzeugt Rechnungs-XML und bietet Downloads sowie E-Mail-Versand. Die Erweiterung deckt den XML-Teil ab. Vorhandene PDF-Rechnungslösungen müssen deshalb im Zusammenspiel geprüft werden. Aus der XML-Erzeugung allein folgt keine automatische Erstellung eines PDF/A-3-Dokuments mit eingebetteter XML. Es sind 2 separate Dateien (PDF + XML)
Der Test sollte den vollständigen Weg abdecken: von den Rechnungsdaten in Magento über die erzeugte Datei bis zum Download beziehungsweise Eingang beim vorgesehenen Empfänger. Wenn ein nachgelagertes Buchhaltungssystem die Datei importiert, gehört auch ein repräsentativer Importtest zur Abnahme. Es kann natürlich nicht jegliche Buchhaltungssoftware getestet werden, aber zumindest mit einer (aktuellen) sollte sichergestellt werden, dass es funktioniert.
Vor dem Test: Umgebung und Soll-Ergebnisse festhalten
Testen Sie möglichst auf einem Testsystem, das den produktiven Rechnungsprozess abbildet. Verwenden Sie kontrollierte Empfängeradressen, damit Testbelege keine echten Kunden erreichen.
Dokumentieren Sie Magento-, PHP- und Modulversion sowie die beteiligten Checkout-, Rechnungs-, Steuer- und E-Mail-Erweiterungen. Halten Sie außerdem fest, welche Stores, Währungen, Kundengruppen und Bestellwege geprüft werden.
Entscheidend ist das Soll-Ergebnis. Legen Sie vor dem Test fest, welche Parteien, Positionen, Mengen, Steuern und Summen die Rechnung enthalten soll. Bei steuerlichen Sonderfällen sollte die Buchhaltung beziehungsweise steuerliche Betreuung diese Vorgaben liefern.
Prüfen Sie außerdem, welches Profil und welche Formatversion die konkrete Installation tatsächlich ausgibt. Der Validator muss dazu passen. Ein anderes Prüfprofil auszuwählen, bis keine Fehler mehr erscheinen, ist keine belastbare Abnahme.
Die Magento-ZUGFeRD-Testmatrix
Beginnen Sie mit einer einfachen Rechnung. Ergänzen Sie anschließend alle Fälle, die Ihr Shop tatsächlich erzeugen kann. Seltene Vorgänge sind ebenfalls relevant, wenn sie regulär angeboten werden.
| Testfall | Wann relevant? | Was wird geprüft? |
|---|---|---|
| Einfache Inlandsrechnung | Immer als Basistest | Rechnungsnummer, Datum, Verkäufer, Käufer, Positionen sowie Netto-, Steuer- und Bruttosumme |
| Mehrere Positionen und Mengen größer als eins | Sobald möglich | Einzelpreise, Mengen, Positionssummen und Gesamtsumme |
| Unterschiedliche Steuersätze | Bei gemischtem Sortiment | Zuordnung der Positionen und Steuersummen je Kategorie |
| Versandkosten und kostenloser Versand | Für die angebotenen Versandfälle | Betrag, Steuerbehandlung und Einbeziehung in die Rechnung |
| Positions- und Warenkorbrabatte | Bei entsprechenden Aktionen | Rabattverteilung, Bemessungsgrundlage und Endbetrag |
| Kostenlose Artikel und vollständige Rabattierung | Wenn angeboten | Nullbeträge, Summen und vorgesehener Belegprozess |
| Rundungskritische Preise | Bei entsprechenden Preisen und Mengen | Konsistenz zwischen Positionen, Rabatten, Steuern und Gesamtsummen |
| Gastbestellung und Kundenkonto | Für beide angebotenen Wege | Vollständige und richtige Rechnungsdaten |
| Abweichende Rechnungs- und Lieferadresse | Sobald möglich | Richtige Zuordnung von Rechnungsempfänger und Lieferadresse |
| USt-IdNr. und individuelle Kundenattribute | Wenn verwendet | Datenquelle, Übernahme und Verhalten bei fehlenden Werten |
| Buyer Reference beziehungsweise Leitweg-ID | Wenn benötigt | Eingabe, Speicherung und XML-Ausgabe |
| Teilrechnungen | Wenn genutzt | Nur abgerechnete Positionen, Mengen und zugehörige Beträge |
| Vollständige und teilweise Erstattung | Wenn genutzt | Belegart, Beträge, Steuern und Bezug zum ursprünglichen Vorgang |
| Steuerfreie und grenzüberschreitende Fälle | Wenn vorhanden | Fachlich vorgegebene Steuerbehandlung und zugehörige Angaben |
| Besondere Produkttypen | Bei Bundles, konfigurierbaren oder virtuellen Produkten | Abzurechnende Positionen, Mengen und Preise |
| Admin- und Schnittstellenbestellungen | Wenn genutzt | Vollständige Daten ohne regulären Checkout |
| Mehrere Stores und Währungen | Wenn vorhanden | Verkäuferdaten, Währung und passende Konfiguration |
Prüfen Sie zunächst einzelne Besonderheiten getrennt. Kombinieren Sie danach häufige Konstellationen: beispielsweise einen Geschäftskunden mit abweichender Lieferadresse, Rabatt und Versandkosten. Damit werden auch Wechselwirkungen sichtbar.
Beispiel 1: Rechnung mit Rabatt und Versandkosten
Annahmen für diesen Test: Zwei Artikel kosten jeweils 50,00 Euro netto. Auf die Ware wird ein Rabatt von 10 Prozent gewährt. Die Versandkosten betragen 5,00 Euro netto und werden nicht rabattiert. Für sämtliche Beträge gelten im gewählten Beispielsfall 19 Prozent Umsatzsteuer.
| Rechenschritt | Sollbetrag |
|---|---|
| Warenwert vor Rabatt | 100,00 Euro |
| Rabatt auf die Ware | −10,00 Euro |
| Warenwert nach Rabatt | 90,00 Euro |
| Versandkosten | 5,00 Euro |
| Nettosumme | 95,00 Euro |
| Umsatzsteuer | 18,05 Euro |
| Bruttosumme | 113,05 Euro |
Kontrollieren Sie neben der Endsumme auch, wie Rabatt und Versand in der XML dargestellt werden. Ein Rabatt darf nicht gleichzeitig den Positionspreis reduzieren und nochmals unbeabsichtigt auf Belegebene abgezogen werden.
Wiederholen Sie den Test mit einer Menge größer als eins sowie mit kostenlosem Versand. Für gemischte Steuersätze ist ein eigener Fall mit fachlich festgelegter Rabatt- und Versandzuordnung erforderlich.
Beispiel 2: Geschäftskunde mit abweichender Lieferadresse
Ein Unternehmen bestellt Ware für eine Niederlassung. Rechnungsempfänger ist die Zentrale, geliefert wird an einen anderen Standort.
Prüfen Sie, ob die Käuferdaten weiterhin die richtige Rechnungspartei enthalten und die Lieferadresse gesondert korrekt übertragen wird. Kontrollieren Sie Firmenname, Land, Postleitzahl und gegebenenfalls die USt-IdNr.
Für den Test einer innergemeinschaftlichen Lieferung genügt eine ausländische Lieferadresse allein nicht als Soll-Vorgabe. Lassen Sie zunächst die steuerliche Behandlung des konkreten Falls festlegen. Anschließend wird geprüft, ob Magento und XML genau diese Vorgabe abbilden.
Beispiel 3: Teilrechnung und anschließende Teilerstattung
Annahmen für diesen Test: Ein Kunde bestellt fünf Stück zu jeweils 20,00 Euro netto. Zunächst werden drei Stück berechnet. Es gibt weder Rabatt noch Versandkosten; der Steuersatz beträgt 19 Prozent.
Die erste Rechnung muss damit 60,00 Euro netto, 11,40 Euro Steuer und 71,40 Euro brutto ausweisen. Die noch nicht berechneten zwei Stück dürfen nicht zusätzlich in diese Rechnung eingehen.
Wird anschließend ein Stück aus dieser Rechnung erstattet, betragen die erwarteten Erstattungswerte 20,00 Euro netto, 3,80 Euro Steuer und 23,80 Euro brutto. Prüfen Sie Belegart, Mengen, Beträge und Referenzen. Erwarten Sie nicht pauschal negative Beträge: Das Vorzeichen ist im Zusammenhang mit der verwendeten Belegart und den Formatregeln zu beurteilen.
Welche Bereiche bei der Konvis-Erweiterung besonders relevant sind
Der Changelog nennt Änderungen an Käufer-USt-IdNr., Lieferadressdaten, Versandkostenberechnung, Rabatten, kostenlosen Artikeln und Mengen größer als eins. Diese Bereiche sollten bei entsprechender Nutzung in der Testmatrix enthalten sein. Frühere Korrekturen sind dabei kein Hinweis auf aktuell bestehende Fehler. Wir hoffen natürlich, dass wir bereits jegliche Fehler beseitigt haben, aber es kann leider immer zu Fehlern kommen.
Bei individuellen Attributen empfiehlt sich ein gezielter Vergleich zwischen Quelldaten und XML: Wo steht der gewünschte Wert in Magento, und aus welchem Feld liest die Installation ihn tatsächlich? Testen Sie zusätzlich leere Werte. Eine fehlende USt-IdNr. bei einem Kundentyp darf nicht unbemerkt durch Daten eines anderen Kunden ersetzt werden.
Für Buyer Reference und ähnliche Angaben sollten alle eingesetzten Bestellwege geprüft werden. Ein erfolgreich getesteter Checkout sagt noch nichts über manuell im Adminbereich oder per Schnittstelle angelegte Bestellungen aus.
Versand und Download: Erreicht die richtige Rechnung den Empfänger?
Die Erweiterung bietet alternativ eine separate E-Mail für die XML-Rechnung. Die Produktseite weist auf mögliche Konflikte mit anderen Erweiterungen für Rechnungsanhänge hin. Der Versandweg sollte deshalb mit der tatsächlich eingesetzten Modulkombination getestet werden.
Prüfen Sie den Empfang in einem Testpostfach. Ein Versandstatus im Magento-Backend reicht dafür nicht aus. Kontrollieren Sie:
- Ist die erwartete XML-Datei vorhanden und lesbar?
- Gehören XML und gegebenenfalls PDF zum selben Rechnungsbeleg?
- Stimmen Rechnungsnummer, Beträge und Empfänger?
- Wird eine konfigurierte abweichende Rechnungs-E-Mail korrekt berücksichtigt?
- Funktioniert der Versand auch bei verzögerter Verarbeitung, sofern diese eingesetzt wird?
- Was passiert bei einem manuellen erneuten Versand?
Beim Download sollten der vorgesehene Kundenbereich und der Adminbereich geprüft werden. Kontrollieren Sie außerdem mit zwei Testkunden, dass kein Zugriff auf fremde Belege möglich ist.
Falls der Empfänger die Rechnung automatisiert importiert, testen Sie die Datei möglichst auch in diesem Zielprozess. Technische Validierung und erfolgreicher Import beantworten unterschiedliche Fragen.
Fehler eingrenzen: Daten, Konfiguration oder Integration?
Tritt ein Fehler auf, vergleichen Sie den betroffenen Fall mit dem erfolgreichen Basistest. Ändern Sie möglichst nur einen Faktor pro Wiederholung. So wird erkennbar, ob beispielsweise der Rabatt, die Lieferadresse oder eine bestimmte Kundengruppe den Unterschied ausmacht.
| Beobachtung | Sinnvoller erster Prüfschritt |
|---|---|
| Der Validator meldet Fehler | Profil, Formatversion und konkrete Fehlermeldung prüfen |
| Kundenangaben fehlen | Daten im Beleg, Datenquelle und Attributzuordnung vergleichen |
| Die Gesamtsumme stimmt nicht | Mengen, Rabatt, Versand und Rundung einzeln nachvollziehen |
| XML und PDF unterscheiden sich | Beide Dokumente mit demselben Magento-Rechnungsbeleg abgleichen |
| Der Anhang fehlt | Versandkonfiguration und beteiligte E-Mail-Erweiterungen prüfen |
| Nur ein Bestellweg ist betroffen | Datenentstehung im Checkout, Adminbereich oder Import vergleichen |
Ergänzen Sie bewusst einige Tests mit fehlenden beziehungsweise ungültigen Eingaben. Legen Sie vorher fest, welches Verhalten erwartet wird: etwa eine verständliche Fehlermeldung oder eine erkennbare Sperre des betroffenen Vorgangs. Entscheidend ist, dass unvollständige Belege nicht unbemerkt als erfolgreich verarbeitet gelten.
Für die Fehleranalyse benötigt die betreuende Agentur den reproduzierbaren Ablauf, die Versionen, eine anonymisierte Beispieldatei und das Soll-Ergebnis. Ein Screenshot mit „funktioniert nicht“ lässt die eigentliche Ursache meist offen.
Wann ist der Shop bereit für den Go-live?
Die Freigabe sollte sich auf dokumentierte Ergebnisse stützen. Für jeden relevanten Fall muss erkennbar sein, was getestet wurde, welches Ergebnis erwartet war und ob der Test bestanden wurde.
Eine einfache Tabelle genüg wie z.B.
| Test-ID | Szenario | Soll-Ergebnis | Ist-Ergebnis | Status | Nachweis |
|---|---|---|---|---|---|
| T01 | Einfache Rechnung | Definierte Daten und Summen | Auszufüllen | Offen | XML und Prüfbericht |
| T02 | Rabatt und Versand | 113,05 Euro brutto gemäß Beispiel | Auszufüllen | Offen | XML und Betragsvergleich |
| T03 | Teilrechnung | Nur drei berechnete Stück | Auszufüllen | Offen | Rechnung und XML |
Dokumentieren Sie zusätzlich Testdatum, verantwortliche Person und getesteten Versionsstand. Sinnvolle Statuswerte sind „bestanden“, „fehlgeschlagen“, „offen“ und „nicht relevant“. Begründen Sie kurz, warum ein Fall nicht relevant ist.
Empfohlene Freigabekriterien:
- Alle angebotenen und relevanten Rechnungsfälle wurden geprüft.
- Technische Validierung und fachlicher Abgleich sind erfolgreich.
- Versand, Download und gegebenenfalls Import funktionieren.
- Kritische Fehler bei Empfänger, Beträgen, Steuern oder Zugriff sind behoben.
- Technik und Buchhaltung haben die Ergebnisse für ihren Zuständigkeitsbereich bestätigt.
Ein fehlerhafter Sonderfall darf nicht einfach aus der Matrix gestrichen werden, solange der Shop ihn weiterhin erzeugen kann. Er muss vor Freigabe behoben oder zuverlässig vom produktiven Ablauf ausgeschlossen werden.
Welche Tests nach einem Update wiederholt werden sollten
Bewahren Sie eine kleine Sammlung repräsentativer Testbestellungen und Soll-Ergebnisse auf. Damit lassen sich nach Änderungen dieselben Abläufe erneut prüfen.
Wiederholungstests sind insbesondere nach Updates der ZUGFeRD-Erweiterung, Änderungen am Checkout sowie Anpassungen an Steuerberechnung, Rabatten, Rechnungserstellung oder E-Mail-Versand sinnvoll. Auch ein neues Kundenattribut oder ein zusätzlicher Bestellimport kann Rechnungsdaten beeinflussen.
Testen Sie mindestens den Basistest und die durch die Änderung betroffenen Fälle. Bei umfassenden Änderungen am Rechnungsprozess sollte die gesamte relevante Matrix erneut durchlaufen werden.
Häufige Fragen zur Magento-ZUGFeRD-Testmatrix
Reicht eine einzige erfolgreich validierte Rechnung?
Nein. Das reicht auf keinen Fall(!) Sie bestätigt nur den geprüften Fall unter den verwendeten Prüfregeln. Abweichende Daten, Rabatte oder Teilrechnungen können andere Verarbeitungsschritte auslösen. Ergänzen Sie deshalb die im Shop vorkommenden Varianten.
Muss jeder Shop alle Testfälle durchführen?
Nein. Ein Shop ohne Teilrechnungen benötigt dafür keinen aktiven Abnahmetest. Entscheidend ist, dass diese Vorgänge tatsächlich ausgeschlossen sind. Selten genutzte, aber mögliche Fälle bleiben relevant.
Ist eine gültige XML automatisch inhaltlich richtig?
Nein. Eine formal korrekte Adresse kann zum falschen Kunden gehören. Ein Validator ersetzt deshalb nicht den Abgleich mit dem Geschäftsvorgang und dem festgelegten Soll-Ergebnis.
Müssen Erstattungen separat getestet werden?
Ja, sofern sie im Prozess vorkommen. Prüfen Sie vollständige und teilweise Erstattungen mit ihren eigenen Belegdaten. Ein erfolgreicher Rechnungstest belegt nicht automatisch die korrekte Verarbeitung einer Erstattung.
Was tun, wenn ein individueller Rechnungsfall scheitert?
Dokumentieren Sie den Ablauf und grenzen Sie Daten-, Konfigurations- und Integrationsfehler ein. Ob eine Konfigurationsänderung ausreicht oder eine Anpassung erforderlich ist, lässt sich erst anhand des konkreten Falls beurteilen.
Unterstützung bei der Prüfung Ihrer Rechnungsfälle
Eine zum Shop passende Testmatrix macht die Abnahme nachvollziehbar und hilft, Fehler vor dem ersten produktiven Versand zu erkennen. Besonders bei individuellen Preisregeln, mehreren Bestellwegen oder vorhandenen Rechnungsmodulen lohnt sich eine gemeinsame Prüfung durch Technik und Ihre Buchhaltung.
Unterstützung bei möglichen Bugs oder exotischen Sonderfällen
Sie setzen die Konvis-ZUGFeRD-Erweiterung für Magento 2 ein und benötigen Unterstützung bei besonderen Rechnungsfällen oder beim Zusammenspiel mit Ihrem bestehenden Shop? Oder Sie haben schlicht einen Bug gefunden (der von Ihrer Magento Betreuung bestätigt wurde)
Sprechen Sie uns mit einer Beschreibung Ihres Rechnungsprozesses und den relevanten Beispielen an. Wir prüfen den Unterstützungs- beziehungsweise Anpassungsbedarf. Sollte es sich um einen Bug oder sinnvolle Funktion handeln, versuchen wir es zeitnah und auch kostenlos umzusetzen.
Funktionen die so exotisch sind, dass diese für andere Kunden wohl nicht relevant sind und/oder kein Bug sind, können wir natürlich auch umsetzen. Dazu erstellen wir Ihnen gerne eine Kostenschätzung.
