Wolt, Glovo and Bolt ERP integration: what really happens to your orders

Every order entered manually creates risk. Not necessarily a major error — it can be the wrong product, an incorrect quantity or an order lost in the operational flow. With 30–50 orders per day coming from three different platforms, these errors add up.

More importantly, without integration, stock in the system does not reflect in real time what was sold through aggregators, fiscal documents need to be created manually, financial reconciliation with platforms becomes a weekly time-consuming task, and sales analysis by channel is impossible without manual exports from each platform. In similar implementations, redundant administrative work can reach 2–4 hours per day during peak periods, and a significant part of this effort disappears after integration.

Wolt, Glovo and Bolt can send orders through APIs or available integration mechanisms, depending on the access provided to the merchant and the configuration of each platform. When a customer places an order, the order data — products, quantities, price, address and customer comment — reaches the system automatically, without manual input.

What data actually comes from a Wolt order

This is the first practical lesson: not all fields arrive in the format you expect.

Prices come in minor currency units, not in lei. An order of 45.50 RON may appear as 4550. The system must convert this automatically, otherwise the cashier sees prices that are 100 times higher.

Currency may appear differently if the account settings are not aligned with the ERP. As a result, orders can arrive with the wrong currency, without a clear error message.

Customer comments must be mapped explicitly. If a customer writes “no onion”, this information does not appear in the ERP order unless the integration sends it into the operational document.

Product SKUs must be matched correctly. Wolt, Glovo and Bolt may use their own product identifiers, and if these are not mapped to the ERP items, the order cannot be processed automatically.

One of the most common situations in practice: the order is cancelled by the platform or by the customer, but it remains active in the ERP. The “Rejected” status must be explicitly translated into the ERP system logic. This does not happen automatically unless it is configured in the integration.

Similarly, if you cancel a product line from the ERP order, PayDesk does not automatically reflect that change unless the integration explicitly sends the updated status. The amount to be paid may remain calculated with the cancelled product included, which leads to collection errors.

The correct behavior is this: when a line is cancelled in the ERP order, the system must automatically recalculate the total and update the PayDesk document before fiscalization.

Future prices

If you create a price change document in the ERP with a future effective date, the system should not send it immediately to the platform, because there is a risk that the price will be applied before the intended date. The correct solution is for the ERP to create a scheduled task and send the change only on the day it becomes valid, or to manage the current price and future price separately.

Filtering by price list

If you use multiple price lists, for example one for Wolt, one for Glovo and one for direct sales, the system must synchronize with each platform only the changes from the corresponding list. Otherwise, any price change can trigger data exchanges with all aggregators, even when the change is not relevant for every channel.

Prices per packaging unit

If you sell a product by kilogram, but the platform displays it by package, for example a 500 g pack, the system must calculate and send the price per package automatically. The mapping must handle this conversion correctly in both directions.

For orders received through Wolt, Glovo or Bolt, the fiscal logic must be treated separately from the operational order flow. The integration must be able to distinguish between orders for which only a fiscal receipt is issued and situations where an invoice must be generated and sent through the RO e-Factura system.

In practice, the system must allow orders to be marked according to whether an invoice is required, and it must provide a clear procedure for cases where the customer requests an invoice. In those situations, customer data must be collected correctly, the invoice must be issued from the ERP, and then transmitted through the e-Factura flow.

Important: RO e-Factura rules must be verified before implementation depending on the customer type, transaction type and legislation applicable at that time.