Most EDI implementation projects fail the same way, and it happens in week one.
The team opens the partner's specification and starts mapping documents. Six weeks later they discover nobody agreed how products would be identified, or the catalog was never properly loaded, and half the work unwinds.
Document mapping is phase four. This EDI implementation checklist puts it there, and covers the three phases that have to happen first.
Work through it in order. Each phase has a clear finish line, and you should not start the next one until you have crossed it.
Sequence is the whole point of this checklist. Each phase produces something the next one depends on, which is why working out of order is the most reliable way to lose a month.
The rule for using it: do not start a phase until the previous one has crossed its finish line. Those finish lines are stated explicitly at the end of each phase, and they are deliberately concrete, because "mostly done" is how foundational gaps survive into testing.

This phase costs nothing and prevents the most expensive mistakes.
✅ List every trading partner and what they can technically support.
Enterprise distributor on file transfer, mid-size brand on a storefront, small vendor with a spreadsheet. You are mapping capability, not intent.
✅ Name one internal owner.
Not a committee. Someone accountable for the timeline who can make decisions about field mapping without escalating.
✅ Agree how every product will be referenced.
This is the single most important item on this EDI checklist. Every variant needs one unique, stable code both sides recognize, whether that is a barcode, an internal variant code, or a SKU. Mismatched identifiers are the most common cause of failed documents.
✅ Confirm which documents each partner requires.
Four is the usual minimum: stock update, purchase order, acknowledgement, ship notice. Check whether invoicing is expected or generated automatically.
✅ Decide who watches the exception queue after go-live.
Almost always forgotten at scoping, and the role that matters most at month three.
✅ Set a realistic timeline.
Anyone promising a week has not accounted for testing.
Finish line: Write the product identification scheme down and get both sides to confirm it in writing. If you cannot, do not proceed.
Now the plumbing.
✅ Choose and set up the connection.
On Carro this is SFTP, either hosted by Carro or on your own server. Self-hosted setups need a single static IP whitelisted, which Carro provides during setup.
✅ Generate or exchange credentials.
Carro generates SFTP credentials inside the app under integration settings.
✅ Confirm the folder structure.
Suppliers place outgoing files in one directory and collect incoming files from another. Know which is which before you send anything.
✅ Set the file extensions you will use.
Carro accepts .x12, .edi, .dat, and .txt by default, and other extensions can be configured.
✅ Configure sender and receiver identifiers.
Each side needs an identifier and a qualifier. Carro's testing identity uses qualifier 01 with identifier 117522184. Production identifiers depend on the partner configuration.
✅ Confirm character encoding and timezone.
Carro's servers operate on UTC, which matters for every date and time field you will send.
✅ Check whether batching is permitted.
Carro accepts one document per file, so if your system currently bundles transactions, that needs adjusting before testing.
Finish line: Place a file in the outgoing folder and confirm it is collected. Nothing further works until this does.
Skipped or rushed more often than any other phase, and the cause of most late-stage surprises.
✅ Load your product data.
Carro seeds catalogs by CSV with template mapping, or by API. A file matching the template submits automatically.
✅ Allow time for the initial sync.
This can take up to two hours. Do not schedule a demo an hour after uploading.
✅ Verify every variant carries its unique identifier.
The one you agreed in phase one. Check it rather than assuming it.
✅ Configure addresses.
Ship-from and billing details need to be correct before orders flow.
✅ Choose your invoicing method.
Carro generates invoices automatically once a ship notice is accepted, with payouts through Stripe. If you prefer manual invoicing, configure that per partnership now rather than later.
✅ Build your price list.
Set the margin, then assign the list to each partner. Commercial terms live here, separate from the integration, which means changing a margin later never requires engineering time.
✅ Activate your products.
Only active, priced products become visible to partners. A product that seems missing is usually inactive or absent from a price list.
Finish line: Log in as the partner would and confirm they see the right products at the right prices.
Only now do you open the specification.
Work through each document in turn, deciding for every field where the data comes from. Four categories cover it: fields that map directly to core system data, fields carrying partner-visible information outside the core model, private fields used for troubleshooting, and constants that never change.
Alongside the field work, several decisions carry real business logic. Get these explicitly agreed rather than assumed.
✅ Snapshot or change-only stock updates:
A full snapshot zeroes out any variant not included in the file, which is accurate but unforgiving. A change-only update leaves omitted variants untouched. Confusing the two takes a catalog out of stock overnight.
✅ How rejections propagate.
Acknowledgements work at two levels: a document status and a per-line accepted or rejected flag. Confirm that a rejected line cancels cleanly rather than failing the whole order, and check whether partial orders are enabled in settings.
✅ Carrier identification.
Ship notices identify couriers by their standard carrier code. Make sure your system can produce it.
✅ Date and time formats.
Dates as YYYYMMDD, times on a 24-hour clock, all in UTC.
✅ Stock update frequency.
Carro recommends every five to fifteen minutes, and ignores any file dated earlier than the last one processed so inventory cannot roll backward.
Finish line: Every required field in every required document has a confirmed source.
The phase that earns this checklist its keep.
Test the stock update first.
✅ Send a stock update and confirm quantities changed as expected.
✅ Include a deliberate zero-out so you can see that omitted or zeroed variants behave the way you intended.
✅ Confirm that a file dated earlier than the last one processed is ignored.
Then run a sandbox order: Carro provides a test retailer identity so nothing touches a real customer.
✅ Create the test order and confirm the purchase order arrives in your incoming folder. Allow up to 30 minutes.
✅ Return an acknowledgement and confirm the line-level status propagates correctly.
✅ Send a ship notice and confirm a fulfillment is created with the correct courier and tracking number.
Then test the paths most teams skip: Carro's documentation prescribes three scenarios, and two of them involve things going wrong.
✅ One order fully accepted and fully fulfilled. The happy path.
✅ One order fully rejected. Confirms cancellation propagates properly.
✅ One order partially rejected and partially fulfilled. The realistic case, and the one that exposes whether your line-level logic actually works.
Go-live criteria: All three scenarios pass. Stock updates run on schedule. Someone owns the exception queue and knows where it lives. You have a rollback plan if the first live order misbehaves.
Timelines rarely slip for technical reasons. They slip for these.
Every cause in that table is preventable in phase one or two, which is why the front half of this checklist matters more than the technical half. None of them is a software problem, and none is solved by choosing a better vendor.
Running API and EDI integration side by side is normal in any network with partners at different levels of maturity, and the phases above mostly still apply.
Where they diverge: an API partner skips file transport, folder structure, and file extensions entirely, replacing them with authentication credentials and endpoint configuration. Where they converge: scoping, product identification, catalog loading, price lists, and testing are identical regardless of connection method.
Carro splits this by side. Suppliers connect by EDI over file transfer or by CSV upload. Retailers connect through native storefront integrations for Shopify, WooCommerce, BigCommerce, and Magento, or through the API with webhooks for events like inventory changes.
Everything resolves into one internal model, which is what lets your operations team treat an enterprise distributor and a small brand identically. For the deeper comparison of when each method fits, see our guide to EDI vs API.
Going live is a milestone, not a finish line. The first month determines whether the implementation holds, and each week has a different job.
Check the exception queue daily rather than weekly. Early failures cluster around edge cases nobody anticipated during scoping, and the pattern is far cheaper to catch now than in month three.
Confirm stock updates are arriving on their expected cadence rather than assuming they are. A feed that quietly stopped is the failure most likely to reach a customer before it reaches you.
Reconcile the first batch of settlements against what actually shipped. Automated invoicing on shipment confirmation removes month-end reconciliation, but confirm the numbers are right before you stop checking them.
Check the partner side too. A supplier who disputes their first payout will do it in week two, and resolving it while the shipment records are fresh is considerably easier than three months later.
Sample a handful of real orders end to end. Did tracking reach the customer, and how long after dispatch? Were partial rejections communicated cleanly, or did support have to intervene?
This is where operational success and customer experience either match or diverge. A system can be processing perfectly while customers still receive confusing status updates, and only sampling real orders surfaces that gap.
Write down what you learned about this partner's quirks while it is fresh. If partner two is coming, that document is your head start and turns a repeated discovery process into a checklist.
Confirm the exception queue owner is genuinely watching it and knows what each error type means. Then set a review at 90 days, because volume changes behavior and issues that never appear at fifty orders a week appear reliably at five hundred.
Most of this checklist exists because traditional EDI implementations are slow, sequential, and dependent on someone else's calendar.
Carro removes three of the phases that cause the delay:
1. There is no implementation team to wait for - account creation, credential generation, catalog upload with template mapping, and price list setup all happen in the app. You are not booking discovery calls or waiting for a mapping specialist to become available, which is why G2 reviewers report an average of one month to implement against three to four for the managed alternatives.
2. The sandbox is permanent and available immediately - a dedicated test retailer identity means you can round-trip a complete order, including full rejection and partial fulfillment, before a real customer exists. Phase five stops being a scheduling negotiation with a partner's EDI team.
3. One connection covers every partner, so phases one through four happen once - a supplier satisfying four document requirements is transactional with every retailer on the network, including partners they have not met yet. Adding retail partner eleven means a commercial conversation, not another run through this checklist.
Carro is built for retailers and marketplaces onboarding suppliers at pace, and for brands wanting retail distribution without a wholesale negotiation. Access to more than 1,500,000 products from vetted brands, hand-matched on category, audience, and price point, comes with the connection rather than after it.
As The FairGround described the onboarding experience: "I especially appreciated that they were flexible in supporting brands of all sizes, even those without technical experience."
Pricing starts at $149 per month with unlimited partnerships.
An EDI implementation checklist is a phased sequence of tasks that takes a trading partner connection from initial scoping to a first live order. A workable version has five phases: scoping partners and product identifiers, building the connection and credentials, loading catalog and pricing, mapping documents, then testing before go-live. The most common mistake is starting at document mapping, which belongs in phase four. Each phase should have a clear finish line before the next begins.
The most common mistake is failing to agree how products will be identified before starting technical work. Every variant needs one unique, stable reference that both sides recognize, whether a barcode, internal variant code, or SKU. When identifiers do not match, every document mentioning that product fails, and the problem surfaces late in testing when it is expensive to fix. The second most common mistake is testing only the happy path and meeting the first partner rejection in production.
Test three order scenarios before going live: one fully accepted and fulfilled, one fully rejected, and one partially rejected with partial fulfillment. Carro's documentation prescribes exactly these three, and the partial case is the one that exposes whether line-level logic works. Test your stock update separately, including a deliberate zero-out to confirm omitted variants behave as intended. Also verify that a file dated earlier than the last processed one is ignored rather than rolling inventory backward.
You need a developer for EDI software implementation if you are building direct partner connections or configuring a translator yourself, since document mapping and file generation are engineering work. You do not necessarily need one if you connect through a network handling mapping and connectivity, though something in your system still has to produce the files. Carro's supplier onboarding is self-serve, with catalog upload by CSV template, credentials generated in the app, and a sandbox for testing. Retailers connecting through Shopify, WooCommerce, BigCommerce, or Magento need no developer at all.
You can run API and EDI integration simultaneously, and most multi-supplier networks do. Partners with legacy systems exchange EDI files while modern partners connect through an API, with a translation layer normalizing both into one internal model. The implementation phases are largely shared, diverging only where file transport is replaced by authentication and endpoint configuration. Carro uses EDI or CSV on the supplier side and native storefront integrations, an API, and webhooks on the retailer side.
Implementations slip for organizational reasons far more often than technical ones. The usual causes are unclear decision ownership, product identifiers assumed rather than agreed in writing, catalogs that were not loaded and priced before testing was scheduled, and testing that covered only successful orders. Timezone assumptions and systems that batch multiple documents into one file also surface late. Every one of these is preventable during scoping and foundation.
Watch the exception queue daily rather than weekly in week one, since early failures cluster around edge cases and the pattern is cheapest to catch immediately. In week two, reconcile settlements against what actually shipped before you stop checking. In week three, sample real orders end to end to confirm tracking reached customers promptly and partial rejections were communicated cleanly. In week four, document the partner's quirks while they are fresh, then set a review at 90 days because volume changes behavior.