CRM and ERP

Moneo and E-commerce: Syncing Orders, Payments and Stock Without Double Entry

Orders, payments and stock can sync automatically between a shop and Moneo, if you first decide which system owns each field and what happens when something fails.

FSM Studio · · 4 min read · Updated:

Two blog-post page mockups with a photo of smooth stones on a navy background, labelled Blog Post

If shop orders, payments and stock reach the accounting system by hand, every order is entered twice. Errors do not come from careless staff; retyping between two systems is simply the work in which people make mistakes.

This article covers how to plan a shop-to-Moneo sync (Moneo is accounting software widely used in Latvia): which data to move, in which direction, and what to find out before the project.

What to sync and in which direction

Three main flows run between a shop and an accounting system:

  • Orders from the shop to Moneo. An order becomes an invoice or sales document; the customer is found or created.
  • Payments to Moneo. When a payment arrives (card, bank transfer), it is matched to the document so the invoice is marked paid.
  • Stock and prices from Moneo to the shop. If product records and stock are kept in accounting, the shop must know what is available.

Start with one direction and extend only if the business needs it. This lowers risk and shows results sooner. We use the same approach in Jumis and WooCommerce integration.

Which system owns which field

Decide before coding where each field lives. If both systems may edit the same field, a conflict comes sooner or later. A practical split:

Data Usual source
Product records, SKUs Accounting (Moneo)
Stock Accounting or warehouse system
Prices Accounting if price lists live there; the shop if they exist only online
Orders, cart data Shop
Invoices, payment status Accounting

This is a starting point, not a rule. If your process differs, settle it with your accountant and sales manager.

From order to invoice

Passing an order to accounting is not just copying. Plan for:

  1. Customer. Does it already exist in Moneo? How is it matched: registration number, email? How are private individuals handled?
  2. VAT and countries. Price with or without VAT, EU customers, exemptions.
  3. Discounts, delivery and extras. Separate lines on the document or included in the price.
  4. Cancellations and returns. A cancelled or returned order needs a credit note. This is often forgotten in design.

Payments: how the invoice learns it was paid

Card payments confirm in real time, bank transfers arrive with a delay, and invoices with deferred terms are paid weeks later. Each needs its own rule: when the order is passed, when the invoice is marked paid and what happens with partial payments. Use one reference visible to the payment provider and to accounting; otherwise reconciliation becomes a month-end chore.

Stock: not selling one item twice

If stock updates once a day, the shop can sell goods that are gone. Only reserving stock at order time removes the risk, so play out in advance what happens when two buyers take the last unit. Stock needs one source; the shop only displays it.

What to find out about Moneo before the project

Data exchange options depend on your Moneo version and modules. Third-party documentation, for example, describes creating external API accounts in the Moneo integration module and issuing an API key (CostPocket), but that concerns expense documents, not shop orders. So we establish before the project:

  • which Moneo version and modules you have and what data exchange they allow;
  • which document types must be created automatically (invoice, delivery note, credit note);
  • who is responsible on the Moneo side if vendor help is needed;
  • how many orders a day and updates the sync must handle.

If an option is not available, we build an intermediate layer that converts data into a format the system accepts.

Errors and monitoring

Sync without monitoring produces unnoticed errors. You need an error log showing which order was not passed and why; re-processing without creating a duplicate; an alert when the integration stops; and queueing so orders are not lost when accounting is briefly unavailable. We write these into the requirements at the start, since adding them later costs more.

Decision rule

  • Few orders that can be entered by hand without errors: integration is not urgent; tidy the process first.
  • Orders retyped daily and errors causing corrections: start with passing orders to accounting.
  • Stock is the problem: start with stock sync from accounting to the shop.

If your accounting is in Moneo and your shop or CRM does not talk to it, see our approach to CRM and ERP integrations and online shop development. Discuss an integration.

Sources