PrestaShop mit Ihrer Buchhaltungssoftware verbinden: Xero, QuickBooks und mehr

Zuletzt geprüft im Juni 2026. OSS-Regeln aktuell gemäß der EU-Regelung nach 2021; Back-Office-Pfade gegen PrestaShop 1.7, 8.x und 9.x geprüft. Stimmen Sie die steuerliche Behandlung immer mit Ihrem eigenen Steuerberater ab.

Diese Unterscheidung entscheidet darüber, wie mühsam Ihr Monatsabschluss wird: PrestaShop ist das System, das das Geld einnimmt, und Ihre Buchhaltungssoftware ist das System, das dieses Geld gegenüber einer Steuerbehörde erklären muss. Das ist nicht dieselbe Aufgabe. Ihr Shop speichert eine Bestellung mit Kunde, Versanddienstleister, Zahlungsmethode und Warenkorb. Ihr Steuerberater braucht eine fortlaufend nummerierte Rechnung, ein Erlöskonto, einen Steuercode und für jede Rückerstattung eine Gutschrift - in einem Format, das sich centgenau abstimmen lässt. Die Verbindung beider Systeme besteht darin, ein Modell sauber in das andere zu übersetzen. Gelingt diese Übersetzung, schließen sich die Bücher fast von selbst; geht sie schief, stimmen Sie am letzten Tag des Quartals um 23 Uhr die VAT manuell ab.

In diesem Leitfaden geht es gezielt darum, PrestaShop mit Buchhaltungssoftware zu verbinden - Xero, QuickBooks und andere -, damit aus Bestellungen korrekte, prüfbare Rechnungen werden, ohne sie erneut abzutippen. Es geht nicht darum, PrestaShop an ein vollständiges ERP für Lager und Einkauf anzubinden (das ist ein anderes Problem mit einer anderen Struktur - siehe PrestaShop mit Ihrem ERP verbinden und zur Frage „Wann brauche ich das?“ wenn Ihr Shop aus manueller Arbeit herauswächst). Hier ist der Umfang das Hauptbuch: Rechnungen, Steuern, Rückerstattungen, Gebühren und die Zahlen, die Ihr Steuerberater freigibt.

Was tatsächlich von PrestaShop in die Buchhaltung fließen muss

Bevor Sie ein Tool auswählen, sollten Sie klären, welche Daten die Verbindung transportieren muss. PrestaShop erzeugt den größten Teil davon bereits - Aufgabe der Integration ist es, jedes Element an die richtige Stelle in Ihrem Kontenplan zu mappen, nicht es neu zu erzeugen. Die relevanten Objekte liegen in klar definierten PrestaShop-Tabellen, und wer ihre Namen kennt, weiß genau, was eine Integration liest:

• Die Rechnung, nicht die Bestellung. Eine PrestaShop-Bestellung (ps_orders) ist noch kein Buchhaltungsbeleg. Die Rechnung ist ein eigenes Objekt (OrderInvoice / ps_order_invoice), das erzeugt wird, wenn die Bestellung einen Rechnungsstatus erreicht, und sie trägt ihre eigene Nummer. Für Ihre Buchhaltung zählt die Rechnung. Synchronisieren Sie Bestellungen ohne Rechnung, erzeugen Sie Erlöse, die rechtlich noch gar nicht existieren.
• Steuern, nach Sätzen aufgeschlüsselt. PrestaShop speichert Steuern pro Position und pro Rechnung (ps_order_detail_tax, ps_order_invoice_tax). Eine einzelne Bestellung kann zwei oder drei verschiedene VAT-Sätze enthalten - Waren zum Standardsatz, Waren mit ermäßigtem Satz, steuerfreie Lieferung. Die Integration muss diese Aufschlüsselung erhalten, nicht nur eine Gesamtsumme.
• Rückerstattungen und Stornierungen als Gutschriften. Eine Rückerstattung in PrestaShop ist ein Gutschriftbeleg (OrderSlip / ps_order_slip) mit eigener fortlaufender Nummer. In Ihrer Buchhaltungssoftware muss sie als Gutschrift zur ursprünglichen Rechnung ankommen - nicht als negativer Verkauf und niemals als stillschweigende Löschung.
• Zahlung gegenüber Rechnung. Was der Kunde bezahlt hat (ps_order_payment) und was Sie in Rechnung gestellt haben, sind zwei Ereignisse. Ob eine Rechnung in der Buchhaltung als „bezahlt“ markiert wird, sollte aus dem Zahlungsdatensatz kommen, damit Liquidität und Erlöse getrennt abgestimmt werden können.
• Gateway-Gebühren und Versand. Stripe und PayPal ziehen ihren Anteil ab, bevor das Geld ankommt; Versandumsatz (was der Kunde bezahlt hat) und Versandkosten (was Sie dem Versanddienstleister bezahlt haben) sind zwei verschiedene Zeilen. Nichts davon ist in einer naiven Synchronisierung „Bestellsumme -> Erlös“ sichtbar.

Warum ist das wichtig? Wenn Sie diese fünf Datenflüsse benennen können, können Sie jeden Connector in fünf Minuten beurteilen - Sie fragen einfach, welche davon er verarbeitet und welche er stillschweigend unter den Tisch fallen lässt.

Die Entscheidung vor dem Tool: Wem gehört die Rechnungsnummer?

Das ist die eine Entscheidung, die jede Buchhaltungsintegration prägt, und die meisten Leitfäden überspringen sie. In fast jeder Rechtsordnung müssen Verkaufsrechnungen und Gutschriften fortlaufend und eindeutig sein - und in manchen Ländern muss die Reihenfolge lückenlos sein, oder jede Lücke muss erklärbar und prüfbar sein. Die Frage lautet: Welches System ist die maßgebliche Quelle für diese Nummernfolge?

Wenn PrestaShop die Nummerierung besitzt, ist die native Sequenz zwar konfigurierbar, aber grob - und eine unerklärte Lücke (eine stornierte oder fehlende Rechnung, eine manuelle Datenbankänderung, eine fehlgeschlagene Migration oder ein schlecht konfiguriertes Zurücksetzen der Sequenz) ist genau das, was ein Prüfer beanstandet. Zwei unserer Module existieren genau für diesen Kontrollpunkt: Invoice Number und Order Number erlauben Ihnen, Präfix, Startwert und Format so festzulegen, dass Ihre PrestaShop-Belege der lückenlosen, jahresbezogenen Sequenz folgen, die Ihr Steuerberater erwartet, statt gegen die Standardlogik des Cores zu arbeiten. Der Nutzen ist eng umrissen, aber real: Der Beleg, den Ihr Kunde herunterlädt, und der Beleg, den Ihr Steuerberater ablegt, tragen dieselbe rechtlich gültige Nummer - die Abstimmung ist damit eine Suche, keine Untersuchung.

Xero

Xero ist eine gängige Wahl für Shops in Großbritannien und Europa, und das aus gutem Grund: eine gut dokumentierte API, native Mehrwährungsfähigkeit und eine VAT-Verarbeitung, die auch grenzüberschreitend belastbar ist. Für PrestaShop ist die Verbindung fast immer indirekt - ein Middleware-Dienst oder ein dediziertes Modul liest fakturierte Bestellungen und erzeugt entsprechende Xero-Rechnungen -, weil Xero kein eigenes PrestaShop-natives Plugin anbietet.

Vier Punkte entscheiden tatsächlich, ob eine Xero-Verbindung korrekt ist:

• Mapping des Kontenplans. Ihre PrestaShop-Kategorien (oder Produkte) müssen Xero-Erlöskonten zugeordnet werden. Ein Shop, der physische Waren und digitale Downloads verkauft, will diese normalerweise in getrennten Konten sehen - entscheiden Sie das Mapping vor der ersten Synchronisierung, denn nach Tausenden Rechnungen wird eine Umstellung unangenehm.
• Mapping der Steuersätze. Eine PrestaShop-Steuerregel (Back Office → International → Steuern → Steuerregeln) ist nicht dasselbe Objekt wie ein Xero-Steuersatz. Sie ordnen jede Regel ausdrücklich zu: PrestaShop „FR Standard 20 %“ dem passenden Xero-Satz und so weiter für jedes Land, in das Sie verkaufen. Lassen Sie eine Zuordnung aus, werden die Verkäufe dieses Landes mit der falschen - oder gar keiner - Steuer gebucht.
• Zahlungsstatus. Eine Rechnung sollte in Xero erst dann als bezahlt markiert werden, wenn PrestaShop die Zahlung bestätigt. Steuern Sie das aus dem bezahlten Bestellstatus, nicht aus der Rechnungserstellung, sonst wirkt Ihre Liquiditätslage zu hoch.
• Mehrwährung. Wenn Sie in GBP, EUR und USD verkaufen, lassen Sie Xero die Wechselkurse verwalten und buchen Sie Rechnungen in der Verkaufswährung. Konvertieren Sie nicht vorab in der Integration - sonst verlieren Sie den Prüfpfad zum Betrag in Originalwährung.

Der häufigste Xero-Fehler ist, zu viel zu synchronisieren. Starten Sie ausschließlich mit fakturierten, bezahlten Bestellungen. Entwürfe, abgebrochene Warenkörbe und ausstehende Zahlungen haben in Ihrer Buchhaltung nichts zu suchen, solange kein Geld geflossen ist.

QuickBooks Online

QuickBooks Online ist bei US-Händlern verbreitet und kann auch in manchen europäischen Setups funktionieren, mit einem ausgereiften Connector-Ökosystem - die meisten Middleware-Plattformen unterstützen es direkt. Ob es wirklich zu einem europäischen Shop passt, hängt von Ihren lokalen Steuer- und E-Invoicing-Anforderungen ab; prüfen Sie diese also, bevor Sie sich festlegen. Der Haken für grenzüberschreitende Händler ist, dass QuickBooks sales tax (USA, zielortbasiert, nach Bundesstaat/County) ganz anders modelliert als VAT (EU). Wenn Sie in beiden Märkten verkaufen, muss die Integration anhand des Kundenstandorts den richtigen Steuereintrag erzeugen - eine US-Bestellung bekommt eine Sales-Tax-Zeile, eine EU-Bestellung eine VAT-Zeile - und diese Logik liegt im Connector, nicht in QuickBooks.

Praktische Konfiguration, die sich auszahlt:

• Klassen oder Standorte verwenden. Wenn Sie mehr als einen PrestaShop-Shop betreiben (zum Beispiel einen separaten Shop pro Land), können Sie mit QuickBooks-Klassen die Erlöse jedes Shops in der P&L (GuV) getrennt halten, ohne eine zweite QuickBooks-Datei zu führen.
• In Batches arbeiten, nicht streamen. Echtzeit-Synchronisierung klingt attraktiv; ein täglicher oder stündlicher Batch ist zuverlässiger und deutlich leichter zu debuggen, wenn eine Rechnung fehlschlägt. Sie wollen ein Problem in einem Stapel von 40 finden, nicht es in einem Live-Stream verfolgen.
• Produktgranularität festlegen. Wird jedes PrestaShop-Produkt zu einem QuickBooks-Artikel, oder aggregieren Sie Erlöse nach Kategorie? Pro Produkt erhalten Sie Reporting auf Produktebene und eine viel größere Artikelliste, die gepflegt werden muss; pro Kategorie bleibt QuickBooks schlank. Die meisten Shops fahren mit Aggregation besser.
• Gutschriftbelege als credit memos spiegeln. Ein PrestaShop-Gutschriftbeleg sollte in QuickBooks ein credit memo zur ursprünglichen Rechnung erzeugen - gleicher Betrag, gleiche steuerliche Behandlung.

Die anderen Plattformen - und warum Ihr Land entscheidet

Xero und QuickBooks dominieren die englischsprachige Diskussion, aber das richtige Tool ist in der Regel das, was Ihr lokaler Steuerberater und Ihre Finanzbehörde erwarten. Der Integrationsansatz verschiebt sich entsprechend:

• Sage - im Vereinigten Königreich und in Frankreich seit langem etabliert, häufig bei größeren Unternehmen; der Integrationsansatz hängt vom jeweiligen Sage-Produkt ab, mit Optionen von API-Connectoren (Sage Business Cloud, Intacct) bis zu Middleware und geplanten Exporten.
• Datev - der De-facto-Standard in Deutschland, weil die meisten deutschen Steuerberater damit arbeiten. Sie wollen selten eine API; sie wollen einen Datev-kompatiblen Export, den sie importieren können. Für diese Buchhaltungen ist eine saubere CSV-/Export-Pipeline besser als jeder Echtzeit-Connector.
• Fakturownia / inFakt / wFirma - polnische Rechnungs- und Steuerplattformen. Polnische Nummerierungs- und JPK-Meldepflichten sind streng, wodurch die obige Entscheidung „Wem gehört die Rechnungsnummer?“ hier besonders tragend wird.
• Fattura24 / Aruba - Italien schreibt elektronische Rechnungsstellung (fatturazione elettronica) über das SDI-Austauschsystem vor. Diese Plattformen übernehmen die SDI-Übermittlung; Aufgabe Ihrer PrestaShop-Integration ist es, ihnen eine korrekt strukturierte Rechnung zu liefern, nicht direkt mit SDI zu sprechen.
• FreshBooks / Debitoor-ähnliche Tools - einfachere Rechnungsstellung für Kleinstunternehmen und Freelancer, meist über Export statt tiefer Integration gespeist.

Bei jeder Plattform ohne fertigen Connector läuft die Integration fast immer auf einen strukturierten Export hinaus, den die Buchhaltungssoftware (oder Ihr Steuerberater) nach Zeitplan importiert. Das ist kein Rückschritt - für einen Datev- oder Fattura24-Workflow ist es genau das, was die empfangende Seite erwartet.

Was eine Buchhaltungsexportdatei tatsächlich enthält

Wenn der Exportweg Ihrer ist (Datev, JPK, „schicken Sie mir einfach eine CSV“), hilft es zu wissen, welche Spalten die empfangende Seite erwartet, denn ein sauberer Header ist die halbe Miete. Der Import Ihres Steuerberaters will nicht die Bestellansicht aus Ihrem Shop-Frontend - er will Zeilen auf Rechnungsebene, bei denen die Steuer nach Satz aufgeschlüsselt ist. Ein brauchbarer CSV-Header für einen Verkaufsrechnungsexport sieht so aus:

invoice_number,invoice_date,order_reference,customer_name,customer_vat_number,country,currency,net_amount,tax_rate,tax_amount,gross_amount,payment_method,document_type
INV-2026-000412,2026-06-18,XKBKTSXPM,"ACME GmbH",DE811234567,DE,EUR,200.00,0.00,0.00,200.00,bankwire,invoice
INV-2026-000412,2026-06-18,XKBKTSXPM,"ACME GmbH",DE811234567,DE,EUR,50.00,19.00,9.50,59.50,bankwire,invoice
CN-2026-000031,2026-06-20,XKBKTSXPM,"ACME GmbH",DE811234567,DE,EUR,-50.00,19.00,-9.50,-59.50,bankwire,credit_note

Zwei Dinge sind wichtig: Jeder Steuersatz bekommt seine eigene Zeile (eine Rechnung mit mehreren Steuersätzen umfasst also mehrere Zeilen, die zusammen die Belegsumme ergeben), und eine Rückerstattung erscheint als credit_note mit negativen Beträgen zur ursprünglichen order_reference - niemals als gelöschte oder bearbeitete Rechnungszeile. Klären Sie die exakten Spaltennamen und das Datumsformat vor dem ersten Lauf mit Ihrem Steuerberater; Datev und JPK haben jeweils eigene Pflichtlayouts, aber die Struktur - eine Zeile pro Steuersatz, Gutschriften als negative Werte - bleibt gleich.

Zwei Wege in die Buchhaltung: natives Modul oder Middleware

Wenn Sie wissen, was fließen muss und wem die Nummerierung gehört, gibt es zwei realistische Wege, die Daten tatsächlich zu bewegen. Sie schließen sich nicht gegenseitig aus - viele Shops nutzen ein Modul für Rechnungen und einen Middleware-Connector für eine bestimmte Plattform -, aber es hilft, den Unterschied klar zu sehen.

Auf der Modulseite übernimmt unser Modul Financial Revolution Rechnungserstellung, Nummerierung und Export in Formaten, die Ihre Buchhaltungsplattform verarbeiten kann. Wenn das Ergebnis eine saubere Datei nach Zeitplan sein soll - der Datev- oder JPK-Fall -, zieht Invoice CSV List Exporter die Rechnungs- und Steuerdaten je Steuersatz, die Ihr Steuerberater importiert, während Orders CSV List Exporter die Rohbestellseite abdeckt, wenn das empfangende System genau diese Daten erwartet. Der praktische Effekt: Sie können aus dem Back Office einen korrekten Buchhaltungsdatenfluss aufsetzen, ohne laufende Middleware-Rechnung und ohne dass Bestelldaten Ihren Server verlassen - das ist oft der entscheidende Punkt bei Datev- oder JPK-Workflows, in denen der Steuerberater einfach eine saubere Datei nach Zeitplan will. (Und wenn dieser Zeitplan ohne manuelle Eingriffe laufen soll, ist Cron Manager das Modul, das den wiederkehrenden Export ausführt und protokolliert, damit ein verpasster Lauf sichtbar ist und nicht still bleibt.)

Middleware verdient ihr Abonnement, wenn Sie speziell eine Live-Synchronisierung ohne manuelle Eingriffe zu Xero oder QuickBooks möchten und die integrierten Wiederholungen, Protokolle und vormappten Connectoren schätzen. Wenn Ihr Grund für Zapier oder Make eher eine breitere Shop-Automatisierung ist und nicht das Hauptbuch selbst, ist das ein anderes Thema - die Mechanik solcher Workflows behandeln wir in Zapier und Make für PrestaShop und den No-Code-Aspekt in Workflows automatisieren, ohne Code zu schreiben.

Grenzüberschreitende VAT: der Teil, der aus Buchhaltung eine Rechtsfrage macht

Wenn Sie über EU-Grenzen hinweg verkaufen, ist VAT der Punkt, an dem eine Buchhaltungsintegration aufhört, nur bequem zu sein, und zur Compliance wird. PrestaShop erfasst die Rohdaten; Ihre Buchhaltung muss sie korrekt melden.

• OSS (One-Stop Shop). Seit Juli 2021 kann ein EU-Shop die VAT für alle Mitgliedstaaten über eine einzige OSS-Meldung melden - aber nur, wenn Ihre Datensätze wissen, welcher Ländersatz auf welchen Verkauf angewendet wurde. PrestaShop speichert bereits Zielort und angewendete Steuerregel pro Rechnung; die Integration muss diese Länderdimension bis in die Buchhaltung mitnehmen, sonst wird Ihre OSS-Meldung zur Schätzung.
• B2B-Reverse-Charge. Verkaufen Sie an ein Unternehmen mit gültiger EU-Umsatzsteuer-Identifikationsnummer, berechnen Sie keine VAT - der Käufer versteuert selbst. Das bedeutet: Ihre Integration muss den Verkauf als Reverse-Charge-Buchung posten, nicht als Verkauf mit null VAT; für eine Steuerbehörde sind das unterschiedliche Dinge. Voraussetzung ist die Prüfung der Nummer zum Bestellzeitpunkt; unser Automatic EU VAT Checker prüft VAT-Nummern in Echtzeit gegen VIES, damit die Bestellung korrekt markiert ist, bevor sie überhaupt in der Buchhaltung ankommt.
• Exporte außerhalb der EU. Verkäufe außerhalb der EU sind typischerweise mit 0 % besteuert, müssen aber trotzdem als Exporte in der Buchhaltung erscheinen - vorhanden, nicht unsichtbar.

Die Faustregel: Bringen Sie grenzüberschreitende VAT in Ordnung, bevor Ihr Volumen wächst. Ein falsches Steuer-Mapping ist bei 30 Bestellungen im Monat ein kleines Ärgernis und bei 3.000 eine Korrektur im fünfstelligen Bereich.

Fallstricke, die jede Buchhaltungsintegration treffen können

Unabhängig davon, welches Tool Sie wählen, treten dieselben wenigen Fehler immer wieder auf. Sie von Anfang an einzuplanen ist günstiger, als sie erst zum Jahresende zu entdecken:

• Doppelte Rechnungen. Der Klassiker. Eine Synchronisierung, die zweimal läuft oder nach einem Timeout erneut versucht, kann dieselbe Rechnung doppelt buchen. Die Lösung ist ein Idempotenzschlüssel - fast immer die PrestaShop-Bestell- oder Rechnungs-ID -, damit die Buchhaltungsseite eine Wiederholung erkennt und überspringt.
• Rundungsabweichungen. PrestaShop und Ihre Buchhaltungssoftware können Steuern positionsweise oder gesamtsummenbezogen unterschiedlich runden. Eine Cent-Differenz bei einer Bestellung ist Rauschen; bei Tausenden Bestellungen wird daraus eine Abstimmung, die nie ganz aufgeht. Legen Sie die Rundungsregel einmal fest und sorgen Sie dafür, dass beide Systeme übereinstimmen (Rundungsmodus und Rundungstyp von PrestaShop finden Sie unter Shop Parameters → General).
• Währungsabweichungen. Ein Kunde zahlt in GBP, Ihre Bücher laufen in EUR - der Eintrag braucht sowohl den Betrag in Originalwährung als auch den umgerechneten Betrag zum richtigen Kurs, sonst ist Ihr Fremdwährungsreporting Fiktion.
• Vergessene Gateway-Gebühren. Der Prozentsatz eines Zahlungsdienstleisters ist kein Erlösrabatt, sondern ein Aufwand. Buchen Sie Bruttoumsatz und Gebühr getrennt, sonst sehen Ihre Margen besser aus, als sie sind, und Ihr Bankbestand lässt sich nicht abstimmen.
• Rückerstattungen, die verschwinden. Der häufigste Bruchpunkt manueller Prozesse sind Rückerstattungen. Wenn Gutschriftbelege nicht automatisch in Gutschriften fließen, sind Ihre Erlöse systematisch zu hoch. Automatisieren Sie diesen Pfad zuerst, nicht zuletzt.

Ein vernünftiger Rollout nach Shop-Größe

Sie brauchen nicht die ausgefeilteste Pipeline - Sie brauchen eine, die korrekt und zuverlässig ist und mehr Zeit spart, als ihr Betrieb kostet. Passen Sie den Aufwand an das Volumen an:

• Unter ~50 Rechnungen/Monat: Ein wöchentlicher Export (CSV-/Datev-Stil), den Ihr Steuerberater importiert, reicht wirklich aus. Nicht überkonstruieren.
• ~50–500/Monat: Eine täglich automatisierte Synchronisierung oder ein geplanter Export, mit automatisierten Rückerstattungen und einer Fehlerwarnung, damit Sie einen defekten Lauf am selben Tag finden und nicht erst zum Monatsende.
• 500+/Monat: Nahezu Echtzeit-Integration mit Idempotenz, Logging und Monitoring - das Volumen, bei dem ein stilles Duplikat oder eine verpasste Gutschrift teuer genug ist, um den technischen Aufwand zu rechtfertigen.

Und unabhängig von der Größe: Sprechen Sie mit Ihrem Steuerberater, bevor Sie bauen. Fragen Sie, welchen Kontenplan Sie verwenden sollen, welche Steuercodes erwartet werden, welches Exportformat tatsächlich importiert wird und ob PrestaShop oder das System des Steuerberaters die Rechnungsnummerierung führen soll. Lassen Sie die neue Pipeline anschließend einen vollen Monat parallel zu Ihrem bestehenden Prozess laufen und stimmen Sie beide ab, bevor Sie den manuellen Fallback abschalten. Das Ziel ist keine clevere Integration - sondern ein Quartalsende, an dem die Bücher bereits geschlossen sind, weil jede Bestellung, jede Rückerstattung und jede Steuerzeile beim ersten Mal korrekt übertragen wurde.

Häufig gestellte Fragen

Soll die Rechnungsnummer aus PrestaShop oder aus meiner Buchhaltungssoftware kommen?

Wählen Sie eines der Systeme als führendes System und bleiben Sie dabei. Wenn Sie für Kunden sichtbare Rechnungen zum Bestellzeitpunkt ausstellen und der Shop Ihr primäres Verkaufsbuch ist, sollte PrestaShop die Nummerierung übernehmen - dann müssen Sie Präfix, Format und Sequenz aber streng kontrollieren, damit sie lückenlos und prüfungssicher ist (dafür sind Invoice Number und Order Number gedacht). Wenn Ihr Steuerberater darauf besteht, alle rechtsgültigen Belege aus seinem System auszustellen, lassen Sie dieses System nummerieren und behandeln Sie die PrestaShop-Bestell-ID als Metadatum - und unterdrücken Sie das Kunden-PDF, damit die beiden Belege nicht kollidieren.

Wie sollen Rückerstattungen in meine Buchhaltungssoftware gelangen?

Als Gutschriften, niemals als gelöschte oder bearbeitete Rechnungen. Ein PrestaShop-Gutschriftbeleg (OrderSlip / ps_order_slip) wird einer Gutschrift (Xero) oder einem credit memo (QuickBooks) zur ursprünglichen Rechnung zugeordnet - gleicher Betrag, gleiche steuerliche Behandlung, negative Werte. Automatisieren Sie diesen Pfad zuerst, denn ein manueller Rückerstattungsprozess ist der häufigste Grund, warum Bücher Erlöse zu hoch ausweisen.

Brauche ich ein kostenpflichtiges Middleware-Abonnement, oder kann ich einfach eine Datei exportieren?

Für einen exportorientierten Steuerberater - Datev in Deutschland, JPK in Polen oder jeden, der sagt „schicken Sie mir einfach eine CSV“ - ist ein geplanter Export genau das Richtige, und ein Modul wie Invoice CSV List Exporter erledigt das ohne wiederkehrende Gebühr und ohne dass Bestelldaten Ihren Server verlassen. Middleware (Synder, A2X) verdient ihr Abonnement, wenn Sie ausdrücklich eine Live-API-Synchronisierung ohne manuelle Eingriffe zu Xero oder QuickBooks möchten, inklusive Wiederholungen und Protokollierung.

Wie verhindere ich doppelte Rechnungsbuchungen, wenn eine Synchronisierung erneut versucht wird?

Verwenden Sie einen Idempotenzschlüssel - fast immer die PrestaShop-Bestell- oder Rechnungs-ID -, damit die Buchhaltungsseite eine Wiederholung erkennt und überspringt. Ohne ihn kann jede Synchronisierung, die zweimal läuft oder nach einem Timeout erneut versucht, dieselbe Rechnung noch einmal buchen; Sie merken es erst bei der Abstimmung. Das ist eine einzeilige Designentscheidung, die den häufigsten Fehler in Buchhaltungsintegrationen verhindert.

Meine grenzüberschreitende VAT sieht in der Buchhaltung falsch aus - wo geht das schief?

Fast immer beim Mapping der Steuersätze oder bei der fehlenden Länderdimension. PrestaShop speichert Zielort und angewendete Steuerregel pro Rechnung, aber die Integration muss dieses Land für die OSS-Meldung bis in die Buchhaltung tragen, B2B-Verkäufe an gültige EU-VAT-Nummern als Reverse Charge buchen (nicht als Null-VAT) und Nicht-EU-Verkäufe als Exporte mit 0 % statt als unsichtbare Vorgänge behandeln. Validieren Sie VAT-Nummern zum Bestellzeitpunkt (Automatic EU VAT Checker prüft gegen VIES), damit jede Bestellung korrekt markiert ist, bevor sie das Hauptbuch erreicht.

Weiterführende Lektüre

• Wenn Ihr Shop aus manueller Arbeit herauswächst - wie Sie entscheiden, ob Buchhaltungsintegration der erste Schritt ist, den Sie brauchen
• PrestaShop mit Ihrem ERP verbinden - die Lager- und Einkaufshälfte, eine andere Struktur als das Hauptbuch
• Zapier und Make für PrestaShop - wenn breitere Shop-Automatisierung, nicht das Hauptbuch, Ihr Integrationsgrund ist