Bringing existing customers into the B2B shop from the ERP

Anyone launching a B2B shop rarely starts with an empty customer base. The business customers have been in the ERP for years, with a debtor number, terms and delivery addresses – they just do not exist in the shop yet. The web channel has long been a channel for business customers: 33.80% of German wholesale enterprises with 10 or more employees sold to other businesses or public bodies via websites, apps or marketplaces in 2024 (Eurostat). This guide shows how to bring existing customers into the B2B shop without making them register a second time, and how to measure activation stage by stage. How registration works for unknown companies, including verification of business status, is covered in our article on B2B onboarding with business verification. This one is about the customers you already know.

Why existing customers should not register again

The obvious route is a circular: “Our new shop is live, please register.” For companies you have supplied for years, that is a detour with consequences. The data the customer types into the form has long been in the ERP, just spelled differently. Duplicates appear that someone later has to match to the right debtor number by hand. And anyone who registers in Shopware through the form of a dedicated customer group does not land there right away: the customer is not assigned to the customer group directly, an approval is required (Shopware documentation). For new customers, this check makes sense. For a regular customer with a running framework agreement, it is a waiting period that tells you nothing new.

The European survey on ICT usage in enterprises shows how widely wholesalers already use their own web channel. 32.75% of German wholesale enterprises with 10 or more employees sold via their own website or app in 2024 (Eurostat). In the same year, 80.78% of the web sales turnover of wholesale enterprises with 10 or more employees came from businesses and public bodies (Eurostat). The wholesale web channel is therefore mainly a channel for business and public-sector buyers, and the seller already knows many of them from existing sales.

Which debtors belong in the shop

Not every debtor is a candidate for a shop account. Over the years, an ERP collects one-time customers, blocked accounts, debtors for credit notes and internal clearing accounts. Importing everything loads dead records into the shop and later sends invitations to companies that no longer exist. Selection therefore starts with a list that sales and accounting go through together, and with rules that can be expressed as filters in the ERP.

• Active customers: debtors with sales within a period that sales and accounting define together.
• Blocks and dunning levels: accounts with a delivery block or an open dunning notice get no shop account for now, or one in which only prepayment is available.
• EDI customers: anyone who already orders straight into the ERP via EDI tends to use the shop for spare parts, samples or small quantities.
• Collective debtors: accounts for walk-in and cash sales are a bookkeeping aid and do not belong in the shop.
• Branches and groups: several debtors with the same company but their own delivery address and their own billing unit need a decision on whether they get a shared shop account or separate ones.

The EDI point is not a corner case. 18.07% of German wholesale enterprises with 10 or more employees had EDI-type sales in 2024 (Eurostat), and these sales accounted for 14.64% of the total turnover of all wholesale enterprises of that size (Eurostat). Customers who order like this have already automated their process. An invitation to the shop is an additional offer for them, not a replacement, and it should be worded accordingly.

Data quality: what the customer base needs before the import

An ERP is built for invoices, not for logins. The e-mail address shows this. The debtor record often holds a shared accounting address for sending invoices, and for purchasing a person who left long ago. Shopware logs customers in by their e-mail address, and the source code states that real customer accounts should only occur once per address (Shopware source code). An address that appears on three debtors therefore leads to a decision, not to three accounts.

• One contact person per debtor with a personal e-mail address for orders, separate from the address used for invoices.
• Resolve duplicates: the same company under two debtor numbers, the same e-mail address on several accounts.
• Billing and delivery addresses in separate fields, consistent country values, postal codes without extra text.
• VAT IDs in a consistent format with the country prefix and without spaces.
• Treat customer numbers as text so that leading zeros are preserved.
• Map each debtor’s price group and payment terms to the customer groups and payment methods of the shop.

The point about leading zeros sounds trivial and can cost an entire import run. The Shopware documentation notes that some spreadsheet programs change separators or leading zeros in CSV files (Shopware documentation). Debtor number 0012045 then becomes 12045, and the sync with the ERP no longer finds the customer. The import file should therefore be produced directly from the ERP or from a script.

Data protection also argues for a lean takeover. Personal data must be adequate, relevant and limited to what is necessary for the purpose (GDPR Art. 5(1)(c)). For a shop account, that means the name and business e-mail address of the person ordering, addresses and terms. Dates of birth, private phone numbers or notes from sales stay in the ERP. The data must also be accurate and, where necessary, kept up to date (GDPR Art. 5(1)(d)). That is another reason to review the contact persons before the import.

From debtor to customer account: the field mapping

For the import, Shopware sets a minimum requirement: a customer profile can only be saved if it contains seven required fields, namely id, defaultBillingAddressId, defaultShippingAddressId, customerNumber, firstName, lastName and email (Shopware documentation). The id may stay empty for new records because the system assigns it (Shopware documentation). Everything else is a question of mapping: which ERP field ends up in which shop field, and where is a translation needed because the ERP knows a price group and the shop a customer group?

Two rows of the table deserve a second look. In Shopware, the customer group determines, among other things, whether a customer sees net or gross prices (Shopware documentation). Payment terms have no fixed counterpart on the customer in the shop. Instead, the availability rule of a payment method determines when it is available (Shopware documentation). A tag “invoice payment approved” on the customer account and a matching rule reproduce the payment terms from the ERP. How invoice payment and credit limits can be controlled is shown in our article on purchase on account in the B2B shop. We describe the connection of the systems themselves on our pages about SAP Business One, Microsoft Dynamics and JTL-Wawi.

# Mapping ERP debtor to shop customer (example, custom import script)
source: erp.debtors
selection:
  status: active
  delivery_block: no
  collective_debtor: no
fields:
  customerNumber: debtor_no           # as text, leading zeros stay
  accountType: business
  company: company_name
  vatIds: [vat_id]
  firstName: contact.first_name
  lastName: contact.last_name
  email: contact.purchasing_mail
  groupId: price_group -> customer_group
  tags: payment_terms -> tag
  password: null                      # set by the customer
before_run:
  mail_delivery: off
  test_run: yes

One login per contact person or a company account

In B2B, it is rare for only one person to order. Purchasing, the workshop and branch management use the same terms, and the invoice still goes to head office. In standard Shopware, a customer account is one login with one e-mail address and one customer number. There are two clean ways to handle several people per company, and which one fits depends on the size and organization of the customer.

The decision is made before the import, because anyone who later switches from individual accounts to company accounts has to move orders and addresses. Sellers with separate shops for consumers and business customers can also bind customers to a sales channel (Shopware documentation). The same e-mail address can then belong to separate accounts in both shops.

The import: test run, mail delivery and repeatability

For a one-off takeover, the Import/Export module in the administration is enough in many cases (Shopware documentation). Tags and custom fields are not part of the default customer profile and need a profile of their own. For an ongoing sync, the takeover belongs in the ERP integration so that new debtors get an account without manual work. Large volumes then run through the shop’s API instead of CSV files. How a bulk import from the ERP with the Shopware Sync API is set up is described by our ERP integration agency in its article on bulk import via the Sync API. Both routes share the same precautions.

1. Test environment: the documentation recommends checking an import in the staging system first and creating a database backup before importing into the live system (Shopware documentation). Restrict access and mail delivery of the copy as described in our article on Shopware staging without real customer data.
2. Test run: it performs the same steps as the import but writes no data to the database tables (Shopware documentation).
3. Evaluate the error file: Shopware collects faulty records in a separate CSV file with a column for the reason (Shopware documentation). Corrections are made at the source in the ERP.
4. Import in waves: first a small group of well-known customers, then the rest.
5. Reconcile: count accounts and customer numbers against the selection in the ERP, then switch mail delivery back on.

One property of the module shapes the planning: the import can only add information, not remove it (Shopware documentation). A wrongly assigned customer group is fixed by a second run. A wrongly created account or a surplus address does not disappear that way. For corrections to many accounts at once, such as customer group, active status or tags, the administration also offers bulk edit for customers (Shopware source code). How it works for orders is shown in our article on bulk edit after sales events.

Passwords: why migrated accounts start without one

An ERP knows no shop passwords. The obvious shortcut would be to generate a password for each account and send it by e-mail. We advise against that: the password then sits in the mailbox, often a shared mailbox of the purchasing department, and it frequently stays unchanged afterwards. An account without a password is the better choice. Shopware does not allow such an account to log in as long as no password is set (Shopware source code). How shops protect themselves against abusive login attempts is covered in our article on defending against account takeover.

The situation is different when customers come from an old shop that stored password hashes. For this case, the customer profile has the fields legacyPassword for a foreign, encrypted password and legacyEncoder for the matching method (Shopware documentation). In its core, Shopware ships methods for MD5 and SHA-256 (Shopware source code). When a customer logs in with the old password, Shopware checks it with the named method, then stores it in its own format and clears both legacy fields (Shopware source code). Other methods need a custom encoder. Which other pitfalls a shop switch involves is shown in our guide to migrating from WooCommerce to Shopware.

The invitation: set a password instead of sending one

In Shopware, the way to the first password leads through password recovery. It has a property that is easily overlooked in an invitation: the link in it is valid for 2 hours from its creation (Shopware source code). For a customer who clicks “forgot password” and opens the mail right away, that fits. An invitation to the customer base, on the other hand, is often opened the next morning, after a vacation or after being forwarded by head office. A mass mailing of recovery links therefore often misses its mark, and the customer sees an error message instead of a form.

The second variant needs no development: the invitation leads to the page where the customer requests the link for setting a password themselves. The link is then fresh when it is needed. The third variant is more convenient because one click is enough. The rules of any access link apply to it: random, single use, with an expiry date and without a plain-text password. Only an active account can request the link (Shopware source code), so debtors created as inactive stay out until they are activated. In both cases, the invitation should come from a sender the customer knows, such as the responsible person in sales.

• What changes: the shop complements phone, fax and field sales, it does not replace them.
• What is already set up: customer number, addresses and terms have been taken over, nothing needs to be entered again.
• What the customer has to do: set a password once, via “forgot password”.
• Who helps: a contact person with a direct line, not a general support address.
• Who the mail is for: the person who orders, not the accounting mailbox.

Legal framework: invitation mail and data protection

Whether an invitation to the shop counts as advertising depends on its content. A mail mainly intended to encourage orders in the new shop is close to advertising. For advertising by e-mail, the UWG generally requires the prior express consent of the recipient (Section 7(2) no. 2 UWG), and this also applies to businesses. For existing customers, there is an exception that depends on four conditions: the address comes from a sale, it is used for the seller’s own similar goods or services, the customer has not objected, and the customer is clearly informed of the right to object when the address is collected and each time it is used (Section 7(3) UWG). Factual information about a new ordering route is to be assessed differently from an advertising mailing with promotional offers.

Under data protection law, taking over contact persons is usually based on legitimate interests. Processing is then lawful insofar as it is necessary for the purposes of the legitimate interests of the controller and the interests of the data subject do not override them (GDPR Art. 6(1)(f)). The contact person is usually not a contracting party themselves but an employee of the customer. The balancing of interests therefore belongs in the documentation, and the shop’s privacy notice should mention the takeover from the existing customer relationship.

Measuring activation: one rate per stage

A takeover is not finished when the accounts have been created, but when customers order in the shop. In between lie five stages, which the graphic above shows as a funnel: debtors in the ERP, accounts created, invitations sent, activated accounts and first orders. Each stage has its own rate, and each rate relates to the stage before. The measurement thus shows where customers drop out. We deliberately give no values: they depend on the industry, customer structure and invitation.

The data for this is already in the shop. For the customer object type, Import/Export offers the fields last login, number of orders and date of the last order (Shopware documentation), though only in an export profile of your own. Shopware rewrites the last login with every login (Shopware source code). A weekly export, linked to the selection from the ERP via the customer number, yields the rates without additional tracking, evaluated separately per wave.

Following up: when customers do not activate

Some customers do not activate their account after the first invitation, often a question of timing or recipient. The rates per wave show where follow-up is needed, and the customer number shows who in sales is responsible. Follow-up works when the first contact in the shop brings a benefit that phone and fax do not offer: a reorder from the order history, an order list for recurring items or entry by item number, as we describe in our article on quick order for regular customers.

• Reminder: a second, shorter mail to those in a wave who have not activated.
• Call from inside sales: for important customers, with help with the first login.
• Note on documents: a sentence about the shop on order confirmations and invoices.
• Check the address: evaluate bounces and correct the contact person in the ERP.

New debtors keep appearing in the ERP after the takeover. An ongoing sync in the integration writes them to the shop without a new import run and passes orders back to the ERP with the correct debtor number. How such an integration is set up is described in our article on ERP integration of Shopware with SAP and Microsoft Dynamics.

How we support the takeover

Taking over existing customers combines three disciplines: data maintenance in the ERP, configuration and extension of the shop, and communication with customers. We support all three, as part of a B2B shop project or as a separate project for an existing shop. The basis is usually Shopware, which we use as a Shopware agency to build B2B shops.