E-shop integration with Pohoda, Money S3, or Helios: A practical guide

Every night somewhere the same scene plays out: the accountant opens the e-shop, reads orders, and types them into the accounting system. Five minutes per order, thirty orders a day — that is two and a half hours of pure admin that adds no value. And that does not even count mistakes from fatigue, mismatched stock, or invoices sent two days late.

The problem is not human — it is systemic. The e-shop and the accounting software are two separate applications that cannot see each other. Until an integration sits between them, data has to move manually. And manual data transfer is reliably the most expensive way to solve something a machine can do. In our general guide to e-shop, ERP, and accounting integration we covered the basic approaches. This article goes a step deeper: three specific systems — Pohoda, Money S3, and Helios — and what to realistically expect from each.

Each of these systems has different integration capabilities, API maturity, and typical bottlenecks. The right choice depends on which system you already use — or which one you are about to deploy.

How integration works on a technical level

Before we get into specific systems, it is helpful to understand how integration between an e-shop and accounting software works technically. There are essentially three approaches, and modern projects combine them.

XML and CSV import/exportis the oldest and still the most widespread approach. The e-shop generates a file with orders in an agreed format and the accounting system imports it. Advantage: works without network connectivity between systems. Disadvantage: not real-time — typical latency is 15 minutes to an hour. With XML the critical question is idempotency: if the same file is imported twice (e.g., on a network error), the system must not create duplicate records. Most professional implementations solve idempotency through an external order identifier.

REST API is the modern approach where the e-shop and the accounting system communicate directly over HTTP. An order is created on the e-shop, the connector sends it immediately to the accounting system, and gets back a confirmation with the internal record number. Latency is measured in seconds. The key design decision is record matching: each order must be uniquely identifiable in both systems so states (paid, shipped, cancelled) can be synced later.

Middleware layer — for example n8n or Make — sits between the e-shop and the accounting system and orchestrates the data flow. Advantage: one middleware can serve multiple systems at once, centralise error handling, and allow visual flow debugging without touching code. Disadvantage at high volume: every HTTP call through middleware adds latency — which at hundreds of orders per hour becomes noticeable. For those cases direct process automation solutions written to spec are more appropriate.

Pohoda: strengths and weaknesses of integration

Pohoda by Stormware is the de facto standard for small and mid-sized companies in Czechia (and Slovakia). Its ubiquity means the integration knowledge base is rich — there are plenty of ready-made solutions, agents, and a community. That is an advantage at project start.

XML interface and mServer

Pohoda offers two main integration interfaces. First is file-based XML import/export: the e-shop generates XML files with orders (and possibly customers and stock movements) and Pohoda imports them through a batch mechanism. The XML structure is well-documented in the Stormware technical guide and most popular e-shop platforms (Shoptet, WooCommerce, PrestaShop) have plugins or export modules.

The second interface is mServer — an HTTP server embedded directly in Pohoda that allows real-time calls over REST. mServer is significantly more flexible than batch import: you can check product availability, create orders and invoices in real time, and read states of existing records. For most integration projects above 50 orders/day we recommend starting with mServer.

Limits to know

Pohoda has several limits to account for during integration. The desktop version (installed on a Windows PC) allows only one process to open the database at a time for XML import — while an import runs, another user cannot write. That can be a problem in a multi-user environment. mServer mitigates this but still runs on one machine and its performance depends on the hardware. For very high volumes (hundreds of transactions per hour) it makes sense to consider the Pohoda SQL version. mServer is an optional module with its own license fee, which should be included in total project costs.

Money S3: strengths and weaknesses of integration

Money S3 is developed by Seyfor (Cígler Software until 2022). It is a long-standing favourite with a large user base in Czechia and Slovakia, especially among small companies and sole proprietors. Seyfor has invested aggressively in the cloud version and API modernisation in recent years, which has benefited integration.

XML and API interface

Money S3 supports data import and export through XML files with its own schema. Like Pohoda, this channel is suitable for batch processing. For real-time integration there is a REST API, available primarily in the cloud and SQL variants. The desktop version has more limited API functionality, but most integration projects today push customers to the SQL or cloud license precisely for better API access.

Cloud vs desktop and multi-user behaviour

The cloud version of Money S3 (or migration to Money S5, the newer product generation) eliminates the single-user XML lock problem of desktop installs. In the cloud the API can write concurrently with the accountant working in the UI. For new integration projects, most partners today recommend the cloud or SQL version.

Money S5 connector or middleware

For companies migrating from Money S3 to the newer Money S5 generation, the API is significantly more modern and integration is simpler. Money S5 has REST API with OAuth2 authentication and Swagger documentation. For those staying on Money S3, the established approach is middleware (n8n, Make) with an XML connector.

Helios: strengths and weaknesses of integration

Helios by Asseco Solutions is a strong player in the mid and upper segment. While Pohoda and Money S3 dominate small companies, Helios is more prominent where more complex processes need to be covered: multiple branches, multi-currency operations, extensive warehouse management, or stricter audit requirements. The modern successor in Asseco's portfolio is Helios iNuvio — a cloud-native platform with an API-first approach.

Helios iNuvio's API-first architecture

Unlike Pohoda and older Money S3, Helios iNuvio is designed with API integration as a first-class channel from the ground up. It has a REST API with more extensive documentation, webhook support, and an audit log of changes — critical for companies where traceability of business events is a legal or internal requirement. For e-shop integration this means the connector can be written purely as an API client without having to go through files.

Setup complexity

Helios is powerful, but that power comes at a cost. Implementation takes longer than Pohoda or Money S3 — typically several weeks — and requires a certified Asseco partner. For a simple e-shop with a few hundred orders a month, Helios is over-engineered. Where it makes sense: B2B e-commerce with five or more stock locations, cross-border sales in multiple currencies, and full audit trail requirements.

How to choose: a decision matrix

If you do not yet have a fixed accounting system and are deciding before the integration project, here are five questions to help you pick the right one:

• Monthly invoice volume. Up to 500 invoices/month is fine for Pohoda or Money S3. Above 2,000 monthly invoices, backend performance starts to matter — SQL variants or Helios iNuvio.
• Multi-user concurrency. If multiple people write simultaneously (warehouse, sales, accounting), desktop versions can cause lock conflicts. Cloud variants or Helios solve this natively.
• Multi-warehouse and multiple branches. Pohoda and Money S3 support multiple warehouses, but with truly distributed logistics and cross-dock operations, Helios is more robust.
• Multi-currency and cross-border sales. If you sell to multiple countries in multiple currencies, ensure your accounting system handles automatic revaluation accounting. Helios has the longer history here.
• Audit trail strictness. If you are in a regulated industry or have internal full-audit trail requirements, Helios iNuvio offers the strongest audit model.

Pain-free implementation plan

Regardless of the system you pick, the proven implementation approach looks the same. Five steps:

1. Audit of current state

   Map every data flow that runs manually today: orders, customer cards, stock movements, invoices, payments. Find out how many records per day, what exceptions exist, and where the most common errors happen.

2. Data contract definition

   Agree on precise field mapping between the e-shop and the accounting system: how product codes, VAT groups, payment methods, order states map. Document it in a simple table.

3. Idempotent connector

   Program the connector so repeated processing of the same order never creates a duplicate. Every order must have a unique external identifier stored on both sides.

4. Sandbox testing

   Before go-live, test every scenario in the test environment: standard order, returns, cash on delivery, partial payment, cancel before shipping.

5. Go-live with reconciliation

   Run a parallel mode for the first 1–2 weeks with daily checks that records match between e-shop and accounting. Set up an automatic reconciliation report. When error rate drops below 0.1 %, remove the manual checks.