When a company decides to build EDI in-house, the decision usually starts and ends with IT. IT assesses the technical feasibility, estimates the build cost, and brings a recommendation; operations is consulted briefly; and finance approves or denies the budget.
However, the information IT has access to covers the technical side of the decision. It doesn't cover the compliance obligations that operations owns, the chargeback exposure that finance manages, or the staffing continuity risks. Those dimensions surface in production, usually at a cost no one budgeted for.
"The tools are great,” said Eric Shelton, a supply chain strategist at SPS Commerce. “The automation capabilities that are out there are great. But if your teams can't or don't know how to leverage them or use them, you're not really any better off.”
This article gives IT, operations, and finance a shared set of questions to work through before a build decision is made, to better understand how to leverage these tools.
Questions To Answer Before You Build
These aren't purely technical questions, and working through them is due diligence in making a build versus buy decision. A build decision made with full cross-functional input is stronger and more defensible than one made on technical assessment alone.
Which retailers are you trading with today, and which do you realistically expect to add in the next 24 months?
Each retailer has its own EDI requirements, such as transaction sets, segment qualifiers, timing windows, and testing protocols. A build tuned for your current trading partners will often require significant rework when a new retailer comes online. Operations typically has the clearest view of where retailer growth is likely. IT needs that input before scoping the build.
Who owns compliance monitoring, and what does the exception-handling process look like when a transaction fails?
This question sits at the IT/operations boundary. A build that generates errors without a defined escalation path creates downstream problems. IT can build the error notification, but operations needs to own the response process. If that ownership isn'testablished before the build, it gets established reactively, after the first failure has already cost something.
What is your current chargeback rate, and what does finance consider acceptable exposure?
Chargebacks tied to EDI non-compliance (late ASNs, missing segments, timing errors, etc.) are a direct cost of gaps in the EDI layer. Finance often doesn't know the current chargeback rate in detail; operations may not know what threshold finance has implicitly accepted. Getting both teams in the same conversation before a build reveals whether current exposure is a problem the build needs to solve, or one it might make worse.
What’s more is that all three teams may not even think of EDI as connected to chargebacks and deductions. Unless there is a cross-functional team dedicated to revenue loss, there won’t be the full visibility into the financial risk that there should be.
Have you modeled what a single retailer's chargeback cycle looks like if your EDI system goes down for 48 hours?
In-house builds require internal maintenance windows, internal incident response, and internal recovery. Downtime maps to specific retailers, specific transaction volumes, and specific chargeback risk. Finance should understand that model before the build decision is made.
If the primary person who builds and maintains this system leaves, what is the transition plan?
In-house EDI systems tend to become highly personalized, built by one developer or a small team whose understanding of the implementation lives largely in their heads. This is a staffing continuity risk that rarely surfaces in the original build estimate.
Having detailed documentation on the build that is accessible throughout the org is essential for maintaining a build solution for the future.
Does your current team have EDI-specific expertise, or will you be developing it during the build?
Building EDI expertise while simultaneously building EDI infrastructure is slow and expensive. The learning curve for EDI standards, retailer-specific requirements, and exception-handling logic is difficult. IT estimates are often built on general development capacity, not EDI-specific capacity. Operations needs to flag any compliance deadline that makes that learning curve a business risk.
A network-intelligent, managed EDI solution sidesteps this entirely: The retailer-specific expertise is already built in, so your team isn't developing it from scratch while the clock is running.
Are any of your retailer relationships subject to EDI compliance thresholds that affect your vendor scorecard?
Some retailers tie EDI compliance performance to vendor scorecard metrics that affect shelf placement, order volume, and preferred vendor status. Sales and account management typically have this information. If a build delay or coverage gap affects scorecard performance, the cost extends well beyond chargebacks.
What is the realistic onboarding timeline for a new retailer on your in-house system, and what is the revenue cost of that timeline compared to alternatives?
Retailer EDI onboarding involves testing protocols, certification requirements, and specific go-live windows. The relevant question is whether an in-house build can eventually support a new retailer, and whether it can do so within the window that relationship requires. Operations and sales know that window. Finance should see the cost of missing it.
What does the build estimate include and what does it not include?
Initial build estimates typically cover development time, infrastructure, and integration. They often don't cover ongoing maintenance, compliance updates when retailers change their requirements, internal testing for each new trading partner, or the staff time required to manage exceptions.
What is the cost comparison point, and is it like-for-like?
Build-vs.-buy comparisons often measure the build cost against a managed solution's licensing fee, without accounting for the operational and staffing costs a managed solution absorbs. The comparison is only meaningful if it accounts for the full cost of internal ownership.
How will you ensure data integrity if the EDI logic operates outside of your ERP?
When EDI processing happens in a system that doesn't share a data model with your ERP, reconciliation becomes a manual or semi-manual process. Discrepancies between EDI transaction records and ERP data create downstream problems ininvoicing, fulfillment, and financial reporting.
Does the build include native support for required communication protocols like AS2, or are those being addressed through third-party solutions?
AS2 is the standard secure transport protocol for EDI with most major retailers. If native AS2 support isn't part of the build, the gap typically gets filled by a third-party solution, which adds cost and a further point of failure.
Will your system catch structural formatting errors before they are sent, or will you find out through a compliance fine?
Pre-transmission validation is the difference between catching a problem internally and having a retailer catch it for you. And that difference is expensive, since retailers charge back the cost of your formatting errors. A build without robust pre-send validation shifts that cost onto operations and finance, often invisibly until the chargeback cycle runs.
Do you have a plan for a shadow mode testing environment to validate mapping logic against real partner data without risking live transactions?
Shadow mode testing (i.e., running new or updated EDI logic in parallel against real transaction data before going live) is the most reliable way to catch mapping errors before they become compliance failures. It requires deliberate build investment and isn't always included in initial scoping.
Not Ready To Build? There’s Another Way
If your teams can't align on the answers to these questions (or if the answers reveal more risk than the build estimate accounted for) a managed EDI solution may be your company’s best bet.
SPS Commerce Fulfillment handles the retailer-specific mapping, compliance monitoring, and protocol support that make in-house builds expensive to maintain at scale. For companies trading with more than a handful of retailers (or expecting to grow) an in-house system tends to cost more to maintain than the money saved.
