Field Analysis

Dealer portals on Acumatica: what a custom manufacturer's rebuild shows

Mid-market manufacturers running Acumatica often find the dealer-portal integration question shorter than peers on other ERPs. Acumatica's customer-specific pricing, multi-warehouse availability, and account hierarchy are already exposed in a way a portal can call. The architecture choice becomes which commerce front end best renders that record. This field analysis reads the pattern across the published customer cases Acumatica lists for manufacturer dealer portals.

Why Acumatica shortens the integration conversation

Most portal projects spend their first months answering where each number comes from. On Acumatica much of that is settled. The pricing engine handles customer-specific prices and price classes alongside volume and promotional pricing, definable per warehouse and unit of measure. Inventory carries location-level quantities, allocations, and costs across multiple warehouses in real time. Order management covers quotes converting to sales orders and real-time credit checks.

The architecture matters more than any single feature. Acumatica's self-service portal reads current inventory and pricing because it's built on the same database as the rest of Acumatica. No synchronization layer, no staleness window, and none of the pricing and availability errors that buyers punish.

Above that sits a contract-based REST API, versioned in the URL, so an integration binds to a stable business object rather than a screen layout. That's what keeps it working through upgrades and customizations.

What the Lustre build actually shows

Lustre Products makes custom elevator handrails and safety barricades, the high-volume, one-off work most shops turn down. It runs on Acumatica. About 85% of its orders still arrived on a 25-column paper worksheet that had been the industry standard for 35 years.

That worksheet survives because it works. The shop floor reads and builds from it at a glance, and it carries information the ERP had no way to express. Acumatica could store the order data, but its configurator produced text, not a validated visual build. Moving order entry into the ERP made the process slower, because the same specifications got keyed twice.

Every order needed a manual math check before it reached the floor. A person re-entering specifications by hand is a person who can put 38 inches of hardware on a 37-inch rail, and that error doesn't surface until the product is built.

"Light years ahead."

 Lustre Products sales team, on an early prototype of the visual configurator

Two competitors had meanwhile started winning on buying experience rather than product. Their handrails aren't better. Their ordering is cleaner, and when a customer can't see a quality difference, they choose on what they can see.

This is a configuration problem before it's a portal problem, which is exactly why it belongs here. A dealer portal promises that the system can answer a customer's question correctly and instantly. A business that can't validate its own order form can't make that promise, whatever it puts on the front end.

What still has to be built above the ERP

Manufacturers on Acumatica get into trouble by assuming the native self-service portal is a commerce platform. Acumatica is clear that it isn't. The Customer Self-Service Portal covers online ordering against distribution data, current pricing and inventory, a controlled catalogue with per-user visibility and warehouse ship-from control, online payments, invoice and balance history, and case management. That's a solid ERP self-service surface.

What Acumatica doesn't document for that portal is worth stating carefully, because absence of documentation isn't absence of capability: saved lists and reorder flows, buyer-initiated requests for quote, approval workflows, parent and child company hierarchy, punchout, and the findability of a real storefront. Product configuration of the kind Lustre needs sits outside it too. For B2B commerce Acumatica's strategy points to its native connectors for Amazon, BigCommerce, and Shopify, with Adobe Commerce available through a partner-built connector for an additional fee.

At Lustre the work is phased, architecture first. The visual configurator comes first, so no order can be built from an invalid combination. Then a headless Shopware storefront and a connector that pushes structured orders into the ERP with no re-keying. Standard parts and configured products share one cart. Acumatica stays the system of record, and the commerce layer reads live pricing, inventory, and customer data from it.

So the decision on Acumatica is a three-way one, the same one the pre-built versus custom comparison works through. Use the native portal when the need is account self-service for existing customers. Use a native connector when you sell in fairly standard ways through a supported storefront. Build decoupled when dealer hierarchy, configuration rules, or a blended direct and dealer experience exceed what a package expresses.

What to take from this

• Find what the ERP can't express – Acumatica held Lustre's order data perfectly well. It couldn't validate a configuration, and that gap kept 85% of orders on paper.
• One database is an architectural advantage – Reading pricing and availability from the system that owns them removes the sync gap where most portal data errors start.
• The native portal is not a storefront – It's strong at account self-service. Decide which problem you have before choosing.
• Bind to the API, not the screens – The contract-based REST API is versioned, which keeps an integration working through upgrades.

For how distributor self-service scales across many accounts and warehouses, see distributor self-service on Acumatica. 

Frequently Asked Questions

Next Step

Get the foundation right before you build.

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