Overview
Selling to businesses breaks an assumption most storefronts make: that a customer is a person. A business buyer is a person acting for an organization — one that has other buyers, several delivery sites, a VAT number, and a finance team who wants to see everything anyone ordered. A company in Spree models that. And because real organizations aren’t flat, a company can be a tree: a parent with subsidiaries, divisions, regional units, each with its own people and addresses. A node is one of two kinds, and the difference is about tax, not hierarchy:
Trees are capped at five levels, and the root must always be a
company.
Membership covers a subtree
Someone belongs to a company through a membership, and that standing reaches everything below the node — not just the node itself. So a buyer attached to “Acme Europe” can act for Sales and Operations beneath it, without anyone creating three memberships. Give someone standing at the root and they cover the whole group. This is why authorization always asks “does this person have standing on this node or any of its ancestors”, never “is this person a member of exactly this node”.In open source, every member can do everything within their standing — buy, see the subtree’s orders, and manage addresses and members. There are no company roles; the
role label on a membership is cosmetic.To restrict what individual people may do, see company governance below.Adding people
Both the dashboard and the storefront add members the same way — by email:- An existing customer becomes a member straight away.
- An unknown email produces an invitation, valid for 30 days, and an email with a link.
cmem_ for a membership, cinv_ for an invitation.
Accepting an invitation either signs an existing customer in, or registers a new account with the invited email. Either way it ends as a membership:
Buying for a company
A cart and an order can name a company. That’s what turns a personal purchase into a company one — it decides which addresses are on offer, whose tax registration applies, and who else will see the order.The shared address book
A company keeps its own addresses — ship-to sites, a billing address — separate from any individual’s. They’re labelled, and one of each kind can be the default.Tax
Tax registrations and exemption certificates live only on legal entities, and a purchase resolves tax through the node’s nearestcompany ancestor.
active rather than reading its status — a verified certificate stops exempting once it expires, and active accounts for that.
See Taxes for how these reach the tax calculation.
Company governance
Open source deliberately trusts every member equally. That’s the right default for a company of five people, and the wrong one for a company of five hundred — where a junior buyer should not be able to place a £40,000 order, remove their manager, or see what another division spent. Company governance adds that control. It works through the same endpoints and the same data, so nothing about your storefront integration changes when it’s switched on — the calls you already make simply start enforcing.Requires a Spree Enterprise licence
Company roles, order approvals, spending limits and governance audit history are part of Spree Enterprise. See what’s included, or talk to the team about your use case.
Company roles
Where open source has a cosmetic label, Enterprise has real roles built from a fixed set of capabilities:
Roles are data, edited by the company’s own administrator rather than by your staff — the buying organization manages its own structure, which is the point of self-service. Guards prevent someone granting themselves more than they hold.
These are entirely separate from staff roles. A company role never reaches anything belonging to the store.
Order approvals
A member withoutplace_orders submits their basket instead of completing it. Someone with approve_orders reviews and releases it.
Checkout returns a well-known approval_required response rather than a generic failure, so a storefront can show the right message and the right next step. The approval history is append-only — who asked, who decided, when.
Spending limits
Limits are set per member or per node, with a reset period — £5,000 a month for a buyer, £50,000 for a division. They’re enforced at completion, alongside approvals, so an over-limit basket is caught before payment rather than after.Restricted self-service
The same storefront endpoints — the company directory, address book, member management, order history — become capability-gated. A member withoutview_company_purchases sees their own node’s orders and not the group’s; a member without manage_company_members can read the team but not change it.
Nothing about the data model changes. Governance enforces through a policy layer and the checkout validation hooks, over the same companies, memberships and endpoints described on this page. You can build a B2B storefront against open source today and have it work unchanged when governance is enabled.
Managing companies as staff
parent_id. Deleting a node removes its whole subtree, and is refused outright once any order exists beneath it — history doesn’t get deleted to tidy up an org chart.
Each row carries children_count and members_count. children_count is the node’s direct sub-units. members_count is the number of distinct customers holding a membership on the node or on any node below it, so somebody who is a member of both a parent and one of its sub-units is counted once rather than twice.