Both are called “integrated.” Only one stops pricing errors and inventory oversells from reaching your customers.
TL;DR
- Batch sync updates your portal on a schedule — hourly, nightly, or manually triggered. Real-time sync queries your ERP at the exact moment a buyer requests data.
- For customer-specific pricing: batch sync means a buyer may see a price that changed since the last sync. Real-time means they always see their current contract rate.
- For inventory: batch sync means a product may show “in stock” after it sold out between sync windows. Real-time eliminates oversells.
- Most B2B eCommerce platforms default to batch sync. Real-time requires an API architecture.
- For B2B operations with contract pricing and multi-location inventory, real-time sync is not a nice-to-have. It’s the difference between a portal buyers trust and one they abandon.
“We’re integrated with our ERP” is one of the most misleading statements in B2B eCommerce. Nearly every manufacturer and distributor with a portal says it. But the integration they’re describing is usually a batch export that runs every few hours — sometimes every night — not a live connection to the ERP.
Batch sync and real-time sync are both integrations. They produce entirely different customer experiences. And for B2B operations where pricing is customer-specific and inventory turns over daily, that difference shows up as pricing errors, oversells, and buyers who stopped trusting the portal six months ago.
What Batch Sync Is and How It Works
Batch sync moves data between your ERP and your portal on a schedule. The ERP generates an export file — product data, pricing, inventory levels — and the portal imports it at a defined interval. Common configurations:
- Nightly sync: Portal data reflects ERP state from last night. Any changes made today aren’t visible until tomorrow.
- Hourly sync: Better, but still a window. An order placed 45 minutes ago may not be reflected in current inventory.
- Event-triggered batch: Better still — sync fires when specific ERP events occur. Still not real-time; there’s processing and transfer latency.
Batch sync is the default in most B2B eCommerce platform implementations because it’s simpler to build. It doesn’t require the ERP to expose a live API. It doesn’t require the portal to make real-time calls. It works in environments where the ERP is older, the IT resources are limited, or the integration was scoped as “basic.”
For product catalog updates and marketing content, batch sync is fine. Products don’t change hourly. Images don’t change daily. A nightly sync for catalog content is entirely adequate.
For pricing and inventory at a B2B operation, it’s not.
What Real-Time Sync Is and How It Works
Real-time sync works differently. Instead of moving data on a schedule, the portal calls the ERP’s API at the moment the buyer requests the data. When a buyer loads a product page, the portal sends a query: “What is the current price for Account #7423 on Item #1234?” The ERP responds in real time — typically under 2 seconds — and the portal displays the result.
The same pattern applies to inventory: when a buyer checks availability, the portal queries the ERP’s inventory module for current available stock, not the import from three hours ago.
For orders: when a buyer places an order, it creates a record in the ERP immediately — not after the next batch run — and order status updates flow back to the portal as the ERP processes fulfillment.
Real-time sync requires two things: an ERP with a live API (REST or equivalent), and a portal integration architecture that calls that API rather than reading from a sync file. Most modern ERPs — Epicor P21, NetSuite, SAP Business One, Acumatica, Dynamics 365 — support this. The integration work is the differentiator.
Where Batch Sync Fails in B2B Operations
Customer-specific pricing
Your contract accounts have negotiated rates. Those rates change when contracts renew, when volume commitments are met, or when your pricing team runs an adjustment. With batch sync, a rate change in the ERP may not reach the portal for hours or until the next nightly sync.
A buyer places an order at 2 PM on a price that changed at 10 AM. Your system processed the order at the old rate. Someone on your team has to catch it, contact the buyer, and process a correction. That interaction costs rep time, buyer trust, and in some cases the order itself.
Real-time pricing queries eliminate this category of error. The portal calls the ERP at the moment the buyer requests pricing. Whatever the ERP says is current, the buyer sees.
Inventory oversells
A distributor with 50 units available at 8 AM does a batch sync. By 11 AM, three orders have consumed 35 units, leaving 15 available. The portal still shows 50. A buyer places an order for 20 units. There aren’t 20 units. Someone has to call the buyer and explain that the inventory they ordered on isn’t available.
This scenario happens at a predictable rate in batch-sync environments with active order flow. The cost is emergency fulfillment, customer service labor, and buyer trust that doesn’t fully recover.
Real-time inventory queries eliminate the window. When a buyer checks availability, the portal asks the ERP: “How many of Item #1234 are available right now?” The ERP responds with the current committed-to-available figure. Oversells on real-time inventory queries require a system error, not just a timing gap.
Order status visibility
With batch sync, order status updates from the ERP — confirmed, picked, shipped, invoiced — reach the portal on the sync schedule. A buyer who placed an order yesterday and checks their account today may see “pending” when the ERP shows “shipped” because the status sync hasn’t run.
That buyer calls your team to check. That call costs 5-10 minutes of support time. Multiplied across your active account base, it’s a significant weekly contact volume that adds zero value to either party.
Real-time order status queries pull directly from the ERP’s order management system when the buyer loads their account page. The status they see is the status in the ERP.
When Batch Sync Is Acceptable
Not everything needs to be real-time. Batch sync is appropriate for:
- Catalog updates: New product descriptions, images, technical specifications. These don’t change fast enough for batch sync to create problems.
- Customer account metadata: Company name, address, contact information. Updated infrequently.
- Historical order data beyond the current period: Order history from 12+ months ago. No operational urgency.
A hybrid architecture — real-time for pricing, inventory, and order status; batch for catalog and static account data — is common and appropriate. The key is being deliberate about which data flows real-time and which can tolerate latency.
How to Know Which Sync You Have
The test is simple. Ask your IT team or your eCommerce platform administrator:
Question 1: When I update a customer’s pricing in the ERP right now, how long until the new price appears in the portal?
- If the answer is “immediately” or “under 2 minutes” — real-time.
- If the answer is “next sync” or a specific time interval — batch.
Question 2: When a customer places an order online, how does it get into the ERP?
- If it arrives in the ERP within seconds and automatically — real-time order sync.
- If it arrives in a queue that someone processes or a batch runs — batch or manual.
Question 3: If I sell the last unit of a product through a phone order right now, how long until the portal shows “out of stock”?
- If the portal reflects it in under 2 minutes — real-time inventory.
- If it takes an hour or more — batch.
Most operations running batch sync have at least one story about the pricing error or the oversell it caused. If you’ve had those conversations, you know which one you have.
The Migration from Batch to Real-Time
Moving from batch to real-time sync for pricing and inventory is an API integration project. The work involves:
- Confirming the ERP has a live REST API that supports the required queries (pricing by customer, inventory by location, order placement)
- Building or updating the Adobe Commerce integration layer to call the API rather than read from sync files
- Testing pricing hierarchy queries across account types (base price, contract price, customer-specific override)
- Testing concurrent inventory queries under realistic load
- Replacing the batch order workflow with the real-time order placement endpoint
For operations currently on a batch-sync architecture, this work typically takes 4-6 weeks for a mid-size manufacturer or distributor using Epicor, NetSuite, SAP Business One, or Acumatica. It does not require a platform replacement or a new ERP.
HumCommerce has completed this migration for multiple clients who had existing Adobe Commerce deployments with batch ERP sync that was producing pricing errors. In every case, buyer trust and self-serve order volume improved within 60 days of the real-time integration going live.
Sources
- HumCommerce ERP integration implementation data, 2026
- Adobe Experience League, How to Integrate Adobe Commerce with SAP ERP for B2B Commerce, May 2026: https://experienceleague.adobe.com/en/perspectives/how-to-integrate-adobe-commerce-with-sap-erp-for-b2b-commerce
- Epicor P21 REST API documentation (epicor.com)
- NetSuite REST API documentation (oracle.com)
- SAP Business One Service Layer documentation (help.sap.com)
