-
01 Pricing Price lists on the Account, not in a spreadsheet.
A buyer requests a quote. The Account record carries tier, contract terms, custom price list, payment terms (Net 30 / Net 60 / 2% early-pay), and the SKUs the buyer is contracted for. The storefront prices against those records on the next request; the rep prices against them in the CRM; finance bills against them. No PRM tool, no quote-to-cash sync, no spreadsheet that drifted since the last contract renewal. When the contract is renegotiated, the new terms write to the Account row — every surface reads the change.
-
Contract on the Account
Tier, payment terms, custom price list, and contracted SKUs are properties of the Account row. CRM, storefront, finance all read it.
Quote on the same row
A quote reads the contract; the order writes back to the same Account. No quote-to-cash sync, no quote-only tool.
List + net + early-pay
List discounts, net-30/60 terms, 2% early-pay rules — three columns on the Account. Finance bills against them.
Storefront prices against
A logged-in buyer sees their contract price on every product page — no PRM, no separate B2B portal storefront.
AI proposes renewals
AI Builder proposes renewal terms based on usage, payment history, and category margin. Sales reviews the diff and ratifies.
Audit every change
Every price-list edit, quote, renewal, override logs actor, before, after. Finance audits without a forensic expedition.
-
02 Approvals The PO routes by the contract.
A buyer raises a PO above their delegation threshold. The routing rule reads the contract on the Account — Net 60, 2% early-pay, two-step approval over €10k, finance review required if the SKU is outside the contracted list. The right approvers see the same PO row the buyer drafted. When ratified, the order writes to the Account, the invoice posts on Net 60, and AR aging starts against the same row. No copy of the PO in a workflow tool, no amount that drifts between the request and the posting.
-
One PO, one row
The buyer drafts, the approvers see, and finance posts the same record. The amount cannot drift.
Routing reads the contract
Thresholds, two-step rules, finance review — every routing condition queries the Account record. Policies are data.
SoD at the record
Segregation of duties is enforced on the PO row, not in a workflow layer the ERP cannot see.
Out-of-contract flagged
If the buyer adds a SKU not in their price list, the rule flags it; finance reviews before the order ships.
AP matches on the row
The vendor invoice three-way-matches against the PO and GRN. The reconciliation step collapses to a query.
-
03 Hierarchy One Account, many buyers, one history.
A distributor has twelve sub-accounts — offices, locations, depots. Each sub-account places orders against the parent's contract; pricing inherits; payment terms inherit. Invoicing rolls up to the parent or stays per-location based on the contract clause. The CRM, the orders, the AR aging, and the renewal report all read the same Account hierarchy. When a new location opens, it joins the hierarchy by config — not by a separate onboarding flow in a B2B portal.
-
Account tree, one schema
Parent + sub-accounts on the same record table. Pricing and terms inherit; overrides live as records on the sub-account.
Per-location ordering
A sub-account places orders against the parent contract. The order row carries both the buyer and the inheriting location.
Invoicing rolls up
Monthly invoice consolidates child orders or stays per-location based on a clause on the parent contract.
AR aging on the parent
The parent Account sees aged AR for the whole tree; the location sees its own column. Finance reads either.
When a buyer already runs ordering through their own ERP, their purchase orders flow straight in — over EDI, a scheduled file feed, or a REST integration — and land on the same Account and order rows the rest of the platform reads.
A B2B account whose ordering already lives in someone else's ERP is an integration conversation, not a same-week pilot. Today: REST API + webhooks against the same rows; tomorrow: turnkey connectors for the buyer systems you sell into.
Production vs Pilot
- Account-based pricing — tier, custom price list, contracted SKUs on the Account row
- Net-term payment configuration — Net 30 / 60 / 90, early-pay discounts
- Multi-buyer Account hierarchy with inherited terms and overrides
- PO routing rules reading contract clauses on the Account
- Three-way match (PO / GRN / vendor invoice) on the same row
- AR aging at parent or per-location, consolidated invoicing by clause
- audit_events on every quote, contract edit, PO, invoice, AR write
- Buyer-system integration — POs from a customer's ERP land as orders on the Account
- EDI connectors for orders, confirmations, dispatch notes, and invoices
- AI-proposed renewal terms from usage + payment history + category margin
- Multi-currency B2B with FX revaluation on the Account row
- Self-serve B2B portal for sub-account onboarding
Where it fits
B2B sales and operations share records with CRM , OMS , Ecommerce , ERP , Ticketing , Workflows , Channels , and AI Builder — the same row across every module that wrote it. No second copy, no reconciliation step.
Often read alongside: Front Office , Operations , and Retail .
Bring one B2B account and one contract — we'll run a renewal quote on your data.
Your hardest account: multiple sub-locations, custom price list, Net-60 terms with a 2% early-pay rule, a couple of out-of-contract SKUs they keep ordering. Twenty-five minutes. We open the admin, model the account and contract against a sandbox, run a renewal quote and a sample PO through approvals, and show what changes when the contract, the order, and the invoice all live on the same Account row.