Selling a logistics software company in Canada

An owner who has decided to sell a logistics software company can prepare for two things a buyer’s technical team may ask about: a list of every connection the platform keeps with carriers and trading partners, and a history of the times it failed while freight was moving. Neither may be written down in a form a stranger can read. Preparing them first is a sensible start. This guide runs in an order that preparation, disclosure and handover can follow, and flags where logistics platforms differ from other software sales.

Write the integration register first

List each carrier and EDI connection with its protocol, the customers that use it, recent transaction volume, the date it was last tested end to end, the person who maintains it and the account under which its credentials are held. Mark the connections with no recent traffic and decide whether to retire them before listing or to disclose them as maintenance liabilities. Record known problems too, such as a carrier that has announced a format change you have not yet built. A register that shows its own weak spots can be more credible than one that appears flawless, and it can spare the buyer’s engineers reverse-engineering work during diligence.

Put credentials and trading identities in the company’s name

Carrier API accounts, EDI network or mailbox subscriptions, the trading-partner identifiers carriers have issued and any licensed map or rate data can sit under the name of whoever set them up, such as the founder or an early developer. Moving them during diligence can look like a defect even when it is harmless, and some counterparties may want to confirm the change before accepting it. Move what you can now and note which counterparties must be told at closing. The same tidying applies to code: connectors written by contractors need a signed written assignment, because the Copyright Act makes an assignment invalid unless it is in writing and signed by the owner or the owner’s duly authorized agent.

Prepare the incident and breach record yourself

A buyer can read the status page, the support queue and any post-incident write-ups. Assemble these yourself: each outage that fell inside a live shipment window, which customers were affected, what was credited or conceded, and what changed afterwards. Alongside it, find your privacy breach record. The Office of the Privacy Commissioner says PIPEDA requires an organization to keep records of all breaches of security safeguards, regardless of whether they present a real risk of significant harm, and a buyer may ask to see yours. A missing record is a finding in its own right.

Decide what shipment data a buyer may see

Shipment records can name consignees and drivers, so showing live data to a bidder is a privacy question as well as a commercial one. Under section 7.2 of PIPEDA, parties to a prospective business transaction may use and disclose personal information without the individual’s knowledge or consent if the organizations have entered into an agreement that requires the recipient to use and disclose it solely for purposes related to the transaction, to protect it with security safeguards appropriate to its sensitivity and, if the transaction does not proceed, to return it to the organization that disclosed it or destroy it within a reasonable time, and the information is necessary to determine whether to proceed and, if so, to complete the transaction. Section 7.2(4) says this does not apply to a transaction whose primary purpose or result is the purchase, sale or other acquisition or disposition, or lease, of personal information. A seller can sidestep part of the problem by offering aggregated, de-identified volumes and releasing detail late. Quebec’s Law 25 adds its own provisions, so involve counsel where Quebec customers appear in the data. Our answer on privacy obligations when a tech company is sold goes further.

A sequence a sale can follow

1. Finish the integration register and incident record, and retire or disclose the dead connections.
2. Review customer contracts for assignment, change-of-control, service-level and data-retention terms, and approach key customers about consent only as far as confidentiality allows.
3. Sign a confidentiality agreement before technical detail is shared, and withhold customer names until late.
4. Agree a letter of intent, then host the buyer’s technical review, which can include live testing against carriers.
5. Fix the cutover date outside the busiest shipping periods and name who is on call during the switch.
6. Close, then run the carrier revalidations and customer notices.

What can delay a close

Delays can come from handover mechanics as well as from price. Check whether each carrier and EDI connection will need technical revalidation, notice or consent when the owner changes, and ask each carrier how long that takes. Customer contracts that require consent to assign can become closing conditions, and a customer that competes with the buyer may use that leverage. See whether customer contracts are transferable for how those clauses work. A buyer may want you reachable afterwards. BDC says that for a seller who wants a smooth transition so the business carries on, there is a benefit in staying involved, such as through vendor financing, an earn-out or a phased transfer of ownership, and that an accountant can help prepare the financial statements and projections buyers ask to see. The general process is covered in selling a software business.