A B2B customer account often represents an organization rather than one individual. Several people may purchase for the same company, while each person needs different access to products, prices, locations, orders, invoices, and administrative tools.
One buyer may place routine orders for a single branch. Another may approve purchases across several locations. A finance employee may need invoices without access to product pricing. A company administrator may need to invite colleagues and manage their permissions.
Supporting those relationships requires more than adding several usernames to one customer record. The organization needs a clear model for companies, locations, users, roles, purchasing rules, and system ownership.
Many B2B ecommerce platforms now provide useful building blocks for company accounts and permissions. The harder work is determining how those capabilities should reflect the way your customers actually operate.
Start With a Clear Account Model
Before selecting features or configuring the platform, define what each part of the customer relationship represents.
Company
The parent customer organization. It may hold broad commercial information such as contracts, credit relationships, or account status.
Division or subsidiary
A business unit within the broader organization that may have its own users, purchasing rules, or reporting requirements.
Location
A branch, facility, bill-to account, ship-to account, job site, or other entity where commercial settings may differ.
User
An individual acting on behalf of one or more companies or locations.
Role
A collection of permissions that determines what a user may see and do.
Relationship
The connection between a user and a company, division, or location. The same person may have a different role in each relationship.
This distinction matters because important rules may apply at different levels. Pricing could belong to the parent company, while shipping methods and tax settings vary by location. A user may be allowed to place orders for one branch but only view invoices for another.
Defining the hierarchy early helps prevent the platform, ERP, CRM, and internal teams from using the word “account” to mean different things.
Decide How Users Join a Company
Registration is only one part of granting company access. The process should also confirm the user’s identity, associate the person with the correct organization, and assign appropriate permissions.
Common access models include:
Seller-created access
The manufacturer or distributor creates the user or sends an invitation after confirming the relationship.
This provides greater control but can create more administrative work for the seller.
Customer-administered access
A verified company administrator invites colleagues and assigns approved roles or locations.
This can reduce seller involvement and help customers maintain their own teams, provided the administrative permissions are clearly defined.
Self-registration with review
A buyer requests access and provides information such as a customer number, company name, location, or business email. The seller reviews the request before granting company-specific access.
Self-registration with automated matching
The platform attempts to associate the buyer with an existing company using approved information such as an invitation code, known customer number, verified domain, or record from another system.
Automated matching can make registration faster, but it needs clear exception handling when the available information is incomplete or ambiguous.
Public purchasing with a later account upgrade
A buyer may initially purchase using public products, prices, and terms, then request access to company-specific capabilities later.
This can be useful when the business serves both known accounts and new buyers.
Do Not Rely on One Signal Alone
An email domain may help identify a user’s company, but it should not be treated as conclusive proof in every situation.
Organizations may use:
- Several approved domains
- Personal email addresses
- Franchise or subsidiary domains
- Shared service providers
- Contractors
- Acquired-company domains
- Third-party purchasing organizations
The strength of the verification process should reflect the access being granted. Viewing public products presents less risk than viewing negotiated prices, invoices, credit information, or companywide orders.
A dependable approval process may use several signals, such as:
- A company invitation
- A known customer number
- Approval from an existing administrator
- Information from the ERP or CRM
- Approved email domains
- Manual seller review
- Additional verification for sensitive permissions
Separate Identity From Authorization
Confirming that someone controls an email address does not automatically confirm that the person should have access to a company’s account.
The account process should treat these as separate decisions:
- Registration: How the user creates or receives an account.
- Authentication: How the user proves control of that identity.
- Company association: How the person is connected with the correct organization or location.
- Authorization: What the person may see and do after access is granted.
This distinction becomes especially important when a buyer changes employers, supports several companies, or retains an active login after leaving an organization.
Plan the Company-Administrator Role Carefully
Allowing customers to manage their own users can reduce administrative work and give them more control. It also creates important governance questions.
Define:
- Who becomes the first company administrator
- Who approves that assignment
- Whether the company may have more than one administrator
- Which users and locations an administrator may manage
- Which roles the administrator may assign
- Whether sensitive permission changes require seller review
- How administrator ownership is transferred
- How a locked-out company regains control
- Which changes are logged
- Which changes trigger notifications
Using one administrator for an entire company can create a continuity problem. Consider allowing a backup administrator or providing a documented seller-assisted recovery process.
Account recovery should verify the request carefully. It should not depend only on access to the former administrator’s email address or expose company information to someone whose relationship has not been confirmed.
Manage the Complete User Lifecycle
Company-account planning should cover more than adding new users. Access and responsibilities will change over time.
The lifecycle may include:
- Invitation
- Activation
- Company association
- Role assignment
- Location assignment
- Role changes
- Temporary suspension
- Company transfers
- Administrator replacement
- Account recovery
- Deactivation
- Dormant-user review
- Audit history
When an employee leaves a customer organization, access should be removed promptly. Historical orders, approvals, and account activity should usually remain connected with that person’s record for business continuity and reporting.
In other words, deactivating access is not the same as deleting business history.
Build Roles Around Real Customer Tasks
Roles should reflect what people actually need to accomplish. Avoid creating one broad “buyer” role if customer organizations require more control.
Possible roles include:
- Requester
- Buyer
- Approver
- Company administrator
- Finance user
- Accounts-payable user
- Location manager
- Service technician
- Distributor representative
- Read-only user
Permissions might control whether a user can:
- View products
- View company pricing
- Place orders
- Request quotes
- Approve purchases
- Access company credit information
- View invoices
- Manage addresses
- View other users’ orders
- Manage users
- Access selected locations
- Create saved lists
- Use purchase orders
- Review returns
- Download technical documents
A permission matrix can help the team see which capabilities belong to each role and identify combinations that may create unnecessary access.
Apply Least-Privilege Access
Users should receive the minimum access required for their responsibilities.
Not every person within the same company needs access to:
- All locations
- Every order
- Negotiated pricing
- Invoices
- Credit limits
- Tax records
- Company administration
- Other users’ personal information
Limiting access reduces security risk and creates a cleaner customer experience. A buyer serving one facility should not need to navigate information from unrelated departments or locations.
Permissions should also be reviewed when responsibilities change. Access that was appropriate when a user joined the company may no longer be appropriate several years later.
Define Order and Document Visibility
Order visibility is rarely a simple choice between “my orders” and “all company orders.”
A user may need access to:
- Only orders the user placed
- Orders for an assigned location
- Orders for a department
- Orders the user must approve
- All company orders
- Orders placed by a sales representative
- Historical orders imported from another channel
- Quotes
- Shipments
- Returns
- Invoices
- Credits
The business should also decide whether users can:
- Reorder another buyer’s purchase
- View historical prices
- Download invoices containing sensitive details
- See orders placed before their account was created
- Access an order after moving to another location
- View open orders when their own access is suspended
These are policy decisions, not simply platform settings.
Support Users With Several Companies or Locations
One person may purchase for several facilities, subsidiaries, customers, or business entities. This is common for purchasing groups, franchise operators, contractors, distributors, consultants, and corporate buyers.
The account experience should answer:
- Can one identity belong to several companies or locations?
- Does the user have a separate role in each one?
- How does the user switch between them?
- Is the active company or location always clear?
- Which prices, products, payment terms, and shipping rules change?
- How does the platform prevent an order from being submitted under the wrong account?
- What happens to a cart when the user switches context?
A clear account selector can make this easier, but authorization must also be enforced by the platform and APIs. Hiding information in the interface is not enough to protect another company’s orders or prices.
Treat Locations as More Than Addresses
A company location may represent a separate commercial relationship rather than simply another shipping destination.
Location-level settings may include:
- Billing and shipping addresses
- Tax IDs and exemptions
- Catalogs
- Pricing
- Payment terms
- Credit limits
- Purchase-order requirements
- Shipping methods
- Sales assignments
- Currency
- Language
- Inventory source
- Contract eligibility
- Approval rules
The organization should decide whether each setting belongs to the parent company, the individual location, or a combination of both.
For example, the parent organization may have one broad agreement while each facility has its own shipping addresses, buyers, tax treatment, and payment requirements.
Govern Billing and Shipping Addresses
Allowing customers to add addresses may look like a simple convenience, but the change can affect tax, freight, credit, territory assignments, and downstream records.
Define:
- Which system owns approved addresses
- Whether buyers may add temporary shipping locations
- Whether a new address requires approval
- Whether adding an address updates the ERP or CRM
- Who validates tax and freight implications
- Whether users may access only assigned locations
- How duplicate or inactive addresses are handled
- Whether project-specific destinations are allowed
- Who may change the billing address
Some organizations may permit one-time project addresses while requiring permanent locations to be approved. Others may restrict users to locations already maintained in the ERP.
The appropriate model depends on the business and the risk created by an incorrect address.
Plan Purchasing Limits and Approvals
When several people purchase for one organization, the company may need controls that reflect its internal policies.
Possible requirements include:
- Per-order spending limits
- Monthly spending limits
- Department budgets
- Required purchase-order numbers
- Product or category approvals
- Location-based approval
- Several approval levels
- Substitute approvers
- Escalation when an approver is unavailable
- Approval expiration
- Notifications and reminders
Do not assume every customer needs the same workflow. One organization may require formal approval for every order, while another may want only a companywide spending limit.
The account model should support the customers who need purchasing controls without adding unnecessary steps for those who do not.
Define Pricing and Catalog Inheritance
Company-specific pricing and product access may be assigned at several levels.
Rules may belong to:
- The parent company
- A location
- A contract
- A buying group
- An individual user
- A sales region
- A market or currency
- A combination of these factors
The business should define what happens when several rules apply.
For example:
- Does a location agreement override the parent-company catalog?
- Does a contract price override a public promotion?
- Can a user see different products when switching locations?
- What happens when a user belongs to two companies with different terms?
- Which system resolves the final price?
These rules should be understood before they are implemented. Otherwise, the storefront may display a technically valid result that does not reflect the intended commercial agreement.
Define System Ownership
An account model may work well in the storefront while creating operational problems when the same relationships cannot be represented in the ERP, CRM, identity system, or other business applications.
Identify the source of truth for:
- Companies
- Locations
- Contacts
- Customer numbers
- User-to-company relationships
- Roles and permissions
- Addresses
- Catalogs
- Pricing
- Payment terms
- Credit status
- Tax exemptions
- Orders
- Account status
For each type of information, ask:
- Which system creates the record?
- Which system owns future changes?
- How does information move between systems?
- How quickly must an update appear?
- What happens when records conflict?
- How are failures reported?
- Can an update be replayed safely?
- Who corrects the underlying data?
The ecommerce platform does not need to own every relationship. It does need a dependable way to receive and apply the information required for the customer experience.
Consider Enterprise Identity Requirements
Some larger customers may prefer to use their corporate identity provider rather than maintain another password and offboarding process.
Depending on customer demand and account risk, consider whether the experience should support:
- Single sign-on
- Federated identity
- Multi-factor authentication
- Customer-managed employee removal
- Domain-based identity discovery
- Corporate authentication policies
These capabilities are not necessary for every B2B account. They may be more appropriate for large or strategically important customers with formal security requirements.
The implementation decision should consider customer value, security, operational ownership, and support complexity.
Maintain Audit History and Notifications
High-impact account changes should be understandable after they occur.
The platform may need to record:
- Who invited a user
- Who approved the company relationship
- When a role changed
- Who added an address
- Who approved an order
- When access was suspended
- Who transferred company administration
- Which employee performed a seller-side account change
Customers may also need notifications when:
- A new administrator is assigned
- A user is added or removed
- A sensitive role changes
- A new location is approved
- A spending limit changes
- An account-recovery request is submitted
Audit information supports troubleshooting, customer confidence, and investigation of unexpected access or activity.
Design the Internal Support Experience
Complex account structures create support questions for the seller’s customer-service and ecommerce teams. Internal employees need enough information to understand what the buyer sees without bypassing controls casually.
Useful administrative tools may include:
- Search by company, location, user, or customer number
- Role and permission visibility
- Invitation management
- Account suspension and restoration
- Administrator transfer
- Approval-status review
- Integration-error visibility
- Explanations for product, order, or pricing restrictions
- Carefully controlled account emulation
- Audit logs for seller-side actions
Internal access should also follow defined permissions. Not every employee should be able to change company administrators, view credit information, or access every customer’s account.
Evaluate Standard Capabilities Before Custom Development
Many current B2B platforms provide a starting point for companies, locations, users, roles, and permissions. The available model may still require configuration, integration, extensions, or custom development to match the business.
Before customizing, evaluate:
- Standard platform capabilities
- Configuration options
- Supported extensions
- Integration requirements
- Account-model fit
- Customer-administration needs
- Permission complexity
- Audit requirements
- Migration effort
- Upgrade and maintenance cost
- Security implications
- Internal administrative effort
Custom development may be appropriate when the required workflow creates meaningful customer or business value and cannot be supported dependably another way.
The decision should include the full ownership responsibility: testing, security, documentation, support, platform upgrades, and eventual retirement.
Test Realistic Account Scenarios
Account testing should cover more than one administrator and one buyer. Use examples that reflect the complexity of real customers.
Test scenarios such as:
- A new company requesting access
- A new user joining an existing company
- A company administrator inviting a colleague
- An administrator leaving the organization
- One user working with several companies
- One company with several locations
- A buyer with limited order visibility
- An approver with a spending threshold
- An inactive company
- An expired invitation
- A suspended user attempting to sign in
- A user changing locations
- A contract-price update
- A new shipping address
- An ERP synchronization failure
- A user attempting to access another company’s order directly
Permissions should be tested at the interface, API, and server level. The system should reject unauthorized access even when someone attempts to open a saved URL or manipulate a request directly.
Measure Whether the Account Model Is Working
Registration volume alone does not show whether the account experience is effective.
Useful measures may include:
- Registration completion
- Approval time
- Invitation acceptance
- Account activation
- Users per company
- Customer-administrator adoption
- Support requests related to access
- Failed company-association attempts
- Time required to replace an administrator
- Orders requiring account correction
- Approval-workflow completion
- Digital order adoption by company and location
- Dormant or inactive users
- Permission-related incidents
These measures can help the organization identify whether customers are able to manage access efficiently and whether internal teams are spending more or less time resolving account problems.
A Company-Account Planning Checklist
Before implementation, confirm that the team can answer these questions:
- What does a company account represent?
- How are divisions and locations modeled?
- Can one user belong to several companies or locations?
- How are new users verified and approved?
- Who becomes the first company administrator?
- How is administrator access recovered or transferred?
- Which roles are required?
- What may each role see and do?
- Which orders, invoices, and documents may each user access?
- How are billing and shipping addresses governed?
- Are purchasing limits or approvals required?
- Where are pricing, catalogs, and terms assigned?
- Which system owns each account relationship?
- How are changes synchronized?
- How are integration failures handled?
- Are single sign-on or additional authentication controls needed?
- Which actions require an audit record or notification?
- How will former employees lose access?
- Which capabilities are standard, configured, integrated, or custom?
- How will realistic account scenarios be tested?
- How will the organization measure adoption and support impact?
A Practical Next Step
Start by drawing the account structure for several real customers. Include the parent company, locations, users, roles, pricing relationships, approval rules, and source systems.
Then compare those examples. Look for patterns the platform should support consistently and exceptions that may require a different process.
A dependable B2B account experience starts with a clear model of companies, locations, users, roles, and system ownership. The technology provides the building blocks, but the organization still needs to define how access, purchasing, security, and account changes should work.
Planning Ecommerce for Companies With Multiple Buyers or Locations?
We can help you define the account structure, permissions, system relationships, and customer workflows before selecting or extending the platform.
Contact us to talk through your current customer-account model.
