Bergen Logistics connects to AIMS360 over a mix of REST API and CSV, with no X12 EDI at the warehouse end at all. AIMS360 still produces a conformant 856 for the retailer, because the carton level SSCC detail comes back on the shipment confirmation. Your 3PL does not have to speak EDI. We do.
There is no X12 envelope anywhere in this integration. Ship orders and shipment confirmations move over a REST API. Inbound advice and receipts move as CSV files over SFTP. Bergen never sends or receives a single EDI transaction. And the retailer at the other end still gets a fully conformant 856 advance ship notice, because AIMS360 builds it.
Retailer EDI and warehouse integration are two different jobs, and only one of them has to be EDI. AIMS360 runs the retailer side itself: the 850 purchase order comes in, and the 855 acknowledgement, 856 advance ship notice and 810 invoice go back on that retailer's routing guide spec. The warehouse side is separate, and it runs on whatever the warehouse can actually do. API, CSV, tab delimited, XML, flat file, or genuine X12 if they have it.
We describe the warehouse messages using the X12 numbers, 940, 943, 944, 945, 947, 832 and 846, because that is the shared vocabulary of the industry and everyone knows what a 940 means. It is not a statement about the file format. Bergen is the clearest example on our list: two of those messages travel as REST API calls, two travel as CSV over SFTP, and not one of them is an EDI envelope.
| The assumption | What is the case |
|---|---|
| Our 3PL has no EDI, so we cannot automate fulfillment | The warehouse connection can be API, CSV, tab delimited, XML or flat file. EDI capability at the warehouse is optional |
| If we use a 3PL we lose retailer EDI compliance | Retailer EDI stays in AIMS360 and is unaffected by where the goods sit. The warehouse never touches a retailer document |
| A 940 means an EDI file | A 940 means a ship order. How it travels is a transport decision made per warehouse |
| We need an EDI provider as well as the ERP | AIMS360 is the EDI. There is no separate translator or subscription in between |
| Modern ecommerce 3PLs are ruled out because they only have an API | An API is easier to integrate than EDI, not harder. It is the warehouses with neither that are the problem |
This matters commercially more than it sounds. If your ERP insists the warehouse must be EDI capable, your shortlist quietly shrinks to warehouses that have already built EDI, which excludes a large share of the modern ecommerce 3PLs, the ones with a clean API and no X12 at all. You would be ruling out good operators for a technical reason that has nothing to do with how well they pick, pack and ship.
| Message | Direction | Transport | What it carries |
|---|---|---|---|
| 940 | AIMS360 to Bergen | REST API | The ship order, serving as order or pick ticket depending on a system setting, with the pick number and the customer purchase order |
| 945 | Bergen to AIMS360 | REST API | Shipment confirmation carrying carton level detail, weights, tracking and the SSCC on each carton |
| 943 | AIMS360 to Bergen | CSV over SFTP | Inbound advice. What is arriving from production or another location and what to expect on the container |
| 944 | Bergen to AIMS360 | CSV over SFTP | The receipt, posting against the open purchase order or return line |
A hybrid connection like this is normal and it is usually the right answer rather than a compromise. An API suits the traffic where you want an immediate result and a rejection reason attached. Files suit the higher volume traffic where batching is efficient and a failure can be corrected and reprocessed rather than lost. What matters is not which transport a message uses, it is whether a failure is visible and recoverable.
This is the single most valuable mechanism in any 3PL integration and almost nobody explains it, so here it is in order.
Bergen packs the carton and assigns it an SSCC, the serial shipping container code that uniquely identifies that carton and appears on the GS1-128 label the retailer's dock will scan.
The shipment confirmation returns not just "shipped" but the full carton structure: which units are in which carton, the weight, the tracking and the SSCC.
The advance ship notice is a nested structure, shipment to order to carton to item. It cannot be built from a shipped quantity. It can only be built from the carton detail, which is exactly what came back.
The SSCC on the physical label matches the SSCC in the electronic notice. The carton is received without a discrepancy, which is where chargebacks come from.
Take any step out and the chain breaks. A warehouse that returns only a shipped quantity cannot support a compliant ASN no matter how good your ERP is, and an ERP that cannot consume carton level detail wastes a warehouse that does return it. When you are evaluating warehouses, the question is not "do you support ASN", because everyone says yes. It is "what carton level detail do you return on shipment confirmation, and does it include the SSCC."
Last reviewed 15 August 2026 by the AIMS360 integrations team.
Integration status and transports reviewed against the AIMS360 production configuration for this partner. Company facts checked against bergenlogistics.com and its parent company's published material in August 2026, and attributed to the publisher rather than stated as our own.
When a unit is found damaged at Bergen it does not simply disappear from the count, and it does not sit in sellable inventory waiting to be allocated to a customer who will never receive it. It moves to a ghost location: a warehouse position that exists in the record but is not available to sell.
Two things follow from that. The unit stops being promised to anyone, so you are not selling goods that cannot ship. And it stays visible, so damages remain a number you can look at and act on rather than shrinkage you discover at the next count. Warehouses that write damages straight off make your inventory look tidier and your loss harder to explain.
Attributed to Bergen and to its parent company rather than repeated as fact.
| What they publish | Detail |
|---|---|
| Company | Bergen Shippers Corp., trading as Bergen Logistics, founded 1998 and headquartered in North Bergen, New Jersey |
| Ownership | Elanders AB, a publicly traded Swedish group, acquired 80 percent in November 2021. Bergen operates as part of that group |
| Footprint | 18 locations published on their own site across the United States, Canada, the Netherlands, Sweden, Germany, the United Kingdom, Singapore, India, China, Brazil and Mexico |
| Team | Around 800 employees, published by the parent group for the 2025 financial year |
| Apparel handling | They describe themselves as experts in garment on hanger, and publish custom embroidery and branded packaging. Ticketing, steaming and pressing are not published on their own site |
| Channels | Omnichannel and ecommerce fulfillment, and subscription box fulfillment which they put at more than 20 million boxes a year into the US and Canada |
| Cross border | Freight forwarding with customs clearance, and bonded warehousing for duty deferment |
| Automation | Automated sorters, conveyors and packaging machines |
| Warehouse system | Their own proprietary cloud platform, currently presented as CloudX Systems. Older third party integration documentation refers to a custom system called Rex11 |
| Leadership | Charles Ickes was appointed chief executive in March 2024 |
| Not published | Square footage, client count, certifications, named carriers and named retailer compliance programs. Directory sites carry square footage figures that Bergen does not publish, so we are not repeating them |
A naming note: this is Bergen Shippers Corp. in North Bergen, New Jersey. It is unrelated to Norwegian companies carrying the name of the city of Bergen, and unrelated to other trucking firms operating out of Bergen County.
An inbound advice cannot be cancelled or replaced through the connection. Once a 943 has gone to Bergen there is no API method to void or amend it. The process is to contact Bergen, have them void it in their warehouse system, and then retransmit. If you raise inbound advices speculatively, that will cost you time. Raise them when the shipment is firm.
Cancelling a released pick ticket is a manual step. Same shape of problem, same answer: it is a conversation with the warehouse rather than a button in AIMS360. That is true of most warehouses on our list.
The 947 and 846 are not part of this connection. Inventory adjustments and periodic inventory snapshots run on some of our other warehouse connections but not this one, so scheduled position to position reconciliation is something you arrange with Bergen directly rather than something the integration performs.
No. AIMS360 performs the retailer EDI itself, so the 850 comes in and the 855, 856 and 810 go back on the retailer's routing guide spec regardless of what the warehouse can do. The warehouse connection is separate and runs on whatever that warehouse supports: REST API, CSV, tab delimited files, XML, flat files, or genuine X12 if they have it. Bergen Logistics is the clearest example, exchanging no X12 at all while the retailer still receives a conformant advance ship notice.
Yes, and it is live. Ship orders go out and shipment confirmations come back over a REST API, while inbound advice goes out and receipts come back as CSV files over SFTP. The shipment confirmation carries carton level detail including the SSCC on each carton, which is what AIMS360 uses to generate the retailer 856.
The 856 is a nested structure: shipment, then order, then carton, then item. It cannot be assembled from a shipped quantity. The warehouse has to return which units are in which carton along with the SSCC that appears on the physical GS1-128 label, and the ERP has to consume that structure and map it to the retailer's spec. Bergen returns carton level SSCC detail on the shipment confirmation and AIMS360 builds the notice from it, so the code the retailer's dock scans matches the code in the electronic notice.
Not "do you support ASN", because the answer is always yes. Ask what carton level detail comes back on shipment confirmation, whether it includes the SSCC, and whether it is returned per carton rather than per order. A warehouse that returns only a shipped quantity cannot support a compliant notice however good your ERP is, and that is the gap that produces receiving discrepancies and chargebacks months after go live.
They move to a ghost location rather than being written off or left in sellable stock. The unit stops being available to allocate, so you are not selling goods that cannot ship, and it stays visible in the record, so damages remain a number you can act on rather than shrinkage discovered at the next count.
Not through the connection. There is no API method to void or replace an inbound advice once it has gone across. The process is to contact Bergen, have them void it in their warehouse system, and retransmit. The practical advice is to raise inbound advices when a shipment is firm rather than speculatively.
They publish 18 locations across North America, Europe, Asia and Latin America, plus freight forwarding with customs clearance and bonded warehousing for duty deferment. In AIMS360 each facility is simply another warehouse on the same stock record, so inventory templates decide what each location can sell and routing decides where an order ships from. Adding a country is adding a location, not adding a system.
Bring a retailer order and a routing guide. We will send the ship order, take the carton detail back, and show you the advance ship notice it produces with the SSCC codes matching the labels.
