Integrations

QUOMODA has a native Shopify integration for syncing products, variants, prices, images, and inventory. A Resourced (PLM) catalogue import is also available. More integrations are being developed.

A duplicate means one product holds two records for the same SKU that describe the SAME article — same size, same colourway, same name — usually after a product was deleted and re-imported in Shopify, so its stock is split and totals disagree. The sync now re-links re-imported variants instead of creating duplicates, and if any exist you'll see an amber "duplicate SKUs" card on the Integrations page. Open Review & merge, pick which record to keep per SKU (the Shopify-linked one is pre-selected), and the other's stock, orders and history fold into it — Shopify is re-synced automatically.

Because they are not duplicates. If two records share a SKU but differ in size, colourway or name — the same skirt in wool and in cupro, say, or one code covering XS, S and M — then both articles are real, separately stocked, and separately sold. Merging would delete one of them for good. QUOMODA lists these under "used by more than one article" on the Integrations page and deliberately gives them no merge button. Nothing is broken in QUOMODA, but a code that means two garments will confuse a warehouse and any barcode scan, so it is worth giving them distinct SKUs in your store.

1. 1In Shopify, create a custom app: Settings → Apps → Develop apps → Build apps.
2. 2On the app's API access page, grant these Admin API scopes: read_products, write_products, read_inventory, write_inventory, read_locations, read_orders, read_all_orders — then Release and Install the app on your store.
3. 3Turn on Protected customer data access on that same API access page (it appears once read_orders is added) and click Request access → enable Protected customer data. This is required for the sales/orders sync that powers demand planning; for a single-store custom app it's granted immediately.
4. 4Copy the app's Client ID and Client secret.
5. 5In QUOMODA go to Integrations → Connect Shopify and paste them in.
6. 6Run your first full sync from the integration card. This imports your catalogue, maps your variants and locations, and switches on the live webhooks.

The QUOMODA app on the Shopify App Store is the other way in, and it is simpler: install it from your Shopify admin and it links itself. It is free, and it is a connector — you still need a QUOMODA account to use it. There is nothing to type either way; QUOMODA never asks you for your myshopify.com address to install, because Shopify carries that itself.

Either. Open QUOMODA under Apps in your Shopify admin and you get a card with the connection status, when it last did anything, whether the live webhooks are registered, and buttons to sync now, re-register webhooks or disconnect.

It is the same connection either way — the card in Shopify and the card on QUOMODA's Integrations page act on one record, so they cannot disagree.

Products, variants, images, prices, and inventory levels sync between QUOMODA and Shopify. Wholesale orders stay in QUOMODA. If you enable orders access (read_orders + Protected customer data), your consumer sales — e-commerce and retail/POS — also flow in as sell-out, split per channel and store, to power demand planning's velocity and reorder suggestions.

Live demo · loops

Q

QUOMODA

Products

Shopify

Allocated wholesale stock shows as reserved in Shopify

Demand planning's velocity, weeks-of-cover and reorder suggestions run on your own-channel sell-out — e-commerce and retail/POS sales (wholesale bookings don't trigger reorders). To feed them, your Shopify custom app needs the read_orders and read_all_orders scopes plus Protected customer data access enabled. Once that's on, new sales arrive automatically via webhooks — no reconnect needed.

To load past sales as well, open the Shopify card's ⋯ menu → Import sales history. It backfills the last 12 months of e-commerce and POS orders into demand planning so velocity is meaningful from day one, and it's safe to re-run.

QUOMODA works out which of your Shopify options separates one article from another by looking for one called Colour. If your styles vary by something else — fabric, material, finish, wash — no option matches, and every variant arrives with that field empty. Three sizes in two fabrics then land as three articles that cannot be told apart, which is what looks like a duplicate.

Tell it which option to use: on the Shopify card choose ⋯ → Variant axis. It reads the option names straight out of your store and shows a few real values under each, so you can point at the right one rather than guess.

1. 1Pick the option that separates your articles — Fabric, say — as the colourway axis.
2. 2Confirm the size axis, if it is called something other than Size.
3. 3Set what you want the field to be called in QUOMODA. It follows through to the products table, order forms, linesheets and printed documents.
4. 4Run a sync. Products already imported are filled in as well — nothing has to be re-created.

Yes. QUOMODA pushes product, price and stock changes to Shopify as you make them, and Shopify pushes product and inventory changes back via webhooks — so both stay in step automatically, without a manual sync each time.

It depends on the integration, so the answer is different for each one:

Shopify — no, we create them. The live link runs on webhooks, and we register them for you on your first full sync. Connecting alone does not create them. They cover products (create / update / delete), inventory levels, and orders (which feed sales velocity in demand planning).

Resourced — yes, you create it. The webhook lives in Resourced and only you can add it. Connecting gets you the Sync button; without the webhook, Resourced changes arrive only when you press Sync. On the Resourced card choose ⋯ → Real-time webhook to get the URL, username and key, then paste them into Resourced under Settings → Webhooks → Add webhook (Method POST, with *Include resource* and *Enabled* on).

Yes — QUOMODA connects to Fortnox and Xero, so your accountant stops re-keying invoices by hand. There is no single accounting system across Europe, so the connector is built to take more of them: each one is a separate connection you authorise from Integrations → Accounting.

A connection belongs to a brand, not to your workspace. An agency running six brands connects six ledgers, one per brand, and they never see each other's documents.

Only what an accountant needs. The ledger gets your books, not your catalogue.

1. 1Customers — the wholesale accounts your invoices point at.
2. 2Invoices you have issued (sent, part-paid or paid). Drafts and cancelled documents stay put.
3. 3Credit notes, linked to the invoice they credit.
4. 4Payments you record in QUOMODA, against those invoices.
5. 5Proformas — only if you switch them on, and never as a booked document.

Never sent: products, variants, stock, locations, allocations, linesheets, selections, and any order that has not been invoiced. Pushing your articles into an accounting system would give you a second product master that immediately starts drifting from the real one.

Because nothing about tax or bookkeeping may be guessed. A new connection sits at Not mapped and refuses to run until you have filled in and confirmed the mapping — that is the whole point of the step, not a formality.

1. 1Tax codes — for every VAT rate you actually invoice at, pick the code your ledger uses. Xero publishes its own list and QUOMODA reads it live; Fortnox publishes none, so you type the code your accountant uses.
2. 2Chart of accounts — which revenue account, which receivables account, and (if you post approved invoices) which bank account payments land in.
3. 3Confirm — each row records who confirmed it and when. Editing any row un-confirms the connection and you re-confirm before the next run.
4. 4Dry run — builds every document and resolves every code without writing a single thing to your ledger. Do this before the first real sync.

Because accounting systems do not let a booked invoice be edited, and neither will we. Before every update QUOMODA reads the document back and checks its state:

1. 1Not booked yet — the change is pushed normally.
2. 2Already booked, approved or in a closed period — the document is blocked, with a sentence naming the ledger's own number so you can find it.
3. 3Part-paid or paid — amounts, quantities and tax are frozen. QUOMODA will still push the harmless header fields (reference, due date, number, link back), but if the total no longer matches it blocks instead.
4. 4Voided or deleted in the ledger — the link is closed and QUOMODA never writes to that document again.

Credit notes work differently per system. Xero takes a standalone credit note, which you then apply to the invoice yourself in Xero. Fortnox models a credit as an operation on the invoice it credits, so it must be linked to that invoice and must credit it in full — a partial credit cannot be sent to Fortnox.

Yes. Every document QUOMODA has pushed is recorded against the remote document it became, and that record is consulted before anything is sent — so a second run updates or skips, it never creates a second invoice. A document QUOMODA has not changed since the last run is reported as Unchanged and costs no call at all.

If a run is interrupted halfway, the next one looks your documents up in the ledger by the reference QUOMODA stamped on them before creating a duplicate.

Draft is the safe default and what a first connection should use: documents arrive unbooked, they create no journals and appear in no report, and your accountant approves them in their own system. Approved posts them straight to the ledger.

Proformas are always pushed unbooked, whatever this setting says — a proforma is not a tax document and must never create a receivable. They are off by default; if you switch them on, be aware that anyone can approve one inside the accounting system afterwards and turn it into a real invoice.

Whichever you choose — and both numbers are always stored and shown together. You can push QUOMODA's number, or let the ledger assign its own (Fortnox always assigns its own; Xero lets you pick).

The run history shows the pair for every document, because without it reconciling your QUOMODA invoice list against your accountant's is guesswork.

QUOMODA sends the document currency and the document amounts, and lets your accounting system apply its own exchange rate. It never sends, computes or invents a rate — an inverted FX rate misstates revenue, and your ledger already knows the rate it wants to book at.

Every press of Post is recorded against that document, with the accounting system's own words kept verbatim. The vocabulary matters:

1. 1Created / Updated — it reached the ledger.
2. 2Unchanged — nothing has changed since it was last posted, so nothing was sent.
3. 3Blocked — QUOMODA stopped on purpose and you need to act: a mapping is missing, the remote document is booked, or the customer or supplier has no VAT treatment set. It is not an error and it is never a silent skip.
4. 4Rejected — the ledger refused the document. The reason is shown exactly as it came back, and pressing Post again will not help until the underlying data is corrected.
5. 5Skipped — the document cannot be posted as it stands: a draft, or one that has been cancelled.

The tokens are deleted and QUOMODA stops pushing immediately — but the record of what already reached your ledger is kept. That record is what stops a later reconnect from re-creating every invoice you already have in your books, so it is never deleted.

If you only want to stop temporarily, use Pause instead: it keeps the connection, the mapping and the record intact.