Adobe's B2B documentation lists company accounts, shared catalogs, negotiable quotes, requisition lists, quick order, purchase orders with approval rules, and company credit as the features the extension adds. Every one of them is stored in Commerce. The question a merchant with an ERP has to answer is not where the feature lives but which system is the record of truth for the data behind it, because a feature that reads a stale copy of an ERP record is a feature that lies to the buyer. This guide takes the four that matter most and reads Adobe's documentation for each.
Company accounts: shared ownership, ERP as the master for identity
Adobe describes the company account as the key entity within B2B, with a structure of divisions and users, roles and permissions, and a customer group or shared catalog assigned at company level. Commerce owns the structure: who can order, who approves, what each role sees. What Commerce does not own is whether the company exists as a customer in finance, which account number it carries, and which ship-to addresses are valid. Those are ERP records. scandiweb's BK-Group case shows the join: a new registration is checked against the ERP after admin approval, matched by registration number or email, and created in the ERP if no match exists, with the ERP returning the full customer record to Magento. Bemeir's NetSuite article describes the mapping problem from the other side, noting that one Commerce company may be one NetSuite customer with several ship-to addresses or several customers under a parent. Decide the mapping before the first company is created.
Negotiated pricing: the ERP owns the price, Commerce resolves it
Commerce offers two mechanisms. Shared catalogs give each company a custom price list; Adobe's documentation states that creating a shared catalog automatically creates a customer group of the same name and that assigning a company to one is essentially the same as assigning it to a customer group. Negotiable quotes let a buyer request a quote from the cart, a seller apply discounts at line or quote level, and the buyer check out on the agreed terms before the quote expires. Both store prices in Commerce.
Neither should be the record of truth for a contract price. The reason is in Adobe's own documentation: adding a customer group triggers a full price reindex, and the price index stores rows per website and customer group, so a shared catalog per company multiplies the index by the company count and rebuilds it on every new account. A merchant with hundreds of companies should keep contract prices in the ERP, or in a PIM the ERP feeds, and have Commerce fetch them per customer at cart time. That is the design in scandiweb's BK-Group case, with the ERP pushing prices to Pimcore every few minutes and Magento reading the customer's price on request, and it is the position in Bemeir's NetSuite article, with NetSuite holding the authoritative customer-specific price. Shared catalogs then carry visibility, which products a company may see, rather than price. Quotes are the exception: a negotiated quote is created in Commerce and should be written back to the ERP as an order once accepted, not synced as a price.
Requisition lists: Commerce owns them, the ERP does not need to know
A requisition list, in Adobe's words, saves time when purchasing frequently ordered products because items are added to the cart directly from the list, and unlike a wish list it persists after the items are added. Adobe allows up to 999 lists per buyer account, depending on configuration. This is a Commerce-only feature. The ERP has no equivalent record and no reason to hold one; what it needs is the order that results. The one connector concern is that a list holds SKUs, so when the ERP retires or renames a SKU the connector must update or flag the product in Commerce, or the list will fail at the cart. A catalog sync that soft-disables retired SKUs rather than deleting them keeps the lists usable.
Credit limits: Commerce stores a copy, finance owns the limit
Adobe's company credit page sets the credit limit in the Commerce Admin under Customers and Companies, defines Payment on Account as an offline method that lets a company buy up to that limit, tracks the outstanding balance and available credit, offers a per-company setting to allow exceeding the limit, and records reimbursements through a button in the company profile. The page describes no ERP synchronization. That makes company credit the feature most likely to lie: the binding limit lives in finance, changes when an invoice is paid or a credit review lands, and Commerce holds whatever number was last written into it.
The design that holds is to treat the Commerce limit as a cache. The connector writes the limit and the balance from the ERP on a schedule, checkout revalidates against the ERP at order placement and fails closed if the ERP is unreachable, and the ERP is the only system that ever changes the limit. Bemeir's timeline article lists credit holds not enforced in time among the things that go wrong on these projects, and no agency on this site publishes its design for this, so it belongs on the list of written questions.
Purchase orders and approvals: Commerce owns the workflow, the ERP owns the number
Adobe describes purchase orders as the way companies track and control spending, with approval rules such as any order over a threshold needing manager approval or any order with more than 30 unique SKUs needing administrator approval, and with prices snapshotted when the purchase order is created. The approval workflow is a Commerce feature and should stay one. What the ERP owns is the purchase order number that finance and the buyer's procurement system use; Adobe's page does not describe carrying an external number, so the connector has to write the approved Commerce order to the ERP and, where the buyer's procurement system issued its own number, carry it on the order. Buyers who order from inside a procurement system need PunchOut, which Adobe's B2B documentation does not mention and which TradeCentric and Greenwing sell as a separate product.
The summary table
| Feature | Stored in Commerce | Record of truth | What the connector must do |
|---|---|---|---|
| Company accounts | Yes: structure, roles, permissions | Shared; ERP for identity, account number and ship-to addresses | Match or create the ERP customer on registration; keep the mapping between companies and ERP customers |
| Negotiated pricing | Yes: shared catalogs, quotes | ERP, or a PIM the ERP feeds | Push contract prices to the PIM or resolve from the ERP at cart time; write accepted quotes back as orders |
| Requisition lists | Yes | Commerce | Keep SKUs valid when the ERP retires or renames products |
| Credit limits | Yes: limit, balance, history | ERP or finance system | Write limit and balance on a schedule; revalidate at order placement; fail closed |
| Purchase orders and approvals | Yes: workflow, rules, price snapshot | Commerce for the workflow; ERP for the order number | Write approved orders to the ERP; carry the procurement system's PO number |
None of this is exotic, and all of it is in Adobe's public documentation. What no agency on this site publishes is its own answer to the third column. Ask for it.