The Customer and Company Model
This article explains how Norce Commerce models customer and company data, how the two entities relate, and what integrators need to know to import and maintain them correctly.
Two Entities: Customer and Company
Norce Commerce uses two separate entities to represent the people and organizations that buy from your store.
| Entity | Represents | Unique identifier |
|---|---|---|
| Customer | An individual person — a B2C buyer or a contact at a company | EmailAddress (default lookup) |
| Company | An organization — a business, division, department, or business unit | VATNumber / OrganizationNo (default lookup) |
A B2C order has a Customer and no Company. A B2B order has both — the Customer is the contact person placing the order on behalf of the Company.
The same Customer can do both. A person can place an order as a private individual and later place an order as a contact for a company. Norce supports this without needing two separate customer records.
The Customer Model
Roles
A Customer in Norce Commerce serves two roles depending on the order:
- B2C buyer: The customer is the end buyer. No company is involved.
- B2B contact: The customer is a contact person associated with one or more companies. The company is the buyer; the customer represents who placed the order.
Customer ↔ Company: Many-to-Many
The relationship between Customer and Company is many-to-many. A customer can be linked to multiple companies — one marked as their primary company (e.g. their employer), plus others they are allowed to purchase on behalf of (e.g. client projects as a contractor). A company has many customers (contacts).
Built-in Fields
The table below lists the commonly used fields. See the full Customer schema for a complete reference.
| Field | Notes |
|---|---|
EmailAddress | Unique identifier; default lookup key |
Code | External identifier — typically the ERP or CRM customer number |
FirstName, LastName | |
InvoiceAddress | One per customer |
DeliveryAddresses | Multiple allowed |
Flags | Boolean tags for segmentation (see below) |
PriceLists | Optional; for loyalty-based or custom pricing |
Accounts | Optional login credentials per application |
AdditionalInfo | InfoTypes — extensible custom fields |
Customer Flags
Customer flags work like product flags but on the customer register. Use them for:
- Loyalty segmentation (Gold / Silver / Bronze)
- Interest or preference tagging
- Campaign targeting — flags can be used as conditions in Norce campaign functionality
Price Lists
Customers can be linked to specific price lists, giving them access to custom prices or restricted assortments when they identify themselves. Less common than company price lists, but useful for loyalty programs.
Accounts
Accounts are Norce's built-in login mechanism. An account is tied to a specific application and holds a login name, role, and hashed password. This is optional — many solutions use a third-party identity provider instead. When using third-party auth, the authenticated user's email address or customer code is used to look up the correct customer in Norce after login.
InfoTypes (AdditionalInfo)
The customer model can be extended with custom fields via InfoTypes (called AdditionalInfo in the Connect contract). Examples: clothing sizes, delivery preferences, opt-in flags for personalisation. These can be imported and maintained via ImportCustomers.
The Company Model
Built-in Fields
The table below lists the commonly used fields. See the full Company schema for a complete reference.
| Field | Notes |
|---|---|
VATNumber / OrganizationNo | Unique identifier; default lookup key |
Code | External identifier — typically the ERP company/customer number |
Name | |
InvoiceAddress | One per company |
VisitAddress | One per company |
DeliveryAddresses | Multiple allowed |
ParentCompanyCode | Optional; for hierarchy (see below) |
Flags | Boolean tags for segmentation |
PriceLists | Common in B2B for contract prices and restricted assortments |
CompanyDiscounts | Real-time discount rules applied on top of price list |
DeliveryMethods | Optional company-specific delivery options |
PaymentMethods | Optional company-specific payment options |
AdditionalInfo | InfoTypes — extensible custom fields |
Parent Company Hierarchy
Norce supports a parent-child hierarchy between companies via ParentCompanyCode. This is a structural model only — there is no automatic inheritance of prices, discounts, or settings between parent and child. Use it to represent organizational structures (holding company → subsidiaries) that your storefront or integration logic can act on.
Price Lists and Assortments
Company price lists are common in B2B. They serve two purposes:
- Customer-unique prices: The company sees prices from its contracted price list rather than the standard price list.
- Customer-unique assortment: Certain products are only visible or purchasable for specific companies.
Important: Price lists must exist in Norce before they can be linked to a company. Create them via the Management API first, then reference them by code in
ImportCompanies.
Company Discounts
Company discounts are category- or flag-based discount rules applied on top of the price list, calculated in real time at checkout. They are not stored as explicit prices and do not appear in price exports. They are visible when a logged-in user fetches prices via the Query or Storefront APIs.
B2B Approval Flow
In B2B implementations, the ERP typically owns the company register (contracts, credit limits). A common pattern:
- Company is created in Norce when an organization registers on the storefront.
- Integration sends the new company to the ERP for approval.
- ERP returns the
CompanyCodeand a verification flag (e.g. "approved to buy on contract"). - Integration updates the company in Norce via
ImportCompanieswith the ERP code and any linked price lists.
Until the ERP code is set and the company is approved, they cannot purchase on contract terms.
Identification and Lookup Keys
Customer
Norce looks up existing customers by EmailAddress by default. If a customer is imported with an email address that already exists, Norce updates the existing record rather than creating a duplicate.
Code (CustomerCode) is the external identifier — the number assigned by the CRM or ERP that owns the customer register. This must be globally unique across all applications regardless of the application-unique setting (see below).
Company
Norce looks up existing companies by VATNumber (also called OrganizationNo). Code (CompanyCode) must also be unique and is used as the external identifier from the ERP or CRM.
Application-Unique vs Client-Unique
The customer and company register lives at the client level — accessible across all applications by default. However, you can configure customers and companies to be unique per application in the client settings.
| Setting | Behavior |
|---|---|
| Client-unique (default) | One shared register. An email or VAT number matches the same customer/company regardless of which application the request comes from. Use when there is one shared CRM or ERP across all applications. |
| Application-unique | Separate registers per application. The same email address can exist as different customers in different applications. Use when each application has its own CRM or customer master. |
Note: This setting applies to both Customer and Company simultaneously — you cannot have different settings for each within the same client.
Warning:
CustomerCodeandCompanyCodemust be globally unique regardless of the application-unique setting. The application-unique setting only controls whether duplicate email addresses / VAT numbers are treated as the same record across applications.
Changing the Is application unique setting on an existing client is highly destructive — it will cause existing customer and company lookups to behave differently across all applications immediately. If you believe this setting needs to change, contact Norce support rather than making the change yourself.
Importing via Connect
Both ImportCustomers and ImportCompanies are asynchronous operations — a job ID is returned for status tracking, identical to product imports.
ImportCustomers
Accepts a list of Customer objects. You can include:
- All built-in fields (name, addresses, email)
AdditionalInfo(InfoTypes / custom fields)Accounts(login credentials)- Price list codes (price lists must already exist)
- Company associations — by
CodeorId; setIsPrimaryon the primary company relationship
You cannot create companies via
ImportCustomers. Companies must already exist before linking.
ImportCompanies
Accepts a list of Company objects. You can include:
- All built-in fields (name, addresses, VAT number)
AdditionalInfo(InfoTypes / custom fields)- Price list codes (price lists must already exist)
CompanyDiscountsParentCompanyCode- Delivery method and payment method associations (must already exist)
- A full
Customerslist — you can create or update customer records inline when importing a company. This is the recommended approach when onboarding a new company and wanting to create a default admin contact in the same operation.
GDPR and Anonymization
Norce has built-in anonymization functionality that scrambles all personal data for a given customer across the entire data store — customer records, orders, and baskets. After anonymization:
- Internal IDs and relationships are preserved (so order history structure remains intact).
- All PII fields are overwritten and can no longer be read back.
Important for integrations: If an external system pushes customer data back to Norce after anonymization (e.g. a scheduled sync), the customer record will be re-populated with PII. Anonymization must be coordinated across all systems that hold customer data simultaneously. Norce does not prevent a re-import of data for an anonymized customer.
Common Pitfalls
| Pitfall | Details |
|---|---|
| CustomerCode not globally unique | Even with application-unique customers enabled, CustomerCode must be unique across the entire client. Duplicate codes cause one record to silently overwrite the other. |
| Linking to non-existent price lists | Price lists referenced in ImportCustomers or ImportCompanies must already exist. Create them via the Management API before the import. |
| Creating companies via ImportCustomers | Not possible. Companies must be created via ImportCompanies first. |
| Re-importing after anonymization | A scheduled sync from ERP can inadvertently re-populate anonymized records. Coordinate anonymization across all systems. |
| Wrong application-unique setting | Choosing application-unique when a shared CRM exists (or vice versa) causes duplicate records or unexpected merging. Align the setting with your system landscape before the first import. |
Further Reading
- Customer and Company Integrations — integration patterns and flows
- ImportCustomers API reference
- ImportCompanies API reference
- Metadata Integrations — creating price lists via the Management API
- Calling Norce Commerce Connect
- Calling Norce Commerce Query