Celeste library
The B2B mechanics that decide whether a platform fits
Contract pricing, quote to order, punchout, credit limits, account hierarchies, kits, UOM conversion. These are the mechanics that break commerce projects. Each page explains one of them in plain language, then says which platforms and connectors handle it and which do not.
How does contract pricing actually work in B2B ecommerce, and why does it break native connectors?
A B2B price is a stack, not a number: a list price, a price class rate, a customer-specific negotiated price, and a volume break, resolved into one effective price for one customer on one day. Native ERP connectors break on it because Acumatica and Cin7 calculate that effective price at order entry, while Shopify B2B and BigCommerce want it pre-computed and pushed as a price list, so the connector ships the ingredients and never the answer.Quote to order: what changes when most of your revenue starts as a quote instead of a checkout
Quote to order is the sequence where a buyer asks for a price, a person or a system prices it, and the accepted quote becomes an order. It matters because a checkout assumes the price is already known: Shopify B2B has no buyer-initiated quote object and reaches quoting through merchant-created draft orders, while BigCommerce B2B Edition and Shopware B2B Components both ship a real request-a-quote flow, and Acumatica can import Shopify draft orders as sales quotes.Punchout explained: cXML, OCI, and what a customer means when they say "we need punchout"
Punchout lets a buyer shop your storefront from inside their own procurement system, then hands the cart back as a requisition for their approval. It comes in two protocols, cXML from SAP Ariba and OCI from SAP, and no commerce platform Celeste scores supports it natively: on Shopify it is an app, priced from about USD 199 a month, and it is usually one large customer’s procurement requirement rather than something your whole customer base is asking for.Credit limits and payment terms on a B2B storefront: reading the live position from the ERP
A B2B buyer on account can only order up to their available credit, which is their credit limit minus what they already owe and what is already on order. Shopify B2B documents payment terms of net 7 through net 90 but no credit limit at all, BigCommerce B2B Edition does expose an availableCredit figure that disables purchase order payment above it, and in both cases the ERP is where the real position lives, so the practical question is whether the storefront asks it or guesses.Company accounts, buyer roles and approvals: why one customer record per person is the wrong shape for B2B
In B2B the customer is an organisation, not a person: several buyers, several ship-to locations, different permissions, and often an internal approval step before an order is allowed to leave. Shopify B2B models companies and locations with exactly two contact permission levels and has no buyer-side approval chain, BigCommerce B2B Edition adds company user roles and sales agents, and Shopware B2B Components is the only one of the four with a documented order approval module.Multi-warehouse availability: what do you show a buyer when stock lives in five places?
A single company-wide stock number is a promise you cannot keep, because availability in B2B is a question with a customer in it: which warehouse can actually serve this buyer, by when. BigCommerce allows four to 100 inventory locations by plan but its Stencil storefront reads only the default location unless you request an aggregated model, Shopware puts warehouses and warehouse groups behind its Beyond tier, and no platform natively answers "what can you ship me from the depot that serves my region".Two brands, three regions, one ERP: what has to be modelled where?
One ERP behind two storefronts forks six things: catalogue, price scope, inventory scope, customer identity, order numbering, and content. Shopify forks at the store boundary, where a Plus organization gets one main store plus nine expansion stores and Shopify states products and inventory are not synced between them; BigCommerce forks at the channel inside one shared catalogue; and Acumatica has to be told which storefront it is answering, because its native connector filters what a store receives with entity mapping rather than per item.What date do you actually put on the page? Promise dates, lead times and backorders
A promise date is a date you are willing to have printed on a customer’s purchase order, and neither Shopify nor BigCommerce holds the inputs needed to compute one. There are six: on-hand stock at the location that will ship, quantity already committed, inbound receipts with confirmed dates, supplier or production lead time, pick and pack time, and a transit calendar. Shopify computes delivery dates from a global fulfilment time plus a per-rate transit time and only displays them when a product’s inventory exceeds zero, so any date that depends on an inbound purchase order has to come out of Acumatica or Cin7.Volume-break and tier pricing: break quantities, two-dimension matrices, and what survives a connector
A volume break is a price that changes at a quantity threshold, and B2B runs it in three shapes: one break table for everyone, a break table per customer price class, and a two-dimension matrix where quantity and customer class both move the price. Shopify B2B carries up to 10 price breaks per product applied to each variant within a catalogue, BigCommerce carries bulk pricing rules with quantity_min and quantity_max per product, and Acumatica holds break quantities per item in a sales price worksheet, which is why the second and third shapes are the ones that do not survive a native connector.