JTL-Shop Integration
Live für JTL-Shop 5.2+E-Rechnungen direkt aus JTL-Shop — XRechnung, ZUGFeRD und PDF heute live, sieben weitere Formate ab Q3 2026. Kostenfreies MIT-Plugin, kostenpflichtiger E-Rechnungs-Service.
Heute live
- PDF (alle 11 Länderprofile)
- XRechnung 3.0.2 für Deutschland — BIS 3.0 / EN 16931
- ZUGFeRD 2.3/2.4 für DE/AT — Hybrid-PDF/A-3 mit eingebetteter XML
Ab Q3 2026
- Factur-X (FR)
- FatturaPA (IT)
- Facturae (ES)
- ebInterface (AT)
- UBL (BE/NL/BG/RO)
- ISDOC (CZ)
- NAV (HU)
Funktionen
JTL-Wawi-Sync ready
Hook 181 (HOOK_BESTELLUNGEN_XML_BESTELLSTATUS) feuert sobald JTL-Wawi einen Order-Status-Wechsel an den Shop zurückspielt — die Rechnungserzeugung läuft automatisch ohne zusätzliche Verdrahtung.
Drei Formate live, sieben weitere ab 2026
PDF, XRechnung 3.0.2 und ZUGFeRD 2.3/2.4 sind heute verfügbar. Die übrigen länderspezifischen Formate erscheinen automatisch im Dropdown sobald die API sie unterstützt — kein Plugin-Update nötig.
Plugin kostenfrei, Service kostenpflichtig
MIT-lizenziert, kostenfrei auf GitHub. Die Wertschöpfung liegt im invoice-api.xhub.io-Service-Abo — gleiches Modell wie bei Stripe, PayPal, Mollie.
§14 UStG-konforme Rechnungsnummerierung
Lückenlose, race-safe Sequenznummern über eine eigene DB-Tabelle (xplugin_xhubio_invoice_api_xhub_seq). Token-Format `2026-{seq:0000}` für rechtskonformen Produktivbetrieb.
Eigene Rechnungs-Templates
Layout in der Console gestalten, Template-ID kopieren, in die Plugin-Settings einfügen. Per-Order-Override über die Meta-Tabelle für Sonderdesigns einzelner Großkunden möglich.
DSGVO-friendly Storage
Rechnungsdateien liegen lokal im Plugin-Storage-Pfad. Beim Uninstall mit $deleteData=true werden beide Plugin-Tabellen (Sequenz + Meta) sauber gedroppt — keine verwaisten Kundendaten.
JTL-Wawi-Workflow-Integration
E-Rechnungs-Erzeugung direkt aus JTL-Wawi-Workflows triggern. Das Plugin reagiert auf die standardmäßigen Order-State-Events die Wawi in die Shop-DB pusht — kein Custom-JavaScript, kein zusätzlicher Service.
Auftrag.StatusGeändertBestellstatus geändert (Standard-Trigger)
E-Rechnung.ErstelltE-Rechnung in JTL erstellt — wird durch den API-Call ersetzt
Zahlung.EingegangenZahlung eingegangen — passt zu Stripe/PayPal/Mollie-Vorkasse-Workflows
Versand.AbgeschlossenVersand abgeschlossen — nutzt on_completed-Trigger für versand-getriggerte Erzeugung
Screenshots
Wie es funktioniert
Plugin per ZIP-Upload im JTL-Shop-Admin installieren (Plugins → Plugin-Manager → "Verfügbar"), Account auf invoice-api.xhub.io anlegen, API-Key in den Configuration-Tab einfügen, Land, Format und Trigger wählen. Sobald eine Bestellung den konfigurierten Status erreicht, feuert Hook 181, das Plugin POSTet die Order an die API, und die fertige Rechnung landet im Plugin-Storage — pro Order in einer Meta-Tabelle indiziert.
Production-ready
JTL-Shop-V5-nativ: PSR-4-Autoload via composer.json, PHP 8.1+, Hook 181 plus moderner \JTL\Events\Dispatcher als Bootstrap-Extension-Point. Atomic invoice numbering via INSERT...ON DUPLICATE KEY UPDATE hält die Nummern lückenlos auch bei Wawi-Sync-Bursts. Diagnose-Sichtbarkeit (Template- und API-Hash-Spalten) ist direkt im Admin Settings-Tab eingebaut — kein Log-Wühlen nötig.
Für wen
DACH-B2B-JTL-Shops vor der 2025-XRechnung-Empfangs-Pflicht und der 2027/28-Versand-Pflicht — du brauchst ZUGFeRD oder XRechnung, nicht "irgendein PDF". Multi-Country-EU-Shops auf JTL mit PDF-Bedarf heute und länderspezifischen Formaten beim Roll-out 2026. JTL-Wawi-Anwender mit bestehender Buchhaltungs-Pipeline — das Plugin produziert standardkonforme XML/PDF; die Übermittlung an Behördenportale (Peppol, ZRE/OZG-RE, KSeF) bleibt in deinem existierenden Flow.
Anwendungsfälle
Multichannel-Händler
E-Rechnungen für Amazon, eBay, Otto und eigenen JTL-Shop — zentrale Archivierung für jeden Kanal.
- 1Bestellung kommt von beliebigem Kanal in JTL-Wawi
- 2Wawi pusht Status-Änderung an JTL-Shop
- 3Hook 181 feuert, E-Rechnung wird erzeugt
- 4Zentrale Ablage für alle Kanäle — ein Formatset, ein Workflow
B2B-Großhandel mit Zahlungszielen
XRechnung für Geschäftskunden mit USt-IdNr. und Netto-30-Zahlungszielen.
- 1B2B-Kunde mit USt-IdNr. wird auf der Bestellung erkannt
- 2E-Rechnung wird beim Versand erzeugt
- 3XRechnung-XML mit Zahlungszielen und IBAN-Block
- 4Peppol-Übermittlung via nachgelagerte Buchhaltungssoftware
Buchhaltungs-Integration
Standardkonforme XML/PDF aus JTL-Shop, Weiterverarbeitung in DATEV, sevDesk oder Lexoffice.
- 1Plugin erzeugt konforme XML- oder Hybrid-PDF
- 2GoBD-konforme lokale Ablage im Plugin-Storage
- 3Bestehender JTL-Wawi-to-DATEV/sevDesk-Export deckt die Verbuchung ab
- 4Automatische Konten-Zuordnung via Buchhaltungssoftware — kein doppelter Workflow
Diagnose-Sichtbarkeit
Sieh genau welche Template-UUID für jede erzeugte Rechnung wirklich an die API ging — keine stillen Fallbacks, keine Überraschungen. Template- und API-Hash-Spalten in der History-Tabelle geben dir die Tools um Layout-Änderungen sofort nachzuverfolgen und Produktiv-Renderings run-to-run zu vergleichen.
Template-Spalte in der History
Jede Zeile in der History-Tabelle zeigt die gekürzte Template-UUID die für diese Rechnung an die API gesendet wurde.
API-Hash-Spalte
Der von der API zurückgegebene Content-Hash erlaubt run-to-run-Vergleich — gleicher Input, gleicher Hash.
Diagnose-Success-Card
Nach Klick auf Generate now zeigt die grüne Success-Card Dateinamen, Byte-Größe, gesendete Template-UUID und API-Hash auf einen Blick.
Template-aware Cache-Invalidation
Der Idempotency-Cache vergleicht jetzt auch die templateId. Eine Änderung der Template-UUID erzwingt eine frische Generierung anstatt die alte Datei zu cachen.
Eigenes Template hinterlegt aber das PDF sieht trotzdem gleich aus?
Das Plugin hat deine Template-UUID korrekt an die API gesendet. Wenn die erzeugte PDF immer noch wie der Standard aussieht, ist der Template-Inhalt selbst noch nicht angepasst. Öffne console.invoice-api.xhub.io/pdf/templates und passe Layout, Logo und Farben an damit der Unterschied sichtbar wird.