E-Commerce mit ERP & E-Rechnung verbinden (2026): Fertiger Konnektor oder eigene API-Brücke?

Wenn Sie Ihren Onlineshop an ein ERP und die E-Rechnung anbinden möchten, läuft die Entscheidung auf eine einfachere Frage hinaus, als die meisten Unternehmen vermuten: Läuft Ihr Shop auf einer der Plattformen, die ein fertiger Konnektor unterstützt, oder handelt es sich um eine codebasierte bzw. individuelle Lösung? Lautet Ihre Antwort auf das Erste, genügt in den meisten Fällen ein fertiger Konnektor (wie Entegra, Sopyo oder Sentos): Sie zahlen eine monatliche Gebühr zuzüglich eines Guthaben-Kontingents pro Beleg, die Einrichtung ist schnell, die Wartungslast liegt nicht bei Ihnen. Lautet Ihre Antwort auf das Zweite – Sie betreiben also keine namentlich gelistete Plattform wie WooCommerce, Shopify oder İkas –, deckt der „Happy Path" der fertigen Konnektoren Ihren Fall nicht ab, und eine eigene API-Brücke zu entwickeln (oder die API eines Anbieters aus Ihrer eigenen Brücke heraus aufzurufen) ist der einzig tragfähige Weg. Die entscheidende technische Tatsache lautet: In der Türkei ist die E-Fatura/E-Arşiv ein von der Finanzverwaltung (GİB) vorgeschriebenes strukturiertes XML-Dokument – es findet keine OCR über ein PDF oder einen Scan statt; der Beleg wird programmatisch erzeugt und binnen Sekunden übermittelt. „Rechnungsintegration" ist also keine Bilderkennung, sondern das Erzeugen und Parsen von ausgezeichnetem XML. Nachfolgend liefern wir die Entscheidung nicht als Slogan, sondern als messbare Entscheidungsmatrix mit der Logik der Gesamtbetriebskosten (TCO). Als in Sakarya ansässiges B2B-/White-Label-Softwareunternehmen treffen wir diese Wahl fortlaufend für Agenturinhaber und Unternehmenskunden – deshalb teilen wir den von uns verwendeten Rahmen so, wie er ist.

In diesem Beitrag verzichten wir auf die allgemeine Predigt „Integration ist gut" und gehen in die Mechanik: die XML-Realität der E-Rechnung, was tatsächlich synchronisiert werden muss (Bestand, Preis, Bestellung, Rechnung, Retoure), die Vor- und Nachteile des fertigen Konnektors, die Vor- und Nachteile der eigenen Brücke, eine Entscheidungsmatrix und schließlich die TCO-Überlegung „Guthaben-Kontingent oder Entwicklung + Wartung?". Den Rahmen dieses Themas haben wir bereits in unseren Beiträgen Individualsoftware vs. Standardsoftware und unternehmensspezifische ERP/CRM-Software allgemein behandelt; hier ergänzen wir eine Ebene, die speziell auf das Dreieck E-Commerce + ERP + E-Rechnung zugeschnitten ist.

Die XML-Realität der E-Rechnung: hier gibt es keine OCR

Die häufigste Fehlannahme besteht darin, sich die E-Rechnungsintegration wie „eine Rechnung einscannen und ins System übertragen" vorzustellen. In der Türkei sieht es anders aus. Die GİB hat für E-Fatura/E-Arşiv einen strukturierten XML-Standard namens UBL-TR etabliert; die Belege werden gemäß diesem Schema-Paket (mit UTF-8-Kodierung) erstellt. API-Integration bedeutet, dass Ihre Bestell-/Verkaufs-/ERP-Software sich mit der GİB oder dem Webservice eines privaten Integrators verbindet und die Rechnung ohne menschliches Eingreifen erzeugt, versendet und deren Status überwacht – da der Beleg von Anfang bis Ende maschinell strukturiertes XML ist, gibt es weder beim Ausstellen noch bei der eingehenden Rechnung einen OCR-Schritt.

Die praktische Konsequenz lautet: Das Herzstück der Integration besteht darin, Felder wie Positionszeilen, Steuersätze, Geschäftspartner-(Empfänger-)Daten und Belegtyp korrekt auf die richtigen XML-Felder abzubilden. Nach der offiziellen Definition der GİB kann eine E-Fatura auf drei Wegen ausgestellt werden: über das E-Fatura-Portal, per Integration (die direkte 7/24-Anbindung des Systems des Steuerpflichtigen selbst) und per Privatintegration / privatem Integrator. Der private Integrator dient nach dem offiziellen Wortlaut der GİB dazu, „über das EDV-System eines technisch qualifizierten privaten Integrators" im Namen des Steuerpflichtigen E-Rechnungen zu empfangen und zu versenden; er muss die Tests der GİB bestanden haben und zugelassen sein (GİB — Privatintegratorschaft). In der Praxis übernimmt der private Integrator die GİB-Anbindung und -Infrastruktur und stellt Ihnen meist eine REST-API bereit. Diese Unterscheidung bildet auch die Grundlage Ihrer Entscheidung „fertiger Konnektor oder eigene Brücke"; die API-Seite behandeln wir im Rahmen unseres API-Integrationsservice.

Was muss eigentlich synchronisiert werden?

Eine E-Commerce-↔-ERP-↔-E-Rechnung-Brücke ist keine einzelne „Datenübertragung", sondern besteht aus fünf Datenflüssen mit jeweils unterschiedlichen Lebenszyklen. Welche Lösung Sie auch wählen, Sie müssen alle fünf modellieren:

• Bestand: Meist bidirektional. Eine Mengenänderung im ERP muss sich im Shop widerspiegeln und ein Verkauf im Shop im ERP. Andernfalls verkaufen Sie ein bereits ausverkauftes Produkt weiter.
• Preis & Produkt: Preis-/Produktdefinition fließt in den meisten Setups vom ERP zum Shop; Aktionspreise erfordern hier besondere Aufmerksamkeit.
• Bestellung: Fließt vom Shop zum ERP. Der kritische Punkt: Dieser Fluss läuft in den meisten Konnektoren nicht als Echtzeit-Push, sondern über intervallweises Polling (Details weiter unten).
• Rechnung: Umwandlung Bestellung → Rechnung. Hier wird der E-Fatura-/E-Arşiv-/E-SMM-Beleg programmatisch erzeugt und offiziell bei der GİB registriert.
• Retoure: Der am häufigsten übersehene Fluss. Eine bereits ausgestellte E-Fatura lässt sich nicht „löschen"; Retoure/Teilretoure wird über einen separaten Buchungsbeleg (Retourenrechnung) modelliert.

Diese fünf Flüsse haben unterschiedliche Anforderungen an Latenz und Konsistenz. Bei der Bestellsynchronisation etwa arbeiten viele ERP-Integrationen mit Stapel-/Polling-Logik: Laut den Dokumentationen von IdeaSoft und vergleichbaren Konnektoren gelangen die vom Shop eingehenden Bestellungen über eine sichere Webservice-Schicht in Intervallen von etwa 15 Minuten ins Mikro-ERP (nicht per direktem Datenbankzugriff), und Bestand/Produkt/Preis werden bidirektional synchronisiert (IdeaSoft — Mikro-Integration). Diese ~15 Minuten sind ein Verhalten der Konnektor-Anwendung und keine Garantie der „Mikro"-Plattform; überdies umfasst „Mikro" verschiedene Produktlinien (Jump/Fly/ältere Versionen), und die Integrationsschnittstellen variieren. Beim Planen der Latenz von Bestellung → Rechnung müssen Sie diese Polling-Realität einkalkulieren.

Idempotenz: das heimtückischste Engineering-Risiko der Brücke

Da die Synchronisation per Polling läuft und E-Fatura-/E-Arşiv-Belege einmalig bei der GİB registriert werden, kann eine naive Brücke bei einem erneuten Versuch (Retry) oder einem wiederholten Bestell-Webhook eine doppelte Rechnung ausstellen. Das bedeutet, ein rechtlich verbindliches Dokument mehrfach zu erzeugen – sowohl gegenüber dem Kunden als auch steuerlich problematisch. Eine robuste Brücke erfordert einen Idempotenz-Schlüssel pro Bestellung, eine Exactly-once-Rechnungserzeugung und die sorgfältige Verwaltung von Status-Flags wie e_invoice_sent/e_archive_sent. Dies ist eine unmittelbare Engineering-Anforderung, die sich aus dem Modell registrierter Belege der GİB und dem beobachteten Polling-Verhalten ableitet. Dieselbe Sorgfalt bei Webhooks/Idempotenz auf der Virtual-POS-Seite haben wir in unserem Leitfaden zur Virtual-POS-Integration behandelt; dieselbe Disziplin gilt auch im Rechnungsfluss.

Fertiger Konnektor: Vor- und Nachteile

Fertige Konnektoren (wie Entegra, Sopyo, Sentos, İkas) schlagen eine Brücke zu ERP-/Vorbuchhaltungszielen (Logo, Netsis, Mikro, Paraşüt und weitere) und zum E-Rechnungssystem; ihre Unterstützung ist jedoch um eine feste, überwiegend SaaS-basierte Liste von E-Commerce-Plattformen herum aufgebaut. Entegra etwa verbindet ERP-Ziele wie Logo, Netsis, Mikro, SAP, ETA, Zirve, DİA, Nebim, Paraşüt, Link, Microsoft Dynamics und E-Commerce-Plattformen wie IdeaSoft, Ticimax, OpenCart, T-Soft, Hipotenüs, WooCommerce, Shopify, PrestaShop, Magento bidirektional; es bietet Bestellung → Rechnung mit einem Klick, bidirektionale Bestand-/Preissynchronisation und automatische Anlage des Geschäftspartners (Entegra — E-Commerce-Integration). Auch Sopyo listet auf ähnliche Weise Plattformen wie Shopify, WooCommerce, IdeaSoft, İkas, Ticimax zusammen mit Zielen wie Logo/Mikro/Paraşüt und der E-Rechnung.

Genau hier liegt die eigentliche Lücke: Diese Konnektoren zielen auf die genannten, überwiegend SaaS-basierten Plattformen ab und listen keine Unterstützung für vollständig individuelle/codebasierte Shops. Die Integrationsseite von Sentos listet nur bestimmte Plattformen (İkas, Ticimax, Shopify, IdeaSoft, Hipotenüs, T-Soft, OpenCart, WooCommerce, Ethica) und erwähnt keine individuelle/proprietäre Software (Sentos — B2C-Integration). Ebenso existieren die Vorbuchhaltungs-/ERP-Integrationen von İkas (Logo İşbaşı, Mikro, Nebim, Uyumsoft, Akınsoft Wolvox, DİA, Microsoft Dynamics, Netsis, Zirve, Link, kostenlose Angebote wie BirFatura/Bizim Hesap usw.) – aber sie existieren, weil İkas selbst eine gehostete SaaS-Plattform ist; die Integrationsschnittstelle liegt zwischen der İkas-Plattform und dem ERP, weshalb ein codebasierter individueller Shop dies nicht wiederverwenden kann, ohne auf İkas zu wechseln (İkas — Vorbuchhaltungsintegrationen).

Eigene API-Brücke: Vor- und Nachteile

Die eigene Brücke ist eine nach Ihren Geschäftsregeln geschriebene Schicht, in der Ihr Shop (oder Ihr Zwischendienst) die APIs des ERP und eines privaten Integrators/einer Buchhaltungsplattform direkt aufruft. Die APIs moderner Ziele eignen sich dafür. Paraşüt etwa bietet eine offizielle REST-API (v4); zur Authentifizierung verwendet es OAuth2 (Host api.parasut.com, basePath /v4). Die Autorisierung läuft über die Endpunkte /oauth/authorize und /oauth/token; das access_token ist vom Typ Bearer und verliert seine Gültigkeit innerhalb von 2 Stunden, es wird per refresh_token erneuert. Die Spezifikation dokumentiert drei OAuth2-Grant-Typen: authorization_code, password und refresh_token; die Standard-Weiterleitungsadresse ist urn:ietf:wg:oauth:2.0:oob (Paraşüt — offizielle API-Dokumentation (Swagger)).

Noch wichtiger: Die Paraşüt-API stellt die Ressourcen E-Fatura, E-Arşiv und E-SMM direkt bereit: /{company_id}/e_invoices, /{company_id}/e_archives, für PDF die Endpunkte .../pdf sowie der Rechnungsstatus-Enum (printed, not_printed, invoices_not_sent, e_invoice_sent, e_archive_sent, e_smm_sent) sind dokumentiert. Für die programmatische Rechnungserzeugung und den PDF-Abruf ist also kein separater OCR-/Belegschritt nötig. Auf der ERP-Seite bietet Logo Netsis in seiner offiziellen Dokumentation eine REST-API namens „NetOpenX Rest"; diese API standardisiert die NetOpenX-Funktionen und ermöglicht es, für die Web-/Mobile-Integration Daten ins ERP zu schreiben und daraus abzurufen, ohne die Geschäftslogik zu stören (Logo — Netsis-Anpassungswerkzeuge). Existenz und Funktionsumfang dieser API sind bestätigt; den genauen Authentifizierungsmechanismus (Token oder Sitzung) behaupten wir hier nicht – es genügt, sie als REST-API mit eigener Auth einzuordnen.

Hinweis: Eine eigene Brücke bedeutet nicht, „das Guthaben-Kontingent vollständig loszuwerden"; E-Rechnungsbelege gehen weiterhin an die GİB/den privaten Integrator, und dort wird pro Beleg Guthaben verbraucht. Was die eigene Brücke gewinnt, ist, dass die Orchestrierungs- und Geschäftslogikschicht Ihnen gehört – gleich auf welcher Plattform Sie sind. Die Arbeit an der eigenen Brücke führen wir im Rahmen von Individueller Web-Software und CRM-/ERP-Lösungen gemeinsam durch.

Entscheidungsmatrix: Wann genügt Fertig, wann ist Individuell Pflicht?

Um die Entscheidung intuitiv zu machen, einzeilige Regeln:

Die Entscheidung lautet nicht „welche ist besser", sondern „in welche Schublade fällt Ihr Shop". Sind Sie auf einer gelisteten SaaS-Plattform, genügt der fertige Konnektor meist; bei einem individuellen/codebasierten Shop oder eigenen Geschäftsregeln ist die eigene Brücke keine Wahl, sondern eine Notwendigkeit.

Unterschätzen Sie den Retourenfluss nicht

Welchen Weg Sie auch wählen, Sie müssen die Retoure separat modellieren. Da eine ausgestellte E-Fatura/E-Arşiv bei der GİB registriert ist, lässt sie sich nicht einfach „löschen": Innerhalb eines kurzen Stornofensters kann die E-Arşiv storniert und der GİB gemeldet werden; nach Schließen dieses Fensters erfolgt Korrektur/Retoure über einen Retouren-(Credit-)Beleg (Paraşüt — E-Arşiv Storno vs. Retoure). Die getrennte Behandlung von Voll- und Teilretoure ist erforderlich, damit Bestand, Geschäftspartnersaldo und Steueraufzeichnungen konsistent bleiben. Die Tagesanzahl des Stornofensters geben wir hier nicht als feste Regel an – die Quellen weichen ab; falls Sie eine genaue Frist benötigen, legen Sie die aktuelle E-Arşiv-Mitteilung/-Anleitung der GİB zugrunde.

TCO-Überlegung: Guthaben-Kontingent oder Entwicklung + Wartung?

Die Entscheidung ist im Grunde die Wahl einer Kostenform: Der fertige Konnektor ist eine wiederkehrende Ausgabe (Abonnement + Guthaben pro Beleg), die eigene Brücke hingegen eine Ausgabe für Vorab-Entwicklung + laufende Wartung. Die Zahlen schwanken 2026 und variieren je nach Anbieter/Volumen; lesen Sie die folgenden daher nicht als feste Preise, sondern als ungefähre Marktspannen.

• Guthaben-Kontingent (digitales Guthaben pro Beleg): In der Regel wird für jeden ausgehenden Beleg ~1 Guthaben verbraucht (manche Anbieter berechnen auch eingehende). Laut Marktvergleichsdaten für 2026 liegt der Guthaben-Stückpreis bei den gängigen Anbietern im Durchschnitt etwa im Bereich von ungefähr 0,75–1,50 TL/Beleg; bei ERP-integrierten Unternehmensintegratoren kann er pro Beleg höher liegen (berichtet ~5–10 TL) (Faturaport — Guthabenpreise 2026 (keine offizielle Liste)). Dies sind keine offiziellen Anbieterpreise, sondern ein datierter Marktvergleich.
• Abonnement: Der Kostenleitfaden 2026 von Faturaport gibt die Abonnementbänder pro Jahr an (z. B. nur E-Rechnung ~300–1.500 TL/Jahr; KMU ~1.500–6.000 TL/Jahr; Unternehmen ~6.000–50.000+ TL/Jahr, angebotsbasiert), außerdem gibt es wiederkehrende Zertifikatskosten für Finanzsiegel/E-Signatur (Faturaport — E-Rechnungs-Kostenleitfaden 2026 (keine offizielle Liste)). Auch diese Bänder sind ungefähr und anbieterabhängig.
• Volumensensitivität: Da Guthaben und Abonnement mit dem Volumen steigen, erhöht ein Kampagnen-/Black-Friday-Peak den Guthabenverbrauch unmittelbar und kann Sie an die Volumen-/Limitgrenzen bringen.

Die eigene Brücke tauscht dieses wiederkehrende Modell gegen Vorab-Entwicklung + laufende Wartung: Positionen wie API-Versionswechsel, Retry-/Warteschlangenlogik und Synchronisationsabweichung erzeugen mit der Zeit Kosten. Ihr Fokus sollte nicht darauf liegen, den Stückpreis auswendig zu lernen, sondern den Mechanismus zu verstehen: Ist Ihr Belegvolumen groß und vorhersehbar, kann die wiederkehrende Guthabenposition mit der Zeit die Kosten für Vorab-Entwicklung + Wartung übersteigen; ist Ihr Volumen niedrig oder unterstützt Ihre Plattform ohnehin, ist der fertige Konnektor mit Abstand wirtschaftlicher. Den Gesamtrahmen zusammen mit der Logik unseres Beitrags Individual- vs. Standardsoftware zu bewerten, macht diesen Abgleich deutlich.

Der B2B-/White-Label-Ansatz von Partnerfy

Als in Sakarya ansässiges B2B-/White-Label-Softwareengineering-Unternehmen treffen wir diese Entscheidung nicht als „Versprechen", sondern als Prozess: Zuerst diagnostizieren wir, in welche Schublade Ihr Shop fällt (gelistete SaaS, individuell/codebasiert, gibt es eigene Geschäftsregeln), dann ordnen wir die fünf Flüsse (Bestand/Preis/Bestellung/Rechnung/Retoure) zu, und anschließend positionieren wir entweder einen fertigen Konnektor korrekt oder schreiben eine eigene API-Brücke mit korrekt aufgesetzter Idempotenz und korrektem Retourenfluss. Für Agenturen liefern wir diese Brücke im White-Label-Modell unter Ihrer Marke; für Unternehmenskunden vereinen wir E-Commerce-Systeme und CRM-/ERP-Lösungen auf einer einzigen beobachtbaren Linie.

Um ehrlich zu sein: Keine Brücke kann garantieren, dass das Guthaben-Kontingent auf null geht oder die GİB-Vorschriften sich nie ändern – das sind externe Variablen. Unser Wort ist keine Garantie, sondern ein Fundament: eine Architektur, die Rechnungen exactly-once ausstellt, die Retoure über einen separaten Beleg modelliert, Token-Erneuerung und Retry nicht vernachlässigt und Volumen-Peaks trägt. Aufträge mit Codebasis, eigenen Geschäftsregeln oder unerwarteter ERP-Linie decken wir auch auf der Seite Individuelle Web-Software ab.

Fazit

Bei der E-Commerce-↔-ERP-↔-E-Rechnung-Brücke lautet die richtige Frage nicht „welche ist besser", sondern „in welche Schublade fällt mein Shop". Sind Sie auf einer gelisteten SaaS-Plattform und sind Ihre Flüsse standardisiert, genügt der fertige Konnektor meist – vorausgesetzt, Sie akzeptieren die wiederkehrenden Kosten aus Abonnement + Guthaben. Haben Sie einen individuellen/codebasierten Shop oder eigene Geschäftsregeln, ist die eigene API-Brücke kein Luxus, sondern eine Notwendigkeit. In beiden Fällen ist die E-Rechnung keine OCR-Aufgabe, sondern eine UBL-TR-XML-Aufgabe; Idempotenz und Retourenfluss korrekt zu modellieren ist nicht verhandelbar. Wenn Sie unsicher sind, wo Sie beginnen sollen, nehmen Sie Kontakt mit uns auf; wir klassifizieren Ihren Shop und erarbeiten für Sie eine individuelle Entscheidung „fertiger Konnektor oder eigene Brücke" samt Kostenform-Vergleich.

Quellen

• GİB — Privatintegratorschaft (drei E-Fatura-Methoden und offizielle Definition)
• GİB — E-Beleg-(E-Fatura/E-Arşiv-)Portal und E-Fatura-Paket (UBL-TR-Schemata)
• Paraşüt — Offizielle API-Dokumentation (OAuth2, v4, e_invoices/e_archives, PDF-Endpunkte, Status-Enum)
• Logo — Netsis-Anpassungswerkzeuge / NetOpenX Rest API
• Entegra — E-Commerce-Integration (ERP-Ziele + Plattformliste)
• Sentos — B2C-E-Commerce-Integration (feste Plattformliste)
• İkas — Vorbuchhaltungs-/ERP-Integrationen
• IdeaSoft — Mikro-Integration (~15 Min. Polling, Webservice-Schicht)
• Faturaport — Guthabenpreise 2026 (Marktvergleich, keine offizielle Liste)
• Faturaport — E-Rechnungs-Kostenleitfaden 2026 (jährliche Abonnementbänder, keine offizielle Liste)
• Paraşüt — E-Arşiv Storno vs. Retourenrechnung (konzeptionell)

Häufig gestellte Fragen (FAQ)