E-Commerce Automation

We integrate with all major platforms: Shopify, WooCommerce, Shopware, Magento, Amazon, eBay and more. Almost any system can be connected via APIs and webhooks. What matters is less the platform than the data model behind it: whether variants map cleanly to SKUs, whether tax lines exist per line item, and whether refunds are separate objects. We check that before we build, not afterwards.

Every operation is anchored to a stable key, usually the shop order ID plus the event type. If the same webhook arrives twice – which is normal with delivery retries – the pipeline recognises it and does not process it again. Events arriving out of order, for example a refund before the order itself, are held back and re-evaluated instead of throwing an error.

Shop and carrier APIs cap the number of calls per time window. The pipelines therefore run with a queue, throttled execution and staggered retries. Anything that still fails after several attempts goes into an error list with order number and reason, not into a log nobody reads. Critical cases are pushed via Slack or email to a named person, agreed before go-live.

That is decided before we build and then held to consistently – usually the ERP or warehouse system, rarely the shop. Without that decision two systems write against each other and stock oscillates. We also define the sync cadence, a buffer for fast-moving items and how conflicts are handled: report and stop rather than overwrite.

As a separate record linked to the original order, not as a retroactive edit of the invoice. A partial refund affects specific line items, sometimes a proportional share of shipping, and a specific tax rate per item. That breakdown is the actual work. Stock is only returned when the goods have physically arrived – a refund on its own is not a goods receipt.

Yes, and that is where most of the effort sits. Marketplaces keep their own item numbers, their own order statuses and their own refund logic. We build a mapping table between the channel item and your SKU, normalise the status names and define which channel is allowed to set which field. Without that mapping, every additional channel is a new one-off project rather than an extension.

Yes, we actually recommend the step-by-step approach. The sensible order follows the flow of money: order and invoice first, then shipping and tracking, then returns and payment reconciliation, and the tax preparation last. Each stage runs in production for two to four weeks before the next one is added. That keeps it traceable which change caused which discrepancy.

The engagement is set up as a six-week effort, and a first automation is typically in production within 4 to 8 weeks. Initially the new pipeline runs alongside the existing route so you can compare results without putting the shop at risk. We only cut over once orders, invoices and stock levels agree across several days.

Costs depend on the scope. A starter package, for example order handling and invoicing, starts at €5,000. Projects with several system integrations – shop, ERP, shipping, payment provider – start at €15,000. Ongoing tool costs are EUR 50-200/month. The price covers a scope defined up front; additional sales channels are quoted as a separate step.

No. We prepare the data so that revenue is cleanly separated by country, tax rate and reporting period, and so reverse-charge cases are identifiable. Judging which rate applies, whether a registration is required and what gets reported stays with your tax adviser. We supply the underlying figures, not the tax decision – and we do not file anything with an authority.

It does not repair product master data. If variants are named differently in the shop and in the ERP and nobody maintains the mapping, automation only moves the problem faster. It also does not replace tax or legal review, does not replace accounting software, and does not decide whether a return is accepted. And it will not make a range with unreliable stock records shippable.