Acro Commerce
Run the diagnostic

Celeste library

B2B commerce and ERP glossary

Plain-language definitions of the terms that come up when a manufacturer or distributor connects an ERP to a storefront. Every definition is written to be understood by someone who does not build software for a living.

Allocation

Allocation is the act of reserving stock for a specific order before it ships, so the same units cannot be sold twice. Most ERPs keep stock on hand and stock already allocated to somebody else as two separate numbers.
Why it decides a platform: A storefront that reads on-hand quantity rather than unallocated quantity will oversell. The gap between the two numbers stays invisible until the first customer is told an item shipped when it did not.

API

An API is the defined way one piece of software asks another for data or tells it to do something. When a storefront shows a live price from the ERP, it is calling an API.
Why it decides a platform: Whether a system has an API, and what that API can actually read and write, sets the ceiling on any integration. Vendors use the phrase “open API” freely, so the useful question is which objects and which fields it exposes.

Available to promise

Available to promise is the quantity you can commit to a customer for a given date, counting stock on hand, stock already allocated elsewhere, and inbound purchase orders. It is a smaller and more honest number than on-hand quantity.
Why it decides a platform: Available to promise is what a B2B buyer actually needs, and few storefronts calculate it. Most display on-hand, which is why sales teams keep phoning the warehouse instead of trusting the site.

Avalara

Avalara is a third-party service that calculates sales tax, GST and use tax based on the ship-to address, the product and the customer’s exemption status. Its calculation product is called AvaTax.
Why it decides a platform: If tax is calculated in two places, the storefront total and the ERP invoice will eventually disagree. Naming one system as the owner of the calculation, and having the other read the result, removes a whole class of customer service work.

B2B customer portal

A B2B customer portal is the logged-in area where a business customer looks up their own orders, invoices, quotes and pricing without phoning anyone. Ordering may or may not be part of it.
Why it decides a platform: A portal is often the cheapest first phase of a commerce programme, because it earns its keep on deflected phone calls rather than on new online revenue. It also exposes every integration weakness early, while the stakes are still low.

B2B Edition

B2B Edition is BigCommerce’s add-on that provides company accounts, buyer roles, quotes, price lists and shopping lists on top of the standard platform. It is licensed separately from the core plan.
Why it decides a platform: Most of what a B2B seller needs on BigCommerce lives in B2B Edition rather than in the base product. A quote or a feature comparison that leaves it out is describing a different product than the one you would actually run.

Backorder

A backorder is an order line accepted for stock you do not currently have, to be shipped when it arrives. It is normal in distribution, and it is different from cancelling the line or telling the buyer to come back later.
Why it decides a platform: Sellers who cannot backorder online push their largest and most predictable orders back onto the phone. That is the opposite of the reason the project was funded.

Batch sync

A batch sync moves data between systems on a schedule, for example every night or every 15 minutes, rather than the moment something changes. It is simpler to run than event-driven integration and it is always at least slightly out of date.
Why it decides a platform: Batch is fine for product descriptions and wrong for stock and credit. Deciding which fields tolerate a delay, and which have to be read live, is most of what integration design actually is.

Bill of materials

A bill of materials is the list of components that go into a manufactured item, held in the ERP for production and costing. It is not the same as a kit, which is an assembly picked at the time of the order.
Why it decides a platform: Items with a bill of materials are made rather than picked, so their availability is a lead time rather than a stock figure. Showing one as in stock because its components are in stock is a promise the plant has not agreed to.

Blanket order

A blanket order is an agreement to buy an agreed quantity over a period, released in smaller shipments against the same contract. The price and the terms are fixed once, and each release draws down the remaining balance.
Why it decides a platform: Blanket orders live in the ERP and almost never in the commerce platform. If your customers release against blankets, the storefront has to show the remaining balance or those accounts will not use it.

Buyer role

A buyer role is the set of permissions attached to one person inside a customer company, such as whether they can submit an order, only build a cart for someone else to authorize, or only view invoices.
Why it decides a platform: Roles are the mechanism behind approval workflows and ordering on behalf of a customer. A platform with a single flat customer login can only add approvals later through custom code.

Catalogue

A catalogue is the set of products a given audience can see and buy. In B2B, different customers frequently see different catalogues from the same storefront.
Why it decides a platform: Whether the platform supports more than one catalogue decides whether dealers, retail buyers and OEM customers can run from one site. Adding that afterwards usually means standing up a second site.

Catalogue entitlement

Catalogue entitlement is the rule that decides which products a specific customer is allowed to see and buy. A dealer might see the full range, an end customer a subset, and a competitor nothing at all.
Why it decides a platform: Entitlement is often a contractual obligation rather than a preference. If you have promised a distributor that end customers will not see their products, a platform that can only hide products globally cannot honour the agreement.

Checkout

Checkout is the step where a cart becomes an order and shipping, payment and terms are confirmed. A B2B checkout usually also carries a purchase order number, a requested delivery date and a ship-to chosen from the account’s locations.
Why it decides a platform: Most platforms restrict what can be changed in checkout, and B2B needs more fields there than consumer retail does. Ask what is editable before assuming a purchase order number field is free.

Company account

A company account is a customer record that holds several people, each with their own login and their own permissions. One buyer might place orders, another might only approve them, a third might only look up past invoices.
Why it decides a platform: Consumer platforms model a customer as one person. If your customers are organisations, everything downstream, from pricing to approvals to reporting, depends on the platform modelling that properly.

Composable commerce

Composable commerce is an approach where the storefront, the cart, search, pricing and content are separate services assembled into one system, rather than a single product that does all of it. The trade is flexibility against the cost of owning the assembly.
Why it decides a platform: Composable moves cost from licence fees to engineering time, and engineering time is recurring and easy to underestimate. It is the right answer for a specific set of requirements and an expensive answer for everyone else.

Configurable product

A configurable product is one the buyer specifies rather than picks off a list, such as a machine built to order from a set of options with rules about which options can go together. The final part number and price may not exist until the configuration is finished.
Why it decides a platform: Ordinary product variants cannot express a rule like “option A excludes option B”. If your products are configured, the real question is whether the configurator lives in the ERP, in a quoting tool or on the storefront, and those three answers have very different costs.

Contract pricing

Contract pricing is a price that applies to one customer or one group of customers rather than to everyone. In B2B it is normal for the same product to have a different price for every account on the book.
Why it decides a platform: This is the single most common reason a native ERP connector fails a B2B seller. A connector that syncs only a default price will show the wrong number to every contract customer you have.

CPQ

CPQ stands for configure, price, quote. It is software that walks a seller or a buyer through valid product configurations, works out the price, and produces a quote document.
Why it decides a platform: CPQ is the most commonly over-bought item on a B2B commerce project. It is also the one thing that cannot be faked when the products really are configured, so scoping it early changes the budget materially.

Credit hold

A credit hold is a flag on a customer account that stops new orders from being processed, usually because the balance is over the limit or an invoice is overdue. The ERP sets it and finance clears it.
Why it decides a platform: If the storefront does not read the hold flag, a customer on hold can place orders all day that finance then has to cancel. Reading that one flag live is a small piece of integration with a large effect on trust.

Credit limit

A credit limit is the amount a customer may owe at any one time. Buying on account, often on thirty-day terms, is standard in B2B and the limit is enforced by the ERP.
Why it decides a platform: If the storefront cannot read the live credit position from the ERP, it will either block good orders or accept orders the finance team then has to unwind. Both erode trust in the channel quickly.

Customer group

A customer group is a label on customer records used to apply shared pricing, catalogue access or shipping rules to a set of accounts at once. Platforms name it differently, including customer group, customer segment and company.
Why it decides a platform: Customer groups are how most commerce platforms approximate an ERP price class. How many groups a platform allows, and whether one customer can belong to more than one, decides how closely the storefront can mirror the ERP.

cXML

cXML is the XML format used to exchange punchout sessions, purchase orders and invoices between procurement systems such as Ariba and Coupa and a supplier’s website. It is the most common punchout standard in North America.
Why it decides a platform: When a customer says they need punchout, they usually mean cXML specifically. Confirm the standard and the exact documents before assuming a platform’s punchout support covers what that customer requires.

Dealer portal

A dealer portal is a logged-in site for a manufacturer’s dealers or distributors, showing their own pricing, stock, order history and often marketing material and warranty claims. It is a channel tool rather than a public storefront.
Why it decides a platform: Dealer portals fail on entitlement and on the non-commerce features around the edges, not on the cart. Scoping one as a storefront project is the usual reason it runs over.

Decoupled architecture

A decoupled architecture separates the customer-facing front end from the commerce back end so the two can change independently. It is the same idea as headless, and the two words get used loosely and often interchangeably.
Why it decides a platform: Decoupling buys front-end freedom and costs you the platform’s built-in pages, which you then own forever. That trade is worth making when the front end is genuinely unusual, and not otherwise.

Drop ship

A drop ship is an order shipped to the end customer directly by a supplier or another warehouse, so the goods never pass through your building. The ERP still records the sale, the cost and the margin.
Why it decides a platform: Drop-shipped lines have no local stock to display and usually a different lead time. A storefront that only understands your own warehouses will either hide those products or state the wrong availability for them.

EDI

EDI, or electronic data interchange, is a long-established set of standard message formats businesses use to exchange purchase orders, invoices and shipping notices system to system. Large retailers and distributors often require it from their suppliers.
Why it decides a platform: EDI volume often dwarfs online order volume at a distributor, and it belongs to the ERP rather than to the storefront. Platform shortlists that treat EDI as an ecommerce feature tend to buy the wrong thing.

ERP

An ERP is the system of record for a business’s inventory, pricing, customers, orders and finance. Acumatica, Cin7, NetSuite, SAP Business One and Microsoft Dynamics are examples.
Why it decides a platform: In an ERP-run business the commerce platform is a channel and not the centre. Projects that reverse that relationship end up maintaining the same data in two places.

ERP integration

ERP integration is the work of connecting a commerce platform to the ERP so products, prices, stock, customers and orders stay consistent between them. It is usually the largest and least predictable part of a B2B commerce project.
Why it decides a platform: Integration is where B2B commerce budgets are won and lost. A platform that fits the business perfectly and cannot be integrated economically is the wrong platform.

Eventual consistency

Eventual consistency means two systems will agree after a short delay rather than at the same instant. Most commerce and ERP integrations work this way, so there is always a window where the storefront shows something the ERP has already changed.
Why it decides a platform: The size of that window is a business decision rather than a technical detail. A 15-minute stock lag is harmless for slow-moving parts and unacceptable for a single-unit item several customers are chasing.

Exemption certificate

An exemption certificate is the document a customer provides to prove they should not be charged sales tax, usually because they are reselling the goods or are a tax-exempt body. It has to be on file, valid, and matched to the right jurisdiction.
Why it decides a platform: If exempt customers get charged tax online, they stop buying online. Certificate status normally lives in the ERP or in a tax service, so the storefront has to read it rather than keep its own copy.

Field mapping

Field mapping is the record of which field in one system corresponds to which field in the other, for example that the ERP’s item description feeds the platform’s product title. Every integration has one, written down or not.
Why it decides a platform: Undocumented field mapping is why nobody can explain a wrong value on the site two years later. Ask to see the mapping document before you accept an integration as finished.

Freight rules

Freight rules decide what a customer is charged for shipping: live carrier rates, a flat rate, a table by weight or zone, freight collect on the customer’s own carrier account, or free over a threshold. B2B sellers commonly use several of these at once, by account.
Why it decides a platform: Many B2B customers ship on their own carrier account and expect no freight charge at all. A platform that cannot switch freight behaviour per account will either overcharge those customers or need a manual correction on every order.

GTIN

A GTIN is the standard product identifier behind barcodes, covering UPC in North America and EAN elsewhere. It identifies the product itself, unlike a SKU, which is your own internal code.
Why it decides a platform: Marketplaces, retail customers and shopping feeds require GTINs and reject items without them. If the ERP does not hold clean GTINs, that gap surfaces at the worst moment, during a channel launch.

Headless commerce

Headless commerce means the storefront a customer sees is a separate application talking to the commerce platform through APIs, instead of using the platform’s built-in templates. The platform still runs the cart, the pricing and the orders.
Why it decides a platform: Headless is a front-end decision that often gets sold as a platform decision. If the requirement driving it is about pricing, entitlement or ERP data, headless will not address it and adds cost on top.

Idempotency

Idempotency means an operation can be repeated safely, so sending the same order twice produces one order rather than two. Integrations achieve it by attaching a unique key to each request that the receiving system uses to recognize a repeat.
Why it decides a platform: Networks fail halfway through. Without idempotency, a retry after a timeout creates duplicate orders, and a duplicate order in an ERP means a duplicate shipment and a credit note.

Kit

A kit is a product sold as one item but made up of several stock items picked together, such as a tool packaged with blades and a case. Its availability depends on the components rather than on the kit itself.
Why it decides a platform: Kit availability is the most common silent data error in an ERP to storefront sync. The kit shows a plausible number, nobody questions it, and the shortfall only appears in the warehouse.

Landed cost

Landed cost is the full cost of getting goods into your warehouse, including the purchase price, freight, duty, brokerage and currency conversion. It is what margin should be measured against.
Why it decides a platform: If the storefront prices from a cost that excludes landed cost, discount rules and margin floors are set against the wrong number. That bites hardest on imported goods, where freight and duty move independently of the supplier invoice.

Lot and serial tracking

Lot and serial tracking records which specific batch or individual unit went to which customer, for recall, warranty and compliance. Food, medical devices, chemicals and equipment usually require it.
Why it decides a platform: Tracked items constrain fulfilment and returns and add fields the storefront may need to display or collect. A platform that cannot show a serial number on an order history line will not satisfy a warranty process.

MACH

MACH stands for microservices, API-first, cloud-native and headless. It is a label for a style of architecture, promoted by a vendor group called the MACH Alliance.
Why it decides a platform: MACH describes how software is built, not whether it fits your business. A MACH-compliant platform can still be a poor match for contract pricing, and a monolith can still be a good one.

Matrix item

A matrix item is Acumatica’s way of describing a product that comes in variations, such as a shirt in four sizes and three colours. Acumatica calls the parent a template item and generates a stock item for each combination.
Why it decides a platform: Matrix items map onto commerce platform variants imperfectly, and the mismatch produces real sync errors. Shopify, for example, supports a limited number of product options, so a product with more attributes than that cannot be represented as one product.

Metafield

A metafield is a custom field added to a product, customer or order to hold data the platform has no built-in place for. Shopify calls these metafields, and other platforms call them custom fields or attributes.
Why it decides a platform: Metafields are where ERP data with no native home ends up, such as country of origin or a hazmat class. They work, but data stored there is often invisible to search, filters and checkout logic until extra work is done.

Middleware

Middleware is a layer of software that sits between the ERP and the storefront, translating and enforcing rules that neither system holds on its own. It can be a hosted integration platform or a custom service.
Why it decides a platform: Middleware is what you reach for when the business logic does not live cleanly in either system. It adds a component to own and maintain, and it is often the only honest answer for a complex B2B seller.

Minimum advertised price

Minimum advertised price, or MAP, is a manufacturer’s policy setting the lowest price a reseller may display publicly. The reseller can often sell for less, but cannot advertise it.
Why it decides a platform: MAP violations put supply agreements at risk, which makes this a compliance requirement rather than a preference. It usually rules out any approach that shows one price to everyone.

Minimum order quantity

A minimum order quantity is the smallest amount of an item a customer may buy, often set by the pack size or by an economic threshold. Related rules include order increments and a minimum value for the whole order.
Why it decides a platform: Minimum order rules that exist in the ERP but not on the storefront produce orders the warehouse cannot pick and customer service has to phone about. They need enforcing at the point the buyer types the number.

Multi-currency

Multi-currency means the storefront can quote, transact and settle in more than one currency. It involves the displayed price, the exchange rate used, the currency the payment is captured in and the currency the ERP records.
Why it decides a platform: A Canadian seller quoting in US dollars needs the ERP and the storefront to agree on the rate and the rounding, or every order needs a manual adjustment. Currency is where “the connector supports it” and “the numbers match” are frequently different statements.

Multi-warehouse availability

Multi-warehouse availability is showing a buyer what is in stock for them specifically, based on which warehouse or warehouses can actually serve their order, rather than a single company-wide total.
Why it decides a platform: A single aggregate stock number across several warehouses is a promise the business cannot keep. Getting availability right is usually the difference between the storefront being trusted by the sales team or worked around by it.

Native connector

A native connector is integration software published by the ERP or platform vendor themselves, configured rather than built. Acumatica ships native connectors for Shopify and BigCommerce.
Why it decides a platform: A native connector is the cheapest and fastest option when it fits, and the most expensive when it nearly fits, because the workarounds accumulate somewhere nobody is maintaining them.

OCI

OCI, or Open Catalog Interface, is SAP’s punchout standard, used where the buyer runs SAP procurement. It does the same job as cXML with a different message format.
Why it decides a platform: A platform or extension that supports cXML punchout does not automatically support OCI. If the customer demanding punchout runs SAP, confirm OCI specifically before quoting the work.

OMS

An order management system sits between sales channels and fulfilment, deciding which location ships each order and holding one view of order status. Some ERPs include one, and some businesses buy a separate product.
Why it decides a platform: If you sell through several channels and ship from several locations, the routing logic has to live somewhere. Assuming the commerce platform will do it is the usual mistake, because it only ever sees its own orders.

Order approval

Order approval is a workflow where a buyer builds an order and somebody else at their company authorizes it before it is submitted. The rule is usually a spending threshold, a cost centre, or the buyer’s role.
Why it decides a platform: Approval is often the reason a customer’s buyers cannot use the site at all. It is also easy to under-specify, because the requirement lives inside the customer’s business rather than yours.

Order on behalf of

Order on behalf of, sometimes called impersonation, lets an internal salesperson or customer service agent log in as a customer and place or edit an order for them, with that customer’s own pricing and entitlements applied.
Why it decides a platform: This is what gets an inside sales team to adopt the storefront instead of working around it. Without it, phone orders are keyed straight into the ERP and the online order history is incomplete, which customers notice quickly.

PIM

A PIM, or product information management system, is a dedicated place to author and govern product content: descriptions, attributes, images, documents and translations. It feeds the storefront and any other channel that needs the same content.
Why it decides a platform: Product content is the most common reason a launch date slips, and it is almost never on the project plan at the right size. A PIM does not create the content; it only stops the content you have from being scattered.

Polling

Polling is when one system asks another for changes on a schedule instead of being told when something changes. It is simple, it works with systems that cannot send notifications, and it spends most of its calls asking about nothing.
Why it decides a platform: Polling frequency is a direct trade between freshness and API rate limits. Many integrations that look real time in a demo are polling every few minutes, and they slow down as the catalogue grows.

Price class

A price class is a label on a customer account that decides which set of prices they see. Acumatica and most ERPs use price classes so a seller can maintain one price list for a whole tier of customers instead of one per account.
Why it decides a platform: Price classes are how a seller keeps contract pricing manageable at scale. If the storefront cannot model them, every account has to be priced individually, which nobody maintains for long.

Price list

A price list is a named set of prices that can be attached to customers, groups or currencies. ERPs and commerce platforms both use the term, and they rarely mean exactly the same thing by it.
Why it decides a platform: The number of price lists a platform allows, and how many can apply to one customer at once, is a hard limit on how faithfully it can mirror ERP pricing. Check the limit before assuming a one-to-one mapping is possible.

Product option

A product option is a choice a buyer makes on a product page, such as size, colour or length. Options that change which item is actually being sold create separate variants; options that do not, such as an engraving note, do not.
Why it decides a platform: Platforms cap how many options and variants a product can carry, and ERP matrix items frequently exceed the cap. That single limit has ended more platform shortlists than any pricing feature.

Punchout

Punchout is a way for a buyer to shop on a supplier’s website from inside their own procurement system. The buyer clicks out, builds a cart, and the cart is returned to their system as a requisition for approval.
Why it decides a platform: Punchout is frequently a hard requirement from a single large customer, and it is rarely native. Finding out which platforms support it and at what cost changes the shortlist.

Quick order pad

A quick order pad is a form where a buyer types part numbers and quantities directly, or pastes a list, instead of browsing. Repeat buyers who already know their part numbers use it for most of their orders.
Why it decides a platform: For a distributor with returning trade customers, the order pad often carries more revenue than the catalogue pages do. It is also the feature most likely to be missing from a theme built for consumer retail.

Quote to order

Quote to order is the process where a buyer asks for a price, a person or a system prepares a quote, and the accepted quote becomes an order. In much of B2B it is the normal way to buy, not an exception.
Why it decides a platform: A platform built around a checkout assumes the price is already known. If most of your revenue starts as a quote, a checkout-first platform means either a bolt-on or a rebuilt sales process.

Rate limit

A rate limit is the cap a system puts on how many API requests you may make in a period. Go past it and requests are rejected until the window resets.
Why it decides a platform: Rate limits decide whether a live price call on every product page is feasible or whether prices have to be synced ahead of time. They are also the usual reason a nightly full catalogue sync stops finishing overnight as the catalogue grows.

Rebate

A rebate is money returned to a customer after the fact for hitting an agreed volume or product mix, rather than a discount taken off the invoice at the time. The buyer pays the contract price now and receives the benefit later.
Why it decides a platform: Rebates get confused with tiered discounts during requirements gathering, and they behave differently. A rebate does not change the invoice; a tier does.

Reorder

Reorder is buying the same items again from an order history or a saved list, in one action rather than by searching for each line. It is the most-used feature on most B2B storefronts.
Why it decides a platform: Reorder only works if order history is complete, which means orders placed by phone, by EDI and by a sales rep have to appear alongside the online ones. That is an integration requirement rather than a feature toggle.

Replenishment ordering

Replenishment ordering is a recurring order that repeats on a schedule, so a customer receives the same items at the same interval without placing an order each time. It is the B2B version of a subscription.
Why it decides a platform: Subscription tooling on commerce platforms is built for consumer retail with a card on file. B2B replenishment on account at contract prices breaks most of those assumptions.

Requisition list

A requisition list is a saved list of items a buyer keeps for repeat ordering, sometimes shared across everyone at their company. Platforms also call these shopping lists, saved carts or favourites.
Why it decides a platform: Shared lists are what let a customer standardize what all of their sites order. Lists that are private to one login do not do that, and the difference is easy to miss in a demo.

REST API

A REST API is the most common style of web API, where each type of record has an address and standard verbs read or change it. Most ERP and commerce integrations are built on REST, with GraphQL as the other common option.
Why it decides a platform: API style matters less than what the API exposes and how quickly it responds. A REST API missing the price fields you need is worse than a GraphQL one that has them.

RMA

An RMA, or return merchandise authorization, is the record that authorizes a customer to send goods back and tells the warehouse what to expect. Without one, returns arrive unannounced and cannot be matched to an order.
Why it decides a platform: Returns are the part of a customer relationship most likely to end it, and the part most often left out of a commerce scope. Deciding early that the ERP owns the RMA saves rebuilding the workflow later.

Safety stock

Safety stock is a quantity held back as a buffer so the last few units are not sold online. Sellers often publish availability net of that buffer so the storefront cannot sell into it.
Why it decides a platform: Publishing raw on-hand quantity instead of on-hand minus the buffer is a common connector default and a common cause of oversells. It is a configuration decision that nobody was asked to make.

Sandbox

A sandbox is a separate copy of a system used for testing, so changes can be tried without touching live data. Staging is the same idea applied to the storefront.
Why it decides a platform: An integration cannot be tested safely without a sandbox on both sides, and an ERP sandbox is sometimes an extra licence. Discovering that during build is a schedule problem.

Shopify Plus

Shopify Plus is Shopify’s enterprise tier, adding higher API limits, checkout customization, multiple linked stores and account management. Shopify’s B2B features require Plus.
Why it decides a platform: Any Shopify B2B evaluation is really a Plus evaluation, which changes the cost comparison against BigCommerce or Shopware. A feature list that does not say which tier a capability belongs to cannot support a decision.

Single sign-on

Single sign-on lets people use one set of credentials, usually their work account, across several systems. In commerce it shows up both for staff logging into the admin and for buyers logging into a portal.
Why it decides a platform: Enterprise customers increasingly require single sign-on for any portal their staff use, and it is not universally available on mid-market commerce platforms. It is worth asking before the customer does.

SKU

A SKU is the code a business uses to identify one specific sellable item, including its size, colour or pack. It is internal to your business, unlike a UPC or EAN, which identifies the product globally.
Why it decides a platform: The SKU is the join between the ERP and the storefront, so any inconsistency in how SKUs are formed becomes an integration problem. Trailing spaces, case differences and legacy renames all break matching quietly.

Source of truth

The source of truth is the system that gets to be right when two systems disagree. For price, stock and customer terms in an ERP-run business, that is almost always the ERP.
Why it decides a platform: Most integration arguments are really an unresolved source-of-truth question. Deciding it up front, field by field, removes more risk from a commerce project than any platform choice.

Storefront

The storefront is the customer-facing part of a commerce system: the pages people browse, the search, the cart and the checkout. The back end that holds products, prices and orders is a separate concern.
Why it decides a platform: Separating the two settles most platform arguments. Complaints about how a site looks are storefront problems, complaints about what it can price are back-end problems, and only one of those is fixed by a redesign.

Storefront API

A storefront API is the read and cart API a commerce platform exposes for building a custom front end, as distinct from the admin API used to manage data. Shopify’s is named the Storefront API.
Why it decides a platform: What the storefront API exposes sets what a headless build can do, and B2B fields such as company-specific prices tend to arrive there later than they arrive in the admin API. Check the specific fields rather than the general claim of API support.

Tax nexus

Nexus is the connection that obliges a seller to collect tax in a jurisdiction, created by having a location, staff, inventory or enough sales there. In the United States it varies by state and includes thresholds based on sales volume.
Why it decides a platform: Nexus decides where the storefront has to calculate tax at all, and it changes as the business grows. It is a finance decision the commerce project implements, not the other way round.

Trade credit

Trade credit is the practice of shipping goods and invoicing later, typically on 30-day terms, rather than taking payment when the order is placed. It is the default in most B2B relationships.
Why it decides a platform: A checkout that requires a card excludes every customer who buys on account. Supporting payment by invoice, gated on the credit status held in the ERP, is usually a launch requirement rather than a phase two.

Unit of measure conversion

Unit of measure conversion is the rule that says one case equals twenty-four eaches, so a customer can buy in the unit that suits them while stock is counted in the unit that suits the warehouse.
Why it decides a platform: Selling in a unit the ERP does not price in is a classic source of wrong prices on a B2B storefront. If the sales unit and the base unit differ and the connector does not convert, the number on the page is wrong by whatever the conversion factor is.

Variant

A variant is one buyable version of a product, such as a specific size and colour combination. Each variant normally carries its own SKU, price and stock figure.
Why it decides a platform: Variant limits are a hard constraint rather than a preference. Shopify caps how many options and variants a product can have, so an ERP matrix item with more attributes than the cap cannot be represented as a single product. Check the current limit for the plan you are on.

Volume pricing

Volume pricing gives a lower unit price at higher quantities, set by break points such as nine or fewer, 10 to 99, and 100 or more. The break points and the prices normally come from the ERP.
Why it decides a platform: Volume breaks are the most common form of B2B pricing after contract pricing, and the two frequently apply at once. A platform that handles either one alone but not both together will misprice a large share of orders.

Webhook

A webhook is a message one system sends the moment something happens, so the other does not have to keep asking. An order placed on the storefront can fire a webhook that pushes it to the ERP within seconds.
Why it decides a platform: Webhooks are how an integration feels immediate, and they fail silently. Any design that relies on them needs a way to detect and replay missed messages, or the day the receiver is down becomes a day of lost orders.

Will call

Will call is a customer collecting an order at the counter or the warehouse instead of having it shipped. Consumer platforms call the equivalent BOPIS or click and collect.
Why it decides a platform: Will call needs a per-location pickup option, availability by that location, and a ready-for-pickup notification. Platforms built around shipping treat pickup as an afterthought and often cannot tie it to the right branch.

WMS

A warehouse management system runs the inside of the warehouse: where stock sits, how pickers are routed, and how shipments are packed and confirmed. Some ERPs include one, and larger operations often run a separate product.
Why it decides a platform: Where a WMS is in play, it and not the ERP may hold the freshest stock position. Integrating the storefront to the ERP while the WMS is where reality lives produces availability that is always slightly behind.