Onboarding a Trading Partner: The Technical Checklist

The kickoff email always sounds simple: "Great news — we've signed with Northwind. They need EDI connectivity live in six weeks. IT is on the thread." Behind that sentence sits a project with two companies, a dozen exchanged details, certificates, firewall tickets, test files, and a go-live date that the business has already promised. Onboarding a trading partner — an external company you will exchange business documents with — is the moment all the theory in this pillar becomes a deadline.

The good news: onboarding is the same project every time. The steps do not change, the information to exchange is knowable in advance, and the failures are the same handful of predictable snags. This article turns that repetition into a reusable checklist — the connectivity details both sides must trade, a test-file protocol that catches problems before production does, explicit go-live criteria, the runbook to write when it works, and the offboarding step almost everyone forgets. It is part of our AS2 & B2B Exchange series and assumes the background from EDI basics for admins, whose three-layer model this project walks through in real life.

The Shape of Every Onboarding

Whatever the partner or industry, the project has the same phases, and knowing them lets you schedule realistically from day one:

1. Specs and decisions — read the partner's requirements, agree the transport and document types.
2. Connectivity exchange — trade the technical details: identifiers, URLs or hostnames, certificates or keys, schedules.
3. Access plumbing — accounts, firewall rules, certificate loading, monitoring hooks.
4. Testing — a deliberate ladder of test exchanges, from "can we connect" to "full documents parse both ways."
5. Go-live — a gated cutover with a watch period.
6. Documentation — the partner runbook that future-you will thank present-you for.

Three roles share the work. You own the transport layer — connectivity, credentials, certificates, schedules. An EDI analyst (possibly also you, in a small shop) owns document formats and translator maps — EDI being Electronic Data Interchange, the standardized formats those business documents travel in. A business owner answers commercial questions and signs off go-live. Sorting every incoming question into one of those three buckets keeps a six-week project from becoming a twelve-week argument.

One decision shapes everything after it: the transport. Large partners usually dictate — often AS2 (Applicability Statement 2: signed, encrypted document exchange over web transport with MDN receipts — Message Disposition Notifications) — while smaller partnerships often agree on SFTP (the SSH File Transfer Protocol: scheduled pushes and pulls against a hosted server). If the choice is genuinely open, work through AS2 vs SFTP for partner exchange before the kickoff call, because reversing it mid-project restarts the clock.

Step 1: Read the Spec Before the First Call

Most sizable partners send an implementation guide or connection packet. Read it before the kickoff call, highlighter in hand, and extract five things:

• Transport requirements — protocol, security options, whether they require you to host anything, source-address restrictions.
• Document types and directions — which documents flow in, which out, and which acknowledgments are mandatory with what deadlines.
• Environments — nearly every serious partner runs separate test and production systems with different endpoints, identifiers, and certificates. Assume both exist and plan to configure both.
• Volumes and windows — how many documents, how large, delivered when. Batch cutoff times become your schedule constraints.
• Compliance teeth — deadlines with penalties attached (late shipping notices are the classic). These determine where your monitoring must be sharpest.

Arrive at the kickoff with your open questions written down. The partner's onboarding team runs dozens of these projects in parallel; the companies that come prepared get the fast lane.

Step 2: The Connectivity Exchange

This is the heart of onboarding: two companies trading the details that let their systems talk. Collecting them piecemeal across email threads is how projects stall — one thread per detail, each waiting on someone. Instead, exchange them in one structured pass. The checklist below is the template this article exists to give you; copy it into your ticket system and fill every line, once per partner, once per environment.

PARTNER ONBOARDING - CONNECTIVITY CHECKLIST   (one per partner, per environment)

GENERAL
[ ] Partner name + our internal partner code:  ______________________
[ ] Business owner (ours):  _____________  EDI/map owner:  __________
[ ] Partner technical contact + escalation phone:  __________________
[ ] Transport agreed:  AS2 / SFTP / other:  _________________________
[ ] Environment this sheet covers:  test / production
[ ] Document types + directions (e.g. orders in, invoices out): _____
[ ] Expected volumes, sizes, batch windows, deadlines:  _____________
[ ] Acknowledgment rules (transport receipt? functional ack?): ______

IF AS2
[ ] Our AS2 ID:  ______________  Their AS2 ID:  _____________________
    (exact spelling and case - both sides confirm in writing)
[ ] Their inbound URL + port:  ______________________________________
[ ] Our inbound URL + port:  ________________________________________
[ ] MDN mode: sync / async     Async return URL:  ___________________
[ ] Signing required?  algorithm:  __________________________________
[ ] Encryption required?  algorithm:  _______________________________
[ ] Public certificates exchanged BOTH ways:  _______________________
[ ] Fingerprints verified over a second channel:  ___________________
[ ] Expiry dates entered in certificate register + renewal calendar
[ ] Firewall rules opened both sides (list source addresses): _______

IF SFTP
[ ] Host side:  ours / theirs
[ ] Hostname + port:  _______________________________________________
[ ] Account name; auth method: password / key  ______________________
[ ] Keys or passwords exchanged securely + verified:  _______________
[ ] Folder layout (inbound / outbound / archive):  __________________
[ ] File naming convention:  ________________________________________
[ ] Upload-complete convention (temp name + rename, or done-file)
[ ] File-level encryption required? (e.g. OpenPGP) keys exchanged: __
[ ] Pickup/drop schedule both sides + cutoff times:  ________________

SIGN-OFF
[ ] Both sides confirm every line above in writing:  date ___________

Two lines deserve commentary. The AS2 identifiers line insists on exact spelling and case because identifier mismatch is the most common day-one failure — the receiving station matches the header text exactly against its partner profile, and NorthWind is a stranger to a profile that says NORTHWIND. And the SFTP upload-complete convention line prevents the classic race where one side's scheduled pickup grabs a file the other side is still writing; uploading under a temporary name and renaming on completion (or dropping a small "done" marker file) makes partial pickups impossible.

Step 3: Certificates, Credentials, and Firewalls

With the sheet filled, do the plumbing — starting with the items that have the longest lead times, because they gate everything else.

• Firewall changes first. If either side restricts by source address, corporate firewall tickets can take longer than every other step combined. File them the day addresses are known.
• Certificates, verified and registered. For AS2, exchange public certificates and verify each one's fingerprint (the short identifying hash) over a second channel before trusting it. Then — before anything else happens — record every expiry date in your certificate register and renewal calendar. Onboarding day is when the certificate lifecycle clock starts ticking; partnerships that skip this step are scheduling their own future outage.
• Per-partner accounts, least privilege. When you host the SFTP side, create a dedicated account per partner, confined to its own folder tree, with only the permissions the flow needs — a partner that drops files needs write on its inbound folder, not a wander of your filesystem. On a Windows server such as Sysax Multi Server this is ordinary user setup: a per-partner account, its home folder, and activity logging switched on so every login and transfer is recorded from day one.
• Schedules configured but disabled. Build the scheduled jobs that will run the flow — pickups, drops, sweeps to the translator — and leave them switched off until testing says otherwise. A folder-monitoring scheduler like Sysax FTP Automation can sit watching the outbound folder and push each batch on the agreed timetable with retries; configuring it now, during onboarding calm, beats configuring it during go-live week.

Step 4: The Test-File Protocol

Never test by "send something and see." Run a ladder, one rung at a time, in the partner's test environment, and record evidence at every rung — dates, message identifiers, receipts. The ladder isolates failures: each rung adds exactly one new thing that can break, so a failure names its own cause.

1. Reachability. Can each side reach the other's endpoint at all? A connection attempt that fails here is pure network — addresses, ports, firewall rules — before any protocol complexity enters.
2. Transport-level test file. Send a small arbitrary file through the full transport machinery. For AS2: signed, encrypted, and answered by a clean signed MDN in the agreed mode. For SFTP: uploaded, renamed per the convention, visible to the other side, picked up on schedule. This rung proves identifiers, certificates or keys, and folder permissions.
3. Structured test document. Send a real document type — a test purchase order, flagged as test data inside its envelope (EDI envelopes carry a test indicator for exactly this purpose). This rung proves the translator maps parse what actually arrives, and it is where the EDI analyst joins the loop.
4. Acknowledgment round trip. Confirm the document-level acknowledgments flow back and reconcile — transport receipts pair with messages, functional acknowledgments pair with documents. Testing the receipt path now is what makes "missing acknowledgment" alarms trustworthy later.
5. Volume and size rehearsal. If production will move large files or large batches, rehearse at that scale. Timeouts and size limits only reveal themselves under load — better in test week than in the first month-end rush.
6. One deliberate failure. The rung everyone skips and the one that pays best: break something on purpose — send during a window when the partner endpoint is down, or drop a malformed document in test — and verify your monitoring actually alarms and your retry behaves. A failure drill in test is the only proof your safety net exists.

Step 5: Go-Live Criteria — the Gate

Go-live should be a gate with written criteria, not a mood. When the business asks "can we switch on Monday?", the answer is a checklist read, not an opinion:

• Every line of the connectivity checklist confirmed in writing by both sides, for production.
• The full test ladder passed in both directions, evidence filed.
• Certificates registered, renewal calendar entries created, expiries comfortably far out.
• Monitoring live: alerts on failed sends, missing receipts, and silent schedules — routed to a mailbox humans read.
• Contacts and escalation paths for both companies written into the runbook.
• A resend/recovery procedure agreed: how each side re-drives a failed document, and who calls whom.
• Business sign-off, a go-live date, and a hypercare window — an agreed first period (typically the first full business cycle) during which someone reviews every exchange daily on purpose.

During hypercare, watch the first occurrence of everything: the first real document each direction, the first batch window, the first month-end if volumes spike then. Most latent onboarding defects surface within one full business cycle; watching for them deliberately turns each into a quiet fix instead of a partner escalation. When hypercare ends without surprises, say so in writing to both companies — a short "partnership stable, moving to normal operations" note closes the project cleanly and marks the moment responsibility shifts from the project to the runbook.

Step 6: Write the Partner Runbook

The project is not done when documents flow; it is done when someone who was not on the project can operate the partnership. That is the partner runbook — one document per partner, in the team's shared documentation, holding: the completed connectivity checklist; where the certificates live and when they expire (pointing at the register); the schedules and their cutoffs; the document flows in plain words ("orders arrive from them by 6 a.m., invoices leave nightly"); both companies' contacts and escalation paths; the resend procedure; and a running log of incidents and quirks ("their test endpoint rejects files over 50 MB — confirmed with their support"). When the 2 a.m. failure eventually comes, the runbook is the difference between a ten-minute fix and an archaeology dig — and it is the first thing troubleshooting AS2 assumes you have.

Offboarding: the Forgotten Half of the Lifecycle

Contracts end. Partners merge, businesses change suppliers, and one day the flow that took six weeks to build needs to stop — cleanly. Untended, dead partnerships rot into security findings: orphaned accounts that still accept logins, firewall holes to companies you no longer trade with, certificates trusted for no reason, schedules faithfully sweeping empty folders forever. Offboard with the same discipline you onboarded:

• Agree the last-document date with the business and the partner, and reconcile final counts — every document sent, received, and acknowledged.
• Disable, then remove, access: partner accounts, firewall rules, stored keys. Disable first and watch briefly (something always turns out to still be using the path), then delete.
• Retire certificates from active use — remove them from partner profiles, but archive them, because verifying old signatures and receipts during a later dispute may need them.
• Keep the evidence, not the plumbing. Archived messages, receipts, and logs follow your retention rules; live connectivity does not.
• Stop the schedules and silence the monitoring deliberately, so nobody gets paged about a partnership that is supposed to be silent.
• Mark the runbook and register entries offboarded with the date — do not delete them. "Why does this account exist?" should always have a written answer, including "it doesn't anymore, as of this date."

The Checklist Habit

Onboarding rewards boring consistency. The same sheet every time, the same ladder every time, the same gate every time — and each new partner takes less effort than the last, because the template absorbs the lessons. Keep the connectivity checklist current as the partnership evolves, run the renewal calendar it feeds, and when something does break at 2 a.m., the runbook and the troubleshooting guide pick up where the checklist left off. For choosing the transport before any of this begins, the decision framework is in AS2 vs SFTP for partner exchange.

Frequently Asked Questions