How Does B2B E-Commerce Manage Order and Invoice Permissions Across Multiple Companies?

Why does multi-company B2B require a separate permission model?

A multi-company structure requires a dedicated permission model because every transaction must systematically identify the legal entity on whose behalf it is performed. Instead of giving one user account unrestricted access to several companies, the system should evaluate user, company, role, and action permissions together. The primary security boundary is the company context; when a user switches companies, prices, addresses, billing records, order history, and approval workflows should also change according to that selected context.

Which objects should the permission model keep separate?

The design should define not only login access but also what a user can see within each company and how far the user may advance a transaction. For that reason, when evaluating technical features of enterprise e-commerce software, the account and role model is as critical as the catalog. Keeping the architecture simple also makes it easier to add new companies, roles, or approval levels in a controlled way.

• Users and the companies they can access should be stored as separate relationships.
• Each company should have independent price, product, and address rules.
• Role permissions should be configurable differently for each company.
• Order and billing actions should preserve the same company context.
• Permission changes should remain traceable over time.

Simplicity is prerequisite for reliability. - Edsger W. Dijkstra

How can one user transact on behalf of multiple companies?

One user should transact for multiple companies by selecting an active working context only from the companies assigned to that user. The portal session keeps the user identity while the selected company is stored as a separate transaction context. This allows the same person to create a purchase request for Company A, view orders only for Company B, and have no access to financial information for Company C. Company switching should be explicit, visible, and designed to reduce the risk of selecting the wrong entity.

Which controls are needed for multi-account user experience?

In B2B multi-account management, single-session convenience should never weaken the data boundary between companies. When the company changes, the cart, delivery addresses, payment terms, and approval chain should be validated again. Likewise, when planning modules and integrations for portal software, the company selector should be treated not merely as a user-interface component but as a central context that affects every business rule.

• Users should only be able to select companies assigned to them.
• The active company should be clearly visible in the interface.
• Cart and session data should be revalidated after a company switch.
• Roles and limits should be recalculated for the selected company.
• An unauthorized company identifier must not work through URLs or APIs.

How should product and price access differ by company?

Product and price access can be separated by legal entity whenever a customer-group rule is not granular enough. As the same user moves between companies, that user may see a different catalog, discount structure, contracted products, minimum-order rules, or currency. The source of pricing should be the company account, not the individual user; this keeps commercial terms attached to the correct legal entity even when personal access changes.

How should catalog and commercial rules be modeled?

When developing a corporate purchasing portal, product visibility and pricing logic should be modeled as separate layers rather than compressed into one permission field. One company may be allowed to see a product but not order it, while another may purchase the same product under a different price list. This distinction also makes campaign and contract-specific conditions clearer and helps define which fields a customer administrator is allowed to change.

• Product visibility can be defined by company or company group.
• Price lists can be linked to customer accounts or contract logic.
• Discount and payment terms can be managed as separate rules.
• Purchasing restrictions can operate independently from product visibility.
• Changes to private catalogs should be recorded for auditability.

How should delivery and invoice permissions be restricted?

Delivery and invoice permissions should be restricted through verified address and account records belonging to the selected company rather than by allowing users to enter unrestricted data. Permission to create an order does not automatically mean permission to add a delivery address or change billing information. Company-level invoice authority is a core control in structures with multiple tax identities, branches, or subsidiaries because it helps prevent orders from being assigned to the wrong legal entity.

How should responsibility for address and billing data be split?

The selling company can remain the owner of master customer, tax, and contract data while customer-company administrators receive access only to approved operational fields. For example, a customer administrator might assign existing addresses to users but be unable to create a new billing account. This split improves self-service without leaving data ownership unclear. Critical changes are also safer when handled through a controlled administration flow rather than during the ordering process itself.

• The billing account must match the selected company.
• Delivery addresses should be restrictable at the individual-user level.
• Permission to add addresses should be separate from order permission.
• Tax and customer-account fields should require stronger privileges.
• Inactive or unverified records should not be available for ordering.

How many approval levels should an order workflow include?

The required number of approval levels should come from the organization's purchasing policy and risk model rather than from a fixed number. A small request may need one approval, while specific product groups, budget thresholds, cost centers, or companies may require additional approval steps. When designing approval-based ordering software, the objective is not to add as many steps as possible but to route the right transaction to the right responsible approver.

How should a role-based approval workflow be structured?

In a typical flow, the requester, department or company approver, and person who finalizes the order can hold separate roles. Finance, central purchasing, or a product specialist can be added as conditional approval steps when required. Making the workflow configurable by company allows different subsidiaries to operate under different rules within the same portal. Rejection, return, and revision scenarios should also be designed from the start; modeling only the successful approval path is not sufficient.

• Approval levels should depend on company and order conditions.
• Amount, product group, or cost center can trigger additional approvals.
• The requester and the final order approver can be separate roles.
• Rejection and revision actions should use explicit workflow states.
• Delegated or temporary permissions should include start and end dates.

How can the correct ERP customer and company code be sent?

The correct ERP customer and company code should be sent through the portal's company-mapping table and server-side validation, not by trusting a user selection at checkout. The portal company, ERP customer account, sales organization, and, where necessary, branch or warehouse code should be mapped in advance. When the order is finalized, the system should validate that mapping again and stop the transfer if a required relationship is missing or contradictory.

Which fields should be validated together during integration?

In a multi-company B2B ordering system, integration is more than sending an order number. Customer account, price condition, delivery location, payment plan, tax data, and the ordering company must all carry the same context. When planning an ERP-integrated B2B e-commerce environment, data mapping rules, error codes, and retry scenarios should be explicit parts of the technical specification.

• The portal company and ERP customer account should map uniquely.
• The company code should be validated server-side before ERP transfer.
• Address and tax fields should be checked against the order context.
• Failed transfers should have retry logic and an error record.
• The ERP response should be stored as a reference on the portal order.

Which settings should seller and customer admins control?

Seller-side and customer-company administrators should not have identical administration rights. The seller can manage commercial account mappings, price sources, ERP connections, and master contract data, while the customer administrator can manage user invitations, role assignments, and operational approvers within that company's boundary. This separation preserves self-service convenience while keeping critical commercial information under the control of the selling organization.

How should administrative boundaries be defined in the project?

In corporate customer portal development, ownership of each setting should be defined not only in screen design but also in project scope and the operating model. When reviewing enterprise B2B e-commerce project and proposal scope, administrator roles, support responsibilities, and data ownership should be evaluated separately. This reduces unnecessary dependence on the software team while avoiding uncontrolled self-service in sensitive areas.

• Seller administrators can manage customer and integration mappings.
• Customer administrators can manage users within their own company.
• Price and contract fields can remain under restricted authority.
• Approver assignment can be delegated according to company policy.
• Critical settings can require dual control or central approval.

How should permission changes and access logs be recorded?

Permission changes should record who granted or removed which role for which user, in which company, and at what time. Access logs should cover more than sign-in events; they should also capture company switching, order creation, approvals, billing-account selection, and critical administration actions. An audit trail should be created at the moment of the transaction, not reconstructed later as a report.

How should logs support operations and security reviews?

These records provide a shared reference for investigating errors, supporting customers, reviewing unauthorized activity, and improving processes. Each event should include the user, company, action, time, result, and, where possible, the related order or record identifier. Access to logs should also be role-based so ordinary users cannot view sensitive audit data. Retention and access policies should be defined separately according to the organization's technical, contractual, and regulatory requirements.

• Role additions and removals should be recorded as separate events.
• Company context should appear in every critical transaction record.
• Approval and rejection events should link to the order identifier.
• Log access should be limited to authorized administrative roles.
• Retention policy should reflect the organization's requirements.

How should a multi-company B2B portal be phased and planned?

A multi-company B2B portal can be phased by first validating the core company and user model, then adding approval workflows, ERP integration, and advanced administration permissions. Early discovery should clarify the number of companies, user roles, approval levels, pricing sources, address structure, and the ERP customer-code model. Without this information, proposals based only on a list of screens become difficult to compare because they may hide major differences in workflow and integration scope.

What information should be prepared for an architecture workshop?

When comparing solutions, evaluate not only the number of features but also how company boundaries are enforced, how integration failures are handled, and which actions administrators can perform through self-service. Phased development is easier to control when the core data model will not need to be replaced later. Sharing a sample company structure, role matrix, and approval scenarios during proposal preparation helps the development team define technical scope around the actual operating model.

• Prepare the company and user matrix before discovery.
• Explain approval levels and conditions with sample scenarios.
• Provide ERP customer and company-code mapping requirements.
• Define the boundary between the first phase and later phases.
• Separate permissions, logs, and administration responsibilities in the proposal.