Field Analysis

Distributor self-service on Acumatica: serving many accounts at once

Distribution is where self-service either scales or collapses. Thousands of accounts, each with its own pricing, several warehouses, and a mix of B2B and direct buyers is more variation than a team can handle by hand. Acumatica already encodes most of that logic, which changes what the storefront has to do.

A distributor's self-service problem is not really a volume problem, it's a variation problem. Every account can have its own price list, its own terms, its own ship-to locations, and its own approval chain. Multiply that by several warehouses and two or three channels and you get a combinatorial mess that no amount of manual maintenance survives.

Which is why the architecture question matters more here than anywhere else in self-service. If the storefront holds its own copy of pricing and stock, someone has to keep thousands of records synchronized and eventually two systems disagree in front of a customer. If the storefront reads from the system that owns the rules, the number of accounts stops being an architectural problem.

What Acumatica already handles

For distributors this is the useful part, because most of the variation is already modelled. Acumatica's pricing engine handles customer-specific prices and customer price classes with volume and promotional pricing applied together, and prices can be defined per warehouse and per unit of measure. Sales price worksheets let a team roll new prices across an item class or product line rather than record by record, which is what makes thousands of account prices maintainable at all.

Inventory is handled across multiple warehouses with location-level quantities, allocations, and costs, tracked in real time, with default locations for receipts and shipments and automated replenishment between central warehouses and branches. Order management adds real-time credit checks and quotes converting to sales orders in a click. For a distributor, that combination is the hard part of the problem already solved.

The native Customer Self-Service Portal then exposes a controlled slice of it. Acumatica describes business partners browsing inventory and placing orders around the clock, tracking order and shipment status, and viewing invoices, with control over which products each user sees and which warehouses goods can ship from. Pricing and inventory stay current because the portal runs against the same database as the rest of Acumatica.

Where the storefront has to take over

The native portal's limits show up exactly where distribution gets complicated. Acumatica doesn't document parent and child company hierarchy for the portal, nor approval workflows, saved lists and reorder flows, buyer-initiated quotes, or punchout. It also isn't built to be a findable, searchable storefront with real content and search engine visibility.

Those gaps matter more at scale than they do for a single-site manufacturer. A distributor selling to dealer groups needs a parent account with many locations and buyers, thresholds that route an order to an approver, and often a procurement system connecting directly. A distributor selling both B2B and direct needs one product catalogue behaving differently for two audiences.

So the pattern that works is a division of labour rather than a choice of winner. Acumatica stays the system of record for pricing, availability, credit, and order status. The storefront, whether a supported platform through one of Acumatica's native connectors or a decoupled build, owns the buying experience, the account structure the ERP doesn't model, and discovery. Neither tries to do the other's job.

What this looks like in practice

Acro's own Acumatica work with Accurate Industries is a fair illustration of the integration half, and it's worth being precise about the scope. Accurate Industries is the largest distributor of steam room and sauna equipment, accessories, and parts in the US, running Acumatica as the source of product data with a Drupal Commerce storefront across direct and B2B domains, including specialized discount pricing.

The two systems didn't talk out of the box. We generated an API client from Acumatica's OpenAPI specification, found it wasn't sufficient on its own, and built a PHP Acumatica API library and a Drupal integration module to connect them bi-directionally, synchronizing products, customers, pricing, and sales orders. Both components are public.

Two honest caveats. This is an integration and pricing-sync engagement rather than a dealer portal build, and we haven't published performance metrics for it, so we're not claiming any. What it demonstrates is the architecture: the ERP kept the commercial logic, the storefront rendered it, and the connector was the deliverable that made per-account pricing work across two audiences.

What to take from this

1. Keep the rules in one place – Per-account pricing and availability belong in Acumatica. A storefront that renders them scales with account count; one that copies them doesn't.
2. Maintainability is the real constraint – Sales price worksheets and price classes are what make thousands of account prices survivable. Model pricing so it can be rolled in bulk.
3. Expect to add account structure – Parent and child hierarchy, approval thresholds, and punchout usually come from the storefront layer, not the native portal.
4. Commit only what you can ship – Location-level availability with a clear promising rule beats an approximate number, because customers act on what they see.

For the manufacturer view of the same foundation, see dealer portals on Acumatica. For sequencing the build, see what a portal needs to include and the rollout piece.

Frequently Asked Questions

Next Step

Get the foundation right before you build.

For readers scoping a platform decision or wanting a full architecture recommendation.