Why Does Connecting a New Business Partner Take So Long?

A new partner’s IT team sends your IT team a list: your server’s public IP address, a public key, file-naming requirements, and the name of someone authorised to sign a security agreement.

None of these requirements is unusual. But the next partner will send a different list, with different requirements and a different process.

These requirements are documented in real partner onboarding guides.

The ASX SFTP External User Guide requires 2048-bit SSH-2 RSA keys and a public IP address. It also specifies separate account policies, including deactivation after 90 days of inactivity and deletion after 12 months. Health Net’s SFTP setup guide describes a process in which a blank test file is sent to the partner and returned using an assigned naming convention. CalPERS’ SFTP onboarding guide takes partners through 13 steps involving six named CalPERS teams and departments. Its guide does not specify a completion time, but warns that requests may be postponed if files are not correctly formatted and tested.

The details differ. The underlying questions are remarkably similar.

What does every new partner need to establish?

The wording changes from one partner to another, but five areas need to be covered.

1. What does the file look like?

Partners need to agree on file formats, structures, naming conventions and other requirements. CalPERS, for example, provides partners with the schema for its XML files. Health Net requires files to use an assigned naming prefix.

2. Who is allowed to connect?

Both sides need to establish identity and trust. This may involve SSH keys, certificates and fingerprints, with sensitive details verified through a separate communication channel.

3. Where does the connection take place?

The technical setup may require public IP addresses, ports and firewall rules on both sides.

4. How do both sides know the connection works?

Testing can involve exchanging sample files, checking the return transfer and using separate credentials or keys for the test environment.

5. Who handles problems?

The partners need technical contacts, escalation procedures and clear rules for account management. ASX, for example, deactivates accounts after 90 days of inactivity and deletes them after 12 months.

These are not exceptional requirements. They are recurring parts of establishing a secure file exchange with a new business partner.

Why does every partner become a project of its own?

Because the answers often arrive one partner at a time, in different formats and through separate email conversations.

Someone on the IT team has to collect the information, enter it into a configuration, test the connection, resolve issues and repeat the checks. If the details are stored only in an email thread or in an engineer’s memory, the next partner often means starting the process again.

TrueCommerce describes a similar challenge in EDI onboarding: one-off configurations, limited reuse of earlier work, and coordination between multiple parties. Its article also highlights that configuring one side does not mean both sides are ready.

The result is a process in which every new connection requires coordination, even when many of the technical questions have already been answered for previous partners.

What does that cost?

A new partner may already have signed an agreement and agreed on a start date. But from the IT team’s perspective, that partner is still a ticket waiting to be completed.

The gap between the commercial agreement and the first successful file exchange is time during which the partnership cannot operate as planned.

Cleo’s guide to EDI trading partner onboarding cites its 2023 State of Ecosystem Integration report: 44% of respondents said onboarding a new trading partner takes between one week and one month, while 16% said it takes more than a month.

TrueCommerce also reports that EDI mapping historically took seven to ten days per partner. This refers to mapping work, not the entire partner onboarding process.

Both figures come from companies that sell integration products, so they should be treated as industry indications rather than independent benchmarks. The actual time will depend on the systems, partner requirements and complexity of the connection.

A more useful starting point is your own experience.

Take the last five partner connections. Record the date each agreement was signed, the date the first real file was exchanged, and how many people were involved along the way. Look at the time spent waiting for information, configuration changes, testing and corrections.

This gives you a practical picture of how long partner onboarding really takes in your organisation.

What changes when the process becomes standardised?

The recurring questions become part of a repeatable process, and partner-specific details are stored in a consistent format.

Start by collecting the same essential information from every partner and keeping it in one place. This is a process recommendation, not a built-in Xferity onboarding form. The aim is to avoid searching through old email threads every time a new connection is needed.

The technical configuration can then follow a consistent structure.

In Xferity, each partner is described through a reusable YAML configuration file that defines the remote endpoint, including its protocol, connection details, authentication and trust settings. The same approach supports SFTP, FTPS, AS2, S3-compatible storage, WebDAV and Azure Blob. See the Xferity Partner Reference for the supported configuration fields.

This separates the partner’s connection details from the schedules and transfer behaviour that determine when and how files move. More detail is available in the Xferity overview documentation.

The configuration can also be checked before a transfer takes place. Xferity uses strict configuration parsing to identify misspelled or unsupported fields. Its validate command checks the configuration, while diag helps identify endpoint, key, certificate and filesystem problems before a flow runs. For AS2 connections, diagnostics can also test endpoint connectivity and certificate bindings. A flow can be run with —dry-run to check its configuration before production use. These capabilities are described in the Xferity CLI reference and AS2 partner exchange tutorial.

Security and transfer restrictions can be defined for each partner as well. For example, an SFTP configuration can include the partner’s host key fingerprint, while AS2 configurations support certificate roles for signing, encryption and verification. Partner-specific policies can also define maximum file sizes and permitted file extensions.

This does not remove the need to coordinate with a partner, wait for firewall changes or obtain security approvals. Those steps still depend on people on both sides.

What changes is the technical work that your own team has to repeat. Instead of rebuilding each connection from scratch, it can start with a known configuration structure and a consistent set of checks.

So, why does connecting a new business partner take so long?

Because the same technical questions are often handled as a new project every time.

Time is spent collecting information, waiting for responses, configuring connections and repeating tests. A standard approach makes much of that technical work reusable and easier to verify.

Xferity supports this approach by giving each partner a structured configuration and providing tools to validate and diagnose connections before real files are exchanged.

The partner still needs to provide the answers. But your team does not have to start from an empty configuration every time.

If your last partner connection started again tomorrow, which of the five answers would your team still have to request by email?