Scale your business

Connect your ERP

Products, prices, stock, customers, orders: in the right direction, at the right cadence, with one owner per field.

Your ERP has run the company for fifteen years. Everybody trusts it, everybody works around its edges, and nobody has written down what it owns. Now a commerce project needs it to hand over products, prices and stock and to accept orders back. The honest summary is that the ERP sets the timeline and decides whether the project works. This page is for the company doing it for the first time: an Innendienst-led business, no internal development team, one ERP partner on a day rate.

Why this is harder than it sounds

The first surprise is that "the ERP" is not one system. It is an ERP, plus a warehouse module somebody bolted on, plus a CRM with the real contact data, plus a spreadsheet of conditions on the sales manager's drive, plus an Access database holding packaging units because the ERP could not. Every one of those is a source, and you will find the last two mid-project, from someone who assumed you knew.

The second is that the central decision is organisational: who may change which field. Most fields exist in two or three places; the question is which system is allowed to write. Two systems writing the same field is the defect that never gets diagnosed: both sides work correctly and the value keeps changing back overnight. Write the ownership down, field by field, before anyone connects anything. It is an afternoon's work now and a fortnight's forensics later.

Third: cadence is decided per data type. One nightly job for everything is the default that breaks the shop, because the two figures customers judge you on are the two that cannot be a day old.

FlowDirectionCadence that worksWhy
OrdersShop → ERPImmediate, with a retryThe customer has been told it is confirmed; the promise is already made
StockERP → ShopLive query, or minutesA stock figure is a promise. Yesterday's promise is not one
PricesERP → ShopLive for customer conditions; batch for list pricesA wrong price loses the customer permanently, not for one order
ProductsERP or PIM → ShopNightly is fineDescriptions and weights do not change hourly
Customer masterERP ↔ ShopNightly, one direction, decided explicitlyThe most tempting field to write from both sides, and the worst one to
DocumentsERP → ShopNightlyInvoices and delivery notes are self-service, not real time
Buy the connection, do not build it. Hand-written middleware costs at the build and again at every ERP release, forever, and it ends up maintained by the one contractor who understands it. Use the platform's connectors, its file exchange and its workflow tooling, and keep custom code for the exceptions your business has. If you are writing code to move a field from A to B, stop and check whether a mapping already does it.

Fourth: your ERP was not designed to be read by a shop. Expect article numbers with leading zeros that a spreadsheet has eaten, sales units that differ from base units (you sell a box of 100, the ERP counts pieces), unit codes that match no standard, and condition tables with more layers than anyone remembers. None of it is exotic. All of it costs days.

Fifth, a scheduling reality: your ERP partner has a queue and a day rate, and everything on their side is a request rather than a task you control. Book them early, with a written specification, and do not plan a go-live around a slot you have not been given.

And last, the thing that decides whether the integration survives its first year: somebody has to own it after go-live. Feeds break, and they break without a sound. If nobody is named, the first person to notice is a customer.

The levers

Write down who owns which field

What good looks like: a table (field, owning system, direction, cadence) covering products, prices, stock, customers, orders and documents. Every row has exactly one owner, and where two systems both want to write, that is resolved on paper rather than by the integration.

What it depends on: getting sales, warehouse and finance into one room once. They will disagree, and the disagreement is the useful output.

  1. Deciding your system of record
  2. Integration patterns
  3. The catalog data model
  4. Prices and your ERP
  5. Field mapping

Choose a cadence per data type, and a route per system

What good looks like: each flow has a stated cadence and a stated mechanism (an API call, a webhook, a scheduled job, or a file drop for the ERP that only speaks CSV), chosen for what the data is for rather than for what was easiest to build.

What it depends on: knowing what your ERP can offer. Some have a usable API, some a nightly export and nothing else. That constraint shapes the whole design and belongs in week one.

  1. Integration patterns
  2. The platform's interfaces, in one map
  3. SFTP and file exchange
  4. Events and webhooks
  5. Build a workflow

Build it in a sandbox, with credentials that are scoped

What good looks like: the integrator works against a tenant you can break, with seeded data that resembles production and an API key scoped to the flows they are building. Nothing is tested for the first time against live customer data.

What it depends on: provisioning the sandbox before the integrator starts, rather than when they ask. It is the cheapest schedule saving in the project.

  1. The sandbox
  2. Set up a sandbox
  3. Keys, scopes and tenants
  4. Create an API key
  5. Connect a system
  6. Common API tasks, by job

Run it: monitor, reconcile, and name an owner

What good looks like: every flow has a last-successful-run you can see, a failure alerts a named person, and a weekly reconciliation compares what the shop sent with what the ERP received.

What it depends on: treating the integration as an operated service rather than a finished project. That is the difference between a connection that lasts and one that degrades until somebody rebuilds it.

  1. Monitor your syncs
  2. Common sync errors
  3. Monitor your integrations
  4. Reconcile with your ERP
  5. Orders that get stuck
  6. Test an integration end to end

A sensible order

First, a distinction: the initial load of products and the first price list is an import. Getting 8,000 articles in once from a file is a data-preparation task with a clear end; do not let it become your first interface. See Prepare your import file and Import products in bulk.

Phase 1: orders out. The first interface you build is the shop writing orders into the ERP. It runs in one direction, it has an unambiguous test (place an order, find the same order in the ERP with the same lines, units and net value), and it removes the manual step with the highest cost and error rate. Everything else can be maintained by hand for a while; retyping orders cannot. Depends on the sandbox, the unit conventions being agreed, and a decision on what happens when a write fails: a queue, a retry, and a named person who is told.

Phase 2: stock in, then prices in. Stock first: it is a read, it is simple, and it is the figure that decides whether buyers trust the channel. Prices second, because that flow carries the most business logic (condition layers, scales, validity dates, customer-specific entries) and an error there is the most expensive one available. Do not begin prices until the ownership table says which conditions the ERP owns and which the platform may hold. Depends on Phase 1 having proved the connection, the credentials and the monitoring on a flow you can verify one record at a time.

Phase 3: customer master, documents and the return path. The customer master goes last, even though it is what everyone wants to start with: matching your ERP's customer numbers to the organisations and contacts in the platform is a master-data migration, with duplicates, dead accounts and shared logins in it. Alongside it, invoices and delivery notes into self-service and dispatch data back to the customer. Depends on Phase 2, and on somebody owning master-data hygiene afterwards.

Common mistakes

  • Starting with the customer master. It feels like the foundation and it is a migration. Start with orders out.
  • One nightly job for everything. The cheapest design, and it makes stock and prices wrong at exactly the moments they matter.
  • Two systems writing the same field. Nobody diagnoses this. It looks like a ghost.
  • Building custom middleware. It costs at the build and again at every ERP update, and it depends on one person.
  • Planning the go-live before the ERP partner has given you a slot. Their queue sets your date.
  • No owner after go-live. Feeds fail without a sound, and the first report comes from a customer who has already phoned a competitor.

How you know it is working

  • Share of orders reaching the ERP without a human touching them. The headline metric here, and the one the business case rests on.
  • Time from order placed to order present in the ERP. Watch the tail rather than the average; the slow ones carry the problems.
  • Failed sync runs per week, and time-to-notice. The second matters more. If it is measured in days, the monitoring is decorative.
  • Price mismatches reported by customers. Any at all means a condition layer is not being read; see Common pricing problems.
  • Oversells caused by stale stock. The direct measure of whether the stock cadence is right.
  • Fields with more than one writer. The target is zero, and the count exists only if you wrote the ownership table.

Related goals

What you're building

Six flows between the ERP and the platform, each with one owner, one direction and its own cadence. Orders leave the platform the moment they are placed and arrive in the ERP with a retry behind them; stock and contract prices come in often enough to be trusted; products, customer master and documents come in nightly. Every flow is a workflow or an import profile in Integration Studio with a visible run history and a named person who is alerted when it fails.

flowchart LR
  ERP["Your ERP, WMS, CRM"]
  SFTP["SFTP drop for CSV-only systems"]
  subgraph IS["Integration Studio"]
    WF["Workflows and import profiles"]
    EV["Events and webhooks"]
    RUN["Runs and alerts"]
  end
  subgraph CS["Commerce Studio"]
    P["Products"]
    PR["Prices: lists and entries"]
    INV["Inventories: stock levels"]
    C["Customers: organizations, contacts"]
    O["Orders"]
  end
  subgraph XS["Experience Studio"]
    SF["Storefront"]
    DOC["Documents and messaging"]
  end
  ERP -- "articles, nightly" --> WF
  ERP -- "stock, minutes" --> WF
  ERP -- "conditions, hourly to daily" --> WF
  ERP -- "customer master, nightly" --> WF
  ERP -- "invoices, delivery notes" --> WF
  SFTP --> WF
  WF --> P
  WF --> PR
  WF --> INV
  WF --> C
  WF --> DOC
  SF -- "order placed" --> O
  O -- "event" --> EV
  EV -- "order, immediate with retry" --> WF
  WF -- "order" --> ERP
  WF --> RUN

What you need

Build it

  1. List every source system and write the ownership table, field by field — Deciding your system of record
  2. Agree article-number formats, customer-number matching, sales units and unit codes with whoever runs the ERP — Field mapping
  3. Choose the route per flow from what the ERP offers: API, webhook, schedule or file drop — Integration patterns
  4. Provision the sandbox and create an API key scoped to the first flow — Create an API key
  5. Load products and the first price list once, from a prepared file — Prepare your import file
  6. Store the ERP connection and its credentials — Credentials
  7. Build the orders-out workflow: order placed event, mapping, write to ERP, retry, alert — Build a workflow
  8. Test it: place an order in the sandbox, find it in the ERP line by line — Test an integration end to end
  9. Build the stock flow on a schedule or a live query, and check it against the warehouse — Stock accuracy
  10. Build the price flow: list prices in batch, contract conditions as price entries per organisation — Import prices in bulk
  11. Watch the run list and route failures to the named owner — Runs
  12. Match the ERP customer numbers to organisations and contacts, one direction, nightly — Organizations
  13. Bring invoices, delivery notes and dispatch data across for self-service — Reconcile with your ERP
  14. Run the weekly reconciliation and retest after every ERP release — Common sync errors

Decisions you'll need to make

DecisionThe trade-offWhere most customers land
API, file exchange or a connector? Call the ERP's API, drop files on the platform's SFTP server, or use a prebuilt connector where one exists for your ERP.An API gives you minutes-old data and needs an ERP that has one. Files are what every ERP can do and are never fresher than the schedule. A connector saves the mapping work and ties you to its field model.Files via SFTP for products, list prices and documents; API or webhook for orders and stock; a connector wherever one exists for the ERP in use. The route is decided per flow, never per project.
Who owns the customer master? The ERP, the platform, or split.The ERP knows customer numbers, terms and credit limits and has no per-person model. The platform needs contacts and roles the ERP cannot hold. Writing from both sides is the ghost defect.The ERP owns the organisation, its number, terms and credit; the platform owns contacts, roles and the approval limit per contact. Flow is one direction, ERP to platform, nightly. New self-registered organisations go back to the ERP as a manual or scheduled step, never live in both.
Where are prices calculated? The platform prices from its own lists, conditions are synced in as price entries, or the ERP's pricing routine is called at render time.Synced entries are fast and can be minutes to a day stale. A live call is always current and makes page speed depend on the ERP being up.Conditions synced into price lists and price entries, hourly to daily, with an event-driven update when a condition changes. A live ERP call stays reserved for configure-to-order cases where no list can hold the answer.
What happens when an order write fails? Retry until it works, hold the order, or hand it to a person.Silent retries hide a broken ERP for days. Holding the order contradicts the confirmation the buyer already has.Retry automatically for a bounded period, alert a named person on the first failure, and keep the order confirmed to the customer throughout. The buyer never sees the retry.
Who owns the integration after go-live? The ERP partner, an internal colleague, or a platform partner on retainer.The ERP partner knows the ERP and not the platform. An internal owner knows the business and is one person. A retainer costs money every month.A named internal owner who reads the run list daily, plus the ERP partner on a retainer for releases. The internal name is what makes failures get noticed; the retainer is what makes them get fixed.

Related product areas

Consolidate systems

Fewer moving parts, fewer licences, fewer integrations to keep alive.

Reduce manual work

From order intake to ERP without anyone retyping anything.