When a major retailer like Dillard’s or Bloomingdale’s sends your brand a single purchase order for dozens of store locations, your ERP needs to handle each destination separately. Fulfillment happens in parallel, across different Sales Orders, different timelines, and different warehouse picks. But when it comes time to confirm the shipment back to the retailer, many trading partners expect one thing: a single EDI 856 Advance Ship Notice that ties everything together.
That gap between how your ERP processes orders and how your trading partner expects to receive shipment confirmations is where things break down. This article walks through how brands running NetSuite and Celigo handle multi-store EDI purchase orders, split them into individual Sales Orders per destination, and then consolidate all the resulting fulfillments into one ASN for the trading partner.
The EDI Challenge with Multi-Store Purchase Orders
Large retailers operate hundreds or even thousands of store locations. When they place orders with wholesale suppliers, they often send a single EDI 850 Purchase Order that covers every destination at the line level. Each line item includes a Store Destination Quantity (SDQ) segment specifying how many units go to which store.
A single PO might say: send 3 units of SKU-A to Store #2, 3 units to Store #6, 1 unit to Store #10, and 2 units to Store #53. All in one document.
For the retailer, this is efficient. For the supplier running NetSuite as their ERP, it creates a real operational question: how do you represent that in your system?
Most NetSuite environments are set up with a separate customer record per store location, or at least a separate ship-to address per destination. That means one inbound EDI 850 needs to become multiple Sales Orders inside NetSuite, each one tied to a specific store and containing only the items and quantities bound for that destination.
This is standard practice for wholesale brands doing business with retailers like Dillard’s, Bloomingdale’s, Nordstrom, or Target. The splitting logic runs inside the integration layer, typically Celigo, where the inbound 850 data is parsed, grouped by store ID, and used to generate individual Sales Orders in NetSuite.
So far, so good. But the real complexity starts after fulfillment.
What Happens After the Split: Fulfillment and the ASN Problem
Each of those Sales Orders gets fulfilled independently in NetSuite. That means each one generates its own Item Fulfillment record, representing the physical shipment of goods for that specific store destination.
If the original PO was split into five Sales Orders (one per store), you now have five Item Fulfillments in NetSuite.
Here’s where trading partner requirements diverge. Some retailers are fine receiving multiple ASNs, one per shipment, each referencing the same original PO number. Others, like Dillard’s, require that the supplier consolidate all shipments back into a single EDI 856 Advance Ship Notice. One document, covering everything that was ordered, regardless of how many internal fulfillment records were created.
An EDI 856, also called an Advance Ship Notice or ASN, is the electronic document a supplier sends to a retailer confirming that goods have shipped. It includes details like shipment dates, carrier information, tracking numbers, item quantities, and packaging hierarchy (cartons, pallets, weights). Retailers use the ASN to prepare for receiving at their distribution centers or stores. Late or inaccurate ASNs frequently result in chargebacks, receiving delays, and compliance violations.
The consolidation requirement means your integration needs to do something that NetSuite does not handle natively: gather fulfillment data from multiple Sales Orders, group it by the original PO reference, and assemble it into a single outbound 856 document.
How EDI ASN Consolidation Works in a NetSuite and Celigo Integration
The solution sits in the integration layer between NetSuite and the EDI translator (such as Orderful, SPS Commerce, or TrueCommerce). Here is the step-by-step flow:
Step 1: Inbound EDI 850 with multi-store destinations. The trading partner sends a single purchase order. At the line level, SDQ segments specify quantities per store location.
Step 2: PO splitting into multiple NetSuite Sales Orders. The Celigo integration parses the 850, groups line items by store ID, and creates one Sales Order in NetSuite for each destination. If the brand has separate customer records per store in NetSuite, each Sales Order is assigned to the correct customer. If they use a single customer with multiple ship-to addresses, the Sales Order references the appropriate address.
Step 3: Independent fulfillment per Sales Order. Warehouse operations pick, pack, and ship each store’s order separately. Each fulfillment generates an Item Fulfillment record in NetSuite with shipment details: carrier, tracking number, quantities shipped, weights, and carton-level data.
Step 4: ASN consolidation across fulfillments. This is where the integration does the heavy lifting. Instead of sending one 856 per Item Fulfillment, the outbound flow collects all Item Fulfillments that trace back to the same original PO. It groups the shipment data, merges the line-level detail, and builds a single EDI 856 that covers every store destination.
Step 5: Outbound 856 to the trading partner. The consolidated ASN is transmitted to the retailer through the EDI translator. From the retailer’s perspective, they see one shipment confirmation against their original purchase order.
Step 6: Invoicing. After the ASN, invoices (EDI 810) can be sent individually per Sales Order or grouped. Most trading partners accept multiple invoices against a single PO without issue, so the consolidation pressure applies primarily to the ASN.
Core Components of the Consolidation
The consolidation logic handles several things at once:
- PO reference tracking. Every Sales Order created from the split must carry the original PO number so that fulfillments can be traced back and grouped correctly during the ASN build.
- Store-level detail preservation. The consolidated 856 still needs to identify which items went to which store, even though the data is coming from separate fulfillment records.
- Carton and pallet hierarchy. Many retailers require ASNs to include packaging details (SSCC codes, carton contents, pallet structure). The consolidation must merge this hierarchy across fulfillments without duplicating or losing data.
- Timing coordination. The ASN should not be sent until all fulfillments for a given PO are complete, or until a defined cutoff is reached. This requires monitoring fulfillment status across multiple Sales Orders.
The actual transformation happens in code within the Celigo integration, either through hooks (preSavePage, postMap, or postSubmit scripts) or through custom export logic that queries NetSuite for all related fulfillments before building the outbound document.
Use Cases for Mid-Market Product Brands
This pattern shows up across multiple verticals. Any brand selling wholesale to multi-location retailers will encounter it eventually.
Fashion and apparel brands selling to department stores like Dillard’s, Bloomingdale’s, or Nordstrom regularly receive consolidated POs covering dozens of store locations. The ability to split inbound orders, fulfill by destination, and consolidate the ASN is a baseline requirement for maintaining EDI compliance with these partners.
Food and beverage brands deal with a similar pattern when selling to grocery chains or large distributors. EDI 875 (the grocery-specific purchase order) and EDI 880 (grocery invoice) follow the same structural logic as the standard 850/810, with store-level destination quantities driving the same split-and-consolidate workflow.
Beauty and wellness brands expanding into retail distribution through chains like Ulta, Sephora, or Target face the same multi-store PO structure. As order volumes grow, manual handling becomes impossible, and the ASN consolidation requirement is typically non-negotiable.
Accessories and footwear brands working with retailers across department stores and specialty chains encounter this pattern as soon as they move beyond a single distribution center model. Multiple trading partners, each with their own ASN requirements, adds another layer of configuration to the integration.
The common thread: once a brand is shipping to retailers with multiple locations, the PO splitting and ASN consolidation pattern becomes part of the operational infrastructure.
Operational Benefits of Automated ASN Consolidation
Getting this right has direct impact on day-to-day operations and trading partner relationships.
EDI compliance and chargeback prevention
Retailers impose penalties for late, missing, or incorrectly formatted ASNs. Automating the consolidation removes the risk of manual errors and ensures the 856 matches the retailer’s expected format. For brands shipping to 20, 30, or 50 trading partners, this is not optional.
Reduced manual work in the warehouse and operations team
Without automation, someone has to manually track which fulfillments belong to which PO, assemble the ASN data in a spreadsheet or portal, and submit it before the retailer’s deadline. That process does not scale once a brand is managing dozens of wholesale accounts.
Accurate inventory and order visibility
Because each store destination has its own Sales Order in NetSuite, operations teams can track fulfillment status per location. Finance can reconcile invoices against individual deliveries. The split-and-consolidate model gives better granularity inside NetSuite while still meeting the retailer’s expectation of a unified ASN externally.
Scalable architecture for adding new trading partners. The core logic (split PO by store, fulfill independently, consolidate ASN) is reusable across retailers. When a new wholesale partner comes on board with similar requirements, the integration framework is already in place. Partner-specific formatting rules are handled in configuration, not by rebuilding the flow from scratch.
Scalable architecture for adding new trading partners
The core logic (split PO by store, fulfill independently, consolidate ASN) is reusable across retailers. When a new wholesale partner comes on board with similar requirements, the integration framework is already in place. Partner-specific formatting rules are handled in configuration, not by rebuilding the flow from scratch.
Why Companies Work with Hairball on EDI Integration
EDI integration for wholesale brands is not a plug-and-play project. Every trading partner has specific requirements for document formatting, timing, field mapping, and compliance rules. The 856 ASN is one of the most complex EDI documents because it carries detailed shipment, packaging, and logistics data that varies significantly by retailer.
Hairball specializes in building these integrations on Celigo and NetSuite. Beyond the initial build, Hairball provides fully managed EDI solutions, covering trading partner onboarding, proactive monitoring, and ongoing compliance, so your team is not the one catching errors before a retailer’s deadline.
The team has implemented Celigo EDI NetSuite integrations for brands shipping to retailers across fashion, food and beverage, beauty, and lifestyle categories. The work involves configuring PO splitting logic per trading partner, building ASN consolidation flows, handling partner-specific compliance rules, and testing end-to-end before go-live.
This is integration architecture, not generic consulting. The value is in knowing how NetSuite Item Fulfillments map to EDI 856 hierarchies, how SDQ segments should drive Sales Order creation, and where the edge cases hide when a retailer changes their routing guide mid-season.
Key Takeaways
- Large retailers frequently send a single EDI 850 Purchase Order covering multiple store destinations, using SDQ segments to specify quantities per location.
- In NetSuite, this requires splitting the PO into individual Sales Orders per store, each fulfilled independently.
- Some trading partners, like Dillard’s, require that all resulting fulfillments be consolidated into a single EDI 856 Advance Ship Notice.
- The consolidation logic runs in the Celigo integration layer, grouping fulfillments by original PO reference and building one outbound ASN document.
- This pattern is common across fashion, food and beverage, beauty, and accessories brands selling wholesale to multi-location retailers.
- Automating the split-and-consolidate workflow prevents chargebacks, reduces manual effort, and creates a reusable framework for onboarding new trading partners.
Frequently Asked Questions
What is EDI ASN consolidation?
EDI ASN consolidation is the process of combining shipment data from multiple fulfillment records into a single EDI 856 Advance Ship Notice. This is required when a retailer sends one purchase order covering multiple store locations, and the supplier’s ERP (like NetSuite) creates separate fulfillment records per destination. The consolidated ASN ties all shipments back to the original PO in one document.
How does a single EDI 850 become multiple Sales Orders in NetSuite?
When a retailer’s EDI 850 includes Store Destination Quantity (SDQ) segments, the integration platform (such as Celigo) parses the line-level data, groups items by store ID, and creates one NetSuite Sales Order per destination. Each Sales Order carries the original PO number for traceability and is assigned to the appropriate customer or ship-to address in NetSuite.
What role does Celigo play in EDI integrations with NetSuite?
Celigo is an integration platform (iPaaS) that connects NetSuite to EDI translators and other systems. In EDI workflows, Celigo handles inbound document parsing (converting EDI 850s into NetSuite Sales Orders), outbound document generation (building EDI 856 ASNs from Item Fulfillments), and the transformation logic in between, including PO splitting, ASN consolidation, and partner-specific formatting rules.
When should a growing brand invest in EDI automation for wholesale?
Brands typically need EDI automation once they are shipping to retailers that require electronic document exchange, usually starting with the first major department store or grocery chain account. If your team is manually processing purchase orders, building ASNs in spreadsheets, or dealing with repeated chargebacks for compliance issues, it is time to automate. The operational cost of manual EDI handling increases quickly as trading partner count grows.
What is the difference between EDI 850 and EDI 875?
EDI 850 is the standard purchase order used across most industries. EDI 875 is the grocery-specific purchase order used in the food and beverage industry. They serve the same function within the order-to-cash process, with the 875 including fields and segments specific to grocery supply chain requirements. Similarly, EDI 810 (standard invoice) has a grocery counterpart in EDI 880.
Do all retailers require consolidated ASNs?
No. ASN consolidation requirements vary by trading partner. Some retailers accept multiple ASNs per purchase order (one per shipment or store destination). Others, like Dillard’s, require all shipments from a single PO to be consolidated into one EDI 856 document. The specific requirement is defined in each retailer’s EDI implementation guide or routing guide, and the integration must be configured accordingly.