Shopify ERP and Accounting Integration

Every field needs one writer. The ERP usually owns item masters and cost, the store owns merchandising copy and images, and one side owns the sell price. Stock can be owned by the ERP with a buffer pushed to the store, or by the store with reservations posted back, but not both at once.

Write the ownership table on one page and make both teams sign it. The table names the system of record, the update frequency and the person who resolves an exception. Most arguments about integration cost disappear when that page exists, because the argument was never technical.

Variants are where catalogues break. A product with three options can become dozens of SKUs, and a bundle can hide components the ERP needs to reserve. Units of measure, tax classes and custom items have to map one to one, with a rule for anything that cannot.

We build the mapping from an export rather than a sample of ten products. Duplicate detection runs on SKU plus variant identity, and a product that fails validation goes to an exception queue instead of being created twice. Images and descriptions stay on the store; the ERP receives only what it needs to sell, stock and account for the item.

A timeout does not mean the order failed. The store retries, and without idempotency the ERP creates a second sales order. We key every import on the store order identifier, keep a local record of processed events, and reject a repeat before it touches the ledger.

Status vocabularies also differ. Paid, authorised, fulfilled, partially fulfilled, cancelled and refunded do not map cleanly to an ERP's order states. We write the translation explicitly, decide when an invoice is raised, and handle a cancellation that arrives after the invoice exists. Partial fulfilment and split shipments are tested rather than assumed.

A stock push every fifteen minutes cannot protect the last unit in a flash sale. High-velocity channels need a reservation or a buffer, even when the ERP remains the source of truth. We agree the buffer per location and the rule for releasing it when an order is cancelled.

Returns complicate the picture because a refund, a restock and a ledger entry are three events. The integration has to say whether returned goods become sellable immediately, after inspection, or never. Multi-location stores need availability per location rather than one pooled number.

A daily report is more useful than a live dashboard nobody opens. We produce counts of orders imported, invoices raised, payments matched, stock adjustments and exceptions, with a link to the underlying record for each failure. The accounts team gets a short list to clear, not a wall of logs.

Settlement reconciliation compares what the payment provider paid, what the store recorded and what the ERP invoiced. Fees, refunds and chargebacks make those three numbers differ legitimately, so the report explains the difference instead of flagging every row. That is the difference between reconciliation and noise.

The first symptom is price flicker: a merchandiser changes a price in the store, the ERP pushes its own overnight, and the customer sees a different number the next morning. The second is negative stock, because two systems each believed they had the last unit. The third is a duplicate item created by an import that could not match an existing code.

There is also the deleted-SKU problem. Archiving an item in the ERP can orphan historical orders in the store, while deleting it in the store can break a return months later. We keep a tombstone record and never reuse a SKU, which preserves the audit trail both sides need.

The build is not the end of the cost. Channels change APIs, tax rules move and catalogues grow, so the mapping needs an owner and a review cadence. We document the mapping tables, the retry policy and the exception queue so an internal team can make routine changes.

A support arrangement covers monitoring, failed-event alerts and small mapping updates. It is usually cheaper than a rebuild, because the expensive part of an integration is the knowledge of which field belongs to whom.