All articles

Design and ERP integration: a checklist before connecting the systems

An integration is reliable when product codes, revisions and ownership are agreed before the first automated exchange.

Two monitors connecting retail fixture design to structured material data

Connecting design software to an ERP can remove repeated data entry and shorten the path from quote to production. But a technical connection alone does not guarantee reliable information. If the two systems disagree about codes, units or revisions, automation simply moves the inconsistency faster.

Before building the exchange, align the process that the integration is expected to support.

Define the source of each field

Not every system should own every piece of information. Product geometry and configuration rules may begin in the design environment, while prices, taxes, inventory and commercial status remain in the ERP.

Create a field map that answers three questions:

  1. Where is this value created?
  2. Which system is allowed to change it?
  3. What happens when the value is missing or invalid?

This avoids silent overwrites and makes error handling part of the design rather than an afterthought.

Confirm identifiers and units

The item code is the bridge between the configured product and the administrative record. Test codes with leading zeroes, suffixes, inactive items and replacements. Confirm whether quantities can be fractional and which unit each system expects.

A small difference—millimeters in one system and meters in another, for example—can affect every line in a bill of materials.

Decide what a revision means

A customer change may alter the layout, the bill of materials, the quote or all three. Define when a project becomes a new revision, whether an approved quote can be overwritten and how users identify the latest valid version.

Keep a reference that connects the drawing, exported bill of materials and ERP document. Without that relationship, teams can still manufacture from an old revision even when the transfer itself worked correctly.

Test real exceptions

Happy-path tests are not enough. Include:

  • an unknown or inactive product code;
  • a required finish with no ERP equivalent;
  • the same project exported twice;
  • a revised project with removed items;
  • a temporary communication failure;
  • a partial result that must not be accepted as complete.

For each case, decide what the user sees and who is responsible for resolving it.

Start with a controlled handoff

Run the first projects with a visible comparison between the WBCcad bill of materials and the ERP result. The goal is not to keep a permanent manual check, but to prove that mapping, quantities and revisions behave as agreed.

Once the pilot is stable, expand by product family or business unit. A gradual rollout protects daily operations and produces clear evidence of which rules are ready to scale.

A good integration does not hide the process. It gives every team the same traceable version of the project and makes exceptions visible before they reach production.

Want to see this with your catalog?

We'll show you WBCcad with a real product from your company.

Talk to Workbench