The problem: two systems that don’t talk

Swiss SMEs dealing with international suppliers and customers face a familiar pain: Amnis handles multi-currency payments beautifully, Xero manages the books with precision, but the two systems don’t talk to each other.

The result? Finance teams manually entering transactions, reconciling payments by hand, and spending hours on work that software should handle automatically.

We set out to build a proper Amnis-Xero integration — not a hacky workaround, but a robust, production-grade connector that could handle multi-currency complexity, scale across multiple clients, and fail gracefully when things go wrong.

Understanding the APIs

Both Amnis and Xero expose REST APIs with OAuth 2.0 authentication, but they behave quite differently in practice.

The Amnis API is well-documented and straightforward. The key endpoints we needed were:

• Transactions endpoint – fetches completed payments, incoming transfers, card expenses 
• Accounts endpoint – provides multi-currency balances and IBAN details
• FX rates endpoint – for accurate historical conversion tracking. 

Token management was required from day one since the API uses refresh tokens.

Xero’s API is more mature but also more complex. We focused on: 

• Bank Transactions – creating spend and receive transactions
• Bank Accounts – mapping Amnis accounts to Xero bank accounts
• Contacts – matching or creating supplier/customer records
• Tracking Categories – cost center  and project allocation

The main gotcha: Xero tokens expire after 30 minutes, which makes robust refresh handling critical – especially for background processes.

Bridging two different data models

This is where things got genuinely interesting. Amnis and Xero model financial data differently across the board.

We needed a translation layer that could map between these models while preserving data integrity and handling edge cases – not just the happy path.

Development approach: AI-assisted API mapping

One of the more useful aspects of this project was using AI automation to accelerate the API mapping work – something that would normally eat days of a developer’s time.

We fed both API specifications into Claude and asked it to identify matching fields between the two systems, required transformations (data types, formats, enums), edge cases and potential data loss points, and missing fields that would need default values or user input.

This gave us a solid first-pass mapping in hours rather than days.

For the repetitive work of writing transformation functions, we used AI assistance to generate initial implementations. The key was treating AI output as a starting point, not a finished product – every generated function still went through code review, edge case testing, and production hardening.

Architecture: background workers and a consistent pipeline

Real-time sync wasn’t practical here. Amnis transactions take time to settle, Xero has rate limits, and we needed clean failure handling. A background worker architecture made more sense.

Each sync run follows the same six-step pipeline:

1. Fetch – pull new transactions from Amnis since last sync
2. Transform – convert to Xero format, resolve contacts, map accounts
3. Validate – check for data completeness, flag anomalies
4. Push – create transactions in Xero via API
5. Confirm – verify creation, store Xero transaction IDs
6. Log – record sync results, timing, any issues

Idempotency was critical throughout. Running the same sync twice can’t create duplicate transactions. We handled this through: 

• Transaction fingerprinting – each Amnis transaction gets a deterministic hash
• Sync state tracking – we record which transactions have been successfully pushed
• Xero reference matching before creating anything new

Error handling: designing for reality

Things go wrong. APIs time out, tokens expire, data is malformed, rate limits get hit. We classified errors into four categories that each trigger a different response:

For transient errors, we use exponential backoff with jitter: 1 minute, then 5, then 30, then 2 hours. After four failures, the transaction is marked as failed and flagged for manual review.

Notifications run across three channels – Slack for real-time critical alerts and daily sync summaries, email digests for non-urgent weekly reports, and in-app dashboard alerts for tenant admins.

Multi-tenant management frontend

Since this tool integration needed to serve multiple clients from a single interface, we built a management frontend to handle configuration and monitoring across all tenants.

Tenant onboarding covers: 

• OAuth connection flows for both Amnis and Xero, 
• Account mapping (which Amnis accounts map to which Xero bank accounts)
• Default categorisation rules
• Contact matching preferences

The monitoring dashboard surfaces: 

• Sync status – last successful sync, pending transactions, error count
• Transaction volume – daily/weekly/monthly transaction counts and values
• Health indicators like API connectivity, token status and processing latency 

Each tenant also gets configurable settings: 

• Sync frequency – how often to pull new transactions
• Categorisation rules based on counterparty or description patterns
• Notification preferences – who gets alerted and when
• Manual review thresholds for large or unusual transactions

Every action is logged — configuration changes, manual interventions, sync runs, errors and resolutions. This audit trail turned out to be essential, not just for debugging but for clients who need to explain their accounting processes to auditors.

Lessons learned

API documentation lies sometimes

Both APIs had cases where actual behaviour differed from documentation. We learned to trust integration tests over documentation and build in defensive checks for unexpected responses.

Currency is genuinely hard

What happens when a EUR payment arrives in a CHF account? Which FX rate do you use – Amnis’s or Xero’s? What about timing differences between transaction date and value date? We spent significant time getting this right, and the edge cases kept coming.

Observability is worth the investment

When something goes wrong at 2am, you want to diagnose it from logs without reproducing the issue. We log every API call, every transformation decision, every error – with enough context to understand what happened. This paid off repeatedly.

Users have existing workflows

The integration doesn’t exist in isolation. Finance teams have approval processes and reporting requirements that predate your connector. Understanding those workflows and fitting into them – rather than disrupting them – is as important as the technical implementation.

Results

The integration now handles thousands of transactions per month across multiple tenants. Key outcomes include: 

• Time savings – finance teams report saving 5–10 hours per week on manual data entry
• Error reduction – reconciliation discrepancies dropped to near-zero, compared to a 3–5% error rate with manual entry
• Real-time visibility – books are current within 15 minutes of payment completion
• Scalability – adding a new tenant takes minutes, not days

What’s next

We’re continuing to improve the integration with smarter categorisation (using transaction history patterns for automatic account assignment), predictive alerts for unusual transactions, and extended reconciliation that matches Amnis transactions with Xero invoices for automatic payment allocation.

If you’re dealing with disconnected business tools and manual data entry between systems, this kind of integration is exactly what we build. Check out our Tools Integration Services to see how we approach connecting platforms like Amnis and Xero – and what that could look like for your setup.

The post Building an Amnis-Xero Integration: A Technical Deep Dive appeared first on what. AG.

What we built: a live data bridge between Shopify and SAP S/4 HANA

Rausch GmbH needed a fully automated connection between their Shopify Plus store and SAP S/4 HANA. No manual exports, no spreadsheet handoffs.

We built a custom SAP connector handling four core jobs: orders, payment terms, tracking numbers, and inventory sync. Working alongside Eddyson – an external SAP integration partner – we owned the Shopify side while Eddyson bridged the gap to SAP.

The flow works like this:

• Shopify sends order data via webhook to our connector
• We enrich the files with missing information and deposit them on an FTP server for Eddyson to pick up
• In the other direction, SAP sends tracking and inventory updates to Eddyson, which forwards them to us – we enrich and push them into Shopify

Clean loop, when it works.

File enrichment and payment flows: where the real complexity lives

Shopify’s order webhook payload doesn’t include everything SAP S/4 HANA needs – and that gap is where most of the work happened.

Barcodes, for example, aren’t part of the order data. The connector loops through each line item, fires an additional API call using the variant ID, and fetches the barcode separately. Same logic for gift cards: we detect the payment gateway name, hit the transactions endpoint, and pull the gift card data before packaging the file.

None of this is complex in isolation. But when you’re mapping fields across two systems with fundamentally different data models, it adds up fast.

Buy on account required its own solution entirely. SAP handles these orders with a delivery block – the order exists but doesn’t ship until payment is confirmed. That meant orders/create and orders/paid couldn’t follow the same flow. We built two distinct flows, each triggering different downstream logic. Getting the SAP behavior properly documented took longer than expected.

Three-party project coordination: the hidden cost of misalignment

Any project involving a client, an agency, and a third-party integration partner has natural friction points. Mapping decisions took time to finalize, and some delays came from waiting on alignment between parties rather than from the technical work itself.

We navigated it – but it taught us something important about how these projects should be set up from the start.

What we’d do differently on a Shopify ERP integration

We went into this project without a detailed requirements list or milestone-based roadmap. That gap cost us time.

Upfront documentation is non-negotiable. When you’re coordinating between Shopify, a custom connector, and a third-party SAP middleware partner, ambiguity is expensive. A requirement that seems obvious to one party is news to another.

A few things we now treat as mandatory on any Shopify ERP integration:

• A detailed requirements list before kickoff – especially for payment flows, tax logic, and edge cases like gift cards or custom payment methods
• A shared Slack channel with all parties onboarded from day one – context scattered across emails and calls slows everything down
• Data mapping completed early and in detail – the gap between what Shopify sends and what SAP expects is where projects lose weeks

Key takeaways for your Shopify SAP integration

If you’re planning a Shopify SAP or broader Shopify ERP integration with a third-party middleware partner, here’s the short version of what this project taught us:

• Define requirements before kickoff – not a rough scope, an actual list. Payment flows, tax logic, edge cases.
• Map your data early – the Shopify-to-SAP field gap is real and takes time to resolve properly.
• Build on a stack you’ll maintain – technical debt from legacy codebases surfaces as migration costs, not if but when.
• One shared communication channel from day one – when three parties need to align quickly, async fragmentation kills momentum.

The connector works. The lessons were worth it.

We also delivered the full Shopify services scope for Rausch GmbH – building their Shopify Plus store, migrating from Shopware 5, and implementing a custom product configurator for their Pick&Mix solutions. The ERP connector sits inside a larger, working ecosystem.

The post Shopify ↔ SAP S/4 HANA Integration: What We Learned Building a Custom ERP Connector appeared first on what. AG.