ERP with Amazon Integration

Selling on Amazon as a German Mid-Market company is rarely a stand-alone channel decision. Listings, prices, stock and order flow must reconcile with the ERP that runs the rest of the business, and the tax treatment of cross-border sales through Amazon's European fulfilment network sits at the heart of every audit conversation. This page describes the practical requirements for an ERP-to-Amazon integration in the DACH context: which APIs matter, how fulfilment models change the integration scope, which ERPs are known for strong Amazon support, and how OSS, IOSS and the German KassenSichV interact with Amazon flows.

FBA versus seller-fulfilled fulfilment

The choice between Fulfilment by Amazon (FBA) and seller-fulfilled prime (SFP) or merchant-fulfilled network (MFN) shapes the integration substantially. Under FBA the ERP must reconcile inventory levels held in Amazon's fulfilment centres across multiple European countries, ingest FBA settlement reports for revenue and fee recognition, and track the Pan-European FBA programme's cross-border stock movements for VAT registration purposes. Under seller-fulfilled models the ERP-warehouse-management combination must handle Amazon-grade shipping cut-offs, return labels and the prime delivery promise. Most established DACH e-commerce ERPs — plentyOne, JTL-Wawi, Xentral, weclapp, billbee — cover both models, but the operational maturity differs and should be evaluated with reference customers in the same fulfilment model.

From MWS to SP-API

Amazon has migrated its third-party seller interface from the legacy Marketplace Web Service (MWS) to the modern Selling Partner API (SP-API), with full deprecation of MWS for most operations completed. SP-API uses OAuth 2.0 and AWS Signature Version 4, exposes a broader set of operations including catalogue, listing, inventory, order, finance and reports, and applies per-application rate limits. Buyers evaluating an ERP's Amazon connector should verify SP-API coverage rather than legacy MWS support, ask which Amazon regions and marketplaces are certified, and confirm that the connector handles bulk operations through the reports API rather than polling individual order endpoints, which is operationally fragile at higher volumes.

Inventory sync and repricing

Inventory synchronisation is the most operationally critical part of the integration: an oversell on Amazon damages account health metrics and can trigger listing suppression. Mature integrations push stock levels at a frequency calibrated to channel velocity and reserve buffer stock for high-velocity SKUs. Repricing is typically handled either inside the ERP (rule-based) or by a specialist repricer such as RepricerExpress, BuyBoxBuddy or sellerboard that consumes ERP cost data and writes prices back via SP-API. Multi-channel sellers should be explicit about which system owns prices: an ERP that overwrites repricer changes on the next inventory cycle creates a problem that takes weeks to diagnose.

VAT, OSS and the German tax context

Cross-border sales through Amazon's European fulfilment network create VAT obligations that the ERP must support. Since July 2021 the OSS (One Stop Shop) regime allows EU sellers to declare intra-EU distance sales centrally; IOSS covers low-value imports from outside the EU. Pan-European FBA may still trigger local VAT registration in the countries where stock is held. The ERP must therefore tag every Amazon transaction with the correct country-of-consumption, distinguish between B2C and B2B (which retain reverse-charge treatment) and produce reconciliations suitable for the OSS quarterly return filed via the German Federal Central Tax Office (BZSt). Note that KassenSichV does not apply to Amazon e-commerce flows directly — it targets cash-register systems — but sellers operating physical stores alongside Amazon must keep the two flows separated for compliance purposes.

Frequently Asked Questions

Which ERPs are commonly used by German Amazon sellers?

plentyOne (Kassel-based, deep marketplace heritage), JTL-Wawi (the dominant Mittelstand e-commerce ERP in Germany), Xentral (cloud, Augsburg/Erfurt), weclapp (Frankfurt, broader CRM-plus-ERP scope) and billbee (entry-level multi-channel) are the most frequently shortlisted. For larger sellers, Microsoft Dynamics 365 Business Central with a specialist Amazon connector (LS Retail, Tradebyte) or Sana Commerce are also relevant.

Do I need a separate Amazon connector if my ERP claims native support?

Sometimes. "Native support" can mean anything from a fully maintained connector covering all SP-API operations to a CSV-based listing tool. Buyers should ask which SP-API resources are covered, which fulfilment models are supported, how returns and refunds reconcile, and whether the connector is operated as a managed service or installed locally. For sellers above roughly EUR 5 million annual GMV the case for a specialist middleware layer (Tradebyte, ChannelEngine, Channable) grows.

How does Amazon Vendor Central differ from Seller Central in the ERP integration?

Vendor Central is a wholesale relationship: the seller invoices Amazon directly, typically via EDI (EDIFACT) over AS2, and Amazon handles all customer-facing fulfilment. Seller Central is the marketplace model described above. The two require different ERP integrations — Vendor flows are EDI-heavy and resemble traditional retail B2B, Seller flows are API-driven and resemble direct-to-consumer e-commerce.

Can the same ERP handle Amazon and other marketplaces in parallel?

Yes, and this is the typical configuration. JTL-Wawi, plentyOne, Xentral, weclapp and billbee all manage Amazon alongside eBay, Kaufland, Otto Market and Shopify or Shopware front ends. The German-specific quirks to verify are Otto-EDI (DPD-style invoicing flows still required for parts of the catalogue), the Kaufland Marketplace API, and the OSS tagging applied consistently across all channels.