Why we integrate with CargoWise instead of replacing it

There is a temptation, building shipper-side software, to draw a line through the forwarder's system and promise to replace it. We do not. CargoWise is the forwarder's system of record, and that is a position it earns. The shipper's problem and the forwarder's problem are different problems, and the boundary between them is where a lot of value is lost.

What CargoWise is good at

A forwarder runs jobs, consolidations, documentation, customs and invoicing. CargoWise is built precisely around that back office, and it is deep where depth matters: the operational paperwork of carrying other people's cargo across borders. Rebuilding it would be a multi-year effort aimed at the wrong user, and the forwarder would still be the one who has to live in the result.

What a shipper actually needs

The shipper does not run the forwarder's job. The shipper owns the PO, the supplier relationship and the routing rules the retailer imposed. Its questions are narrow and specific: which PO lines are in which carton, will the ASN pass, where is the exception, and can I prove origin at the line. None of those live naturally in a forwarder's back office, because none of them are the forwarder's to answer.

The boundary, not the middle

The right interface is the boundary. Shipeezi holds the PO-to-carton execution and the pre-ship checks, hands the operational job to CargoWise, and takes status back on the same event spine. The forwarder keeps working in the system it knows. The shipper gets an answer at carton grain. Neither side rebuilds the other, and neither side has to pretend to be the other.

Why not just fold everything into one system

Because the two systems answer to different owners. A forwarder optimises its own operations across many clients. A shipper optimises one supply chain and its retailer compliance. Forcing them into one model means one of the two gets a system that fits the other. Keeping them at the boundary lets each be good at its own job, connected by a clean, narrow contract.

What the integration looks like

At the technical level it is events and references, not a merge. A booking and its cartons cross into the forwarder's world as a job. Milestones and documents come back normalised onto the leg. The carton trace never leaves the shipper's record, so the shipper can still answer the DC's questions even while the forwarder owns the operational leg. That is the whole point of drawing the boundary in the right place: the customer keeps the trace, the forwarder keeps the operation, and the two meet at a seam instead of colliding in the middle.

What stays with the shipper, and why

The PO, the supplier relationship, the routing guide and the carton record stay with the shipper because they are the shipper's assets. The forwarder never needed them to run a job, and the shipper cannot afford to lose sight of them. The boundary is not a technical convenience. It is a statement about who owns which decision, and drawing it there is what keeps the integration stable as both sides evolve.

The chargeback argument for the boundary

There is a commercial reason too. A chargeback is answered with the carton record and the pre-ship checks, which are the shipper's data. If that data lives inside the forwarder's back office, the shipper cannot see it in time to prevent the fine. Keeping execution with the shipper and operation with the forwarder means the party who wears the chargeback is the party holding the controls that prevent it.