ERP with JTL Integration

JTL-Wawi is the most widely deployed e-commerce ERP in the German SMB segment, with a long tail of agencies, hosting partners and add-on developers around it. Hilden-based JTL Software has built a stack that covers warehouse management (JTL-WMS, JTL-WMS-mobile), shop frontend (JTL-Shop), marketplace listings (JTL-eazyAuction) and point-of-sale (JTL-POS). The integration question therefore splits into two: within the JTL stack itself, and between JTL-Wawi and adjacent systems. This page describes both, with a focus on what to verify when JTL becomes the operational backbone of a German e-commerce business.

JTL-Wawi as the ERP core

JTL-Wawi is a Windows-client application backed by a Microsoft SQL Server database, with WAWI-Worker services handling asynchronous flows. The architecture is decidedly on-premise: the SQL Server typically runs on the customer's server or in a JTL-hosting partner's data centre, and the client connects directly. JTL has been adding cloud and web-client capabilities incrementally, but the core deployment model has shaped which integrations are easiest. Native interfaces include comprehensive coverage of JTL-Shop, JTL-WMS, JTL-eazyAuction (Amazon, eBay, Kaufland, Otto), DATEV (mature, several format versions), DPD, GLS, DHL and a long list of payment providers. Adjacent ERPs (Sage 100, Microsoft Dynamics 365) are integrated by partner connectors rather than by JTL natively.

JTL-Shop and JTL-WMS

JTL-Shop is a PHP-based e-commerce platform tightly coupled to JTL-Wawi via a shop-sync mechanism. Master data (products, prices, stock, customer groups) is pushed from Wawi to Shop on a configurable schedule; orders flow back from Shop to Wawi for picking, packing and invoicing. The coupling is strong by design and is a competitive advantage in the JTL stack, but it also constrains some customisations: shop features that diverge from Wawi data structures require careful design or a separate PIM layer. JTL-WMS extends the picture into the warehouse with mobile scanning (JTL-WMS-mobile on Android handheld terminals), pick paths, batch management and serial numbers. For Mid-Market e-commerce sellers in the EUR 5-30 million revenue band, the JTL-Wawi-Shop-WMS triplet is typically the lowest-friction option in the DACH market.

JTL-eazyAuction for marketplaces

JTL-eazyAuction is the marketplace-listing module within the JTL stack. It handles listing creation, attribute mapping, repricing rules and order ingestion for Amazon (SP-API), eBay, Kaufland Marketplace, Otto Market (the German legacy Otto-EDI flows for parts of the catalogue), Idealo and several smaller platforms. eazyAuction is licensed separately from JTL-Wawi and priced on a per-marketplace or bundled basis. For sellers operating multi-marketplace at scale, the alternative is to keep JTL-Wawi as the ERP and use specialist middleware such as Tradebyte, ChannelEngine or Channable for the marketplace layer; this is sometimes preferred for richer attribute handling and faster onboarding of new marketplaces, at the cost of an additional subscription.

DATEV, KassenSichV and OSS in the JTL stack

JTL-Wawi ships a mature native DATEV interface covering vouchers, accounts, fixed assets and master data; format versions are kept current. For multi-channel sellers using JTL-POS, the KassenSichV (Kassensicherungsverordnung) requirement for a certified technical security element (TSE) is satisfied by JTL-POS's integrated TSE support, with cloud TSE options from fiskaly and Epson hardware TSE as alternatives. OSS reporting is supported by tagging transactions in JTL-Wawi by country-of-consumption and exporting the consolidated dataset to DATEV for the quarterly return filed via the German Federal Central Tax Office (BZSt). The Verfahrensdokumentation required under GoBD is well-templated by the JTL partner ecosystem — several JTL-Servicepartner offer a starter document that customers complete to match their own configuration.

Häufig gestellte Fragen

Which data is synchronised between the ERP and JTL?

Typically, master data (contacts, companies, products) and transactional data (orders, invoices, payments) are synchronised. Which fields are actually transferred depends on the chosen connector and the master system. In most setups the ERP is the source for financial data and product master data, while JTL is the source for sales or operations data. A clean field-mapping table should be documented before go-live.

How is the sync frequency typically configured?

Common frequencies are real time (webhook-based), 5-15-minute intervals (polling) or nightly batches. Real time is state of the art for sales cases, while batches are sufficient for reporting data. The choice depends on the business process and the API load on both sides. With JTL, API rate limits should be checked early on — otherwise exceeding them leads to data gaps.

What interface options are available for the JTL integration?

There are three typical routes: native connectors from the ERP or JTL vendor, iPaaS platforms (Workato, Make, Zapier, Celigo), or custom REST/SOAP integrations. Native connectors are the fastest to set up, iPaaS offers the most flexibility, and custom integrations adapt to special cases. Which option is best depends on volume, complexity and budget — see the interface overview. A technical pre-analysis saves a lot of effort later on.

What is the master system in a JTL integration?

The master system holds the leading source of truth for a data object. For finance and accounting data the ERP is usually the master, while for sales and marketing data it is often JTL. This assignment should be documented in writing for each data object, otherwise inconsistencies arise with bidirectional synchronisation. A documented mapping is also important for GoBD-compliant traceability.

Which typical sources of error should be planned for?

Classic errors include unmapped mandatory fields, differing format standards (date, currency, tax rates) and missing conflict resolution for bidirectional sync. Just as critical are API limits, token expiry and unstructured error handling. A production-grade integration needs monitoring, alerting and a clear reprocessing path for errors. For the JTL integration, a dedicated test tenant in both systems is recommended.