Das Problem: zwei Systeme, die nicht miteinander kommunizieren

Schweizer KMU, die mit internationalen Lieferanten und Kunden arbeiten, kennen das Problem: Amnis wickelt Zahlungen in mehreren Währungen hervorragend ab, Xero führt die Bücher präzise – aber die beiden Systeme kommunizieren nicht miteinander.

Das Ergebnis? Finanzteams, die Transaktionen manuell eingeben, Zahlungen von Hand abgleichen und Stunden mit Arbeit verbringen, die eigentlich die Software erledigen sollte.

Wir haben uns daran gemacht, eine echte Amnis-Xero-Integration zu entwickeln – keine provisorische Notlösung, sondern einen robusten, produktionsreifen Konnektor, der mit Mehrwährungs-Komplexität umgehen kann, auf mehrere Kunden skaliert und bei Fehlern sauber abbricht.

Die APIs verstehen

Sowohl Amnis als auch Xero bieten REST-APIs mit OAuth 2.0-Authentifizierung an – aber in der Praxis verhalten sie sich ziemlich unterschiedlich.

Die Amnis-API ist gut dokumentiert und unkompliziert. Die wichtigsten Schnittstellen, die wir gebraucht haben:

• Transaktions-Schnittstelle – ruft abgeschlossene Zahlungen, eingehende Überweisungen und Kartenausgaben ab
• Konten-Schnittstelle – liefert Salden in mehreren Währungen und IBAN-Details
• Wechselkurs-Schnittstelle – für eine genaue Nachverfolgung historischer Umrechnungen

Token-Management war von Anfang an notwendig, da die API Refresh-Tokens verwendet.

Die Xero-API ist ausgereifter, aber auch komplexer. Wir haben uns auf folgende Bereiche konzentriert:

• Banktransaktionen – Erstellen von Aus- und Zahlungseingängen
• Bankkonten – Zuordnung von Amnis-Konten zu Xero-Bankkonten
• Kontakte – Abgleichen oder Anlegen von Lieferanten- und Kundendatensätzen
• Tracking-Kategorien – Kostenstellen- und Projektzuordnung

Der wichtigste Knackpunkt: Xero-Tokens verfallen nach 30 Minuten, was eine robuste Handhabung der Token-Aktualisierung entscheidend macht – besonders bei Hintergrundprozessen.

Zwei unterschiedliche Datenmodelle verbinden

Hier wurde es wirklich interessant. Amnis und Xero modellieren Finanzdaten grundlegend unterschiedlich.

Wir brauchten eine Übersetzungsschicht, die diese Modelle aufeinander abbilden kann – mit Wahrung der Datenintegrität und Behandlung von Grenzfällen, nicht nur des Idealfalls.

Entwicklungsansatz: KI-gestütztes API-Mapping

Einer der nützlichsten Aspekte dieses Projekts war der Einsatz von KI-Automatisierung, um die API-Mapping-Arbeit zu beschleunigen – etwas, das normalerweise tagelange Entwicklerzeit frisst.

Wir haben beide API-Spezifikationen in Claude eingegeben und das System gebeten, folgende Punkte zu identifizieren: übereinstimmende Felder zwischen den beiden Systemen, erforderliche Transformationen (Datentypen, Formate, Enums), Grenzfälle und potenzielle Datenverlustpunkte sowie fehlende Felder, die Standardwerte oder Benutzereingaben benötigen.

So hatten wir innerhalb von Stunden statt Tagen ein solides erstes Mapping.

Für die repetitive Arbeit beim Schreiben von Transformationsfunktionen haben wir KI-Unterstützung genutzt, um erste Implementierungen zu generieren. Der Schlüssel dabei: die KI-Ausgabe als Ausgangspunkt zu betrachten, nicht als fertiges Produkt – jede generierte Funktion durchlief weiterhin Code-Review, Tests für Grenzfälle und Produktionsvorbereitung.

Architektur: Background-Workers und eine einheitliche Pipeline

Echtzeit-Synchronisierung war hier nicht sinnvoll. Amnis-Transaktionen brauchen Zeit zur Abwicklung, Xero hat Rate Limits, und wir brauchten eine saubere Fehlerbehandlung. Eine Background-Worker-Architektur hat mehr Sinn ergeben.

Jeder Synchronisierungslauf folgt derselben sechsstufigen Pipeline:

1. Abrufen – neue Transaktionen seit der letzten Synchronisierung von Amnis holen
2. Umwandeln – in das Xero-Format umwandeln, Kontakte abgleichen, Konten zuordnen
3. Überprüfen – Daten auf Vollständigkeit prüfen, Anomalien markieren
4. Übertragen – Transaktionen in Xero über die API erstellen
5. Bestätigen – Erstellung bestätigen, Xero-Transaktions-IDs speichern
6. Protokollieren – Synchronisierungsergebnisse, Zeitpunkte und etwaige Probleme aufzeichnen

Idempotenz war durchgehend entscheidend. Denselben Sync zweimal auszuführen darf keine doppelten Transaktionen erzeugen. Wir haben das folgendermassen gelöst:

• Transaktions-Fingerprinting – jede Amnis-Transaktion erhält einen deterministischen Hash
• Sync-Status-Tracking – wir protokollieren, welche Transaktionen erfolgreich übertragen wurden
• Xero-Referenzabgleich, bevor neue Datensätze erstellt werden

Fehlerbehandlung: für die Realität entworfen

Es kann immer etwas schiefgehen. APIs laufen ab, Tokens verfallen, Daten sind fehlerhaft, Rate Limits werden erreicht. Wir haben Fehler in vier Kategorien eingeteilt, die jeweils eine andere Reaktion auslösen:

Bei vorübergehenden Fehlern verwenden wir exponentielles Backoff mit Jitter: 1 Minute, dann 5, dann 30, dann 2 Stunden. Nach vier Fehlversuchen wird die Transaktion als fehlgeschlagen markiert und zur manuellen Überprüfung gekennzeichnet.

Benachrichtigungen laufen über drei Kanäle – Slack für kritische Echtzeit-Warnungen und tägliche Sync-Zusammenfassungen, E-Mail-Digests für nicht dringende Wochenberichte und In-App-Dashboard-Warnungen für Tenant-Admins.

Frontend für die Multi-Tenant-Verwaltung

Da diese Tool-Integration mehrere Kunden über eine einzige Oberfläche bedienen musste, haben wir ein Management-Frontend entwickelt, das Konfiguration und Monitoring für alle Tenants abdeckt.

Das Tenant-Onboarding umfasst:

• OAuth-Verbindungsabläufe für Amnis und Xero
• Kontenzuordnung (welche Amnis-Konten welchen Xero-Bankkonten zugeordnet werden)
• Standard-Kategorisierungsregeln
• Einstellungen für den Kontaktabgleich

Das Monitoring-Dashboard zeigt:

• Sync-Status – letzte erfolgreiche Synchronisierung, ausstehende Transaktionen, Fehleranzahl
• Transaktionsvolumen – tägliche, wöchentliche und monatliche Transaktionsanzahl und -werte
• Zustandsindikatoren wie API-Konnektivität, Token-Status und Verarbeitungslatenz

Jeder Tenant erhält zudem konfigurierbare Einstellungen:

• Synchronisierungshäufigkeit – wie oft neue Transaktionen abgerufen werden
• Kategorisierungsregeln basierend auf Gegenparteien oder Beschreibungsmustern
• Benachrichtigungseinstellungen – wer wird wann benachrichtigt
• Schwellenwerte für die manuelle Überprüfung bei grossen oder ungewöhnlichen Transaktionen

Jede Aktion wird protokolliert – Konfigurationsänderungen, manuelle Eingriffe, Sync-Läufe, Fehler und deren Behebung. Dieser Prüfpfad hat sich als unverzichtbar erwiesen, nicht nur für die Fehlersuche, sondern auch für Kunden, die ihre Buchhaltungsprozesse gegenüber externen Prüfern erklären müssen.

Was wir gelernt haben

API-Dokumentation ist manchmal irreführend

Bei beiden APIs gab es Fälle, in denen das tatsächliche Verhalten von der Dokumentation abwich. Wir haben gelernt, Integrationstests mehr zu vertrauen als der Dokumentation – und defensive Prüfungen für unerwartete Antworten einzubauen.

Währungsumrechnung ist wirklich knifflig

Was passiert, wenn eine EUR-Zahlung auf einem CHF-Konto eingeht? Welchen Wechselkurs verwendest du – den von Amnis oder den von Xero? Und was ist mit zeitlichen Abweichungen zwischen Transaktionsdatum und Valutadatum? Wir haben viel Zeit damit verbracht, das hinzubekommen – und die Grenzfälle hörten nicht auf.

Observability lohnt sich

Wenn um 2 Uhr morgens etwas schiefgeht, willst du das Problem anhand der Logs diagnostizieren, ohne es reproduzieren zu müssen. Wir protokollieren jeden API-Aufruf, jede Transformationsentscheidung, jeden Fehler – mit genug Kontext, um zu verstehen, was passiert ist. Das hat sich immer wieder ausgezahlt.

Nutzer haben bestehende Workflows

Die Integration existiert nicht im Vakuum. Finanzteams haben Genehmigungsprozesse und Berichtsanforderungen, die schon lange vor deinem Konnektor bestanden haben. Diese Workflows zu verstehen und sich in sie einzufügen – anstatt sie zu stören – ist genauso wichtig wie die technische Umsetzung.

Ergebnisse

Die Integration verarbeitet heute Tausende von Transaktionen pro Monat über mehrere Tenants hinweg. Die wichtigsten Ergebnisse:

• Zeitersparnis – Finanzteams berichten von 5–10 Stunden Ersparnis pro Woche bei der manuellen Dateneingabe
• Fehlerreduzierung – Abgleichabweichungen sind auf nahezu null gesunken, verglichen mit einer Fehlerquote von 3–5 % bei manueller Eingabe
• Echtzeit-Transparenz – die Buchhaltung ist innerhalb von 15 Minuten nach Zahlungsabschluss aktuell
• Skalierbarkeit – einen neuen Tenant hinzuzufügen dauert Minuten, nicht Tage

Was als Nächstes kommt

Wir verbessern die Integration laufend: mit intelligenterer Kategorisierung (auf Basis von Mustern aus der Transaktionshistorie für die automatische Kontenzuordnung), vorausschauenden Warnmeldungen bei ungewöhnlichen Transaktionen und einer erweiterten Abstimmung, die Amnis-Transaktionen mit Xero-Rechnungen abgleicht, um Zahlungen automatisch zuzuordnen.

Wenn du mit isolierten Business-Tools und manueller Dateneingabe zwischen Systemen zu kämpfen hast, ist genau das die Art von Integration, die wir entwickeln. Schau dir unsere Tools Integration Services an, um zu sehen, wie wir Plattformen wie Amnis und Xero miteinander verbinden – und wie das für dein Setup aussehen könnte.

The post Aufbau einer Amnis-Xero-Integration: Technischer Deep Dive appeared first on what. AG.

Was wir entwickelt haben: Eine Live-Datenbrücke zwischen Shopify und SAP S/4 HANA

Die Rausch GmbH brauchte eine vollautomatische Verbindung zwischen ihrem Shopify-Plus-Shop und SAP S/4 HANA. Keine manuellen Exporte, keine Spreadsheet-Übergaben.

Wir haben einen massgeschneiderten SAP-Konnektor entwickelt, der vier Kernaufgaben übernimmt: Bestellungen, Zahlungsbedingungen, Sendungsverfolgungsnummern und Bestandsabgleich. In Zusammenarbeit mit Eddyson – einem externen SAP-Integrationspartner – haben wir die Shopify-Seite übernommen, während Eddyson die Verbindung zu SAP hergestellt hat.

Der Ablauf funktioniert so:

• Shopify sendet Bestelldaten per Webhook an unseren Konnektor
• Wir reichern die Dateien mit fehlenden Informationen an und legen sie auf einem FTP-Server ab, von dem Eddyson sie abholt
• In die andere Richtung sendet SAP Sendungsverfolgungs- und Bestandsaktualisierungen an Eddyson, das sie an uns weiterleitet – wir reichern sie an und übertragen sie zurück nach Shopify

Ein sauberer Kreislauf – wenn er funktioniert.

Dateianreicherung und Zahlungsabläufe: Hier liegt die eigentliche Komplexität

Der Shopify-Bestell-Webhook liefert nicht alles, was SAP S/4 HANA braucht – und genau diese Lücke war für den Grossteil der Arbeit verantwortlich.

Barcodes zum Beispiel sind nicht Teil der Bestelldaten. Der Konnektor geht jede einzelne Position durch, löst einen zusätzlichen API-Aufruf mit der Varianten-ID aus und holt den Barcode separat. Gleiche Logik bei Geschenkkarten: Wir erkennen den Namen des Zahlungsgateways, rufen den Transaktions-Endpunkt auf und holen die Geschenkkartendaten, bevor die Datei verpackt wird.

Jeder dieser Schritte ist für sich genommen nicht komplex. Aber wenn du Felder zwischen zwei Systemen mit grundlegend unterschiedlichen Datenmodellen abbildest, summiert sich das schnell.

Kauf auf Rechnung erforderte eine komplett eigene Lösung. SAP behandelt diese Bestellungen mit einer Liefersperre – die Bestellung existiert, wird aber erst versandt, wenn die Zahlung bestätigt ist. Das bedeutete, dass orders/create und orders/paid nicht demselben Ablauf folgen konnten. Wir haben zwei separate Abläufe gebaut, die jeweils unterschiedliche nachgelagerte Logik auslösen. Das SAP-Verhalten sauber zu dokumentieren hat länger gedauert als erwartet.

Projektkoordination zwischen drei Parteien: Die versteckten Kosten mangelnder Abstimmung

Jedes Projekt mit einem Kunden, einer Agentur und einem externen Integrationspartner hat natürliche Reibungspunkte. Die Mapping-Entscheidungen brauchten Zeit zum Festlegen, und manche Verzögerungen entstanden weniger durch die technische Arbeit selbst als durch das Warten auf Abstimmung zwischen den Parteien.

Wir haben das gemeistert – aber es hat uns etwas Wichtiges darüber gelehrt, wie solche Projekte von Anfang an aufgesetzt werden sollten.

Was wir bei einer Shopify-ERP-Integration anders machen würden

Wir sind ohne detaillierte Anforderungsliste oder Zeitplan mit Meilensteinen in dieses Projekt gegangen. Das hat uns Zeit gekostet.

Vorab-Dokumentation ist unabdingbar. Wenn du zwischen Shopify, einem massgeschneiderten Konnektor und einem externen SAP-Middleware-Partner koordinierst, kommt Unklarheit teuer zu stehen. Eine Anforderung, die für eine Partei selbstverständlich erscheint, ist für eine andere neu.

Ein paar Dinge, die wir bei jeder Shopify-ERP-Integration mittlerweile als unverzichtbar ansehen:

• Eine detaillierte Anforderungsliste vor dem Start – besonders für Zahlungsabläufe, Steuerlogik und Sonderfälle wie Geschenkkarten oder individuelle Zahlungsmethoden.
• Ein gemeinsamer Slack-Kanal, in den alle Beteiligten vom ersten Tag an eingebunden sind – wenn der Kontext über E-Mails und Anrufe verstreut ist, bremst das alles aus.
• Daten-Mapping früh und detailliert abschliessen – die Lücke zwischen dem, was Shopify sendet, und dem, was SAP erwartet, kostet Projekte Wochen.

Die wichtigsten Erkenntnisse für deine Shopify-SAP-Integration

Wenn du eine Shopify-SAP oder eine umfassendere Shopify-ERP-Integration mit einem externen Middleware-Partner planst, hier die Kurzfassung dessen, was uns dieses Projekt gelehrt hat:

• Anforderungen vor dem Start definieren – kein grober Umfang, sondern eine konkrete Liste: Zahlungsabläufe, Steuerlogik, Sonderfälle.
• Daten frühzeitig abbilden – die Feldunterschiede zwischen Shopify und SAP sind real und brauchen Zeit, um sie sauber zu lösen.
• Auf einem Stack aufbauen, den du auch warten wirst – technische Schulden aus alten Codebasen tauchen als Migrationskosten auf, nicht «ob», sondern «wann».
• Einen gemeinsamen Kommunikationskanal vom ersten Tag an – wenn drei Parteien schnell auf einen Stand kommen müssen, bremst asynchrone Fragmentierung den Schwung.

Der Konnektor funktioniert. Die Lektionen haben sich gelohnt.

Für die Rausch GmbH haben wir auch das gesamte Spektrum unserer Shopify-Servicesumgesetzt – den Aufbau ihres Shopify-Plus-Shops, die Migration von Shopware 5 und die Implementierung eines massgeschneiderten Produktkonfigurators für ihre Pick&Mix-Lösungen. Der ERP-Konnektor ist Teil eines grösseren, funktionierenden Ökosystems.

The post Shopify ↔ SAP S/4 HANA Integration: Was wir beim Aufbau eines massgeschneiderten ERP-Konnektors gelernt haben appeared first on what. AG.