Distribution runs on document flows that have to be accurate, timely, and traceable — inbound EDI purchase orders, warehouse dispatches, fulfilment confirmations, and invoices sent back. When any of those steps is manual or unreliable, it shows up as a failed SLA, a compliance penalty, or a warehouse backlog. Entech builds the Celigo integrations that keep that chain running without manual intervention.
Talk to an integration expert →Most distribution operations have an ERP that's reasonably well configured and a set of trading partners with established EDI requirements. The problem isn't either of those things in isolation — it's the gap between them. NetSuite knows what's on order. The retailer's EDI system knows what purchase orders have been sent. The 3PL knows what's in the warehouse. None of them share that information reliably without integration, which means someone is doing manual reconciliation across all three to keep operations running.
The EDI side in particular tends to get underestimated. Retailer EDI requirements are not generic — they're documented, specific, and come with test suites. A 997 functional acknowledgement has to go back within a defined window. An 856 ASN has to match the 850 PO line items exactly or the trading partner raises a chargeback. Getting this right in a test environment is one problem; maintaining it across multiple trading partners with different requirements is a different one. Celigo B2B Manager handles the infrastructure; Entech handles the configuration and ongoing maintenance.
The warehouse and 3PL layer adds its own complexity. The EDI 940 warehouse shipping order has to go to the right fulfilment partner with the right format for their WMS. The 945 shipment confirmation coming back has to close the loop in NetSuite before the 810 invoice can go out. Each step has a dependency on the previous one. If any step is manual, it becomes the bottleneck — and usually the source of the error that causes the chargeback.
Inbound 850 purchase orders parsed by Celigo B2B Manager and mapped to NetSuite Sales Orders, with automated 997 functional acknowledgements generated within the trading partner's SLA window. Outbound 856 ASNs generated on shipment confirmation and transmitted back to the retailer. Outbound 810 invoices generated from NetSuite on invoice creation. Error isolation for malformed documents within multi-transaction files. Trading partner onboarding and test validation included in scope.
Outbound EDI 940 warehouse shipping orders generated from NetSuite Sales Orders and transmitted to the 3PL endpoint — EDI-capable, SFTP, or direct API — on fulfilment authorisation. Inbound 945 shipment confirmations received from the 3PL and written back to the NetSuite Sales Order with shipment date, carrier, and tracking numbers. Inventory positions pulled from the WMS into NetSuite on a scheduled or event-driven basis to keep on-hand counts accurate.
Item master data maintained in NetSuite and pushed to connected systems — 3PL WMS, ecommerce storefronts, marketplace listings — to keep product data consistent without manual re-entry. Inventory adjustments from warehouse receipts and returns written back to NetSuite in real time. Multi-location stock aggregation for businesses with multiple warehouse locations or a mix of owned and 3PL inventory. Discrepancy alerting where system positions diverge beyond a defined threshold.
Purchase orders raised in NetSuite transmitted to suppliers via EDI, SFTP, or API. Supplier acknowledgements, advance shipment notices, and item receipts parsed and written back against the originating PO. Lead time updates and quantity changes surfaced to the relevant NetSuite record rather than sitting in an email thread. Vendor bill creation automated on item receipt confirmation. The full inbound supply chain visible in the ERP without manual data entry at any step.
Orders from ecommerce channels, marketplaces, and B2B customers centralised into NetSuite as Sales Orders with correct subsidiary, location, and fulfilment routing. Channel tagging and revenue attribution applied at order creation so finance has a clean multi-channel view without manual categorisation. Fulfilment status, tracking information, and delivery confirmations written back to the originating channel. Return and cancellation handling included in scope — not as a later phase. For B2B wholesale customers with EDI requirements, the order channel connects directly into the B2B Manager flow rather than sitting outside it.
A branded consumer goods company with retail trading partner EDI requirements was re-keying inbound 850 purchase orders from retailers into their OMS by hand. Generating warehouse shipping orders to their 3PL took hours of manual effort per order cycle. Walmart-tier EDI SLA requirements — specifically the 997 functional acknowledgement window — were at risk on high-volume days.
Entech configured Celigo B2B Manager to parse inbound 850 purchase orders, map them to NetSuite Sales Orders, and generate automated 997 functional acknowledgements within the retailer's SLA window. On Sales Order creation, an outbound EDI 940 warehouse shipping order is automatically generated and transmitted to the 3PL endpoint. The 3PL receives warehouse authorisation within two minutes of retailer PO transmission. End-to-end latency went from hours to under two minutes. No human touches the order between the retailer's transmission and the 3PL's receipt.
The Celigo B2B Manager provides the infrastructure — transaction set definitions, partner envelope configuration, AS2 and VAN transport. It doesn't provide your specific retailer's field requirements, qualifier codes, or segment usage rules. Those are documented in each trading partner's implementation guide and they vary. Walmart's 850 mapping is not the same as Target's. We configure and test against each partner's specifications individually. There is no shortcut through this.
Some 3PLs accept EDI. Some have a REST API. Some have an SFTP endpoint with a proprietary flat-file format. The integration approach is determined by what the WMS exposes, not by what would be convenient. We've built against EDI-capable 3PLs, direct API partners, and flat-file SFTP endpoints with custom parsing logic. The 3PL integration scope needs to be confirmed against the specific partner and their WMS before any timeline estimate is valid.
If NetSuite holds the inventory position and the 3PL WMS holds a different number, someone has to decide which one is authoritative and under what conditions. Before any inventory sync is built, the source-of-truth question has to be answered per record type, per location, and per update scenario. An integration that doesn't resolve this upfront will produce conflicting positions within days of go-live and require manual correction indefinitely.
A single-warehouse, single-3PL operation is relatively straightforward to integrate. Adding a second warehouse location, a second 3PL, or a domestic and international fulfilment split introduces routing logic that has to be defined explicitly — which orders go where, under what conditions, what happens when a preferred location is out of stock, how inventory positions aggregate across locations. This is conditional business logic that lives in the integration layer. We scope it at the design stage, not mid-build.
Distribution integrations have real operational consequences. A failed 997 acknowledgement triggers a chargeback. A missing 940 means the warehouse doesn't ship. An inventory discrepancy means an oversell or a missed order. The stakes are higher than a typical data sync, which means the design phase matters more than it does for most integration work.
Our approach starts with a document flow map — not a requirements document. We trace every transaction from origination to final state: where it starts, what system creates it, what the downstream system requires, what happens on update, what the SLA obligation is if there is one, and what the failure state looks like. For EDI work, this map is validated against each trading partner's implementation guide before any B2B Manager configuration begins. For 3PL work, it's validated against the WMS documentation or an integration spec provided by the 3PL's technical team.
The EDI and B2B Manager methodology behind these workflows →
Read the EDI / B2B capability page →A failed acknowledgement triggers a chargeback. A missing warehouse dispatch means an unfulfilled order. These aren't edge cases — they're what happens when the integration isn't built correctly. We've delivered EDI and 3PL integrations for distribution clients where the SLA obligations are real and the cost of getting it wrong is measurable. If you have a specific trading partner requirement or warehouse flow in mind, we're happy to talk through what build would actually look like.